From peter.levart at gmail.com Tue Jan 1 12:53:17 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 01 Jan 2013 13:53:17 +0100 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> Message-ID: <50E2DC3D.9090104@gmail.com> Hi and happy new year, 2013! I don't know what the main purpose of "hashSeed" actually is. If it is to fight against predictable hashCode to bucket-index mappings, it does it's job somehow, but not very good. For example, it is very easy to predict the next hashSeed numbers that will be allocated: import sun.misc.Hashing; public class HashSeedCrack { private static final long multiplier = 0x5DEECE66DL; private static final long addend = 0xBL; private static final long mask = (1L << 48) - 1; static class Rnd { private long rnd; Rnd(long seed) { this.rnd = seed; } int nextInt() { rnd = (rnd * multiplier + addend) & mask; return (int) (rnd >>> 16); } } public static void main(String[] args) throws Exception { int r0 = Hashing.randomHashSeed(null); int r1 = Hashing.randomHashSeed(null); long s0 = ((long) r0 << 16) & mask; long s1 = ((long) r1 << 16) & mask; long mx = mask - ((1L << 16) - 1); Rnd rnd = null; for (int i = 0; i < 65536; i++) { long sx = s0 + i; if (((sx * multiplier + addend) & mx) == s1) { rnd = new Rnd(sx); int rx = rnd.nextInt(); assert rx == r1; break; } } assert rnd != null; System.out.println("Next HashMap.hashSeed will be: " + rnd.nextInt()); System.out.println("... and it is: " + Hashing.randomHashSeed(null)); } } For this purpuse, the Hashing.randomHashSeed() should not be publicly visible. If ThreadLocalRandom is to be used instead of a private instance of a java.util.Random(), then it would defeat the "secrecy" since ThreadLocalRandom.current() is a shared per-thread instance accessible to anyone. As far as standard ThreadLocalRandom is concerned, it's usability is impaired by it's design. It would be a better API if a plain ThreadUnsafeRandom with standard constructors was part of standard JDK API. ThreadLocal binding would then be a matter of each particular (possibly private) usage... Regards, Peter On 12/27/2012 08:38 PM, Aleksey Shipilev wrote: > Looks very like dumb inlined java.util.Random? > Is there a security threat to use ThreadLocalRandom instead there? > > -Aleksey. > > On 27.12.2012, at 23:16, Zhong Yu wrote: > >> Reported by the SO question >> >> http://stackoverflow.com/questions/14010906 >> >> the HashMap constructor contains a CAS, which is kind of surprising. >> Could it be removed? >> >> transient final int hashSeed = >> sun.misc.Hashing.randomHashSeed(this); // CAS >> >> Zhong Yu From eric.mccorkle at oracle.com Tue Jan 1 23:13:41 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 1 Jan 2013 18:13:41 -0500 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <50E2DC3D.9090104@gmail.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50E2DC3D.9090104@gmail.com> Message-ID: Was the original purpose security-oriented? It seemed to me that the purpose was to make performance pathologies less likely. Consider, for example, a bad hash function that maps ip addresses directly to their integer representation. If an application puts entire subnets into a map. All the addresses will go into contiguous buckets, which increases probability of a collision considerably. Adding in randomness helps to smooth over these sorts of pathologies. On Jan 1, 2013, at 7:53 AM, Peter Levart wrote: > Hi and happy new year, 2013! > > I don't know what the main purpose of "hashSeed" actually is. If it is to fight against predictable hashCode to bucket-index mappings, it does it's job somehow, but not very good. For example, it is very easy to predict the next hashSeed numbers that will be allocated: > > import sun.misc.Hashing; > > public class HashSeedCrack { > private static final long multiplier = 0x5DEECE66DL; > private static final long addend = 0xBL; > private static final long mask = (1L << 48) - 1; > > static class Rnd { > private long rnd; > > Rnd(long seed) { this.rnd = seed; } > > int nextInt() { > rnd = (rnd * multiplier + addend) & mask; > return (int) (rnd >>> 16); > } > } > > public static void main(String[] args) throws Exception { > int r0 = Hashing.randomHashSeed(null); > int r1 = Hashing.randomHashSeed(null); > > long s0 = ((long) r0 << 16) & mask; > long s1 = ((long) r1 << 16) & mask; > long mx = mask - ((1L << 16) - 1); > Rnd rnd = null; > for (int i = 0; i < 65536; i++) { > long sx = s0 + i; > if (((sx * multiplier + addend) & mx) == s1) { > rnd = new Rnd(sx); > int rx = rnd.nextInt(); > assert rx == r1; > break; > } > } > assert rnd != null; > > System.out.println("Next HashMap.hashSeed will be: " + rnd.nextInt()); > System.out.println("... and it is: " + Hashing.randomHashSeed(null)); > } > } > > > For this purpuse, the Hashing.randomHashSeed() should not be publicly visible. If ThreadLocalRandom is to be used instead of a private instance of a java.util.Random(), then it would defeat the "secrecy" since ThreadLocalRandom.current() is a shared per-thread instance accessible to anyone. > > As far as standard ThreadLocalRandom is concerned, it's usability is impaired by it's design. It would be a better API if a plain ThreadUnsafeRandom with standard constructors was part of standard JDK API. ThreadLocal binding would then be a matter of each particular (possibly private) usage... > > Regards, Peter > > On 12/27/2012 08:38 PM, Aleksey Shipilev wrote: >> Looks very like dumb inlined java.util.Random? >> Is there a security threat to use ThreadLocalRandom instead there? >> >> -Aleksey. >> >> On 27.12.2012, at 23:16, Zhong Yu wrote: >> >>> Reported by the SO question >>> >>> http://stackoverflow.com/questions/14010906 >>> >>> the HashMap constructor contains a CAS, which is kind of surprising. >>> Could it be removed? >>> >>> transient final int hashSeed = >>> sun.misc.Hashing.randomHashSeed(this); // CAS >>> >>> Zhong Yu > From jason_mehrens at hotmail.com Tue Jan 1 23:38:15 2013 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 1 Jan 2013 17:38:15 -0600 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <84D3ABF1-2D55-43F9-AF17-7439B36795DF@oracle.com> References: <50D53C0A.6000203@oracle.com>, , , , <50DB9502.4090406@oracle.com>, , <50DCB236.4020709@oracle.com>, , , <84D3ABF1-2D55-43F9-AF17-7439B36795DF@oracle.com> Message-ID: Henry, For point 1 yes. Not just me, even NetBeans considers it an anti-pattern. Supplier return values should be placed in the LogRecord.setParameters method. The 'msg' argument, if present, should always be string. Using the patch I just described, it would allow callers to write the same code as in your testcase and see the same formatted output. All of the existing features of the logging framework would be usable out of the box should the caller choose to opt in and used them. Under the current patch there is no way to opt in because it only encourages the anti-pattern. All parties involved benefit if we switch this around. I could create a prototype from your patch if need be. For point 2, it is way off track and is not the point I was trying to make. The short answer is that point 1 could be evolved even further. Respectfully, Jason> Subject: Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message > From: henry.jen at oracle.com > Date: Fri, 28 Dec 2012 16:11:02 -0800 > CC: brian.goetz at oracle.com; lambda-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > To: jason_mehrens at hotmail.com > > Jason, > > If I understand you correctly, there are two main concerns, > > 1. You want to encourage MessageFormat style logging, consider the other way is an anti-pattern. > 2. The construction of message could be further eliminated when a filter is involved. From lana.steuck at oracle.com Wed Jan 2 05:31:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:25 +0000 Subject: hg: jdk8/tl: 10 new changesets Message-ID: <20130102053126.5650B4749D@hg.openjdk.java.net> Changeset: 8e36a0fabf58 Author: ohrstrom Date: 2012-12-18 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e36a0fabf58 8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes. Reviewed-by: ohair, erikj + common/bin/hgforest.sh ! get_source.sh Changeset: 51d3b65b8093 Author: erikj Date: 2012-12-18 17:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51d3b65b8093 8001901: build-infra: Fix "misbehaving" which command on Solaris Summary: Removed all uses of which in configure on solaris. Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6ee8080a6efe Author: katleman Date: 2012-12-19 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ee8080a6efe Merge Changeset: 32148e971ac8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/32148e971ac8 Added tag jdk8-b69 for changeset 6ee8080a6efe ! .hgtags Changeset: 6b93e7a4401d Author: dholmes Date: 2012-12-20 01:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6b93e7a4401d 7190137: Add support for JVM_VARIANT minimal1 Summary: Allow configuration of minimal1 as a target VM along with client and server Reviewed-by: ohair, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: cd06b2ea58dd Author: katleman Date: 2012-12-20 16:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd06b2ea58dd 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! common/makefiles/RMICompilation.gmk Changeset: 105a25ffa4a4 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/105a25ffa4a4 Merge Changeset: 3fb32a5a2388 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3fb32a5a2388 Added tag jdk8-b70 for changeset 105a25ffa4a4 ! .hgtags Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51ad2a343420 Merge Changeset: b845a2494261 Author: lana Date: 2013-01-01 12:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b845a2494261 Merge From lana.steuck at oracle.com Wed Jan 2 05:31:24 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:24 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130102053127.70EEC4749E@hg.openjdk.java.net> Changeset: 603cceb495c8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/603cceb495c8 Added tag jdk8-b69 for changeset 22ddcac208a8 ! .hgtags Changeset: 8171d23e914d Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8171d23e914d Added tag jdk8-b70 for changeset 603cceb495c8 ! .hgtags From lana.steuck at oracle.com Wed Jan 2 05:31:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:25 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130102053130.DFAE54749F@hg.openjdk.java.net> Changeset: 3b1c2733d47e Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3b1c2733d47e Added tag jdk8-b69 for changeset 756323c99011 ! .hgtags Changeset: f577a39c9fb3 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f577a39c9fb3 Added tag jdk8-b70 for changeset 3b1c2733d47e ! .hgtags From lana.steuck at oracle.com Wed Jan 2 05:31:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:27 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20130102053141.B1FB7474A0@hg.openjdk.java.net> Changeset: 27421008f050 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/27421008f050 Added tag jdk8-b69 for changeset 789a855de959 ! .hgtags Changeset: a72c8391cdd6 Author: katleman Date: 2012-12-20 16:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a72c8391cdd6 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6ec9edffc286 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6ec9edffc286 Merge Changeset: 63815efd132f Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/63815efd132f Added tag jdk8-b70 for changeset 6ec9edffc286 ! .hgtags Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/499be952a291 Merge From lana.steuck at oracle.com Wed Jan 2 05:31:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:35 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130102053153.F32DA474A1@hg.openjdk.java.net> Changeset: 2001991b1b40 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2001991b1b40 Added tag jdk8-b69 for changeset d7360bf35ee1 ! .hgtags Changeset: 7d34e91f66bb Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d34e91f66bb 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! make/Makefile-classic ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 47f71d7c124f Author: katleman Date: 2012-12-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/47f71d7c124f Merge Changeset: 7d5032c2d747 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d5032c2d747 Added tag jdk8-b70 for changeset 47f71d7c124f ! .hgtags Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 1d8438db45f2 Author: lana Date: 2013-01-01 17:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1d8438db45f2 Merge From lana.steuck at oracle.com Wed Jan 2 05:31:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:45 +0000 Subject: hg: jdk8/tl/hotspot: 47 new changesets Message-ID: <20130102053316.55C33474A2@hg.openjdk.java.net> Changeset: 4a2ed49abd51 Author: amurillo Date: 2012-12-07 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a2ed49abd51 8004724: new hotspot build - hs25-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 442f942757c0 Author: johnc Date: 2012-10-01 09:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/442f942757c0 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a14c5698a162 Author: johnc Date: 2012-12-07 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a14c5698a162 Merge Changeset: 2aa953165ade Author: brutisso Date: 2012-12-13 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2aa953165ade 8004661: Comment and function name java_lang_String::toHash is wrong Summary: renamed to hash_code Reviewed-by: dholmes, coleenp, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp Changeset: db8a7163c682 Author: stefank Date: 2012-12-13 09:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db8a7163c682 8004674: Add necessary .inline.hpp files to fix non-PCH build Reviewed-by: stefank, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/shared/gcStats.cpp Changeset: 4459ef2189f5 Author: stefank Date: 2012-12-13 09:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4459ef2189f5 Merge Changeset: fd74228fd5ca Author: jiangli Date: 2012-12-11 12:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd74228fd5ca 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Reviewed-by: coleenp, minqi, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 807f1d348f7b Author: collins Date: 2012-12-14 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/807f1d348f7b Merge Changeset: b6c9c0109a60 Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6c9c0109a60 Merge Changeset: cb8a4e04bc8c Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb8a4e04bc8c Added tag hs25-b13 for changeset b6c9c0109a60 ! .hgtags Changeset: 8b4810c80f5d Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b4810c80f5d Added tag jdk8-b69 for changeset cb8a4e04bc8c ! .hgtags Changeset: 1f323009c3ea Author: amurillo Date: 2012-12-14 14:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f323009c3ea 8005036: new hotspot build - hs25-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 892acf0431ef Author: dcubed Date: 2012-12-14 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/892acf0431ef 7153050: remove crufty '_g' support from HotSpot repo makefiles Summary: Phase 1 is removing '_g' support from the Makefiles. Reviewed-by: dcubed, sspitsyn, coleenp, tbell Contributed-by: ron.durbin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp Changeset: 30866cd626b0 Author: coleenp Date: 2012-12-12 11:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30866cd626b0 8004883: NPG: clean up anonymous class fix Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not. Reviewed-by: stefank, jrose ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp Changeset: 18712b1caf7a Author: rkennke Date: 2012-12-12 21:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18712b1caf7a 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 Summary: fix opto/library_call.cpp compilation errors Reviewed-by: twisti, coleenp ! src/share/vm/opto/library_call.cpp Changeset: 8580f22db905 Author: coleenp Date: 2012-12-14 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8580f22db905 Merge Changeset: 3f84e17b6bca Author: zgu Date: 2012-12-17 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f84e17b6bca 8004802: jcmd VM.native_memory baseline=false crashes VM Summary: NMT has to check option's value also to determine which command to execute Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/nmtDCmd.cpp Changeset: 805aa223d540 Author: zgu Date: 2012-12-17 10:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/805aa223d540 Merge Changeset: 594b9b2119ed Author: minqi Date: 2012-12-19 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/594b9b2119ed Merge Changeset: 0c535211ef13 Author: bharadwaj Date: 2012-12-07 18:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c535211ef13 8004668: Build failure for Zero target Summary: fixed build failure for Zero target Reviewed-by: twisti, kvn ! src/cpu/zero/vm/assembler_zero.cpp Changeset: a70c88896791 Author: kvn Date: 2012-12-13 17:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a70c88896791 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Summary: use unsigned comparison when checking for stack overflow Reviewed-by: kvn, twisti Contributed-by: paul.nauman at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp Changeset: 1b1e16471e46 Author: stefank Date: 2012-12-12 22:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b1e16471e46 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Summary: Move the handelization of 'last' to a point before the GC might enter. Reviewed-by: dholmes, sspitsyn, coleenp ! src/share/vm/classfile/classLoaderData.cpp Changeset: 5c0931d15474 Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c0931d15474 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: 3c433d080bae Author: twisti Date: 2012-12-14 12:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c433d080bae Merge Changeset: 18d56ca3e901 Author: twisti Date: 2012-12-17 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18d56ca3e901 8004548: remove unused AbstractAssembler::print(Label&) Reviewed-by: kvn, twisti Contributed-by: Bharadwaj Yadavalli ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: ad5dd04754ee Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad5dd04754ee 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp Changeset: eb409f2f146e Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eb409f2f146e 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 620e502e3f47 Author: vlivanov Date: 2012-12-18 08:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/620e502e3f47 Merge ! src/share/vm/opto/library_call.cpp Changeset: c4bd2eccea46 Author: twisti Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4bd2eccea46 8004536: replace AbstractAssembler emit_word with emit_int16 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 1e41b0bc58a0 Author: kvn Date: 2012-12-18 17:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e41b0bc58a0 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 65c8342f726a Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65c8342f726a 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java Changeset: 2c7f594145dc Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c7f594145dc 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java Changeset: 2d6c433b1f38 Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2d6c433b1f38 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java Changeset: a46457045d66 Author: kvn Date: 2012-12-20 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a46457045d66 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Fix java names for getAndSet intrinsics Reviewed-by: kvn Contributed-by: aleksey.shipilev at oracle.com ! src/share/vm/classfile/vmSymbols.hpp Changeset: d02120b7a34f Author: twisti Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d02120b7a34f 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: c52660592f37 Author: roland Date: 2012-12-21 01:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c52660592f37 Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/opto/library_call.cpp Changeset: 0b3d19153cc6 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b3d19153cc6 8001028: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: 730cc4ddd550 Author: brutisso Date: 2012-12-17 08:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/730cc4ddd550 7173959: Jvm crashed during coherence exabus (tmb) testing Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com Reviewed-by: dholmes, coleenp, zgu ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 32164d89fe9c Author: brutisso Date: 2012-12-17 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32164d89fe9c 8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private Reviewed-by: dholmes, coleenp Contributed-by: erik.helin at oracle.com ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: c71879335291 Author: stefank Date: 2012-12-18 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c71879335291 8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers Summary: Reverted the changes to these functions from JDK-8000662 Reviewed-by: brutisso, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 345bd97a77be Author: brutisso Date: 2012-12-20 05:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/345bd97a77be 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Reviewed-by: stefank, brutisso, kvn, ctornqvi Contributed-by: erik.helin at oracle.com + test/sanity/ExecuteInternalVMTests.java Changeset: 69627aa9ab10 Author: jwilhelm Date: 2012-12-21 16:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69627aa9ab10 Merge ! src/share/vm/runtime/thread.cpp Changeset: 990bbd393c23 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/990bbd393c23 Merge Changeset: 6a1fc440b396 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a1fc440b396 Added tag hs25-b14 for changeset 990bbd393c23 ! .hgtags Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags From lana.steuck at oracle.com Wed Jan 2 05:33:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:33:15 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20130102053807.24DCB474A5@hg.openjdk.java.net> Changeset: 4ea0ac8e02d2 Author: erikj Date: 2012-12-19 09:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ea0ac8e02d2 8004803: build-infra: Cannot use icedtea as boot for closed build. Summary: Set bootclasspath to javac and not the running jvm Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: a8012d8d7e9c Author: katleman Date: 2012-12-19 13:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8012d8d7e9c Merge Changeset: 4d5db5c038b4 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d5db5c038b4 Added tag jdk8-b69 for changeset a8012d8d7e9c ! .hgtags Changeset: ad6097d547e1 Author: kvn Date: 2012-12-18 17:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad6097d547e1 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/classes/sun/misc/Unsafe.java Changeset: 12fa4d7ecaf5 Author: twisti Date: 2012-12-20 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12fa4d7ecaf5 8005345: JSR 292: JDK performance tweaks Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/sun/invoke/util/ValueConversions.java Changeset: 8cf5b18488d1 Author: dl Date: 2012-12-20 12:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cf5b18488d1 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898) Reviewed-by: alanb, kvn ! src/share/classes/sun/misc/Unsafe.java Changeset: 6b41b40526c6 Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b41b40526c6 Merge Changeset: 1ad29569d6e9 Author: erikj Date: 2012-12-20 13:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ad29569d6e9 8005178: build-infra: Dependency on libfdlibm on mac is broken Reviewed-by: tbell, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: a68090f0dc1a Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a68090f0dc1a 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/native/common/jdk_util_md.h ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/lang/Integer/Unsigned.java ! test/java/lang/Long/Unsigned.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/net/Inet4Address/PingThis.java ! test/java/net/ProxySelector/MultiThreadedSystemProxies.java ! test/java/security/Signature/VerifyRangeCheckOverflow.java ! test/java/util/AbstractCollection/ToArrayTest.java ! test/java/util/Map/EntryHashCode.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/SimpleFormatterFormat.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java ! test/javax/swing/JTable/4235420/bug4235420.java ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/sun/management/AgentCMETest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/nio/ch/SelProvider.java ! test/sun/rmi/rmic/classpath/RMICClassPathTest.java ! test/sun/security/krb5/auto/ReplayCache.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/tools/jps/jps-V_2.sh ! test/tools/jar/JarBackSlash.java ! test/tools/launcher/UnicodeTest.java Changeset: 9dc1990c7d90 Author: yhuang Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9dc1990c7d90 7195759: ISO 4217 Amendment 154 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cbf255324369 Author: yhuang Date: 2012-12-23 19:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbf255324369 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a996b57e5541 Author: katleman Date: 2012-12-26 14:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a996b57e5541 Merge Changeset: 8d7651351cfe Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d7651351cfe Added tag jdk8-b70 for changeset a996b57e5541 ! .hgtags Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf2bcb293f0b Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 38b9a7646093 Author: lana Date: 2013-01-01 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38b9a7646093 Merge ! makefiles/CreateJars.gmk From peter.levart at gmail.com Wed Jan 2 06:58:06 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jan 2013 07:58:06 +0100 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50E2DC3D.9090104@gmail.com> Message-ID: <50E3DA7E.2000204@gmail.com> On 01/02/2013 12:13 AM, Eric McCorkle wrote: > Was the original purpose security-oriented? It seemed to me that the purpose was to make performance pathologies less likely. > > Consider, for example, a bad hash function that maps ip addresses directly to their integer representation. If an application puts entire subnets into a map. All the addresses will go into contiguous buckets, which increases probability of a collision considerably. Adding in randomness helps to smooth over these sorts of pathologies. Then how do you explain the need to have different (unique?) hashSeed values for each individual HashMap instance? The hashSeed is a constant for a particular HashMap instance. It's XOR-ed with the hashCode just before bit-shifting-and-xor-ing. If any random int is ok, then why not take the same value for all HashMap instances? /** * Retrieve object hash code and applies a supplemental hash function to the * result hash, which defends against poor quality hash functions. This is * critical because HashMap uses power-of-two length hash tables, that * otherwise encounter collisions for hashCodes that do not differ * in lower bits. */ final int hash(Object k) { if (k instanceof String) { return ((String) k).hash32(); } int h = hashSeed ^ k.hashCode(); // This function ensures that hashCodes that differ only by // constant multiples at each bit position have a bounded // number of collisions (approximately 8 at default load factor). h ^= (h >>> 20) ^ (h >>> 12); return h ^ (h >>> 7) ^ (h >>> 4); } Regards, Peter On Jan 1, 2013, at 7:53 AM, Peter Levart wrote: >> Hi and happy new year, 2013! >> >> I don't know what the main purpose of "hashSeed" actually is. If it is to fight against predictable hashCode to bucket-index mappings, it does it's job somehow, but not very good. For example, it is very easy to predict the next hashSeed numbers that will be allocated: >> >> import sun.misc.Hashing; >> >> public class HashSeedCrack { >> private static final long multiplier = 0x5DEECE66DL; >> private static final long addend = 0xBL; >> private static final long mask = (1L << 48) - 1; >> >> static class Rnd { >> private long rnd; >> >> Rnd(long seed) { this.rnd = seed; } >> >> int nextInt() { >> rnd = (rnd * multiplier + addend) & mask; >> return (int) (rnd >>> 16); >> } >> } >> >> public static void main(String[] args) throws Exception { >> int r0 = Hashing.randomHashSeed(null); >> int r1 = Hashing.randomHashSeed(null); >> >> long s0 = ((long) r0 << 16) & mask; >> long s1 = ((long) r1 << 16) & mask; >> long mx = mask - ((1L << 16) - 1); >> Rnd rnd = null; >> for (int i = 0; i < 65536; i++) { >> long sx = s0 + i; >> if (((sx * multiplier + addend) & mx) == s1) { >> rnd = new Rnd(sx); >> int rx = rnd.nextInt(); >> assert rx == r1; >> break; >> } >> } >> assert rnd != null; >> >> System.out.println("Next HashMap.hashSeed will be: " + rnd.nextInt()); >> System.out.println("... and it is: " + Hashing.randomHashSeed(null)); >> } >> } >> >> >> For this purpuse, the Hashing.randomHashSeed() should not be publicly visible. If ThreadLocalRandom is to be used instead of a private instance of a java.util.Random(), then it would defeat the "secrecy" since ThreadLocalRandom.current() is a shared per-thread instance accessible to anyone. >> >> As far as standard ThreadLocalRandom is concerned, it's usability is impaired by it's design. It would be a better API if a plain ThreadUnsafeRandom with standard constructors was part of standard JDK API. ThreadLocal binding would then be a matter of each particular (possibly private) usage... >> >> Regards, Peter >> >> On 12/27/2012 08:38 PM, Aleksey Shipilev wrote: >>> Looks very like dumb inlined java.util.Random? >>> Is there a security threat to use ThreadLocalRandom instead there? >>> >>> -Aleksey. >>> >>> On 27.12.2012, at 23:16, Zhong Yu wrote: >>> >>>> Reported by the SO question >>>> >>>> http://stackoverflow.com/questions/14010906 >>>> >>>> the HashMap constructor contains a CAS, which is kind of surprising. >>>> Could it be removed? >>>> >>>> transient final int hashSeed = >>>> sun.misc.Hashing.randomHashSeed(this); // CAS >>>> >>>> Zhong Yu From Alan.Bateman at oracle.com Wed Jan 2 09:20:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Jan 2013 09:20:41 +0000 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50E2DC3D.9090104@gmail.com> Message-ID: <50E3FBE9.8050005@oracle.com> On 01/01/2013 23:13, Eric McCorkle wrote: > Was the original purpose security-oriented? It seemed to me that the purpose was to make performance pathologies less likely. > > Consider, for example, a bad hash function that maps ip addresses directly to their integer representation. If an application puts entire subnets into a map. All the addresses will go into contiguous buckets, which increases probability of a collision considerably. Adding in randomness helps to smooth over these sorts of pathologies. > It was related to collisions, particularly where the keys are Strings and coming from an untrusted source. There are better solutions for handling a huge number of collisions now and we need to change this code (ie: get rid of the alternative hashing). For jdk7u then we have to be more cautious and I think Mike is going to see about changing it to use ThreadLocalRandom. -Alan. From chris.hegarty at oracle.com Wed Jan 2 14:11:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 02 Jan 2013 14:11:56 +0000 Subject: RFR 8005634: TEST_BUG tools/launcher/VersionCheck.java fails version check on jdeps Message-ID: <50E4402C.9040100@oracle.com> The jdeps tools (recently added by 8003562) does not support '-version'. It uses the gnu-style '--version'. It should be excluded from VersionCheck.testToolVersion(), similar to the (un)pack200 tool. Long term we may need to re-visit this test to add support for gnu-style option checking, but that is a bigger issue. The test change is to add 'jdeps' to the list of tools that do not support '-version'. diff -r 38b9a7646093 test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java Tue Jan 01 17:49:22 2013 -0800 +++ b/test/tools/launcher/VersionCheck.java Wed Jan 02 14:05:37 2013 +0000 @@ -68,6 +68,7 @@ public class VersionCheck extends TestHe "jcmd", "jconsole", "jcontrol", + "jdeps", "jinfo", "jmap", "jps", -Chris. From david.lloyd at redhat.com Wed Jan 2 15:13:00 2013 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 02 Jan 2013 09:13:00 -0600 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50DCB236.4020709@oracle.com> References: <50D53C0A.6000203@oracle.com>, , <50DB9502.4090406@oracle.com> <50DCB236.4020709@oracle.com> Message-ID: <50E44E7C.6000407@redhat.com> Being a devil's advocate here, I'd like to point out that the particular example given: > logger.log(level, () -> String.format(...)); is better done through an API like this one: logger.logf(level, fmt, ...); which would in fact allow for the possibility of localization (using the format string as a key as is done for MessageFormat-style messages) while also allowing the same performance optimizations that are allowed in other cases (we actually have such API methods on our LogManager's Logger implementation). The place where this optimization is generally most useful is in fact in the argument list - this is where it is most common for expensive values to be computed. On 12/27/2012 02:40 PM, Brian Goetz wrote: > I think a significant fraction of the community would disagree with you. > We ran a survey where we collected suggestions for lambdafying API > methods, and this one came in top of the list. > > There is a significant fraction of the developer community that uses the > logging API and doesn't care at all about localization, but does care > about logging performance. One doesn't have to look very far to see > that it is common practice to surround logging calls with > > if (logger.isLogging(level)) > logger.log(level, msgExpr) > > to work around the eager evaluation. And such a practice is brittle, > because it's easy to forget to do it in one place, and lose the benefit. > > Now, your answer might be "force all users to use message catalogs." But > that's pretty mean. A lot of users really, really don't want to use > message catalogs. They want to do: > > logger.log(level, () -> String.format(...)); > > You're basically saying we should force-feed those users some > message-catalog vegetables, because it's good for them. > >> Henry, >> Please don't apply this patch. This patch and the suggested >> workarounds are still an anti-pattern of the logging API. You don't >> want to encourage this type of on the fly message construction because >> it can't be localized. Even Netbeans has a code hint to undo this >> pattern that you are enabling. The problem with this patch is it fails >> to meet even its own goals when used it in a real world context. The >> stated goal is to eliminate unnecessary message construction but, in >> this patch you will pay the cost of message construction when you >> create a LogRecord. If you configure a system with MemoryHandler to >> track the events that lead up to a failure you will pay the message >> cost on every LogRecord that passes through the ring buffer. With >> this API change, we are performing costly message construction for >> evicted and unformatted records which is awful. This same kind of >> worst case behavior happens when the handler levels are higher than >> the logger level or if a handler is ! > using a filter to track a specific error. I've used combinations of > those logging configurations on production applications to track down > elusive errors (See bug 6219960). This patch assumes that if a record > is loggable by a logger that it will be formatted and that is > incorrect. In the 1.4-1.7 logging, message construction cost is delayed > until formatting which is as lazy as it gets in the logging world. Take > the workaround you suggest bellow. If you apply Object.toString() to > any of the arguments, then that cripples what you can do with custom > Filter or custom Formatter because you want to be able to access the > arguments in their original form and not the string representation. > Also, you always want to use the ResouceBundle assigned to the LogRecord > from the logger to do the localization. The msg supplier won't know > what that is at the time the lambda is created or I would have to > recreate code that the logger already does for me every time I want to > log something. It would! > be easie > r to do what we've done since 1.4 which is use a guard statement to > avoid evaluation of the expensive method call. Against this patch if I > use a lambda or a guard they will both evaluate the expensive call under > the same scenarios. Take the 'DiagnosisMessages::systemHealthStatus' > example from the API docs. Seems fine until you realize that someday > you might have to read the output of that statement in a log somewhere > or you want to create a filter that only shows when the system is > unhealthy. So you start to transform that example and realize that you > don't want to create a 'systemHealthStatusWithContextMsg' method because > it can't be localized during formatting. You don't want to simply > perform msg concatenation because that is bad practice and doesn't use > lambda. So skip using the lambda APIs because you can use the > parameterized logging with a guard statement and that allows you to > localize the message and or use the raw parameter data in a Filter to > determine which ! > system va > lue has exceed some threshold without resorting to message parsing. > Parameters are always more useful than a preformatted string message. > Once you arrive here, there is no need for a message parameter to be > anything other than a message format pattern or a resource bundle key. > Both of those types of messages are string literals so I don't need a > Supplier. I think what would be more powerful and fitting patch would be > to overload all of the Logger.finest, Logger.finer, Logger.fine, etc. > like 'Logger.finer(String msg, Throwable thrown, Supplier... params)' or > use a sub-interface of Supplier. As long as the given > Supplier.toString() is implemented as: 'return String.valueof(get())' > then the existing logging API would format these lazy parameters the > same way and would properly delay the construction cost to only at the > time of formatting. Filters would be allowed access to the original > parameters through the supplier interface and the already established > localization in th! > e logging > API would still work. The established best practice of not creating on > the fly messages would still remain an enduring goal of the logging API. > Respectfully, Jason >> >>> For messages not just only for developer, they should be localized as >>> you suggested and in such cases, it is possible to achieve the laziness >>> via Object.toString(), less straightforward than using a lambda, but is >>> possible. >>> >>> Cheers, >>> Henry >>> >> >> >> >> >> >> -- - DML From peter.levart at gmail.com Wed Jan 2 15:50:08 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 02 Jan 2013 16:50:08 +0100 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <50E3FBE9.8050005@oracle.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50E2DC3D.9090104@gmail.com> <50E3FBE9.8050005@oracle.com> Message-ID: <50E45730.1060904@gmail.com> On 01/02/2013 10:20 AM, Alan Bateman wrote: > On 01/01/2013 23:13, Eric McCorkle wrote: >> Was the original purpose security-oriented? It seemed to me that the >> purpose was to make performance pathologies less likely. >> >> Consider, for example, a bad hash function that maps ip addresses >> directly to their integer representation. If an application puts >> entire subnets into a map. All the addresses will go into contiguous >> buckets, which increases probability of a collision considerably. >> Adding in randomness helps to smooth over these sorts of pathologies. >> > It was related to collisions, particularly where the keys are Strings > and coming from an untrusted source. There are better solutions for > handling a huge number of collisions now and we need to change this > code (ie: get rid of the alternative hashing). For jdk7u then we have > to be more cautious and I think Mike is going to see about changing it > to use ThreadLocalRandom. > > -Alan. > String keys are treated specially in HashMap (using String.hash32()) and don't need HashMap.hashSeed value at all. hashSeed is only used for non-String keys. The question is why it has to be a unique value for each individual HashMap instance? String.hash32() uses a once-per-JVM allocated String.HASHING_SEED for example... Regards, Peter From mandy.chung at oracle.com Wed Jan 2 16:46:18 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Jan 2013 08:46:18 -0800 Subject: RFR 8005634: TEST_BUG tools/launcher/VersionCheck.java fails version check on jdeps In-Reply-To: <50E4402C.9040100@oracle.com> References: <50E4402C.9040100@oracle.com> Message-ID: <50E4645A.3020605@oracle.com> Chris, Looks good. I missed this test in my default jprt run and thanks for fixing it. Mandy On 1/2/2013 6:11 AM, Chris Hegarty wrote: > The jdeps tools (recently added by 8003562) does not support > '-version'. It uses the gnu-style '--version'. It should be excluded > from VersionCheck.testToolVersion(), similar to the (un)pack200 tool. > Long term we may need to re-visit this test to add support for > gnu-style option checking, but that is a bigger issue. > > The test change is to add 'jdeps' to the list of tools that do not > support '-version'. > > diff -r 38b9a7646093 test/tools/launcher/VersionCheck.java > --- a/test/tools/launcher/VersionCheck.java Tue Jan 01 17:49:22 > 2013 -0800 > +++ b/test/tools/launcher/VersionCheck.java Wed Jan 02 14:05:37 > 2013 +0000 > @@ -68,6 +68,7 @@ public class VersionCheck extends TestHe > "jcmd", > "jconsole", > "jcontrol", > + "jdeps", > "jinfo", > "jmap", > "jps", > > > -Chris. From mandy.chung at oracle.com Wed Jan 2 18:53:45 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Jan 2013 10:53:45 -0800 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50D3FF29.6010005@oracle.com> References: <50D3FF29.6010005@oracle.com> Message-ID: <50E48239.9070505@oracle.com> Hi David, On 12/20/2012 10:18 PM, David Holmes wrote: > jdk repo: http://cr.openjdk.java.net/~dholmes/8004265/webrev.jdk/ I reviewed the src/test changes in the jdk repo and have a few comments: Attributes.java: 568 * {@code Name} object for {@code Profile} manifest attribute used 569 * by applications packaged as JAR files to indicate the minimum 570 * profile required to execute the application. The Profile attribute can be specified in both applications and libraries. Shoud L569 be changed with s/applications/applications or libraries? Pack200.java I think the default implementation for addPropertyChangeListener and removePropertyChangeListener requiring a non-null listener is a right choice. On the other hand, I found that the current pack200 implementation allows the given listener be null that seems to be a bug and the Pack200 class spec also specifies to throw NPE if null argument is passed to a method and looks like what you have sun.misc.URLClassPath L808: typo "attribtue" L820: An empty "Profile" attribute is invalidand Version.supportsProfile returns false if requiredProfile parameter is empty even if the runtime is a full JRE. This is fine but I was wondering if the exception message can indicate if the attribute value is invalid to help diagnosis. L1000: looks like the convention is to use brackets even there is a single statement in the if-statement body. sun.tools.jar.Main It would be helpful if the jar tool checks if the input profile name to the -p option is valid and outputs error. UnsupportedProfileException L29: probably better to link to the javadoc {@link Attributes.Name#Profile Profile} L38 and 44: {@code UnsupportedProfileException} make/tools/src/build/tools/RemoveMethods.java L100: maybe print the method signature rather than just 'name' L106: typo "no longed" -> "no longer" The tests are hardcoded with the profile name and uses Version.profileName(). Will there be a system property for the profile name? Otherwise, looks okay. Mandy From stuart.marks at oracle.com Wed Jan 2 22:21:21 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 02 Jan 2013 22:21:21 +0000 Subject: hg: jdk8/tl/jdk: 8005118: Javadoc styles are inconsistent Message-ID: <20130102222134.1A575474D1@hg.openjdk.java.net> Changeset: cc78ceb99284 Author: jgish Date: 2012-12-28 16:56 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc78ceb99284 8005118: Javadoc styles are inconsistent Summary: use a common javadoc style in the String classes Reviewed-by: darcy ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringIndexOutOfBoundsException.java From brian.burkhalter at oracle.com Thu Jan 3 01:02:10 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 2 Jan 2013 17:02:10 -0800 Subject: core-libs-dev Digest, Vol 68, Issue 113 In-Reply-To: References: Message-ID: <471A19DF-160D-45E0-82A9-EEE2DFA20C73@oracle.com> Hello Tim, Thank you for the updates. We'll take a closer look at this as soon as practically feasible. I have only recently been transferred into the core-libs area and expect to be dealing with the learning curve for some time to come. Regards, Brian > Date: Sat, 29 Dec 2012 15:18:01 +0100 > From: Tim Buktu > Subject: Review Request: BigInteger patch for efficient multiplication > and division (#4837946) > To: core-libs-dev at openjdk.java.net > Message-ID: > Content-Type: text/plain; charset="ISO-8859-15" > > Hello, > > I updated my patch that speeds up multiplication and division of large > BigIntegers. The changes vs. the older patch were trivial. > > BigInteger.java: https://gist.github.com/1576025 > Diff against current BigInteger: https://gist.github.com/1576016 > > The patch to the unit test still applies. > BigIntegerTest.java: https://gist.github.com/1586990 > Diff against current BigIntegerTest.java: https://gist.github.com/1586984 > > See the original posts at > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008860.html > and > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008875.html > > Comments and critique are appreciated. > > Thanks, > Tim From stuart.marks at oracle.com Thu Jan 3 02:54:50 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 02 Jan 2013 18:54:50 -0800 Subject: RMI java processes left running on JPRT systems In-Reply-To: <576B79E0-7EB5-4715-9C83-A8C53827F8F6@oracle.com> References: <576B79E0-7EB5-4715-9C83-A8C53827F8F6@oracle.com> Message-ID: <50E4F2FA.3020702@oracle.com> Hi Kelly, Thanks for mentioning this. I was able to track down a couple of the log files from the test runs that had started these processes, and it looks like the test is trying to tear things down, but it's failing, and these processes get left running. I've filed 8005646 to track this problem. s'marks On 12/29/12 12:51 PM, Kelly O'Hair wrote: > > FYI... > > After shutting down JPRT I found two systems with ActivationGroupInit java processes running. > > I am assuming that a test case has fired them up and forgotten about them??? > > Not sure why JPRT did not kill them automatically... > > -kto > > jprtadm at sc11136053:~> jps -l -m > 11651 sun.tools.jps.Jps -l -m > 16530 sun.rmi.server.ActivationGroupInit > jprtadm at sc11136053:~> ps -fel | fgrep java > 0 S jprtadm 11669 11603 0 80 0 - 511 pipe_w 12:35 pts/0 00:00:00 fgrep java > 0 S jprtadm 16530 1 0 80 0 - 239212 futex_ Dec27 ? 00:01:02 /opt/jprt/T/P1/211212.chhegar/testproduct/linux_i586_2.6-product/jre/bin/java -Djava.security.manager=default -Djava.security.policy=/opt/jprt/T/P1/211212.chhegar/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy -DunregisterGroup.port=53315 -Dtest.src=/opt/jprt/T/P1/211212.chhegar/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup -Dtest.classes=/opt/jprt/T/P1/211212.chhegar/s/jdk/build/linux-i586/testoutput/jdk_rmi/JTwork/classes/java/rmi/activation/ActivationSystem/unregisterGroup sun.rmi.server.ActivationGroupInit > jprtadm at sc11136053:~> uname -a > Linux sc11136053 2.6.27.25-78.2.56.fc9.i686 #1 SMP Thu Jun 18 12:47:50 EDT 2009 i686 i686 i386 GNU/Linux > jprtadm at sc11136053:~> > > > jprtadm at sc11136024:~> jps -l -m > 17187 sun.rmi.server.ActivationGroupInit > 5809 sun.tools.jps.Jps -l -m > 12314 sun.rmi.server.ActivationGroupInit > jprtadm at sc11136024:~> ps -fel | fgrep java > 0 S jprtadm 12314 1 0 80 0 - 239252 futex_ Dec26 ? 00:01:26 /opt/jprt/T/P1/172428.jzavgren/testproduct/linux_i586_2.6-product/jre/bin/java -Djava.security.manager=default -DunregisterGroup.port=42896 -Djava.security.policy=/opt/jprt/T/P1/172428.jzavgren/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy -Dtest.src=/opt/jprt/T/P1/172428.jzavgren/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup -Dtest.classes=/opt/jprt/T/P1/172428.jzavgren/s/jdk/build/linux-i586/testoutput/jdk_rmi/JTwork/classes/java/rmi/activation/ActivationSystem/unregisterGroup sun.rmi.server.ActivationGroupInit > 0 S jprtadm 17187 1 0 80 0 - 239231 futex_ Dec27 ? 00:00:52 /opt/jprt/T/P1/020528.jcg-int/testproduct/linux_i586_2.6-product/jre/bin/java -Djava.security.policy=/opt/jprt/T/P1/020528.jcg-int/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy -Djava.security.manager=default -DunregisterGroup.port=43443 -Dtest.src=/opt/jprt/T/P1/020528.jcg-int/s/jdk/test/java/rmi/activation/ActivationSystem/unregisterGroup -Dtest.classes=/opt/jprt/T/P1/020528.jcg-int/s/jdk/build/linux-i586/testoutput/jdk_rmi/JTwork/classes/java/rmi/activation/ActivationSystem/unregisterGroup sun.rmi.server.ActivationGroupInit > > > From chris.hegarty at oracle.com Thu Jan 3 10:01:53 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 03 Jan 2013 10:01:53 +0000 Subject: hg: jdk8/tl/jdk: 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Message-ID: <20130103100231.C1768474E8@hg.openjdk.java.net> Changeset: 21708d15553b Author: chegar Date: 2013-01-03 10:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21708d15553b 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Summary: add jdeps to the list of tools that do not support '-version' Reviewed-by: mchung ! test/tools/launcher/VersionCheck.java From daniel.fuchs at oracle.com Thu Jan 3 11:33:18 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 03 Jan 2013 12:33:18 +0100 Subject: RFR: (jaxp) 8005473 : Warnings compiling jaxp In-Reply-To: <50DB82E5.20504@oracle.com> References: <50DB82E5.20504@oracle.com> Message-ID: <50E56C7E.60506@oracle.com> On 12/27/12 12:06 AM, Joe Wang wrote: > Hi, > > This is a patch to clean up compiling warnings in jaxp. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473 > Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/ > > Thanks, > Joe Hi Joe, In FactoryFinder.java - line 213, SchemaFactoryFinder.java - line 360, XPathFactoryFinder.java - line 336, I think you could simply do: return creationMethod.invoke(null); since the second parameter is a varargs... best regards, -- daniel From chris.hegarty at oracle.com Thu Jan 3 12:13:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Jan 2013 12:13:38 +0000 Subject: RFR 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Message-ID: <50E575F2.4040606@oracle.com> This test fails on all platforms since the integration of 8004727: "Add compiler support for parameter reflection". The test fails to compile a dependent class tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java: AttributeVisitor is not abstract and does not override abstract method visitMethodParameters(MethodParameters_attribute,Element) in Visitor class AttributeVisitor implements Attribute.Visitor 8004727 added visitMethodParameters(MethodParameters_attribute attr, P p) to class Attribute.Visitor, and AttributeVisitor, concrete implementation of an Attribute.Visitor defined in ClassReader.java, needs to correctly implement it. I would like to add tools/pack200/AttributeTests.java to the ProblemList.txt until the issues with the test can be resolved. This will most likely be done through 8005252, "pack200 should support MethodParameters" hg diff test/ProblemList.txt diff -r 38b9a7646093 test/ProblemList.txt --- a/test/ProblemList.txt Tue Jan 01 17:49:22 2013 -0800 +++ b/test/ProblemList.txt Thu Jan 03 11:54:43 2013 +0000 @@ -324,6 +324,9 @@ tools/pack200/Pack200Test.java # 7150569 tools/launcher/UnicodeTest.java macosx-all +# 8005252 +tools/pack200/AttributeTests.java generic-all + ############################################################################ -Chris. From Ulf.Zibis at CoSoCo.de Thu Jan 3 14:35:51 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 03 Jan 2013 15:35:51 +0100 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <50E3FBE9.8050005@oracle.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50E2DC3D.9090104@gmail.com> <50E3FBE9.8050005@oracle.com> Message-ID: <50E59747.9030308@CoSoCo.de> Am 02.01.2013 10:20, schrieb Alan Bateman: > It was related to collisions, particularly where the keys are Strings and coming from an untrusted > source. I guess you mean *intentionally malicious*, an untrusted source must not necessarily be malicious. -Ulf From huizhe.wang at oracle.com Thu Jan 3 16:58:14 2013 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 03 Jan 2013 08:58:14 -0800 Subject: RFR: (jaxp) 8005473 : Warnings compiling jaxp In-Reply-To: <50E56C7E.60506@oracle.com> References: <50DB82E5.20504@oracle.com> <50E56C7E.60506@oracle.com> Message-ID: <50E5B8A6.3010104@oracle.com> On 1/3/2013 3:33 AM, Daniel Fuchs wrote: > On 12/27/12 12:06 AM, Joe Wang wrote: >> Hi, >> >> This is a patch to clean up compiling warnings in jaxp. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473 >> Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/ >> >> Thanks, >> Joe > > Hi Joe, > > In FactoryFinder.java - line 213, > SchemaFactoryFinder.java - line 360, > XPathFactoryFinder.java - line 336, > > I think you could simply do: > > return creationMethod.invoke(null); > > since the second parameter is a varargs... It is. But refer to Remi's comments in this thread, that casting null is better or otherwise an empty array will be allocated each time the method is called. Best, Joe > > best regards, > > -- daniel From brent.christian at oracle.com Thu Jan 3 17:44:24 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 03 Jan 2013 09:44:24 -0800 Subject: RFR : 8003228 : (props) sun.jnu.encoding should be set to UTF-8 [macosx] In-Reply-To: <50D4EC2A.2020905@oracle.com> References: <50D35E6C.8060205@oracle.com> <50D38F14.5050100@oracle.com> <50D4EC2A.2020905@oracle.com> Message-ID: <50E5C378.7080008@oracle.com> Thanks, Naoto. If there are no other comments, I'll need someone to push this for me. Thanks, -Brent On 12/21/12 3:09 PM, Naoto Sato wrote: > Hi Brent, > > The change looks good to me. Sorry for the delay, as I was taking a half > day off. > > Naoto > > On 12/20/12 2:20 PM, Brent Christian wrote: >> Forgot a regtest - now included w/ v.01: >> >> http://cr.openjdk.java.net/~bchristi/8003228/webrev.01/ >> >> Thanks, >> -Brent >> >> On 12/20/12 10:52 AM, Brent Christian wrote: >>> Hi, >>> >>> I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here: >>> http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/ >>> >>> JPRT passes on all platforms (with the exception of two known bugs[2]). >>> >>> There was some recent discussion related to this - see [3]. >>> >>> Thanks, >>> -Brent >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=8003228 >>> >>> [2] 8005195 (Doclint tests on Windows), 8004544 >>> (FDSeparateCompilationTest timeout) >>> >>> [3] >>> http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-November/005124.html >>> >>> >>> >>> > From david.dehaven at oracle.com Thu Jan 3 18:38:22 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 3 Jan 2013 10:38:22 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> Message-ID: [adding core-libs-dev back in.. not sure how that got lost] > [Back from vacation, let's get the ball rolling again? :] > >> In order to understand and explain here is a truth table: >> >> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >> java -jar fxapp.jar Present LM_JAR LM_JAR >> java -jar fxapp.jar Not present LM_JAR LM_CLASS ?? >> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >> java -cp somedir ... Not present LM_CLASS LM_CLASS >> >> If I am understanding this correctly, the confusion stems from the second case where the >> value is interpreted in different ways. > > Correct. I have actually changed it to fix this case, and IMHO it cleans up the launcher code a bit.. I'll post the webrev when I'm done syncing with TL. The current patch I have: http://cr.openjdk.java.net/~ddehaven/8004547/webrev.2/ Minor change to accommodate this in FX LauncherImpl (needs a new JIRA issue?): http://cr.openjdk.java.net/~ddehaven/javafx/RT-26751/webrev.2/ This was all working fine when I left for vacation, I'm still in the process of building/testing everything and will submit a JPRT run as soon as possible. I had commented out two tests, but FX is in sync with JDK *and* they'll pass vacuously until FX is on the ext classpath anyways so I don't think that's necessary. -DrD- From brian.burkhalter at oracle.com Thu Jan 3 19:28:55 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 3 Jan 2013 11:28:55 -0800 Subject: Review Request: BigInteger patch for efficient multiplication and division (#4837946) References: <471A19DF-160D-45E0-82A9-EEE2DFA20C73@oracle.com> Message-ID: Re-post with correct subject line ? Begin forwarded message: > From: Brian Burkhalter > Subject: Re: core-libs-dev Digest, Vol 68, Issue 113 > Date: January 2, 2013 5:02:10 PM PST > To: core-libs-dev at openjdk.java.net > > Hello Tim, > > Thank you for the updates. We'll take a closer look at this as soon as practically feasible. I have only recently been transferred into the core-libs area and expect to be dealing with the learning curve for some time to come. > > Regards, > > Brian > >> Date: Sat, 29 Dec 2012 15:18:01 +0100 >> From: Tim Buktu >> Subject: Review Request: BigInteger patch for efficient multiplication >> and division (#4837946) >> To: core-libs-dev at openjdk.java.net >> Message-ID: >> Content-Type: text/plain; charset="ISO-8859-15" >> >> Hello, >> >> I updated my patch that speeds up multiplication and division of large >> BigIntegers. The changes vs. the older patch were trivial. >> >> BigInteger.java: https://gist.github.com/1576025 >> Diff against current BigInteger: https://gist.github.com/1576016 >> >> The patch to the unit test still applies. >> BigIntegerTest.java: https://gist.github.com/1586990 >> Diff against current BigIntegerTest.java: https://gist.github.com/1586984 >> >> See the original posts at >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008860.html >> and >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008875.html >> >> Comments and critique are appreciated. >> >> Thanks, >> Tim From mandy.chung at oracle.com Thu Jan 3 21:49:31 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jan 2013 13:49:31 -0800 Subject: RFR 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters In-Reply-To: <50E575F2.4040606@oracle.com> References: <50E575F2.4040606@oracle.com> Message-ID: <50E5FCEB.9050700@oracle.com> Thumbs up. Mandy On 1/3/2013 4:13 AM, Chris Hegarty wrote: > This test fails on all platforms since the integration of 8004727: > "Add compiler support for parameter reflection". > > The test fails to compile a dependent class > tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java: > AttributeVisitor is not abstract and does not override abstract method > visitMethodParameters(MethodParameters_attribute,Element) in Visitor > class AttributeVisitor implements Attribute.Visitor > > 8004727 added visitMethodParameters(MethodParameters_attribute attr, P > p) to class Attribute.Visitor, and AttributeVisitor, concrete > implementation of an Attribute.Visitor defined in ClassReader.java, > needs to correctly implement it. > > I would like to add tools/pack200/AttributeTests.java to the > ProblemList.txt until the issues with the test can be resolved. This > will most likely be done through 8005252, "pack200 should support > MethodParameters" > > > hg diff test/ProblemList.txt > diff -r 38b9a7646093 test/ProblemList.txt > --- a/test/ProblemList.txt Tue Jan 01 17:49:22 2013 -0800 > +++ b/test/ProblemList.txt Thu Jan 03 11:54:43 2013 +0000 > @@ -324,6 +324,9 @@ tools/pack200/Pack200Test.java > # 7150569 > tools/launcher/UnicodeTest.java > macosx-all > > +# 8005252 > +tools/pack200/AttributeTests.java > generic-all > + > > ############################################################################ > > > > -Chris. From kumar.x.srinivasan at oracle.com Fri Jan 4 00:41:15 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 03 Jan 2013 16:41:15 -0800 Subject: RFR 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters In-Reply-To: <50E575F2.4040606@oracle.com> References: <50E575F2.4040606@oracle.com> Message-ID: <50E6252B.6000700@oracle.com> Yes please go ahead, I will fix 8005252 shortly. Thanks for doing this. Kumar > This test fails on all platforms since the integration of 8004727: > "Add compiler support for parameter reflection". > > The test fails to compile a dependent class > tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java: > AttributeVisitor is not abstract and does not override abstract method > visitMethodParameters(MethodParameters_attribute,Element) in Visitor > class AttributeVisitor implements Attribute.Visitor > > 8004727 added visitMethodParameters(MethodParameters_attribute attr, P > p) to class Attribute.Visitor, and AttributeVisitor, concrete > implementation of an Attribute.Visitor defined in ClassReader.java, > needs to correctly implement it. > > I would like to add tools/pack200/AttributeTests.java to the > ProblemList.txt until the issues with the test can be resolved. This > will most likely be done through 8005252, "pack200 should support > MethodParameters" > > > hg diff test/ProblemList.txt > diff -r 38b9a7646093 test/ProblemList.txt > --- a/test/ProblemList.txt Tue Jan 01 17:49:22 2013 -0800 > +++ b/test/ProblemList.txt Thu Jan 03 11:54:43 2013 +0000 > @@ -324,6 +324,9 @@ tools/pack200/Pack200Test.java > # 7150569 > tools/launcher/UnicodeTest.java macosx-all > > +# 8005252 > +tools/pack200/AttributeTests.java generic-all > + > > ############################################################################ > > > > -Chris. From stuart.marks at oracle.com Fri Jan 4 02:39:48 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 03 Jan 2013 18:39:48 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Message-ID: <50E640F4.20501@oracle.com> Hi all, Please review these additional RMI test cleanups: http://cr.openjdk.java.net/~smarks/reviews/7187882/webrev.0/ in service of fixing the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187882 The basic problem here is that tests were waiting for the JVM subprocess to exit, but not waiting for all output from the subprocess to be collected. The fix includes a bit of new infrastructure in RMI's test library and adjustment of several other tests to use it. Thanks, s'marks From amy.lu at oracle.com Fri Jan 4 02:46:58 2013 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 04 Jan 2013 10:46:58 +0800 Subject: Code review request 8005683: ProblemList.txt updates (01/2013) Message-ID: <50E642A2.3060202@oracle.com> Following issue has been fixed, related test should be removed from ProblemList: # 7194607 java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh generic-all Following test cause job hang and left running Server process, need to be put into ProblemList before the issue be fixed: # 8005472 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh Please review: http://dl.dropbox.com/u/5812451/yl153753/8005683/webrev.00/index.html Thanks, Amy From mandy.chung at oracle.com Fri Jan 4 03:15:10 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jan 2013 19:15:10 -0800 Subject: Code review request 8005683: ProblemList.txt updates (01/2013) In-Reply-To: <50E642A2.3060202@oracle.com> References: <50E642A2.3060202@oracle.com> Message-ID: <50E6493E.9010302@oracle.com> Amy - looks good. Mandy On 1/3/2013 6:46 PM, Amy Lu wrote: > Following issue has been fixed, related test should be removed from > ProblemList: > # 7194607 > java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh > generic-all > > Following test cause job hang and left running Server process, need to > be put into ProblemList before the issue be fixed: > # 8005472 > com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh > > > Please review: > http://dl.dropbox.com/u/5812451/yl153753/8005683/webrev.00/index.html > > Thanks, > Amy From Alan.Bateman at oracle.com Fri Jan 4 07:15:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jan 2013 07:15:47 +0000 Subject: Code review request 8005683: ProblemList.txt updates (01/2013) In-Reply-To: <50E642A2.3060202@oracle.com> References: <50E642A2.3060202@oracle.com> Message-ID: <50E681A3.6010200@oracle.com> On 04/01/2013 02:46, Amy Lu wrote: > Following issue has been fixed, related test should be removed from > ProblemList: > # 7194607 > java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh > generic-all > > Following test cause job hang and left running Server process, need to > be put into ProblemList before the issue be fixed: > # 8005472 > com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh > > > Please review: > http://dl.dropbox.com/u/5812451/yl153753/8005683/webrev.00/index.html Looks fine to me too. (I think Jaroslav has a fix for 8005472 coming, see: http://mail.openjdk.java.net/pipermail/jmx-dev/2012-December/000172.html) -Alan From Alan.Bateman at oracle.com Fri Jan 4 07:54:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jan 2013 07:54:39 +0000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50E48239.9070505@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> Message-ID: <50E68ABF.8090303@oracle.com> On 02/01/2013 18:53, Mandy Chung wrote: > > I reviewed the src/test changes in the jdk repo and have a few comments: > > Attributes.java: > 568 * {@code Name} object for {@code Profile} manifest attribute used > 569 * by applications packaged as JAR files to indicate the minimum > 570 * profile required to execute the application. > > The Profile attribute can be specified in both applications and > libraries. > Shoud L569 be changed with s/applications/applications or libraries? Thanks, this is more correct and will be in the next webrev. > > Pack200.java > I think the default implementation for addPropertyChangeListener > and removePropertyChangeListener requiring a non-null listener is > a right choice. On the other hand, I found that the current pack200 > implementation allows the given listener be null that seems to be > a bug and the Pack200 class spec also specifies to throw NPE if null > argument is passed to a method and looks like what you have Joe Darcy and I chatted about this recently and he suggested it would be better if the default method be a no-op (with no side effects). It's updated in the jdk8/profiles forest so should be in the next webrev. > > sun.misc.URLClassPath > L808: typo "attribtue" Fixed. > > L820: An empty "Profile" attribute is invalidand > Version.supportsProfile > returns false if requiredProfile parameter is empty even if the runtime > is a full JRE. This is fine but I was wondering if the exception > message > can indicate if the attribute value is invalid to help diagnosis. We could although I'm not sure how this could arise (as you can't set an empty profile name with the "p" option, and the "m" option to add/update a manifest also disallows empty values). > > L1000: looks like the convention is to use brackets even there is a > single statement in the if-statement body. Okay. > > sun.tools.jar.Main > It would be helpful if the jar tool checks if the input profile > name to the -p option is valid and outputs error. I considered this when updating the jar tool but decided at the time that it shouldn't know about the profile names. It would be easy to do of course. > > UnsupportedProfileException > L29: probably better to link to the javadoc > {@link Attributes.Name#Profile Profile} > L38 and 44: {@code UnsupportedProfileException} I've added {@code ...}. > > make/tools/src/build/tools/RemoveMethods.java > L100: maybe print the method signature rather than just 'name' > L106: typo "no longed" -> "no longer" Done. > > The tests are hardcoded with the profile name and uses > Version.profileName(). > Will there be a system property for the profile name? A supported property or API to indicate the profile has the potential to be problematic when we move to modules so it's not there. So far we haven't had any real need for it as applications can easily check for types to determine the profile. There are a few tests that do need to know the names but most of the new tests aren't dependent on the name. > > Otherwise, looks okay. Thanks for looking at it. I think David plans to send out an updated webrev in the next few days. -Alan. From chris.hegarty at oracle.com Fri Jan 4 11:25:38 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 04 Jan 2013 11:25:38 +0000 Subject: hg: jdk8/tl/jdk: 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Message-ID: <20130104112631.13C8B47551@hg.openjdk.java.net> Changeset: 438d37d16417 Author: chegar Date: 2013-01-04 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/438d37d16417 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Reviewed-by: mchung, ksrini ! test/ProblemList.txt From chris.hegarty at oracle.com Fri Jan 4 11:35:55 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 04 Jan 2013 11:35:55 +0000 Subject: hg: jdk8/tl/jdk: 8005638: Less secure Authentication schemes should work when more secure schemes are not available Message-ID: <20130104113607.6248D47552@hg.openjdk.java.net> Changeset: 6d814b2f9112 Author: chegar Date: 2013-01-04 11:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d814b2f9112 8005638: Less secure Authentication schemes should work when more secure schemes are not available Reviewed-by: alanb ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java From chris.hegarty at oracle.com Fri Jan 4 12:13:25 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 04 Jan 2013 12:13:25 +0000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50E68ABF.8090303@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> Message-ID: <50E6C765.1040104@oracle.com> I took a look over the jdk src and test changes. Given the comments below, it looks ok to me. -Chris. On 04/01/2013 07:54, Alan Bateman wrote: > On 02/01/2013 18:53, Mandy Chung wrote: >> >> I reviewed the src/test changes in the jdk repo and have a few comments: >> >> Attributes.java: >> 568 * {@code Name} object for {@code Profile} manifest attribute used >> 569 * by applications packaged as JAR files to indicate the minimum >> 570 * profile required to execute the application. >> >> The Profile attribute can be specified in both applications and >> libraries. >> Shoud L569 be changed with s/applications/applications or libraries? > Thanks, this is more correct and will be in the next webrev. > >> >> Pack200.java >> I think the default implementation for addPropertyChangeListener >> and removePropertyChangeListener requiring a non-null listener is >> a right choice. On the other hand, I found that the current pack200 >> implementation allows the given listener be null that seems to be >> a bug and the Pack200 class spec also specifies to throw NPE if null >> argument is passed to a method and looks like what you have > Joe Darcy and I chatted about this recently and he suggested it would be > better if the default method be a no-op (with no side effects). It's > updated in the jdk8/profiles forest so should be in the next webrev. > > >> >> sun.misc.URLClassPath >> L808: typo "attribtue" > Fixed. > >> >> L820: An empty "Profile" attribute is invalidand Version.supportsProfile >> returns false if requiredProfile parameter is empty even if the runtime >> is a full JRE. This is fine but I was wondering if the exception message >> can indicate if the attribute value is invalid to help diagnosis. > We could although I'm not sure how this could arise (as you can't set an > empty profile name with the "p" option, and the "m" option to add/update > a manifest also disallows empty values). > >> >> L1000: looks like the convention is to use brackets even there is a >> single statement in the if-statement body. > Okay. > >> >> sun.tools.jar.Main >> It would be helpful if the jar tool checks if the input profile >> name to the -p option is valid and outputs error. > I considered this when updating the jar tool but decided at the time > that it shouldn't know about the profile names. It would be easy to do > of course. > >> >> UnsupportedProfileException >> L29: probably better to link to the javadoc >> {@link Attributes.Name#Profile Profile} >> L38 and 44: {@code UnsupportedProfileException} > I've added {@code ...}. > >> >> make/tools/src/build/tools/RemoveMethods.java >> L100: maybe print the method signature rather than just 'name' >> L106: typo "no longed" -> "no longer" > Done. > >> >> The tests are hardcoded with the profile name and uses >> Version.profileName(). >> Will there be a system property for the profile name? > A supported property or API to indicate the profile has the potential to > be problematic when we move to modules so it's not there. So far we > haven't had any real need for it as applications can easily check for > types to determine the profile. There are a few tests that do need to > know the names but most of the new tests aren't dependent on the name. > >> >> Otherwise, looks okay. > Thanks for looking at it. I think David plans to send out an updated > webrev in the next few days. > > -Alan. From jviswana at linux.vnet.ibm.com Fri Jan 4 14:16:46 2013 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Fri, 04 Jan 2013 19:46:46 +0530 Subject: Review Request : Java exe doesn't process args ending Back slash In-Reply-To: <50D20960.8080300@oracle.com> References: <50D1F3D7.20608@linux.vnet.ibm.com> <50D1FA7E.8040609@linux.vnet.ibm.com> <50D20960.8080300@oracle.com> Message-ID: <50E6E44E.7090105@linux.vnet.ibm.com> On 20-12-2012 12:07 AM, Kumar Srinivasan wrote: > Hello Jayashree, > > a. you are referencing a bug which has already been fixed, is there a > new one for this ? > > b. with regards to the fix, I don't quite understand the issue, could > you please > provide a use case ? > > c. your regression test does not seem to be accurate it behaves the > same with or > without your fix, also you will need to provide a C++ test case in > cmdtoargs.c > as well see the bottom of that file. > > > Thanks > Kumar > > > >> >> >> Hi All, >> >> Java.exe doesn't seems to process arguments ending with back slashes >> well , in windows only . >> >> I have added test scenario and changeset in the below webrev . >> >> http://cr.openjdk.java.net/~jviswana/7188114/webrev.01/ >> >> This seems to be introduced after the bug fix for 7188114 has be made >> into jdk8 . >> >> Thanks and Regards, >> Jayashree Viswanathan >> >> >> >> > Hi Kumar , a. I am referencing an old bug because , that bug fix has caused this regression . b. The use case is when there are backslashes at the end args for a java command using say -Dtest.argEndingInBackslash=a\\\\ JavaVM args: version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 5 option[ 0] = '-Dsun.java.launcher.diag=true' option[ 1] = '-Djava.class.path=.' option[ 2] = '-Dtest.argEndingInBackslash=a' option[ 3] = '-Dsun.java.command=TestCmdLineParsing' option[ 4] = '-Dsun.java.launcher=SUN_STANDARD' 74439 micro seconds to InitializeJVM Main class is 'TestCmdLineParsing' App's argc is 0 9182 micro seconds to load main class ----_JAVA_LAUNCHER_DEBUG---- value of test.argEndingInBackslash = a c. Sorry , I seem to have missed something , the above test case should help you exhibit the problem . Can you please let me know where to find or add such C++ test cases , as In the test cases bucket I know off is jtreg or JCKs only at the moment . Thanks and Regards, Jayashree Viswanathan From daniel.fuchs at oracle.com Fri Jan 4 14:31:19 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 04 Jan 2013 15:31:19 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50D18CC0.3080308@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> Message-ID: <50E6E7B7.1030708@oracle.com> Hi guys, Happy new year to you all! And apologies for this long email :-) I think we still haven't converged on this issue in javax.xml.stream - so let me make a recap. The issue is for the newInstance/newFactory methods that take a factoryId parameter, in the factories for the javax.xml.stream package: [ FactoryFinder.java: line 267-268 right hand side. ] recap of the issue: ------------------- In case the provided factoryId did not correspond to any System/JAXP/StAX property, the old code used to look for a service in META-INF/services using the factoryId as the name of the file for looking up the implementation class. In case factoryId was not the same as the base service class (or a subclass of it) it still would have worked although it went in contradiction to the Jar Specification mentioned in the javadoc, since the Jar Specification clearly states that the file name should be the fully qualified name of the base service class. Since we're going to replace the code that looked up for a service in META-INF with a call to ServiceLoader, we can no longer fully preserve that old behavior, because ServiceLoader only takes a base service class (and no arbitrary file name). what choices do we have? ------------------------ The question is therefore how we want to change this. I think we have 4 (exclusive) possibilities. In the case where a factoryId is provided, but no System/JAXP/StAX property by that name has been found, we could choose to either: 1. Always call ServiceLoader.load(type) where type is the service base class. 2. Never call ServiceLoader.load(type) 3. Only call ServiceLoader.load(type) when the provided factoryId is equal to type.getName() 4. If factoryId is equal to type.getName(), call ServiceLoader.load(type), otherwise, attempt to load factoryId as a class - and if that class is a subclass of 'type' then call ServiceLoader.load for that subclass. pros & cons: ------------ Here is a list of pros & cons for each of these options: 1. is the naive implementation I originally proposed. Pros: - P1.1: simple - P1.2: no change in behavior if factoryId == type.getName() Cons: - C1.1: may find no provider when the old code used to find one, (case where factoryId="foo", there's a provider for "foo" and there's no provider for type.getName()) - C1.2: may find a provider when the old code used to find none (case where factoryId="foo", there's no provider for foo, but there's a provider for type.getName()) - C1.3: may find a different provider than what the old code use to find (case where factoryId="foo", there's a provider for "foo" and there's also a provider for type.getName()) 2. is more drastic: if you specify a property - then the property has to be defined somewhere for newInstance/newFactory to succeed. Pros: - P2.1: simple Cons: - C2.1: there's a change of behavior even when factoryId == type.getName() and no property by that name is defined. - C2.2: in all cases where the old code used to find a provider by looking at META-INF/services, the new code will find nothing. Although it's the most simple - it's probably the most risky in terms of compatibility. 3. Same as 1. except that C1.2 and C1.3 are removed. 4. Same as 3. except that it's more complex (so P1.1 is removed) and that C1.1 will not occur in the case where factoryId is the name of a subclass of 'type' In conclusion: -------------- Since the original spec only says that factoryId is "same as property" - it's very difficult to figure out which of these 4 options is the closer to the behavior intended by the spec. I personally think that the case where factoryId="foo", and no property "foo" is defined, but a provider exists for "foo" and an implementation is returned, is a bug - since it's in contradiction with the Jar Specification mentioned in the spec which clearly states that "foo" should have been a service class name. So although 4. is the implementation that would offer the greater compatibility with existing code, I am sorely tempted to recommend that we do 3. and clarify the spec on this point. (3: Only call ServiceLoader.load(type) when the provided factoryId is equal to type.getName()) Best regards, -- daniel On 12/19/12 10:45 AM, Daniel Fuchs wrote: > On 12/19/12 12:10 AM, Joe Wang wrote: >> It's different. If 'foo.bar' is specified but not found, it indicates >> a configuration error. If the factory falls back to an impl by the >> default factory id, it would serve to hide the error. > Yes - I fully agree with that. >> Note that newInstance/newFactory with a factoryId parameter do not >> fall back to the default implementation. > Ahh! Yes I missed that. When called from newInstance with a factoryId > parameter the fallbackClassname parameter > is null... > > So should we still call ServiceLoader when fallbackClassname is null and > factoryId is type.getName()? It would be more > backward compatible - since previously it was looking in the jars and > found (valid) providers registered with that name. > > On the other hand we could alter the spec to say that if no property > with the factoryId name is found - then > no fallback loading is perform (either on ServiceLoader or > system-default implementation) and an error is thrown. > > -- daniel From kumar.x.srinivasan at oracle.com Fri Jan 4 16:52:37 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 04 Jan 2013 08:52:37 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> Message-ID: <50E708D5.9030304@oracle.com> David, It is looking good, a couple of comments and requests: 1. LauncherHelper.java: Can you please document the table below in LauncherHelper.java, and a note to refer to LauncherHelper.java in FXLauncherTest.java this will make it easier to understand everything in the future. 2. FXLauncherTest.java a. testExtraneousJars, you have changed the cmd from javac to java using a java class, thus this error message is not accurate: throw new Exception("jfxrt.jar is being loaded by javac!!!"); b. The case of -jar with no JAC is being commented out ? I take it this is redundant now ? Does this need to present ? or a todo for later ? If so please comment it appropriately. // Todo: blah // testBasic...... or /* * Redundant but can be used iff ..... * ....... */ Kumar > [adding core-libs-dev back in.. not sure how that got lost] > >> [Back from vacation, let's get the ball rolling again? :] >> >>> In order to understand and explain here is a truth table: >>> >>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >>> java -jar fxapp.jar Present LM_JAR LM_JAR >>> java -jar fxapp.jar Not present LM_JAR LM_CLASS ?? >>> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >>> java -cp somedir ... Not present LM_CLASS LM_CLASS >>> >>> If I am understanding this correctly, the confusion stems from the second case where the >>> value is interpreted in different ways. >> Correct. I have actually changed it to fix this case, and IMHO it cleans up the launcher code a bit.. I'll post the webrev when I'm done syncing with TL. > The current patch I have: > http://cr.openjdk.java.net/~ddehaven/8004547/webrev.2/ > > Minor change to accommodate this in FX LauncherImpl (needs a new JIRA issue?): > http://cr.openjdk.java.net/~ddehaven/javafx/RT-26751/webrev.2/ > > This was all working fine when I left for vacation, I'm still in the process of building/testing everything and will submit a JPRT run as soon as possible. > > I had commented out two tests, but FX is in sync with JDK *and* they'll pass vacuously until FX is on the ext classpath anyways so I don't think that's necessary. > > -DrD- > From darryl.mocek at oracle.com Fri Jan 4 17:24:19 2013 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 04 Jan 2013 09:24:19 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently In-Reply-To: <50E640F4.20501@oracle.com> References: <50E640F4.20501@oracle.com> Message-ID: <50E71043.2050806@oracle.com> Hey Stuart, the changes look good to me, although I didn't apply the patch and run the tests. The only comment I have is to update all copyrights to 2013. Darryl On 01/03/2013 06:39 PM, Stuart Marks wrote: > > Hi all, > > Please review these additional RMI test cleanups: > > http://cr.openjdk.java.net/~smarks/reviews/7187882/webrev.0/ > > in service of fixing the following bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187882 > > The basic problem here is that tests were waiting for the JVM > subprocess to exit, but not waiting for all output from the subprocess > to be collected. The fix includes a bit of new infrastructure in RMI's > test library and adjustment of several other tests to use it. > > Thanks, > > s'marks From chris.hegarty at oracle.com Fri Jan 4 17:34:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 04 Jan 2013 17:34:13 +0000 Subject: RFR 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Message-ID: <50E71295.9040608@oracle.com> Trivially, add @since 1.8 tags to the two new ForkJoinPool methods in 1.8. diff -r 6d814b2f9112 src/share/classes/java/util/concurrent/ForkJoinPool.java --- a/src/share/classes/java/util/concurrent/ForkJoinPool.java Fri Jan 04 11:34:17 2013 +0000 +++ b/src/share/classes/java/util/concurrent/ForkJoinPool.java Fri Jan 04 17:30:41 2013 +0000 @@ -2611,6 +2611,7 @@ public class ForkJoinPool extends Abstra * {@link #shutdown} or {@link #shutdownNow}. * * @return the common pool instance + * @since 1.8 */ public static ForkJoinPool commonPool() { // assert commonPool != null : "static init error"; @@ -2793,6 +2794,7 @@ public class ForkJoinPool extends Abstra * Returns the targeted parallelism level of the common pool. * * @return the targeted parallelism level of the common pool + * @since 1.8 */ public static int getCommonPoolParallelism() { return commonPoolParallelism; -Chris. From david.dehaven at oracle.com Fri Jan 4 17:46:59 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 4 Jan 2013 09:46:59 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: <50E708D5.9030304@oracle.com> References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> <50E708D5.9030304@oracle.com> Message-ID: <7650DA8C-7DDF-45C3-B343-2F485199D057@oracle.com> [pardon the data shuffle?] >>>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >>>> java -jar fxapp.jar Present LM_JAR LM_JAR >>>> java -jar fxapp.jar Not present LM_JAR [LM_JAR] >>>> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >>>> java -cp somedir ... Not present LM_CLASS LM_CLASS > It is looking good, a couple of comments and requests: > 1. LauncherHelper.java: Can you please document the table below in > LauncherHelper.java, and a note to refer to LauncherHelper.java in > FXLauncherTest.java this will make it easier to understand everything > in the future. Can do. > 2. FXLauncherTest.java > > a. testExtraneousJars, you have changed the cmd from javac to java > using a java class, thus this error message is not accurate: > > throw new Exception("jfxrt.jar is being loaded by javac!!!"); Will fix the error message. > b. The case of -jar with no JAC is being commented out ? I take it this > is redundant now ? Does this need to present ? or a todo for later ? > If so please comment it appropriately. > // Todo: blah > // testBasic...... > > or > > /* > * Redundant but can be used iff ..... > * ....... > */ That's what my final comment was about in my email: >> I had commented out two tests, but FX is in sync with JDK *and* they'll pass vacuously until FX is on the ext classpath anyways so I don't think that's necessary. I've uncommented them since it should be fine as long as the corresponding FX change gets into the same promotion. -DrD- From huizhe.wang at oracle.com Fri Jan 4 18:51:33 2013 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 04 Jan 2013 10:51:33 -0800 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50E6E7B7.1030708@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> Message-ID: <50E724B5.1030408@oracle.com> Hi Daniel, Yes, I agree with 3. As I said before, we should return an error if factoryId != type.getName() since it indicates a configuration error. Scenario 4 does exist, but it's beyond the current spec. Such an impl should not use the default API. The StAX spec is not always clear. My interpretation of the definition of factoryId to be the "same as a property name" is that the author basically was saying that it's equivalent to a name as in a property, not the "value", therefore different from the DOM/SAX API -- a bad choice I would think. Thanks, Joe On 1/4/2013 6:31 AM, Daniel Fuchs wrote: > Hi guys, > > Happy new year to you all! And apologies for this long email :-) > > I think we still haven't converged on this issue in > javax.xml.stream - so let me make a recap. > > The issue is for the newInstance/newFactory methods > that take a factoryId parameter, in the factories for > the javax.xml.stream package: > > [ > > FactoryFinder.java: line 267-268 right hand side. ] > > > recap of the issue: > ------------------- > > In case the provided factoryId did not correspond to any > System/JAXP/StAX property, the old code used to look > for a service in META-INF/services using the factoryId as the > name of the file for looking up the implementation class. > In case factoryId was not the same as the base service > class (or a subclass of it) it still would have worked > although it went in contradiction to the Jar Specification > mentioned in the javadoc, since the Jar Specification clearly > states that the file name should be the fully qualified name > of the base service class. > > Since we're going to replace the code that looked up for > a service in META-INF with a call to ServiceLoader, we can > no longer fully preserve that old behavior, because ServiceLoader > only takes a base service class (and no arbitrary file name). > > what choices do we have? > ------------------------ > > The question is therefore how we want to change this. > I think we have 4 (exclusive) possibilities. > > In the case where a factoryId is provided, but no > System/JAXP/StAX property by that name has been found, > we could choose to either: > > 1. Always call ServiceLoader.load(type) where type is the > service base class. > > 2. Never call ServiceLoader.load(type) > > 3. Only call ServiceLoader.load(type) when the provided > factoryId is equal to type.getName() > > 4. If factoryId is equal to type.getName(), call > ServiceLoader.load(type), otherwise, > attempt to load factoryId as a class - and if that > class is a subclass of 'type' then call > ServiceLoader.load for that subclass. > > pros & cons: > ------------ > > Here is a list of pros & cons for each of these options: > > 1. is the naive implementation I originally proposed. > Pros: > - P1.1: simple > - P1.2: no change in behavior if factoryId == type.getName() > Cons: > - C1.1: may find no provider when the old code used to > find one, (case where factoryId="foo", there's a > provider for "foo" and there's no provider for type.getName()) > - C1.2: may find a provider when the old code used to > find none (case where factoryId="foo", there's no provider > for foo, but there's a provider for type.getName()) > - C1.3: may find a different provider than what the old > code use to find (case where factoryId="foo", there's a > provider for "foo" and there's also a provider for > type.getName()) > > 2. is more drastic: if you specify a property - then the property > has to be defined somewhere for newInstance/newFactory to > succeed. > Pros: > - P2.1: simple > Cons: > - C2.1: there's a change of behavior even when > factoryId == type.getName() and no property by that > name is defined. > - C2.2: in all cases where the old code used to find a > provider by looking at META-INF/services, the new code > will find nothing. > Although it's the most simple - it's probably the most risky > in terms of compatibility. > > 3. Same as 1. except that C1.2 and C1.3 are removed. > > 4. Same as 3. except that it's more complex (so P1.1 is > removed) and that C1.1 will not occur in the case > where factoryId is the name of a subclass of 'type' > > In conclusion: > -------------- > > Since the original spec only says that factoryId is > "same as property" - it's very difficult to figure out > which of these 4 options is the closer to the behavior > intended by the spec. > > I personally think that the case where factoryId="foo", > and no property "foo" is defined, but a provider exists for > "foo" and an implementation is returned, is a bug - since > it's in contradiction with the Jar Specification mentioned > in the spec which clearly states that "foo" should > have been a service class name. > > So although 4. is the implementation that would offer the > greater compatibility with existing code, I am sorely > tempted to recommend that we do 3. and clarify > the spec on this point. > (3: Only call ServiceLoader.load(type) when the provided > factoryId is equal to type.getName()) > > Best regards, > > -- daniel > > On 12/19/12 10:45 AM, Daniel Fuchs wrote: >> On 12/19/12 12:10 AM, Joe Wang wrote: >>> It's different. If 'foo.bar' is specified but not found, it indicates >>> a configuration error. If the factory falls back to an impl by the >>> default factory id, it would serve to hide the error. >> Yes - I fully agree with that. >>> Note that newInstance/newFactory with a factoryId parameter do not >>> fall back to the default implementation. >> Ahh! Yes I missed that. When called from newInstance with a factoryId >> parameter the fallbackClassname parameter >> is null... >> >> So should we still call ServiceLoader when fallbackClassname is null and >> factoryId is type.getName()? It would be more >> backward compatible - since previously it was looking in the jars and >> found (valid) providers registered with that name. >> >> On the other hand we could alter the spec to say that if no property >> with the factoryId name is found - then >> no fallback loading is perform (either on ServiceLoader or >> system-default implementation) and an error is thrown. >> >> -- daniel > From martinrb at google.com Fri Jan 4 18:54:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 4 Jan 2013 10:54:30 -0800 Subject: RFR 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool In-Reply-To: <50E71295.9040608@oracle.com> References: <50E71295.9040608@oracle.com> Message-ID: Many moons ago, I wrote a script to find missing @since tags in the JDK, that may still be floating around somewhere in openjdk-land. On Fri, Jan 4, 2013 at 9:34 AM, Chris Hegarty wrote: > Trivially, add @since 1.8 tags to the two new ForkJoinPool methods in 1.8. > From david.dehaven at oracle.com Fri Jan 4 20:27:00 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 4 Jan 2013 12:27:00 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: <7650DA8C-7DDF-45C3-B343-2F485199D057@oracle.com> References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> <50E708D5.9030304@oracle.com> <7650DA8C-7DDF-45C3-B343-2F485199D057@oracle.com> Message-ID: >>>>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >>>>> java -jar fxapp.jar Present LM_JAR LM_JAR >>>>> java -jar fxapp.jar Not present LM_JAR [LM_JAR] >>>>> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >>>>> java -cp somedir ... Not present LM_CLASS LM_CLASS I didn't see any reliable means of testing the last case without further changes to TestHelper.java, is it that important? The code path through LauncherHelper.java should be the same for either -cp case. I can add the test case if it's important, but that will require changes to TestHelper.java to allow compiling to a directory without creating a jar file. -DrD- From kumar.x.srinivasan at oracle.com Fri Jan 4 21:11:32 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 04 Jan 2013 13:11:32 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> <50E708D5.9030304@oracle.com> <7650DA8C-7DDF-45C3-B343-2F485199D057@oracle.com> Message-ID: <50E74584.2090107@oracle.com> On 1/4/2013 12:27 PM, David DeHaven wrote: >>>>>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >>>>>> java -jar fxapp.jar Present LM_JAR LM_JAR >>>>>> java -jar fxapp.jar Not present LM_JAR [LM_JAR] >>>>>> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >>>>>> java -cp somedir ... Not present LM_CLASS LM_CLASS > I didn't see any reliable means of testing the last case without further changes to TestHelper.java, is it that important? The code path through LauncherHelper.java should be the same for either -cp case. I can add the test case if it's important, but that will require changes to TestHelper.java to allow compiling to a directory without creating a jar file. -cp fxapp.jar should be sufficient for this, this is more sensitive to the launcher itself, and is tested thoroughly in Arrrghs.java and elsewhere. Kumar > > -DrD- > From david.dehaven at oracle.com Fri Jan 4 23:10:59 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 4 Jan 2013 15:10:59 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: <50E74584.2090107@oracle.com> References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> <50E708D5.9030304@oracle.com> <7650DA8C-7DDF-45C3-B343-2F485199D057@oracle.com> <50E74584.2090107@oracle.com> Message-ID: >>>>>>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >>>>>>> java -jar fxapp.jar Present LM_JAR LM_JAR >>>>>>> java -jar fxapp.jar Not present LM_JAR [LM_JAR] >>>>>>> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >>>>>>> java -cp somedir ... Not present LM_CLASS LM_CLASS >> I didn't see any reliable means of testing the last case without further changes to TestHelper.java, is it that important? The code path through LauncherHelper.java should be the same for either -cp case. I can add the test case if it's important, but that will require changes to TestHelper.java to allow compiling to a directory without creating a jar file. > > -cp fxapp.jar should be sufficient for this, this is more sensitive to the launcher itself, > and is tested thoroughly in Arrrghs.java and elsewhere. In that case, the only changes I have are the changes you requested earlier. If there are no further objections can we call this done? Latest webrev: http://cr.openjdk.java.net/~ddehaven/8004547/webrev.3/ -DrD- From stuart.marks at oracle.com Sat Jan 5 00:17:57 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Sat, 05 Jan 2013 00:17:57 +0000 Subject: hg: jdk8/tl/jdk: 8005683: ProblemList.txt updates (01/2013) Message-ID: <20130105001818.60DFF4756A@hg.openjdk.java.net> Changeset: 92c3b24a8e9a Author: smarks Date: 2013-01-04 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92c3b24a8e9a 8005683: ProblemList.txt updates (01/2013) Reviewed-by: mchung, alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From stuart.marks at oracle.com Sat Jan 5 00:24:02 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 04 Jan 2013 16:24:02 -0800 Subject: Code review request 8005683: ProblemList.txt updates (01/2013) In-Reply-To: <50E642A2.3060202@oracle.com> References: <50E642A2.3060202@oracle.com> Message-ID: <50E772A2.4050507@oracle.com> I've pushed this as: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92c3b24a8e9a s'marks On 1/3/13 6:46 PM, Amy Lu wrote: > Following issue has been fixed, related test should be removed from ProblemList: > # 7194607 > java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh generic-all > > Following test cause job hang and left running Server process, need to be put > into ProblemList before the issue be fixed: > # 8005472 > com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh > > Please review: > http://dl.dropbox.com/u/5812451/yl153753/8005683/webrev.00/index.html > > Thanks, > Amy From mandy.chung at oracle.com Sat Jan 5 00:38:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 04 Jan 2013 16:38:24 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently In-Reply-To: <50E640F4.20501@oracle.com> References: <50E640F4.20501@oracle.com> Message-ID: <50E77600.1030306@oracle.com> It is a good cleanup and the change looks okay to me. I'll count on your testing to verify if this fixes the intermittent problem :) StreamPipe.run() catches InterruptedIOException and IOException and ignores the error. Is it safe? Are the tests expected to fail in some other way (missing output?). Should it (or waitFor method) throw a RuntimeException instead if any such exception is thrown? Just curious - Is this intermittent test failure easy to reproduce? Thanks Mandy On 1/3/2013 6:39 PM, Stuart Marks wrote: > > Hi all, > > Please review these additional RMI test cleanups: > > http://cr.openjdk.java.net/~smarks/reviews/7187882/webrev.0/ > > in service of fixing the following bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187882 > > The basic problem here is that tests were waiting for the JVM > subprocess to exit, but not waiting for all output from the subprocess > to be collected. The fix includes a bit of new infrastructure in RMI's > test library and adjustment of several other tests to use it. > > Thanks, > > s'marks From stuart.marks at oracle.com Sat Jan 5 00:42:04 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 04 Jan 2013 16:42:04 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently In-Reply-To: <50E71043.2050806@oracle.com> References: <50E640F4.20501@oracle.com> <50E71043.2050806@oracle.com> Message-ID: <50E776DC.7030408@oracle.com> Hi Darryl, Thanks for looking. Was it last year already that I developed this patch? Sheesh! :-) s'marks On 1/4/13 9:24 AM, Darryl Mocek wrote: > Hey Stuart, > > the changes look good to me, although I didn't apply the patch and run the > tests. The only comment I have is to update all copyrights to 2013. > > Darryl > > On 01/03/2013 06:39 PM, Stuart Marks wrote: >> >> Hi all, >> >> Please review these additional RMI test cleanups: >> >> http://cr.openjdk.java.net/~smarks/reviews/7187882/webrev.0/ >> >> in service of fixing the following bug: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187882 >> >> The basic problem here is that tests were waiting for the JVM subprocess to >> exit, but not waiting for all output from the subprocess to be collected. The >> fix includes a bit of new infrastructure in RMI's test library and adjustment >> of several other tests to use it. >> >> Thanks, >> >> s'marks > From kumar.x.srinivasan at oracle.com Sat Jan 5 01:01:59 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 04 Jan 2013 17:01:59 -0800 Subject: RFR 8004547: Extend JavaFX launcher support... In-Reply-To: References: <303CEFBB-9D1F-4D39-812F-EFA079B9BB8C@oracle.com> <50D406BB.7050100@oracle.com> <3417CACD-506E-4C4E-A8AA-13160C868D3F@oracle.com> <50D48AB3.9060408@oracle.com> <50D49FFE.9020108@oracle.com> <50D51275.9000600@oracle.com> <50D8F9FA.6090605@oracle.com> <11CC3A29-1BB9-488C-A280-3AB2847844F4@oracle.com> <50E708D5.9030304@oracle.com> <7650DA8C-7DDF-45C3-B343-2F485199D057@oracle.com> <50E74584.2090107@oracle.com> Message-ID: <50E77B87.2040902@oracle.com> On 1/4/2013 3:10 PM, David DeHaven wrote: >>>>>>>> Cmd line FAC LAUNCH_MODE JAVAFX_LAUNCH_MODE >>>>>>>> java -jar fxapp.jar Present LM_JAR LM_JAR >>>>>>>> java -jar fxapp.jar Not present LM_JAR [LM_JAR] >>>>>>>> java -cp fxapp.jar ... Not present LM_CLASS LM_CLASS >>>>>>>> java -cp somedir ... Not present LM_CLASS LM_CLASS >>> I didn't see any reliable means of testing the last case without further changes to TestHelper.java, is it that important? The code path through LauncherHelper.java should be the same for either -cp case. I can add the test case if it's important, but that will require changes to TestHelper.java to allow compiling to a directory without creating a jar file. >> -cp fxapp.jar should be sufficient for this, this is more sensitive to the launcher itself, >> and is tested thoroughly in Arrrghs.java and elsewhere. > In that case, the only changes I have are the changes you requested earlier. If there are no further objections can we call this done? I approve the change with the following adjustments. small nit indenting.... + * java -cp fxapp.jar MainClass N/A LM_CLASS LM_CLASS actually I prefer the that table in LauncherHelper.java in the FXHelper inner class I don't need to see another webrev only for this. Thanks Kumar > > Latest webrev: > http://cr.openjdk.java.net/~ddehaven/8004547/webrev.3/ > > -DrD- > From bhavesh.x.patel at oracle.com Sat Jan 5 07:07:57 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sat, 05 Jan 2013 07:07:57 +0000 Subject: hg: jdk8/tl/langtools: 8004891: Check for abstract method in javadoc does not conform to the language model Message-ID: <20130105070802.29B1847575@hg.openjdk.java.net> Changeset: 0e17c3c23e3b Author: bpatel Date: 2013-01-04 23:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e17c3c23e3b 8004891: Check for abstract method in javadoc does not conform to the language model Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java + test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java + test/com/sun/javadoc/testAbstractMethod/pkg/A.java + test/com/sun/javadoc/testAbstractMethod/pkg/B.java + test/com/sun/javadoc/testAbstractMethod/pkg/C.java From bhavesh.x.patel at oracle.com Sat Jan 5 08:56:51 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sat, 05 Jan 2013 08:56:51 +0000 Subject: hg: jdk8/tl/langtools: 8005092: javadoc should check for synthesized bit on an annotation Message-ID: <20130105085653.85E6B47578@hg.openjdk.java.net> Changeset: 8c0c63a6e3b7 Author: bpatel Date: 2013-01-05 00:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c0c63a6e3b7 8005092: javadoc should check for synthesized bit on an annotation Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java From chris.hegarty at oracle.com Sat Jan 5 15:33:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 5 Jan 2013 15:33:14 +0000 Subject: RFR 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool In-Reply-To: References: <50E71295.9040608@oracle.com> Message-ID: On 4 Jan 2013, at 18:54, Martin Buchholz wrote: > Many moons ago, I wrote a script to find missing @since tags in the JDK, that may still be floating around somewhere in openjdk-land. Sorry Martin, I'm wasn't aware of it. I'll see if it can be found. I see these changes have been pushed to Doug's CVS. I assume you are ok with the change? -Chris > On Fri, Jan 4, 2013 at 9:34 AM, Chris Hegarty wrote: >> Trivially, add @since 1.8 tags to the two new ForkJoinPool methods in 1.8. From dl at cs.oswego.edu Sat Jan 5 15:39:44 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 05 Jan 2013 10:39:44 -0500 Subject: RFR 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool In-Reply-To: References: <50E71295.9040608@oracle.com> Message-ID: <50E84940.1000103@cs.oswego.edu> On 01/05/13 10:33, Chris Hegarty wrote: > On 4 Jan 2013, at 18:54, Martin Buchholz wrote: > >> Many moons ago, I wrote a script to find missing @since tags in the JDK, that may still be floating around somewhere in openjdk-land. > > Sorry Martin, I'm wasn't aware of it. I'll see if it can be found. > > I see these changes have been pushed to Doug's CVS. I assume you are ok with the change? > Yes, you don't have to even bother asking about little things like this :-) -Doug From chris.hegarty at oracle.com Sat Jan 5 17:08:28 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Jan 2013 17:08:28 +0000 Subject: hg: jdk8/tl/jdk: 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Message-ID: <20130105170901.C712947579@hg.openjdk.java.net> Changeset: 0c89465b656a Author: chegar Date: 2013-01-05 17:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c89465b656a 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Reviewed-by: dl ! src/share/classes/java/util/concurrent/ForkJoinPool.java From chris.hegarty at oracle.com Sat Jan 5 18:10:52 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 05 Jan 2013 18:10:52 +0000 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Message-ID: <50E86CAC.8090606@oracle.com> As part of JEP 155 we are proposing to add the following public classes to support Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator and LongAdder. These have been written by Doug Lea, with assistance from members of the former JCP JSR-166 Expert Group. Webrev and javadoc are at: http://cr.openjdk.java.net/~chegar/8005311/ver.00/ Since Doug is the author, I am taking a reviewer/sponsor role. Here are my initial comments. - There are various places in DoubleAccmulator where there are broken links to #sum ( I think it is just a cut'n'paste error ). These should be #get. - Accumulators {@link #get} may read somewhat better as {@link #get current value} ?? - Accumulators Does the 'identity' value need further explanation? Note: There is one minor change to the implementation. Currently in the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble. This method has been renamed to applyAsDouble in the lambda/lambda repo. When these changes are sync'ed from lambda/lambda this can be reverted. A similar comment has been added to the code. -Chris. From martinrb at google.com Sat Jan 5 19:14:24 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 5 Jan 2013 11:14:24 -0800 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E86CAC.8090606@oracle.com> References: <50E86CAC.8090606@oracle.com> Message-ID: On Sat, Jan 5, 2013 at 10:10 AM, Chris Hegarty wrote: > - Accumulators > Does the 'identity' value need further explanation? > I think so. A brief introduction to accumulation/reduction seems appropriate. From dl at cs.oswego.edu Sat Jan 5 19:22:38 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 05 Jan 2013 14:22:38 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: References: <50E86CAC.8090606@oracle.com> Message-ID: <50E87D7E.6060806@cs.oswego.edu> On 01/05/13 14:14, Martin Buchholz wrote: > > > On Sat, Jan 5, 2013 at 10:10 AM, Chris Hegarty > wrote: > > - Accumulators Does the 'identity' value need further explanation? > > > I think so. A brief introduction to accumulation/reduction seems > appropriate. I'm sure the lambda-libs folks will someday provide a nice one we can link to here :-) On 01/05/13 13:10, Chris Hegarty wrote: > Note: There is one minor change to the implementation. Currently in the jdk8 > repo j.u.f.DoubleBinaryOperator defines operateAsDouble. This method has > been renamed to applyAsDouble in the lambda/lambda repo. When these changes > are sync'ed from lambda/lambda this can be reverted. A similar comment has > been added to the code. I suspect that there will a lot of this sort of thing over the next several months. It is probably still worthwhile to establish these classes for the sake of integration checks, but we'll surely need a bunch more sync-ups for JDK8. -Doug From chris.hegarty at oracle.com Sat Jan 5 19:54:35 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 5 Jan 2013 19:54:35 +0000 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E87D7E.6060806@cs.oswego.edu> References: <50E86CAC.8090606@oracle.com> <50E87D7E.6060806@cs.oswego.edu> Message-ID: <14F7D82E-2D63-4788-A389-1EAE9B843A1E@oracle.com> > On 01/05/13 13:10, Chris Hegarty wrote: > >> Note: There is one minor change to the implementation. Currently in the jdk8 >> repo j.u.f.DoubleBinaryOperator defines operateAsDouble. This method has >> been renamed to applyAsDouble in the lambda/lambda repo. When these changes >> are sync'ed from lambda/lambda this can be reverted. A similar comment has >> been added to the code. > > I suspect that there will a lot of this sort of thing over the > next several months. It is probably still worthwhile to > establish these classes for the sake of integration checks, Agreed. > but we'll surely need a bunch more sync-ups for JDK8. This is no problem. I just thought it was worth mentioning. -Chris > > -Doug > From martinrb at google.com Sat Jan 5 20:10:04 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 5 Jan 2013 12:10:04 -0800 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E86CAC.8090606@oracle.com> References: <50E86CAC.8090606@oracle.com> Message-ID: I did a bit of review. ---- """The supplied accumulator function must be side-effect-free. It may be re-applied when attempted updates fail due to contention among threads. """ Too strong. I prefer """The supplied accumulator function should be side-effect-free, since it may be re-applied when attempted updates fail due to contention among threads. """ Users can usefully use side effects for e.g. performance monitoring or debugging. ---- Double.MINIMUM_VALUE - WAT? The alternative Double.MIN_VALUE actually exists, but is also inappropriate, since it's positive. Why not Double.NEGATIVE_INFINITY, which is a true identity for max (ignoring NaN)? ---- Chris, the internal links in your generated javadoc are broken, e.g. I clicked on http://cr.openjdk.java.net/java/util/concurrent/atomic/DoubleAccumulator.html#reset() Maybe the webrev tool needs fixing (as always?) ? ---- There need to be more docs on the requirements on the accumulatorFunction, e.g. associative/commutative? ---- """ public void reset() Resets variables maintaining updates the given value. """ That sentence english not. There is no "given value". Perhaps "Resets variables maintaining the accumulated value to the identity.""" ---- Class DoubleAdder provides analogs of the functionality of this class for the common special case of maintaining sums.) I would add a code sample showing how to create a DoubleAccumulator equivalent to a DoubleAdder. ---- but does not define methods such as hashCode and compareTo I would include equals in that list of methods. ---- From dl at cs.oswego.edu Sat Jan 5 21:01:17 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 05 Jan 2013 16:01:17 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: References: <50E86CAC.8090606@oracle.com> Message-ID: <50E8949D.2010808@cs.oswego.edu> On 01/05/13 15:10, Martin Buchholz wrote: > I did a bit of review. Thanks especially for finding the doc adaptions missing in the transition from un-lambda-ized jsr166e versions! > > ---- > > """The supplied accumulator function must be side-effect-free. It may be > re-applied when attempted updates fail due to contention among threads. """ > > Too strong. I prefer """The supplied accumulator function should be > side-effect-free, since it may be re-applied when attempted updates fail due to > contention among threads. """ Users can usefully use side effects for e.g. > performance monitoring or debugging. Fine. We will need some consistent wording about such functions all over the stream APIs as well. -Doug From whoschek at cloudera.com Sat Jan 5 22:10:39 2013 From: whoschek at cloudera.com (Wolfgang Hoschek) Date: Sat, 5 Jan 2013 22:10:39 +0000 (UTC) Subject: Scaling problem of HashMap (introduced with alternative hashing) References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> Message-ID: Mike Duigou writes: > > I am responding on the StackOverflow thread. I will look into using ThreadLocalRandom. > > The random.next() is clearly a potential bottleneck but given that this happens only once per HashMap > instance it is still unclear why a reasonable application would want to create hundreds or thousands of > hash maps per second. > > Mike There are tons of apps out there that create a transient HashMap per record in big data applications. Think parsers and serializers in tight loops, for example. ArrayList and HashMap are probably the most heavily used data structures in every day java usage, and perf regressions in this area affect all existing java programs. Putting any synchronization into unsynchronized collections classes is a real gotcha. In my opinion, this is unacceptable and needs to be fixed ASAP. The change that was apparently introduced in 7u6, CR#7118743 should be reverted or fixed without requiring any synchronization or CAS operation. Somehow this situation reminds me of the colossal mistake of making StringBuffer and Vector and HashTable synchronized in JDK 1.1/1.2. People paid dearly for years for that mistake. No need to repeat that experience. Indeed, the performance of HashMap constructor is of such high importance that Josh Bloch (the creator of the java collections framework) back in the day even put in the optimizations in response to customer feedback to avoid the multiplication loop for the common case, which is the HashMap() no-arg constructor: java6: public HashMap() { this.loadFactor = DEFAULT_LOAD_FACTOR; threshold = (int)(DEFAULT_INITIAL_CAPACITY * DEFAULT_LOAD_FACTOR); table = new Entry[DEFAULT_INITIAL_CAPACITY]; init(); } I just checked the source and it appears that this optimization has ALSO somehow got lost on the way from java6 to java7. In Java7 I find that the no-arg constructor required the while (capacity < initialCapacity). In other words, CR#7118743, not only adds CAS and other unnecessary random related computation overhead that hurts a common usage pattern, but it also removes the deliberate fast path put in by Josh Bloch back then, which makes this an even bigger performance regression! java7: public HashMap() { this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR); } public HashMap(int initialCapacity, float loadFactor) { if (initialCapacity < 0) throw new IllegalArgumentException("Illegal initial capacity: " + initialCapacity); if (initialCapacity > MAXIMUM_CAPACITY) initialCapacity = MAXIMUM_CAPACITY; if (loadFactor <= 0 || Float.isNaN(loadFactor)) throw new IllegalArgumentException("Illegal load factor: " + loadFactor); // Find a power of 2 >= initialCapacity int capacity = 1; while (capacity < initialCapacity) capacity <<= 1; this.loadFactor = loadFactor; threshold = (int)Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1); table = new Entry[capacity]; useAltHashing = sun.misc.VM.isBooted() && (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD); init(); } Wolfgang From forax at univ-mlv.fr Sat Jan 5 23:42:35 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 06 Jan 2013 00:42:35 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E86CAC.8090606@oracle.com> References: <50E86CAC.8090606@oracle.com> Message-ID: <50E8BA6B.3070809@univ-mlv.fr> On 01/05/2013 07:10 PM, Chris Hegarty wrote: > As part of JEP 155 we are proposing to add the following public > classes to support Scalable Updatable Variables, DoubleAccumulator, > DoubleAdder, LongAccumulator and LongAdder. > > These have been written by Doug Lea, with assistance from members of > the former JCP JSR-166 Expert Group. > > Webrev and javadoc are at: > http://cr.openjdk.java.net/~chegar/8005311/ver.00/ > > Since Doug is the author, I am taking a reviewer/sponsor role. > > Here are my initial comments. > - There are various places in DoubleAccmulator where there are broken > links to #sum ( I think it is just a cut'n'paste error ). These > should be #get. > - Accumulators > {@link #get} may read somewhat better as {@link #get current value} ?? > - Accumulators > Does the 'identity' value need further explanation? > > Note: There is one minor change to the implementation. Currently in > the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble. This > method has been renamed to applyAsDouble in the lambda/lambda repo. > When these changes are sync'ed from lambda/lambda this can be > reverted. A similar comment has been added to the code. > > -Chris. The code is not very java-ish, by example, in Striped64, Cell[] as; Cell a; int n; long v; if ((as = cells) != null && (n = as.length) > 0) { if ((a = as[(n - 1) & h]) == null) { instead int n; Cell[] as = cells; if (as != null && (n = as.length) > 0) { Cell a = as[(n - 1) & h]; if ((a == null) { also I think that the variable created (and 'init' after in the code) are not needed. boolean created = false; try { // Recheck under lock Cell[] rs; int m, j; if ((rs = cells) != null && (m = rs.length) > 0 && rs[j = (m - 1) & h] == null) { rs[j] = r; created = true; } } finally { cellsBusy = 0; } if (created) break; The code can become try { // Recheck under lock Cell[] rs = cells; int m, j; if (rs != null && (m = rs.length) > 0 && rs[j = (m - 1) & h] == null) { rs[j] = r; break; } } finally { cellsBusy = 0; } Overall, I think there are too many lazy initializations. Unlike HashMap, if a developer uses let say LongAccumulator it's because AtomicLong doesn't work well, so not having the array of cells initialized by default seems weird. R?mi From dl at cs.oswego.edu Sun Jan 6 11:39:36 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 06 Jan 2013 06:39:36 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E8BA6B.3070809@univ-mlv.fr> References: <50E86CAC.8090606@oracle.com> <50E8BA6B.3070809@univ-mlv.fr> Message-ID: <50E96278.8020106@cs.oswego.edu> On 01/05/13 18:42, Remi Forax wrote: > The code is not very java-ish, But is very consistent across j.u.c. As a convention, inline assignments to locals are used to hold field reads to visually ensure use of consistent snapshots. The C-like look-and-feel is a less important than is ability to simply check these cases by inspection. > > Overall, I think there are too many lazy initializations. > Unlike HashMap, if a developer uses let say LongAccumulator it's because > AtomicLong doesn't work well, > so not having the array of cells initialized by default seems weird. You wouldn't say this if you were on a 256-way machine with millions of LongAdders, where only a thousand of them heavily contended :-) -Doug From forax at univ-mlv.fr Sun Jan 6 17:59:16 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 06 Jan 2013 18:59:16 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E96278.8020106@cs.oswego.edu> References: <50E86CAC.8090606@oracle.com> <50E8BA6B.3070809@univ-mlv.fr> <50E96278.8020106@cs.oswego.edu> Message-ID: <50E9BB74.50905@univ-mlv.fr> On 01/06/2013 12:39 PM, Doug Lea wrote: > On 01/05/13 18:42, Remi Forax wrote: > >> The code is not very java-ish, > > But is very consistent across j.u.c. As a convention, > inline assignments to locals are used to hold field reads > to visually ensure use of consistent snapshots. The C-like > look-and-feel is a less important than is ability to simply > check these cases by inspection. I know that, I'm fine with inline assignment when needed. But declaring variables on the first scope of a method or using a boolean variable to test if a try succeed is for me just a good way to make the code more obscure than it should. > >> >> Overall, I think there are too many lazy initializations. >> Unlike HashMap, if a developer uses let say LongAccumulator it's because >> AtomicLong doesn't work well, >> so not having the array of cells initialized by default seems weird. > > You wouldn't say this if you were on a 256-way machine with > millions of LongAdders, where only a thousand of them heavily > contended :-) I'm fine with uncontended/contended switch if the CAS on base fails but not with the fact that the array used in the contended case is not created when the thread local object is initialized. BTW, why do you use an array of objects (Cell) that are padded enough to avoid false sharing instead of allocating an array big enough and to store the values at indexes that are far enough from each others, that should avoid one level of indirections. Also, I've done a micro-test on my laptop (a modesr 4 cores machine), trying to calculate the maximum of one miliion values using LongAccumulator by 4 threads and the calls to Striped64::longAccumulate are never inlined, longAccumulate is too big, a better segregation between the fast paths and the slow ones (that should be pushed in another method) should solve the issue. > > -Doug > R?mi From forax at univ-mlv.fr Sun Jan 6 19:28:16 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 06 Jan 2013 20:28:16 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E9BB74.50905@univ-mlv.fr> References: <50E86CAC.8090606@oracle.com> <50E8BA6B.3070809@univ-mlv.fr> <50E96278.8020106@cs.oswego.edu> <50E9BB74.50905@univ-mlv.fr> Message-ID: <50E9D050.8070303@univ-mlv.fr> On 01/06/2013 06:59 PM, Remi Forax wrote: > On 01/06/2013 12:39 PM, Doug Lea wrote: > > Also, I've done a micro-test on my laptop (a modesr 4 cores machine), > trying to calculate the maximum of one miliion values using > LongAccumulator by 4 threads and the calls to > Striped64::longAccumulate are never inlined, > longAccumulate is too big, a better segregation between the fast paths > and the slow ones (that should be pushed in another method) should > solve the issue. answering myself because I have written something stupid, we don't care if longAccumulate is inlined or not because it's not a fast path. R?mi From martinrb at google.com Sun Jan 6 20:25:15 2013 From: martinrb at google.com (Martin Buchholz) Date: Sun, 6 Jan 2013 12:25:15 -0800 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E8BA6B.3070809@univ-mlv.fr> References: <50E86CAC.8090606@oracle.com> <50E8BA6B.3070809@univ-mlv.fr> Message-ID: On Sat, Jan 5, 2013 at 3:42 PM, Remi Forax wrote: > > The code is not very java-ish, > Yes, j.u.c.-java is hard to read due to extreme performance orientation and need to save reads in locals everywhere, and pretty far from java programmer mainstream. I'm also looking at LongAccumulator.accumulate(long). - shouldn't "function" also be pulled into a local? - Why "as"? Why not "cs"? Did Cell once have a name beginning with "A"? - (m = as.length - 1) < 0 ?? as.length should always be >= 2, so this check should be redundant. Or is this to help hotspot elide NPE throw code? - We're checking as for null twice, which bugs me a bit. - Why not push most of this method into Striped64, as in Striped64: void accumulateLong(long x, LongBinaryOperator fn) LongAccumulator: void accumulate(long x) { return accumulateLong(x, function); } --- I still like this style for pulling final fields into locals (but others don't seem to share my taste): final Cell[] cells = this.cells; final LongBinaryOperator function = this.function; From dl at cs.oswego.edu Sun Jan 6 21:15:23 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 06 Jan 2013 16:15:23 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: References: <50E86CAC.8090606@oracle.com> <50E8BA6B.3070809@univ-mlv.fr> Message-ID: <50E9E96B.1020006@cs.oswego.edu> On 01/06/13 15:25, Martin Buchholz wrote: > Yes, j.u.c.-java is hard to read due to extreme performance orientation and > need to save reads in locals everywhere, and pretty far from java > programmer mainstream. (I'm going to stay out of further general style discussions beyond saying that when people ask me what I program in, I say "JVMese", not Java :-) > > I'm also looking at LongAccumulator.accumulate(long). > > - shouldn't "function" also be pulled into a local? No need: it is typically used only once per call. > - Why "as"? Why not "cs"? Did Cell once have a name beginning with "A"? Yes, and probably will again when we can use @Contended form of AtomicLong. > - (m = as.length - 1) < 0 ?? as.length should always be >= 2, so this > check should be redundant. Or is this to help hotspot elide NPE throw code? Yes; this pushes almost all checks into slow path. > - Why not push most of this method into Striped64, as in Lots and lots of profiling/testing suggests that this is the best compromise form. The basic performance challenge here is that we want to use no more than the cost of a failed CAS taking an alternate path. The path that does this doesn't look as fast as it is; we seem to be within 10% of ideal zero-contention-per-update performance, at vastly less space consumption. We might get even closer than that sometime. -Doug From david.holmes at oracle.com Sun Jan 6 22:46:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Jan 2013 08:46:51 +1000 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction Message-ID: <50E9FEDB.8050800@oracle.com> This is the official RFR for this work. Thanks to everyone for previous comments and feedback. Webrev: http://cr.openjdk.java.net/~dholmes/8005232/webrev/ Description below. Thanks, David ------ JEP-149 looks at dynamic memory footprint reductions in Java 8. http://openjdk.java.net/jeps/149 This CR covers the "Class Instance Size Reduction" project of that JEP. In Java 8, using a 32-bit example, a java.lang.Class instance is 112 bytes consisting of: - 8 byte object header - 20 declared fields (mostly references, some int) - 5 injected fields (3 references, 2 ints) That gives: 8 + (20*4) +(5*4) = 108 bytes. But as we need 8-byte alignment that increases to 112 bytes. Nine of the reference fields are to SoftReferences (null if not used) that hold cached reflection data (declared methods, fields, constructors etc), all of which must be cleared upon class redefinition. If reflection is not used then these fields are wasting space. There are a number of fields related to annotations, and again if unused these are wasting space - however as JSR-308 is doing a lot of work on annotation types it was decided to leave the annotation related fields alone. There are two further fields (cachedConstructor and newInstanceCallerCache) that pertain to use of the newInstance() method. The very existence of these fields suggests that newInstance is a more common reflection construct to support. Further these are direct references not soft-references and they are not cleared upon class redefinition (arguably a bug), and so for those reasons we also exclude those fields from the present changes. The original proposal simply moved all the reflection caching soft-references into a separate helper object. That proposal was sent for review here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html and it was noted by Brian Goetz that additional savings could be made if we held one soft-reference to the helper object rather than a direct reference to a helper containing soft-references. Peter Levart stumbled into this when he was devising solutions to an annotations processing synchronization bottleneck reported by Alexander Knoller: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012049.html After narrowing the scope to the reflection objects the discussion continued here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012911.html With Peter's final proposed patch here: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/webrev.04/index.html In this design we only keep a soft-reference to a ReflectionData object which in turn holds the original fields (but directly) for the cached reflection objects. The ReflectionData object is cleared upon class redefinition and each ReflectionData instance tracks the class redefinition count at the time it was created. This in turn required a seperate redefinition count to be maintained for the annotations processing. As a result we have the following layout changes: - 8 reference fields moved (the reflection caches) - 1 int moved (the class redefinition count) - 1 reference added (for the SoftReference to the ReflectionData) - 1 int added (the class redefinition count for annotations) This is a saving of 7 reference fields ie. 28 bytes, resulting in a new Class instance size of 80 bytes. This saves a further 4 bytes due to the fields being 8-byte aligned without any need for padding. So overall we save 32 bytes per class instance. The ReflectionData instance itself consumes 48 bytes, while a SoftReference consumes 32 bytes. For classes that don't use reflection this is an obvious win of 32 bytes per class. For classes that use all 8 reflection caches this is also a win as we save 7 SoftReferences ie 224 bytes. For classes that only use one cached reflection object, however, there is a space penalty. The existing layout would consume 112 bytes for the Class instance, plus 32 bytes for the SoftReference to hold the cached array. A total of 144 bytes. The new layout consumes 80 bytes for the Class instance, 32 bytes for the SoftReference to the ReflectionData, and 48 bytes for the ReflectionData instance: a total of 160 bytes. Hence we have a 16 byte space penalty if only one reflection cache is needed. Note that if two reflection caches are used then we are again in front as the new scheme requires no further allocations, where the old would add a second SoftReference at 32-bytes, thus giving the new scheme a 16 byte advantage. From daniel.fuchs at oracle.com Mon Jan 7 10:34:42 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 07 Jan 2013 11:34:42 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50E724B5.1030408@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> Message-ID: <50EAA4C2.5070002@oracle.com> Thanks Joe. To make things clear I have pushed a revised webrev with solution 3. The lines of interest are in FactoryFinder.java - right hand side: 267 if (type.getName().equals(factoryId)) { 268 // Try Jar Service Provider Mechanism 269 final T provider = findServiceProvider(type); 270 if (provider != null) { 271 return provider; 272 } 273 } else { 274 // We're in the case where a 'custom' factoryId was provided, 275 // and in every case where that happens, we expect that 276 // fallbackClassName will be null. 277 assert fallbackClassName == null; 278 } regards, -- daniel On 1/4/13 7:51 PM, Joe Wang wrote: > Hi Daniel, > > Yes, I agree with 3. As I said before, we should return an error if > factoryId != type.getName() since it indicates a configuration error. > Scenario 4 does exist, but it's beyond the current spec. Such an impl > should not use the default API. > > The StAX spec is not always clear. My interpretation of the definition > of factoryId to be the "same as a property name" is that the author > basically was saying that it's equivalent to a name as in a property, > not the "value", therefore different from the DOM/SAX API -- a bad > choice I would think. > > Thanks, > Joe > > On 1/4/2013 6:31 AM, Daniel Fuchs wrote: >> Hi guys, >> >> Happy new year to you all! And apologies for this long email :-) >> >> I think we still haven't converged on this issue in >> javax.xml.stream - so let me make a recap. >> >> The issue is for the newInstance/newFactory methods >> that take a factoryId parameter, in the factories for >> the javax.xml.stream package: >> >> [ >> >> >> FactoryFinder.java: line 267-268 right hand side. ] >> >> >> recap of the issue: >> ------------------- >> >> In case the provided factoryId did not correspond to any >> System/JAXP/StAX property, the old code used to look >> for a service in META-INF/services using the factoryId as the >> name of the file for looking up the implementation class. >> In case factoryId was not the same as the base service >> class (or a subclass of it) it still would have worked >> although it went in contradiction to the Jar Specification >> mentioned in the javadoc, since the Jar Specification clearly >> states that the file name should be the fully qualified name >> of the base service class. >> >> Since we're going to replace the code that looked up for >> a service in META-INF with a call to ServiceLoader, we can >> no longer fully preserve that old behavior, because ServiceLoader >> only takes a base service class (and no arbitrary file name). >> >> what choices do we have? >> ------------------------ >> >> The question is therefore how we want to change this. >> I think we have 4 (exclusive) possibilities. >> >> In the case where a factoryId is provided, but no >> System/JAXP/StAX property by that name has been found, >> we could choose to either: >> >> 1. Always call ServiceLoader.load(type) where type is the >> service base class. >> >> 2. Never call ServiceLoader.load(type) >> >> 3. Only call ServiceLoader.load(type) when the provided >> factoryId is equal to type.getName() >> >> 4. If factoryId is equal to type.getName(), call >> ServiceLoader.load(type), otherwise, >> attempt to load factoryId as a class - and if that >> class is a subclass of 'type' then call >> ServiceLoader.load for that subclass. >> >> pros & cons: >> ------------ >> >> Here is a list of pros & cons for each of these options: >> >> 1. is the naive implementation I originally proposed. >> Pros: >> - P1.1: simple >> - P1.2: no change in behavior if factoryId == type.getName() >> Cons: >> - C1.1: may find no provider when the old code used to >> find one, (case where factoryId="foo", there's a >> provider for "foo" and there's no provider for type.getName()) >> - C1.2: may find a provider when the old code used to >> find none (case where factoryId="foo", there's no provider >> for foo, but there's a provider for type.getName()) >> - C1.3: may find a different provider than what the old >> code use to find (case where factoryId="foo", there's a >> provider for "foo" and there's also a provider for >> type.getName()) >> >> 2. is more drastic: if you specify a property - then the property >> has to be defined somewhere for newInstance/newFactory to >> succeed. >> Pros: >> - P2.1: simple >> Cons: >> - C2.1: there's a change of behavior even when >> factoryId == type.getName() and no property by that >> name is defined. >> - C2.2: in all cases where the old code used to find a >> provider by looking at META-INF/services, the new code >> will find nothing. >> Although it's the most simple - it's probably the most risky >> in terms of compatibility. >> >> 3. Same as 1. except that C1.2 and C1.3 are removed. >> >> 4. Same as 3. except that it's more complex (so P1.1 is >> removed) and that C1.1 will not occur in the case >> where factoryId is the name of a subclass of 'type' >> >> In conclusion: >> -------------- >> >> Since the original spec only says that factoryId is >> "same as property" - it's very difficult to figure out >> which of these 4 options is the closer to the behavior >> intended by the spec. >> >> I personally think that the case where factoryId="foo", >> and no property "foo" is defined, but a provider exists for >> "foo" and an implementation is returned, is a bug - since >> it's in contradiction with the Jar Specification mentioned >> in the spec which clearly states that "foo" should >> have been a service class name. >> >> So although 4. is the implementation that would offer the >> greater compatibility with existing code, I am sorely >> tempted to recommend that we do 3. and clarify >> the spec on this point. >> (3: Only call ServiceLoader.load(type) when the provided >> factoryId is equal to type.getName()) >> >> Best regards, >> >> -- daniel >> >> On 12/19/12 10:45 AM, Daniel Fuchs wrote: >>> On 12/19/12 12:10 AM, Joe Wang wrote: >>>> It's different. If 'foo.bar' is specified but not found, it indicates >>>> a configuration error. If the factory falls back to an impl by the >>>> default factory id, it would serve to hide the error. >>> Yes - I fully agree with that. >>>> Note that newInstance/newFactory with a factoryId parameter do not >>>> fall back to the default implementation. >>> Ahh! Yes I missed that. When called from newInstance with a factoryId >>> parameter the fallbackClassname parameter >>> is null... >>> >>> So should we still call ServiceLoader when fallbackClassname is null and >>> factoryId is type.getName()? It would be more >>> backward compatible - since previously it was looking in the jars and >>> found (valid) providers registered with that name. >>> >>> On the other hand we could alter the spec to say that if no property >>> with the factoryId name is found - then >>> no fallback loading is perform (either on ServiceLoader or >>> system-default implementation) and an error is thrown. >>> >>> -- daniel >> From alexey.utkin at oracle.com Mon Jan 7 12:19:45 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 07 Jan 2013 16:19:45 +0400 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> Message-ID: <50EABD61.7060102@oracle.com> I am sorry. Seems that I am out of discussion context, but did we get that sort of problem: https://code.google.com/p/android/issues/detail?id=42265#c114 http://forum.xda-developers.com/showthread.php?t=1987032&nocache=0 The article in Russian: http://habrahabr.ru/post/164881/ Regards, -uta On 27.12.2012 23:55, Mike Duigou wrote: > I am responding on the StackOverflow thread. I will look into using ThreadLocalRandom. > > The random.next() is clearly a potential bottleneck but given that this happens only once per HashMap instance it is still unclear why a reasonable application would want to create hundreds or thousands of hash maps per second. > > Mike > > On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote: > >> Looks very like dumb inlined java.util.Random? >> Is there a security threat to use ThreadLocalRandom instead there? >> >> -Aleksey. >> >> On 27.12.2012, at 23:16, Zhong Yu wrote: >> >>> Reported by the SO question >>> >>> http://stackoverflow.com/questions/14010906 >>> >>> the HashMap constructor contains a CAS, which is kind of surprising. >>> Could it be removed? >>> >>> transient final int hashSeed = >>> sun.misc.Hashing.randomHashSeed(this); // CAS >>> >>> Zhong Yu From aleksey.shipilev at oracle.com Mon Jan 7 12:30:35 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 7 Jan 2013 16:30:35 +0400 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <50EABD61.7060102@oracle.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50EABD61.7060102@oracle.com> Message-ID: <5AE51F1C-3BDA-4443-9E39-A7FDE5B6DE2D@oracle.com> Seriously doubt Android uses (recent) OpenJDK HashMap code, otherwise many lawyers around the world would now be having heart attacks. Also, java.util.Random is plain congruent PRNG, having nothing to do with entropy pools, preseeded with nanoTime() at most. -Aleksey. On 07.01.2013, at 16:19, Alexey Utkin wrote: > I am sorry. Seems that I am out of discussion context, but did we get that sort of problem: > > https://code.google.com/p/android/issues/detail?id=42265#c114 > http://forum.xda-developers.com/showthread.php?t=1987032&nocache=0 > > The article in Russian: > http://habrahabr.ru/post/164881/ > > Regards, > -uta > > On 27.12.2012 23:55, Mike Duigou wrote: >> I am responding on the StackOverflow thread. I will look into using ThreadLocalRandom. >> >> The random.next() is clearly a potential bottleneck but given that this happens only once per HashMap instance it is still unclear why a reasonable application would want to create hundreds or thousands of hash maps per second. >> >> Mike >> >> On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote: >> >>> Looks very like dumb inlined java.util.Random? >>> Is there a security threat to use ThreadLocalRandom instead there? >>> >>> -Aleksey. >>> >>> On 27.12.2012, at 23:16, Zhong Yu wrote: >>> >>>> Reported by the SO question >>>> >>>> http://stackoverflow.com/questions/14010906 >>>> >>>> the HashMap constructor contains a CAS, which is kind of surprising. >>>> Could it be removed? >>>> >>>> transient final int hashSeed = >>>> sun.misc.Hashing.randomHashSeed(this); // CAS >>>> >>>> Zhong Yu > From alexey.utkin at oracle.com Mon Jan 7 12:34:52 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 07 Jan 2013 16:34:52 +0400 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <5AE51F1C-3BDA-4443-9E39-A7FDE5B6DE2D@oracle.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50EABD61.7060102@oracle.com> <5AE51F1C-3BDA-4443-9E39-A7FDE5B6DE2D@oracle.com> Message-ID: <50EAC0EC.9010501@oracle.com> Thanks for explanation, Aleksey! Regards, -uta On 07.01.2013 16:30, Aleksey Shipilev wrote: > Seriously doubt Android uses (recent) OpenJDK HashMap code, otherwise many lawyers around the world would now be having heart attacks. Also, java.util.Random is plain congruent PRNG, having nothing to do with entropy pools, preseeded with nanoTime() at most. > > -Aleksey. > > On 07.01.2013, at 16:19, Alexey Utkin wrote: > >> I am sorry. Seems that I am out of discussion context, but did we get that sort of problem: >> >> https://code.google.com/p/android/issues/detail?id=42265#c114 >> http://forum.xda-developers.com/showthread.php?t=1987032&nocache=0 >> >> The article in Russian: >> http://habrahabr.ru/post/164881/ >> >> Regards, >> -uta >> >> On 27.12.2012 23:55, Mike Duigou wrote: >>> I am responding on the StackOverflow thread. I will look into using ThreadLocalRandom. >>> >>> The random.next() is clearly a potential bottleneck but given that this happens only once per HashMap instance it is still unclear why a reasonable application would want to create hundreds or thousands of hash maps per second. >>> >>> Mike >>> >>> On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote: >>> >>>> Looks very like dumb inlined java.util.Random? >>>> Is there a security threat to use ThreadLocalRandom instead there? >>>> >>>> -Aleksey. >>>> >>>> On 27.12.2012, at 23:16, Zhong Yu wrote: >>>> >>>>> Reported by the SO question >>>>> >>>>> http://stackoverflow.com/questions/14010906 >>>>> >>>>> the HashMap constructor contains a CAS, which is kind of surprising. >>>>> Could it be removed? >>>>> >>>>> transient final int hashSeed = >>>>> sun.misc.Hashing.randomHashSeed(this); // CAS >>>>> >>>>> Zhong Yu > From forax at univ-mlv.fr Mon Jan 7 12:39:32 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 07 Jan 2013 13:39:32 +0100 Subject: Scaling problem of HashMap (introduced with alternative hashing) In-Reply-To: <50EABD61.7060102@oracle.com> References: <5B72EDA5-641A-4691-AC9B-457C7BAAD489@oracle.com> <50EABD61.7060102@oracle.com> Message-ID: <50EAC204.3050705@univ-mlv.fr> On 01/07/2013 01:19 PM, Alexey Utkin wrote: > I am sorry. Seems that I am out of discussion context, but did we get > that sort of problem: > > https://code.google.com/p/android/issues/detail?id=42265#c114 > http://forum.xda-developers.com/showthread.php?t=1987032&nocache=0 > > The article in Russian: > http://habrahabr.ru/post/164881/ Not sure there is a real problem here, if you wake up the CPU of your smartphone often you have better performance (and less battery), paying an application for that is a scam. Anyway, it's related to android kernel/ecosystem so not applicable here. The issue here is that SecureRandom use a lock so if you create a lot of HashMap in a tight loop you can see a regression. I don't think it impact real application and as Mike said, using a ThreadLocalRandom seems a good idea here (no idea if it's secure to use it) . > > Regards, > -uta cheers, R?mi > > On 27.12.2012 23:55, Mike Duigou wrote: >> I am responding on the StackOverflow thread. I will look into using >> ThreadLocalRandom. >> >> The random.next() is clearly a potential bottleneck but given that >> this happens only once per HashMap instance it is still unclear why a >> reasonable application would want to create hundreds or thousands of >> hash maps per second. >> >> Mike >> >> On Dec 27 2012, at 11:38 , Aleksey Shipilev wrote: >> >>> Looks very like dumb inlined java.util.Random? >>> Is there a security threat to use ThreadLocalRandom instead there? >>> >>> -Aleksey. >>> >>> On 27.12.2012, at 23:16, Zhong Yu wrote: >>> >>>> Reported by the SO question >>>> >>>> http://stackoverflow.com/questions/14010906 >>>> >>>> the HashMap constructor contains a CAS, which is kind of surprising. >>>> Could it be removed? >>>> >>>> transient final int hashSeed = >>>> sun.misc.Hashing.randomHashSeed(this); // CAS >>>> >>>> Zhong Yu > From chris.hegarty at oracle.com Mon Jan 7 15:14:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 07 Jan 2013 15:14:48 +0000 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: References: <50E86CAC.8090606@oracle.com> Message-ID: <50EAE668.9@oracle.com> Updated webrev and javadoc: http://cr.openjdk.java.net/~chegar/8005311/ver.01/ I plan to finalize the API based on this updated version. Note: the links in the javadoc do not work. It is simply the way that I copied the html files. I verified that they all link correctly in a full docs build. -Chris. From joe.darcy at oracle.com Mon Jan 7 19:07:24 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 07 Jan 2013 11:07:24 -0800 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E86CAC.8090606@oracle.com> References: <50E86CAC.8090606@oracle.com> Message-ID: <50EB1CEC.6060600@oracle.com> Hello, I had a question about how the double accumulation logic was intended to be used. I've taken a quick look at the code and it uses straightforward "sum = sum + nextValue" code to compute the double sum. Summing doubles values with code numerical accuracy is surprisingly tricky and if the DoubleAccumulator code is meant for wide use, I'd recommend using instead some form of compensated summation: http://en.wikipedia.org/wiki/Kahan_summation_algorithm Thanks, -Joe On 1/5/2013 10:10 AM, Chris Hegarty wrote: > As part of JEP 155 we are proposing to add the following public > classes to support Scalable Updatable Variables, DoubleAccumulator, > DoubleAdder, LongAccumulator and LongAdder. > > These have been written by Doug Lea, with assistance from members of > the former JCP JSR-166 Expert Group. > > Webrev and javadoc are at: > http://cr.openjdk.java.net/~chegar/8005311/ver.00/ > > Since Doug is the author, I am taking a reviewer/sponsor role. > > Here are my initial comments. > - There are various places in DoubleAccmulator where there are broken > links to #sum ( I think it is just a cut'n'paste error ). These > should be #get. > - Accumulators > {@link #get} may read somewhat better as {@link #get current value} ?? > - Accumulators > Does the 'identity' value need further explanation? > > Note: There is one minor change to the implementation. Currently in > the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble. This > method has been renamed to applyAsDouble in the lambda/lambda repo. > When these changes are sync'ed from lambda/lambda this can be > reverted. A similar comment has been added to the code. > > -Chris. From kumar.x.srinivasan at oracle.com Mon Jan 7 19:10:25 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 07 Jan 2013 19:10:25 +0000 Subject: hg: jdk8/tl/jdk: 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Message-ID: <20130107191053.8A920470C0@hg.openjdk.java.net> Changeset: 1d9638ba5202 Author: ksrini Date: 2013-01-07 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d9638ba5202 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Reviewed-by: mchung, kcr, ksrini Contributed-by: david.dehaven at oracle.com ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/FXLauncherTest.java From lowasser at google.com Mon Jan 7 19:18:38 2013 From: lowasser at google.com (Louis Wasserman) Date: Mon, 7 Jan 2013 11:18:38 -0800 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EB1CEC.6060600@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> Message-ID: Hmmm. Is that algorithm doable concurrently without needing a 128-bit CAS? On Mon, Jan 7, 2013 at 11:07 AM, Joe Darcy wrote: > Hello, > > I had a question about how the double accumulation logic was intended to > be used. I've taken a quick look at the code and it uses straightforward > "sum = sum + nextValue" code to compute the double sum. Summing doubles > values with code numerical accuracy is surprisingly tricky and if the > DoubleAccumulator code is meant for wide use, I'd recommend using instead > some form of compensated summation: > > http://en.wikipedia.org/wiki/**Kahan_summation_algorithm > > Thanks, > > -Joe > > > On 1/5/2013 10:10 AM, Chris Hegarty wrote: > >> As part of JEP 155 we are proposing to add the following public classes >> to support Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, >> LongAccumulator and LongAdder. >> >> These have been written by Doug Lea, with assistance from members of the >> former JCP JSR-166 Expert Group. >> >> Webrev and javadoc are at: >> http://cr.openjdk.java.net/~**chegar/8005311/ver.00/ >> >> Since Doug is the author, I am taking a reviewer/sponsor role. >> >> Here are my initial comments. >> - There are various places in DoubleAccmulator where there are broken >> links to #sum ( I think it is just a cut'n'paste error ). These >> should be #get. >> - Accumulators >> {@link #get} may read somewhat better as {@link #get current value} ?? >> - Accumulators >> Does the 'identity' value need further explanation? >> >> Note: There is one minor change to the implementation. Currently in the >> jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble. This method >> has been renamed to applyAsDouble in the lambda/lambda repo. When these >> changes are sync'ed from lambda/lambda this can be reverted. A similar >> comment has been added to the code. >> >> -Chris. >> > > -- Louis Wasserman From dl at cs.oswego.edu Mon Jan 7 19:40:26 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 07 Jan 2013 14:40:26 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EB1CEC.6060600@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> Message-ID: <50EB24AA.40101@cs.oswego.edu> On 01/07/13 14:07, Joe Darcy wrote: > Hello, > > I had a question about how the double accumulation logic was intended to be > used. I've taken a quick look at the code and it uses straightforward "sum = > sum + nextValue" code to compute the double sum. Summing doubles values with > code numerical accuracy is surprisingly tricky and if the DoubleAccumulator code > is meant for wide use, I'd recommend using instead some form of compensated > summation: > > http://en.wikipedia.org/wiki/Kahan_summation_algorithm > I'm sympathetic... Complete lack of control over arithmetic issues (here and for plain atomics) led me to resist offering Double versions for years. But many people are content with the scalability vs numerical stability tradeoffs intrinsic here (and I think unsolvable). I suppose it could stand an explicit disclaimer rather than the implicit one there now. How about: "The order of accumulation of sums across threads is uncontrolled. Numerical stability of results is not guaranteed when values of substantially different orders of magnitude are combined" Or something better? -Doug From james.holmlund at oracle.com Mon Jan 7 21:12:56 2013 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Mon, 07 Jan 2013 21:12:56 +0000 Subject: hg: jdk8/tl/langtools: 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Message-ID: <20130107211301.D1DD5470C7@hg.openjdk.java.net> Changeset: a9cb93cca229 Author: jjh Date: 2013-01-07 17:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a9cb93cca229 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Summary: Fix javap to not output \r\r\n Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! test/tools/javac/MethodParameters.java ! test/tools/javap/MethodParameters.java From naoto.sato at oracle.com Mon Jan 7 21:19:36 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 07 Jan 2013 21:19:36 +0000 Subject: hg: jdk8/tl/jdk: 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Message-ID: <20130107211949.6CCF7470C8@hg.openjdk.java.net> Changeset: dbc692ea3f0a Author: bchristi Date: 2013-01-07 13:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dbc692ea3f0a 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Summary: Hard-code sun.jnu.encoding to UTF-8 on Mac Reviewed-by: naoto ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c + test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java + test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From stuart.marks at oracle.com Mon Jan 7 23:01:16 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 07 Jan 2013 15:01:16 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently In-Reply-To: <50E77600.1030306@oracle.com> References: <50E640F4.20501@oracle.com> <50E77600.1030306@oracle.com> Message-ID: <50EB53BC.5050701@oracle.com> (Note for other readers: StreamPipe is not part of this webrev; the source is viewable at [1].) Hi Mandy, I don't see any place where the StreamPipe threads are interrupted, so the silent exit on InterruptedIOException probably doesn't ever get exercised. This handling does seem a bit odd to me though. For both IOException and InterruptedIOE the thread exits immediately (and for IOE a stack trace is printed) but this is never reported to the caller, so if one of these did occur, it's likely that no one would ever notice -- unless it caused the calling test to fail. It would probably be reasonable for a StreamPipe to store an indication of whether it encountered and exception and have code in JavaVM.waitFor query it and report it to the caller. This seems like a pretty rare case though. Maybe something to do in a future cleanup. Turns out this bug was pretty easy to reproduce by putting a sleep() at the right place in the StreamPipe loop. This causes the StreamPipe always to "lose" the race condition so in the old code the test would fail every time. With the new join() logic the test always passes, even with sleep() in place; it just runs more slowly. Thanks, s'marks [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/a996b57e5541/test/java/rmi/testlibrary/StreamPipe.java On 1/4/13 4:38 PM, Mandy Chung wrote: > It is a good cleanup and the change looks okay to me. I'll count on your > testing to verify if this fixes the intermittent problem :) > > StreamPipe.run() catches InterruptedIOException and IOException and ignores the > error. Is it safe? Are the tests expected to fail in some other way (missing > output?). Should it (or waitFor method) throw a RuntimeException instead if > any such exception is thrown? > > Just curious - Is this intermittent test failure easy to reproduce? > > Thanks > Mandy > > On 1/3/2013 6:39 PM, Stuart Marks wrote: >> >> Hi all, >> >> Please review these additional RMI test cleanups: >> >> http://cr.openjdk.java.net/~smarks/reviews/7187882/webrev.0/ >> >> in service of fixing the following bug: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187882 >> >> The basic problem here is that tests were waiting for the JVM subprocess to >> exit, but not waiting for all output from the subprocess to be collected. The >> fix includes a bit of new infrastructure in RMI's test library and adjustment >> of several other tests to use it. >> >> Thanks, >> >> s'marks From sadhak001 at gmail.com Mon Jan 7 23:21:49 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 7 Jan 2013 23:21:49 +0000 Subject: Fwd: OpenJDK builds: Ant build issues with jdk (netbeans) sub-projects - awt2d, j2se and jarzip In-Reply-To: References: <50E8D2DB.6090206@oracle.com> Message-ID: Hi, I have been recommended to post my below query to your mailing list, if it is the right place to post. If not could you recommend who would be best placed to answer the below questions. I couldn't find an appropriate mailing list for 'jarzip' (as it is part of langtools) - any suggestions? It would be great if you could answer my query about it too. Thanks. Regards, Mani On 01/05/2013 04:05 PM, Mani Sarkar wrote: > Hi all, > > I have made some progress with the below three sub-projects, and have > successfully built jarzip. But still get new error messages with awt2d and > j2se. > > I answered my own question about the -source 8, its basically expecting the > images/j2sdk-image to be assigned to the respective ALT_... variables via > the make.options property in build.properties for all three projects. > > Unfortunately I wasn't able to build swing via the .../javax/swing/ folder > where the required make file(s) are present. > > But my other queries still stand, if you can throw some light on them, it > would be help make progress with these builds using the new build system. > > Thanks. > > Regards, > Mani > > On Sat, Jan 5, 2013 at 12:39 AM, Mani Sarkar wrote: > > Hi All, >> >> I have furthered my pursuits with building *OpenJDK projects *by building >> >> the JDK sub-projects like swing, etc... but came across issues with >> building 3 different projects which I wasn't able to build due >> configuration issues. These sub-projects are located under the netbeans >> subfolder under the .../jdk/make/ folder. >> >> They all are getting compiled for version 8 with the below args (which is >> leading to a build failure): >> >> -source 8 -target 8 >> >> *jdk/awt2d* >> >> https://github.com/**neomatrix369/BuildHelpers/**blob/master/** >> EclipseProjectsForOpenJDK/**Logs/jdk/awt2d/awt2dAntBuild.**log >> >> *jdk/j2se* >> >> https://github.com/**neomatrix369/BuildHelpers/**blob/master/** >> EclipseProjectsForOpenJDK/**Logs/jdk/j2se/j2seAntBuild.log >> >> *jdk/jarzip* >> >> >> https://github.com/**neomatrix369/BuildHelpers/**blob/master/** >> EclipseProjectsForOpenJDK/**Logs/jdk/jarzip/**jarzipAntBuild.log >> >> Where is this version configuration set for these projects, that I can >> change either through file changes or alternative build.properties setting >> changes? My other question is why are there no make files available for >> the >> jdk sub-projects (i.e. *awt2d, j2se,* etc...) except for under * >> javax/swing* has make files to build this project instead Ant build.xml >> >> files are available. Is it possible to hook these ant files with the new >> build system, instead of only being able to build the sub-projects via the >> old build system (using the ALT_... variables via make.options). >> >> Thanks. >> >> Regards, >> mani >> >> -- >> Twitter: @theNeomatrix369 >> Blog: http://neomatrix369.wordpress.**com >> > >> >> *Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!* >> >> > > -- Twitter: @theNeomatrix369 Blog: http://neomatrix369.wordpress.com *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* -- Twitter: @theNeomatrix369 Blog: http://neomatrix369.wordpress.com *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From mandy.chung at oracle.com Mon Jan 7 23:39:56 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Jan 2013 15:39:56 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently In-Reply-To: <50EB53BC.5050701@oracle.com> References: <50E640F4.20501@oracle.com> <50E77600.1030306@oracle.com> <50EB53BC.5050701@oracle.com> Message-ID: <50EB5CCC.4040300@oracle.com> On 1/7/2013 3:01 PM, Stuart Marks wrote: > (Note for other readers: StreamPipe is not part of this webrev; the > source is viewable at [1].) > > Hi Mandy, > > I don't see any place where the StreamPipe threads are interrupted, so > the silent exit on InterruptedIOException probably doesn't ever get > exercised. This handling does seem a bit odd to me though. > > For both IOException and InterruptedIOE the thread exits immediately > (and for IOE a stack trace is printed) but this is never reported to > the caller, so if one of these did occur, it's likely that no one > would ever notice -- unless it caused the calling test to fail. It > would probably be reasonable for a StreamPipe to store an indication > of whether it encountered and exception and have code in > JavaVM.waitFor query it and report it to the caller. This seems like a > pretty rare case though. Maybe something to do in a future cleanup. Swallowing an exception with no good reason seems a potential cause of reliability issue. As you think this seems a pretty rare case, I'm fine if you prefer to do this in a future cleanup. Just wanted to point this out. > > Turns out this bug was pretty easy to reproduce by putting a sleep() > at the right place in the StreamPipe loop. This causes the StreamPipe > always to "lose" the race condition so in the old code the test would > fail every time. With the new join() logic the test always passes, > even with sleep() in place; it just runs more slowly. That's good. Thanks. Mandy > > Thanks, > > s'marks > > > > > [1] > http://hg.openjdk.java.net/jdk8/tl/jdk/file/a996b57e5541/test/java/rmi/testlibrary/StreamPipe.java > > > > On 1/4/13 4:38 PM, Mandy Chung wrote: >> It is a good cleanup and the change looks okay to me. I'll count on >> your >> testing to verify if this fixes the intermittent problem :) >> >> StreamPipe.run() catches InterruptedIOException and IOException and >> ignores the >> error. Is it safe? Are the tests expected to fail in some other way >> (missing >> output?). Should it (or waitFor method) throw a RuntimeException >> instead if >> any such exception is thrown? >> >> Just curious - Is this intermittent test failure easy to reproduce? >> >> Thanks >> Mandy >> >> On 1/3/2013 6:39 PM, Stuart Marks wrote: >>> >>> Hi all, >>> >>> Please review these additional RMI test cleanups: >>> >>> http://cr.openjdk.java.net/~smarks/reviews/7187882/webrev.0/ >>> >>> in service of fixing the following bug: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7187882 >>> >>> The basic problem here is that tests were waiting for the JVM >>> subprocess to >>> exit, but not waiting for all output from the subprocess to be >>> collected. The >>> fix includes a bit of new infrastructure in RMI's test library and >>> adjustment >>> of several other tests to use it. >>> >>> Thanks, >>> >>> s'marks From stuart.marks at oracle.com Tue Jan 8 01:05:04 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 07 Jan 2013 17:05:04 -0800 Subject: RFR: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently In-Reply-To: <50EB5CCC.4040300@oracle.com> References: <50E640F4.20501@oracle.com> <50E77600.1030306@oracle.com> <50EB53BC.5050701@oracle.com> <50EB5CCC.4040300@oracle.com> Message-ID: <50EB70C0.40005@oracle.com> On 1/7/13 3:39 PM, Mandy Chung wrote: > Swallowing an exception with no good reason seems a potential cause of > reliability issue. As you think this seems a pretty rare case, I'm fine if > you prefer to do this in a future cleanup. Just wanted to point this out. Right. You know how I feel about unreliable tests! :-) But yes, this is more of a future thing. I've filed JDK-8005827 to cover this. Thanks, s'marks From stuart.marks at oracle.com Tue Jan 8 02:10:15 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 08 Jan 2013 02:10:15 +0000 Subject: hg: jdk8/tl/jdk: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Message-ID: <20130108021026.D017E470D5@hg.openjdk.java.net> Changeset: 797e8a3dcd51 Author: smarks Date: 2013-01-07 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/797e8a3dcd51 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Summary: Tighten up JavaVM test library API, and adjust tests to match. Reviewed-by: mchung, dmocek ! test/ProblemList.txt ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/sun/rmi/runtime/Log/4504153/Test4504153.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java From mandy.chung at oracle.com Tue Jan 8 04:13:19 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Jan 2013 20:13:19 -0800 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EAA4C2.5070002@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> Message-ID: <50EB9CDF.1050908@oracle.com> Hi Daniel, I also agree with option 3 be the best option among them. Joe's suggestion to throw an exception if factoryId is not the base service type is good so that any existing application depending on that behavior will catch this change. Are you going to revise the spec - there is statement saying that the newFactory method is the same behavior as newInstance method which is weakly specified. 139 * No changes in behavior are defined by this replacement method relative 140 * to the deprecated method. It'd be good to add some tests to cover these APIs if there is none. Otherwise, the change looks good. Mandy On 1/7/2013 2:34 AM, Daniel Fuchs wrote: > Thanks Joe. > > To make things clear I have pushed a revised webrev with solution 3. > > > > The lines of interest are in FactoryFinder.java - right hand side: > > 267 if (type.getName().equals(factoryId)) { > 268 // Try Jar Service Provider Mechanism > 269 final T provider = findServiceProvider(type); > 270 if (provider != null) { > 271 return provider; > 272 } > 273 } else { > 274 // We're in the case where a 'custom' factoryId was > provided, > 275 // and in every case where that happens, we expect that > 276 // fallbackClassName will be null. > 277 assert fallbackClassName == null; > 278 } > > regards, > > -- daniel > > > On 1/4/13 7:51 PM, Joe Wang wrote: >> Hi Daniel, >> >> Yes, I agree with 3. As I said before, we should return an error if >> factoryId != type.getName() since it indicates a configuration error. >> Scenario 4 does exist, but it's beyond the current spec. Such an impl >> should not use the default API. >> >> The StAX spec is not always clear. My interpretation of the definition >> of factoryId to be the "same as a property name" is that the author >> basically was saying that it's equivalent to a name as in a property, >> not the "value", therefore different from the DOM/SAX API -- a bad >> choice I would think. >> >> Thanks, >> Joe >> >> On 1/4/2013 6:31 AM, Daniel Fuchs wrote: >>> Hi guys, >>> >>> Happy new year to you all! And apologies for this long email :-) >>> >>> I think we still haven't converged on this issue in >>> javax.xml.stream - so let me make a recap. >>> >>> The issue is for the newInstance/newFactory methods >>> that take a factoryId parameter, in the factories for >>> the javax.xml.stream package: >>> >>> [ >>> >>> >>> >>> FactoryFinder.java: line 267-268 right hand side. ] >>> >>> >>> recap of the issue: >>> ------------------- >>> >>> In case the provided factoryId did not correspond to any >>> System/JAXP/StAX property, the old code used to look >>> for a service in META-INF/services using the factoryId as the >>> name of the file for looking up the implementation class. >>> In case factoryId was not the same as the base service >>> class (or a subclass of it) it still would have worked >>> although it went in contradiction to the Jar Specification >>> mentioned in the javadoc, since the Jar Specification clearly >>> states that the file name should be the fully qualified name >>> of the base service class. >>> >>> Since we're going to replace the code that looked up for >>> a service in META-INF with a call to ServiceLoader, we can >>> no longer fully preserve that old behavior, because ServiceLoader >>> only takes a base service class (and no arbitrary file name). >>> >>> what choices do we have? >>> ------------------------ >>> >>> The question is therefore how we want to change this. >>> I think we have 4 (exclusive) possibilities. >>> >>> In the case where a factoryId is provided, but no >>> System/JAXP/StAX property by that name has been found, >>> we could choose to either: >>> >>> 1. Always call ServiceLoader.load(type) where type is the >>> service base class. >>> >>> 2. Never call ServiceLoader.load(type) >>> >>> 3. Only call ServiceLoader.load(type) when the provided >>> factoryId is equal to type.getName() >>> >>> 4. If factoryId is equal to type.getName(), call >>> ServiceLoader.load(type), otherwise, >>> attempt to load factoryId as a class - and if that >>> class is a subclass of 'type' then call >>> ServiceLoader.load for that subclass. >>> >>> pros & cons: >>> ------------ >>> >>> Here is a list of pros & cons for each of these options: >>> >>> 1. is the naive implementation I originally proposed. >>> Pros: >>> - P1.1: simple >>> - P1.2: no change in behavior if factoryId == type.getName() >>> Cons: >>> - C1.1: may find no provider when the old code used to >>> find one, (case where factoryId="foo", there's a >>> provider for "foo" and there's no provider for type.getName()) >>> - C1.2: may find a provider when the old code used to >>> find none (case where factoryId="foo", there's no provider >>> for foo, but there's a provider for type.getName()) >>> - C1.3: may find a different provider than what the old >>> code use to find (case where factoryId="foo", there's a >>> provider for "foo" and there's also a provider for >>> type.getName()) >>> >>> 2. is more drastic: if you specify a property - then the property >>> has to be defined somewhere for newInstance/newFactory to >>> succeed. >>> Pros: >>> - P2.1: simple >>> Cons: >>> - C2.1: there's a change of behavior even when >>> factoryId == type.getName() and no property by that >>> name is defined. >>> - C2.2: in all cases where the old code used to find a >>> provider by looking at META-INF/services, the new code >>> will find nothing. >>> Although it's the most simple - it's probably the most risky >>> in terms of compatibility. >>> >>> 3. Same as 1. except that C1.2 and C1.3 are removed. >>> >>> 4. Same as 3. except that it's more complex (so P1.1 is >>> removed) and that C1.1 will not occur in the case >>> where factoryId is the name of a subclass of 'type' >>> >>> In conclusion: >>> -------------- >>> >>> Since the original spec only says that factoryId is >>> "same as property" - it's very difficult to figure out >>> which of these 4 options is the closer to the behavior >>> intended by the spec. >>> >>> I personally think that the case where factoryId="foo", >>> and no property "foo" is defined, but a provider exists for >>> "foo" and an implementation is returned, is a bug - since >>> it's in contradiction with the Jar Specification mentioned >>> in the spec which clearly states that "foo" should >>> have been a service class name. >>> >>> So although 4. is the implementation that would offer the >>> greater compatibility with existing code, I am sorely >>> tempted to recommend that we do 3. and clarify >>> the spec on this point. >>> (3: Only call ServiceLoader.load(type) when the provided >>> factoryId is equal to type.getName()) >>> >>> Best regards, >>> >>> -- daniel >>> >>> On 12/19/12 10:45 AM, Daniel Fuchs wrote: >>>> On 12/19/12 12:10 AM, Joe Wang wrote: >>>>> It's different. If 'foo.bar' is specified but not found, it indicates >>>>> a configuration error. If the factory falls back to an impl by the >>>>> default factory id, it would serve to hide the error. >>>> Yes - I fully agree with that. >>>>> Note that newInstance/newFactory with a factoryId parameter do not >>>>> fall back to the default implementation. >>>> Ahh! Yes I missed that. When called from newInstance with a factoryId >>>> parameter the fallbackClassname parameter >>>> is null... >>>> >>>> So should we still call ServiceLoader when fallbackClassname is >>>> null and >>>> factoryId is type.getName()? It would be more >>>> backward compatible - since previously it was looking in the jars and >>>> found (valid) providers registered with that name. >>>> >>>> On the other hand we could alter the spec to say that if no property >>>> with the factoryId name is found - then >>>> no fallback loading is perform (either on ServiceLoader or >>>> system-default implementation) and an error is thrown. >>>> >>>> -- daniel >>> > From david.holmes at oracle.com Tue Jan 8 04:55:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Jan 2013 14:55:50 +1000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50E68ABF.8090303@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> Message-ID: <50EBA6D6.3090601@oracle.com> I've generated a fresh webrev with your changes. http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/ Looking to get the Thumbs up on the src and test changes. Thanks, David On 4/01/2013 5:54 PM, Alan Bateman wrote: > On 02/01/2013 18:53, Mandy Chung wrote: >> >> I reviewed the src/test changes in the jdk repo and have a few comments: >> >> Attributes.java: >> 568 * {@code Name} object for {@code Profile} manifest attribute used >> 569 * by applications packaged as JAR files to indicate the minimum >> 570 * profile required to execute the application. >> >> The Profile attribute can be specified in both applications and >> libraries. >> Shoud L569 be changed with s/applications/applications or libraries? > Thanks, this is more correct and will be in the next webrev. > >> >> Pack200.java >> I think the default implementation for addPropertyChangeListener >> and removePropertyChangeListener requiring a non-null listener is >> a right choice. On the other hand, I found that the current pack200 >> implementation allows the given listener be null that seems to be >> a bug and the Pack200 class spec also specifies to throw NPE if null >> argument is passed to a method and looks like what you have > Joe Darcy and I chatted about this recently and he suggested it would be > better if the default method be a no-op (with no side effects). It's > updated in the jdk8/profiles forest so should be in the next webrev. > > >> >> sun.misc.URLClassPath >> L808: typo "attribtue" > Fixed. > >> >> L820: An empty "Profile" attribute is invalidand Version.supportsProfile >> returns false if requiredProfile parameter is empty even if the runtime >> is a full JRE. This is fine but I was wondering if the exception message >> can indicate if the attribute value is invalid to help diagnosis. > We could although I'm not sure how this could arise (as you can't set an > empty profile name with the "p" option, and the "m" option to add/update > a manifest also disallows empty values). > >> >> L1000: looks like the convention is to use brackets even there is a >> single statement in the if-statement body. > Okay. > >> >> sun.tools.jar.Main >> It would be helpful if the jar tool checks if the input profile >> name to the -p option is valid and outputs error. > I considered this when updating the jar tool but decided at the time > that it shouldn't know about the profile names. It would be easy to do > of course. > >> >> UnsupportedProfileException >> L29: probably better to link to the javadoc >> {@link Attributes.Name#Profile Profile} >> L38 and 44: {@code UnsupportedProfileException} > I've added {@code ...}. > >> >> make/tools/src/build/tools/RemoveMethods.java >> L100: maybe print the method signature rather than just 'name' >> L106: typo "no longed" -> "no longer" > Done. > >> >> The tests are hardcoded with the profile name and uses >> Version.profileName(). >> Will there be a system property for the profile name? > A supported property or API to indicate the profile has the potential to > be problematic when we move to modules so it's not there. So far we > haven't had any real need for it as applications can easily check for > types to determine the profile. There are a few tests that do need to > know the names but most of the new tests aren't dependent on the name. > >> >> Otherwise, looks okay. > Thanks for looking at it. I think David plans to send out an updated > webrev in the next few days. > > -Alan. From weijun.wang at oracle.com Tue Jan 8 06:55:23 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 08 Jan 2013 06:55:23 +0000 Subject: hg: jdk8/tl/jdk: 8005447: default principal should act as anyone Message-ID: <20130108065534.EDCB5470DC@hg.openjdk.java.net> Changeset: 98935c514de4 Author: weijun Date: 2013-01-08 14:54 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98935c514de4 8005447: default principal should act as anyone Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.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/KrbApReq.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java + test/sun/security/krb5/ServiceCredsCombination.java + test/sun/security/krb5/auto/AcceptPermissions.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DiffNameSameKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/KeyTabCompat.java + test/sun/security/krb5/auto/TwoOrThree.java From dan.xu at oracle.com Tue Jan 8 07:11:38 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 07 Jan 2013 23:11:38 -0800 Subject: Build Failure in JPRT Job Message-ID: <50EBC6AA.9040302@oracle.com> Hi, Today I submitted several jprt jobs asusual, but all jobs failed in building processat the same place. I tried to build jdk locally, and it worked fine. And I also tried to create a new jdk repo from the scratch, and then submitteda job. But the jprt job also failed in the buildwith the same reason as the following. "com/sun/tools/jdeps : no such file or directory". Here is one log file, http://prt-web.us.oracle.com//archive/2013/01/2013-01-08-065313.dan.jdk/logs/linux_i586_2.6-product.log.FAILED.log. My repository only contains open jdk. And in the new repository, I only added a space to a test file. Did anyone encounter a similar problem before? Thanks, -Dan From david.holmes at oracle.com Tue Jan 8 07:20:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Jan 2013 17:20:18 +1000 Subject: Build Failure in JPRT Job In-Reply-To: <50EBC6AA.9040302@oracle.com> References: <50EBC6AA.9040302@oracle.com> Message-ID: <50EBC8B2.1090600@oracle.com> Hi Dan, On 8/01/2013 5:11 PM, Dan Xu wrote: > Hi, > > Today I submitted several jprt jobs asusual, but all jobs failed in > building processat the same place. I tried to build jdk locally, and it > worked fine. And I also tried to create a new jdk repo from the scratch, > and then submitteda job. But the jprt job also failed in the buildwith > the same reason as the following. > > "com/sun/tools/jdeps : no such file or directory". > > Here is one log file, > http://prt-web.us.oracle.com//archive/2013/01/2013-01-08-065313.dan.jdk/logs/linux_i586_2.6-product.log.FAILED.log. > > My repository only contains open jdk. And in the new repository, I only > added a space to a test file. Did anyone encounter a similar problem before? You have to submit jdk and langtools together (at least until the imported langtools catches up with recent changes). You need a langtools with the jdeps tool. David > Thanks, > > -Dan > From dan.xu at oracle.com Tue Jan 8 07:30:04 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 07 Jan 2013 23:30:04 -0800 Subject: Build Failure in JPRT Job In-Reply-To: <50EBC8B2.1090600@oracle.com> References: <50EBC6AA.9040302@oracle.com> <50EBC8B2.1090600@oracle.com> Message-ID: <50EBCAFC.2010809@oracle.com> David, Thanks for your reply. I saw other jobs also had the similar jprt command. I wonder why others could succeed in the build. -Dan On Mon 07 Jan 2013 11:20:18 PM PST, David Holmes wrote: > Hi Dan, > > On 8/01/2013 5:11 PM, Dan Xu wrote: >> Hi, >> >> Today I submitted several jprt jobs asusual, but all jobs failed in >> building processat the same place. I tried to build jdk locally, and it >> worked fine. And I also tried to create a new jdk repo from the scratch, >> and then submitteda job. But the jprt job also failed in the buildwith >> the same reason as the following. >> >> "com/sun/tools/jdeps : no such file or directory". >> >> Here is one log file, >> http://prt-web.us.oracle.com//archive/2013/01/2013-01-08-065313.dan.jdk/logs/linux_i586_2.6-product.log.FAILED.log. >> >> >> My repository only contains open jdk. And in the new repository, I only >> added a space to a test file. Did anyone encounter a similar problem >> before? > > You have to submit jdk and langtools together (at least until the > imported langtools catches up with recent changes). You need a > langtools with the jdeps tool. > > David > > >> Thanks, >> >> -Dan >> From david.holmes at oracle.com Tue Jan 8 07:55:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Jan 2013 17:55:01 +1000 Subject: Build Failure in JPRT Job In-Reply-To: <50EBCAFC.2010809@oracle.com> References: <50EBC6AA.9040302@oracle.com> <50EBC8B2.1090600@oracle.com> <50EBCAFC.2010809@oracle.com> Message-ID: <50EBD0D5.2030401@oracle.com> On 8/01/2013 5:30 PM, Dan Xu wrote: > David, > > Thanks for your reply. > > I saw other jobs also had the similar jprt command. I wonder why others > could succeed in the build. I'm not seeing such successes. I am seeing similar failures eg: http://prt-web.us.oracle.com//archive/2013/01/2013-01-08-005620.bpb.jdk/JobEmail.txt Looks like core-libs has had a bit of a flag-day with langtools (the second is recent time - doclint was the other), and it is catching a lot of people unawares. David > -Dan > > On Mon 07 Jan 2013 11:20:18 PM PST, David Holmes wrote: >> Hi Dan, >> >> On 8/01/2013 5:11 PM, Dan Xu wrote: >>> Hi, >>> >>> Today I submitted several jprt jobs asusual, but all jobs failed in >>> building processat the same place. I tried to build jdk locally, and it >>> worked fine. And I also tried to create a new jdk repo from the scratch, >>> and then submitteda job. But the jprt job also failed in the buildwith >>> the same reason as the following. >>> >>> "com/sun/tools/jdeps : no such file or directory". >>> >>> Here is one log file, >>> http://prt-web.us.oracle.com//archive/2013/01/2013-01-08-065313.dan.jdk/logs/linux_i586_2.6-product.log.FAILED.log. >>> >>> >>> >>> My repository only contains open jdk. And in the new repository, I only >>> added a space to a test file. Did anyone encounter a similar problem >>> before? >> >> You have to submit jdk and langtools together (at least until the >> imported langtools catches up with recent changes). You need a >> langtools with the jdeps tool. >> >> David >> >> >>> Thanks, >>> >>> -Dan >>> From Alan.Bateman at oracle.com Tue Jan 8 09:07:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Jan 2013 09:07:36 +0000 Subject: Build Failure in JPRT Job In-Reply-To: <50EBCAFC.2010809@oracle.com> References: <50EBC6AA.9040302@oracle.com> <50EBC8B2.1090600@oracle.com> <50EBCAFC.2010809@oracle.com> Message-ID: <50EBE1D8.9020708@oracle.com> On 08/01/2013 07:30, Dan Xu wrote: > David, > > Thanks for your reply. > > I saw other jobs also had the similar jprt command. I wonder why > others could succeed in the build. If partial builds of jdk8/tl, ie: jdk repo only, are succeeding then the repository is probably not up to date. Alternatively, they are partial builds of the jdk repo in other forests, jdk8/awt/jdk for example. In general, partial builds are fragile and in the case of jdk8/tl then there regular flag days where you need to build langtools+jdk, can't use the langtools from a promoted build. -Alan From maurizio.cimadamore at oracle.com Tue Jan 8 09:18:38 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 08 Jan 2013 09:18:38 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130108091845.95809470E1@hg.openjdk.java.net> Changeset: 38d3d1027f5a Author: mcimadamore Date: 2013-01-08 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38d3d1027f5a 8005243: Restructure method check code to allow pluggable checkers Summary: Add interface to perform a method check - to be implemented by helper classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: db91d860156a Author: mcimadamore Date: 2013-01-08 10:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/db91d860156a 8005179: Cleanup Resolve.AmbiguityError Summary: Linearize nested ambiguity errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out Changeset: d07340b61e6a Author: mcimadamore Date: 2013-01-08 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d07340b61e6a 8005184: Restructure DeferredAttr to allow pluggable deferred type completers Summary: Add hooks to generalize deferred type completion via custom helper objects Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java From Alan.Bateman at oracle.com Tue Jan 8 11:31:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Jan 2013 11:31:34 +0000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50EBA6D6.3090601@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> <50EBA6D6.3090601@oracle.com> Message-ID: <50EC0396.7090309@oracle.com> On 08/01/2013 04:55, David Holmes wrote: > I've generated a fresh webrev with your changes. > > http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/ > > Looking to get the Thumbs up on the src and test changes. > Thanks for updating the webrev, I can confirm that it has all of the changes that we were accumulating in jdk8/profiles. I've put a page here with additional details as to what is in (or not in) each of the builds: http://cr.openjdk.java.net/~alanb/profiles/impl_notes.html This supplements the API packages proposed in the JEP (I will update the JEP once all the Lambda work and JSR-310 is in as the contents are a bit of a moving target at this time). -Alan From dl at cs.oswego.edu Tue Jan 8 12:05:28 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 08 Jan 2013 07:05:28 -0500 Subject: Improving ThreadLocalRandom (and related classes) Message-ID: <50EC0B88.3070102@cs.oswego.edu> When we introduced ThreadLocalRandom, we conservatively implemented it to use an actual ThreadLocal. However, as it becomes more widely used, it is worth improving the implementation by housing ThreadLocalRandom state (and related bookkeeping) in class Thread itself. This would entail three fields (16 total bytes). So I propose adding the following to class Thread: // The following three initially uninitialized fields are exclusively // managed by class java.util.concurrent.ThreadLocalRandom. /** The current seed for a ThreadLocalRandom */ long threadLocalRandomSeed; /** Probe hash value; nonzero if threadLocalRandomSeed initialized */ int threadLocalRandomProbe; /** Secondary seed isolated from public ThreadLocalRandom sequence */ int threadLocalRandomSecondarySeed; The reasons for doing it in this way are: 1. Uniformly faster access to ThreadLocalRandom state. While ThreadLocal access is normally pretty fast already, this is not only faster, it does not degrade in cases where user programs create large numbers of ThreadLocals, which may (probabilistically) cause any given access to become slower. 2. Smaller total footprint for any program using ThreadLocalRandom. Three fields require less space than boxing into a padded ThreadLocal object. As ThreadLocalRandom becomes widely used within JDK itself, this includes just about all programs. 3. Further time/space savings for java.util.concurrent ForkJoinPool, ConcurrentHashMap, LongAdder, ConcurrentSkipList, and other classes that could use this form of the unified ThreadLocalRandom bookkeeping rather than their own special-purpose ThreadLocals as they now do. Any objections? If not, I'd need the help of someone permitted to paste the above into class Thread, review, and and commit. -Doug From daniel.fuchs at oracle.com Tue Jan 8 12:20:47 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 08 Jan 2013 13:20:47 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EB9CDF.1050908@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> Message-ID: <50EC0F1F.2030403@oracle.com> On 1/8/13 5:13 AM, Mandy Chung wrote: > Hi Daniel, > > I also agree with option 3 be the best option among them. Joe's > suggestion to throw an exception if factoryId is not the base service > type is good so that any existing application depending on that behavior > will catch this change. Are you going to revise the spec - there is > statement saying that the newFactory method is the same behavior as > newInstance method which is weakly specified. > > 139 * No changes in behavior are defined by this replacement method > relative > 140 * to the deprecated method. > > > It'd be good to add some tests to cover these APIs if there is none. > Otherwise, the change looks good. > Mandy Right - thanks Mandy. I've clarified the spec. I also documented an additional step, which was done by the implementation but not documented - which is that the stream factory will also look up for properties in jaxp.properties if stax.properties was not found. webrev: I have generated a spec diff for easier reading of the doc changes: regards, -- daniel > > On 1/7/2013 2:34 AM, Daniel Fuchs wrote: >> Thanks Joe. >> >> To make things clear I have pushed a revised webrev with solution 3. >> >> >> >> The lines of interest are in FactoryFinder.java - right hand side: >> >> 267 if (type.getName().equals(factoryId)) { >> 268 // Try Jar Service Provider Mechanism >> 269 final T provider = findServiceProvider(type); >> 270 if (provider != null) { >> 271 return provider; >> 272 } >> 273 } else { >> 274 // We're in the case where a 'custom' factoryId was >> provided, >> 275 // and in every case where that happens, we expect that >> 276 // fallbackClassName will be null. >> 277 assert fallbackClassName == null; >> 278 } >> >> regards, >> >> -- daniel >> >> >> On 1/4/13 7:51 PM, Joe Wang wrote: >>> Hi Daniel, >>> >>> Yes, I agree with 3. As I said before, we should return an error if >>> factoryId != type.getName() since it indicates a configuration error. >>> Scenario 4 does exist, but it's beyond the current spec. Such an impl >>> should not use the default API. >>> >>> The StAX spec is not always clear. My interpretation of the definition >>> of factoryId to be the "same as a property name" is that the author >>> basically was saying that it's equivalent to a name as in a property, >>> not the "value", therefore different from the DOM/SAX API -- a bad >>> choice I would think. >>> >>> Thanks, >>> Joe >>> >>> On 1/4/2013 6:31 AM, Daniel Fuchs wrote: >>>> Hi guys, >>>> >>>> Happy new year to you all! And apologies for this long email :-) >>>> >>>> I think we still haven't converged on this issue in >>>> javax.xml.stream - so let me make a recap. >>>> >>>> The issue is for the newInstance/newFactory methods >>>> that take a factoryId parameter, in the factories for >>>> the javax.xml.stream package: >>>> >>>> [ >>>> >>>> >>>> >>>> FactoryFinder.java: line 267-268 right hand side. ] >>>> >>>> >>>> recap of the issue: >>>> ------------------- >>>> >>>> In case the provided factoryId did not correspond to any >>>> System/JAXP/StAX property, the old code used to look >>>> for a service in META-INF/services using the factoryId as the >>>> name of the file for looking up the implementation class. >>>> In case factoryId was not the same as the base service >>>> class (or a subclass of it) it still would have worked >>>> although it went in contradiction to the Jar Specification >>>> mentioned in the javadoc, since the Jar Specification clearly >>>> states that the file name should be the fully qualified name >>>> of the base service class. >>>> >>>> Since we're going to replace the code that looked up for >>>> a service in META-INF with a call to ServiceLoader, we can >>>> no longer fully preserve that old behavior, because ServiceLoader >>>> only takes a base service class (and no arbitrary file name). >>>> >>>> what choices do we have? >>>> ------------------------ >>>> >>>> The question is therefore how we want to change this. >>>> I think we have 4 (exclusive) possibilities. >>>> >>>> In the case where a factoryId is provided, but no >>>> System/JAXP/StAX property by that name has been found, >>>> we could choose to either: >>>> >>>> 1. Always call ServiceLoader.load(type) where type is the >>>> service base class. >>>> >>>> 2. Never call ServiceLoader.load(type) >>>> >>>> 3. Only call ServiceLoader.load(type) when the provided >>>> factoryId is equal to type.getName() >>>> >>>> 4. If factoryId is equal to type.getName(), call >>>> ServiceLoader.load(type), otherwise, >>>> attempt to load factoryId as a class - and if that >>>> class is a subclass of 'type' then call >>>> ServiceLoader.load for that subclass. >>>> >>>> pros & cons: >>>> ------------ >>>> >>>> Here is a list of pros & cons for each of these options: >>>> >>>> 1. is the naive implementation I originally proposed. >>>> Pros: >>>> - P1.1: simple >>>> - P1.2: no change in behavior if factoryId == type.getName() >>>> Cons: >>>> - C1.1: may find no provider when the old code used to >>>> find one, (case where factoryId="foo", there's a >>>> provider for "foo" and there's no provider for type.getName()) >>>> - C1.2: may find a provider when the old code used to >>>> find none (case where factoryId="foo", there's no provider >>>> for foo, but there's a provider for type.getName()) >>>> - C1.3: may find a different provider than what the old >>>> code use to find (case where factoryId="foo", there's a >>>> provider for "foo" and there's also a provider for >>>> type.getName()) >>>> >>>> 2. is more drastic: if you specify a property - then the property >>>> has to be defined somewhere for newInstance/newFactory to >>>> succeed. >>>> Pros: >>>> - P2.1: simple >>>> Cons: >>>> - C2.1: there's a change of behavior even when >>>> factoryId == type.getName() and no property by that >>>> name is defined. >>>> - C2.2: in all cases where the old code used to find a >>>> provider by looking at META-INF/services, the new code >>>> will find nothing. >>>> Although it's the most simple - it's probably the most risky >>>> in terms of compatibility. >>>> >>>> 3. Same as 1. except that C1.2 and C1.3 are removed. >>>> >>>> 4. Same as 3. except that it's more complex (so P1.1 is >>>> removed) and that C1.1 will not occur in the case >>>> where factoryId is the name of a subclass of 'type' >>>> >>>> In conclusion: >>>> -------------- >>>> >>>> Since the original spec only says that factoryId is >>>> "same as property" - it's very difficult to figure out >>>> which of these 4 options is the closer to the behavior >>>> intended by the spec. >>>> >>>> I personally think that the case where factoryId="foo", >>>> and no property "foo" is defined, but a provider exists for >>>> "foo" and an implementation is returned, is a bug - since >>>> it's in contradiction with the Jar Specification mentioned >>>> in the spec which clearly states that "foo" should >>>> have been a service class name. >>>> >>>> So although 4. is the implementation that would offer the >>>> greater compatibility with existing code, I am sorely >>>> tempted to recommend that we do 3. and clarify >>>> the spec on this point. >>>> (3: Only call ServiceLoader.load(type) when the provided >>>> factoryId is equal to type.getName()) >>>> >>>> Best regards, >>>> >>>> -- daniel >>>> >>>> On 12/19/12 10:45 AM, Daniel Fuchs wrote: >>>>> On 12/19/12 12:10 AM, Joe Wang wrote: >>>>>> It's different. If 'foo.bar' is specified but not found, it indicates >>>>>> a configuration error. If the factory falls back to an impl by the >>>>>> default factory id, it would serve to hide the error. >>>>> Yes - I fully agree with that. >>>>>> Note that newInstance/newFactory with a factoryId parameter do not >>>>>> fall back to the default implementation. >>>>> Ahh! Yes I missed that. When called from newInstance with a factoryId >>>>> parameter the fallbackClassname parameter >>>>> is null... >>>>> >>>>> So should we still call ServiceLoader when fallbackClassname is >>>>> null and >>>>> factoryId is type.getName()? It would be more >>>>> backward compatible - since previously it was looking in the jars and >>>>> found (valid) providers registered with that name. >>>>> >>>>> On the other hand we could alter the spec to say that if no property >>>>> with the factoryId name is found - then >>>>> no fallback loading is perform (either on ServiceLoader or >>>>> system-default implementation) and an error is thrown. >>>>> >>>>> -- daniel >>>> >> From Ulf.Zibis at CoSoCo.de Tue Jan 8 13:11:12 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 08 Jan 2013 14:11:12 +0100 Subject: Fwd: OpenJDK builds: Ant build issues with jdk (netbeans) sub-projects - awt2d, j2se and jarzip In-Reply-To: References: <50E8D2DB.6090206@oracle.com> Message-ID: <50EC1AF0.8070804@CoSoCo.de> Hi Mani, nb-projects-dev at openjdk.java.net should be the right place, but there is "little" trafic. This keeps me wondering too since years, as NetBeans is an Oracle Product. It's a mystery why it seems so hard to have NetBeans working for JDK developement workflow. So I think it's OK to additionally put your question here in core-libs. -Ulf Am 08.01.2013 00:21, schrieb Mani Sarkar: > Hi, > > I have been recommended to post my below query to your mailing list, if it > is the right place to post. If not could you recommend who would be best > placed to answer the below questions. > > I couldn't find an appropriate mailing list for 'jarzip' (as it is > part of langtools) > - any suggestions? It would be great if you could answer my query about it > too. > > Thanks. > > Regards, > Mani > > On 01/05/2013 04:05 PM, Mani Sarkar wrote: > >> Hi all, >> >> I have made some progress with the below three sub-projects, and have >> successfully built jarzip. But still get new error messages with awt2d and >> j2se. >> >> I answered my own question about the -source 8, its basically expecting the >> images/j2sdk-image to be assigned to the respective ALT_... variables via >> the make.options property in build.properties for all three projects. >> >> Unfortunately I wasn't able to build swing via the .../javax/swing/ folder >> where the required make file(s) are present. >> >> But my other queries still stand, if you can throw some light on them, it >> would be help make progress with these builds using the new build system. >> >> Thanks. >> >> Regards, >> Mani >> >> On Sat, Jan 5, 2013 at 12:39 AM, Mani Sarkar wrote: >> >> Hi All, >>> I have furthered my pursuits with building *OpenJDK projects *by building >>> >>> the JDK sub-projects like swing, etc... but came across issues with >>> building 3 different projects which I wasn't able to build due >>> configuration issues. These sub-projects are located under the netbeans >>> subfolder under the .../jdk/make/ folder. >>> >>> They all are getting compiled for version 8 with the below args (which is >>> leading to a build failure): >>> >>> -source 8 -target 8 >>> >>> *jdk/awt2d* >>> >>> https://github.com/**neomatrix369/BuildHelpers/**blob/master/** >>> EclipseProjectsForOpenJDK/**Logs/jdk/awt2d/awt2dAntBuild.**log >>> >>> *jdk/j2se* >>> >>> https://github.com/**neomatrix369/BuildHelpers/**blob/master/** >>> EclipseProjectsForOpenJDK/**Logs/jdk/j2se/j2seAntBuild.log >>> >>> *jdk/jarzip* >>> >>> >>> https://github.com/**neomatrix369/BuildHelpers/**blob/master/** >>> EclipseProjectsForOpenJDK/**Logs/jdk/jarzip/**jarzipAntBuild.log >>> >>> Where is this version configuration set for these projects, that I can >>> change either through file changes or alternative build.properties setting >>> changes? My other question is why are there no make files available for >>> the >>> jdk sub-projects (i.e. *awt2d, j2se,* etc...) except for under * >>> javax/swing* has make files to build this project instead Ant build.xml >>> >>> files are available. Is it possible to hook these ant files with the new >>> build system, instead of only being able to build the sub-projects via the >>> old build system (using the ALT_... variables via make.options). >>> >>> Thanks. >>> >>> Regards, >>> mani >>> >>> -- >>> Twitter: @theNeomatrix369 >>> Blog: http://neomatrix369.wordpress.**com >>> > >>> >>> *Don't chase success, rather aim for "Excellence", and success will come >>> chasing after you!* >>> >>> >> > > From vicente.romero at oracle.com Tue Jan 8 13:53:40 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 08 Jan 2013 13:53:40 +0000 Subject: hg: jdk8/tl/langtools: 8005167: execution time of combo tests in javac should be improved Message-ID: <20130108135342.EC5A5470EC@hg.openjdk.java.net> Changeset: 954541f13717 Author: vromero Date: 2013-01-08 13:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/954541f13717 8005167: execution time of combo tests in javac should be improved Reviewed-by: jjg, jjh ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java + test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From aph at redhat.com Tue Jan 8 13:43:20 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 08 Jan 2013 13:43:20 +0000 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC0B88.3070102@cs.oswego.edu> References: <50EC0B88.3070102@cs.oswego.edu> Message-ID: <50EC2278.4060506@redhat.com> On 01/08/2013 12:05 PM, Doug Lea wrote: > 1. Uniformly faster access to ThreadLocalRandom state. While > ThreadLocal access is normally pretty fast already, this is > not only faster, it does not degrade in cases where user > programs create large numbers of ThreadLocals, which > may (probabilistically) cause any given access to become > slower. One random thought. Linux x86 has very fast access to thread local variables: it's just a segment prefix on a load instruction. I wonder if the JVM could utilize something like this and so improve performance for thread locals that don't require non-null initial values. This would be better than piling everything into Thread's state... Andrew. From dl at cs.oswego.edu Tue Jan 8 13:58:58 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 08 Jan 2013 08:58:58 -0500 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC2278.4060506@redhat.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC2278.4060506@redhat.com> Message-ID: <50EC2622.8020503@cs.oswego.edu> On 01/08/13 08:43, Andrew Haley wrote: > One random thought. Linux x86 has very fast access to thread local > variables: it's just a segment prefix on a load instruction. I wonder > if the JVM could utilize something like this and so improve > performance for thread locals that don't require non-null initial > values. Thanks. Yes, I've had discussions with various people over the years about somehow exploiting native thread-local support for simple scalars. I don't think there is a great scheme to be had here though. Problems include (1) fixed arena sizes on some/most platforms. (2) no good way to coordinate slot-grabbing with native uses (3) no good way to relinquish (4) no good emulation scheme for systems without support But mostly: The space for "permanent" thread-locals needs to be placed somewhere; why not choose the place that presents the fewest logistics problems? Note that class java.lang.Thread is only the visible tip of the iceberg of per-thread storage on systems. so adding 16bytes is all but undetectable. -Doug From erik.joelsson at oracle.com Tue Jan 8 14:07:59 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 08 Jan 2013 15:07:59 +0100 Subject: Review Request: 8005856: build-infra: Remove special handling of base module classes header generation Message-ID: <50EC283F.1050601@oracle.com> Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotation javax.tools.annotation.GenerateNativeHeader is. Now there is a new annotation on fields, java.lang.annotation.Native, that can be used for these classes. Since this change touches java files, I'm adding core-libs to the review. Original change in build-infra was made by Fredrik Ohrstrom. http://cr.openjdk.java.net/~erikj/8005856/webrev.jdk.01/ /Erik From Alan.Bateman at oracle.com Tue Jan 8 14:17:30 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Jan 2013 14:17:30 +0000 Subject: Review Request: 8005856: build-infra: Remove special handling of base module classes header generation In-Reply-To: <50EC283F.1050601@oracle.com> References: <50EC283F.1050601@oracle.com> Message-ID: <50EC2A7A.9050408@oracle.com> On 08/01/2013 14:07, Erik Joelsson wrote: > Five classes which in jigsaw will be located in the base module > currently have their native headers generated in a special way > (explicitly with javah). This was because the base module could not be > made dependent on the compiler module where the annotation > javax.tools.annotation.GenerateNativeHeader is. Now there is a new > annotation on fields, java.lang.annotation.Native, that can be used > for these classes. > > Since this change touches java files, I'm adding core-libs to the review. > > Original change in build-infra was made by Fredrik Ohrstrom. > > http://cr.openjdk.java.net/~erikj/8005856/webrev.jdk.01/ > > /Erik This looks good to me. -Alan From peter.levart at gmail.com Tue Jan 8 14:38:13 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jan 2013 15:38:13 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EB1CEC.6060600@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> Message-ID: <50EC2F55.4070301@gmail.com> On 01/07/2013 08:07 PM, Joe Darcy wrote: > Hello, > > I had a question about how the double accumulation logic was intended > to be used. I've taken a quick look at the code and it uses > straightforward "sum = sum + nextValue" code to compute the double > sum. Summing doubles values with code numerical accuracy is > surprisingly tricky and if the DoubleAccumulator code is meant for > wide use, I'd recommend using instead some form of compensated summation: > > http://en.wikipedia.org/wiki/Kahan_summation_algorithm Hello Joe, It's very hard to program such algorithm in Java. Guess what prints the following code: double x = 1.0E100; double a = 1d; double y = x + a; double diff = y - x; double c = a - diff; System.out.println(diff); System.out.println(c); Do you have any idea how to do that (still using local variables)? Regards, Peter > > Thanks, > > -Joe > > On 1/5/2013 10:10 AM, Chris Hegarty wrote: >> As part of JEP 155 we are proposing to add the following public >> classes to support Scalable Updatable Variables, DoubleAccumulator, >> DoubleAdder, LongAccumulator and LongAdder. >> >> These have been written by Doug Lea, with assistance from members of >> the former JCP JSR-166 Expert Group. >> >> Webrev and javadoc are at: >> http://cr.openjdk.java.net/~chegar/8005311/ver.00/ >> >> Since Doug is the author, I am taking a reviewer/sponsor role. >> >> Here are my initial comments. >> - There are various places in DoubleAccmulator where there are broken >> links to #sum ( I think it is just a cut'n'paste error ). These >> should be #get. >> - Accumulators >> {@link #get} may read somewhat better as {@link #get current >> value} ?? >> - Accumulators >> Does the 'identity' value need further explanation? >> >> Note: There is one minor change to the implementation. Currently in >> the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble. >> This method has been renamed to applyAsDouble in the lambda/lambda >> repo. When these changes are sync'ed from lambda/lambda this can be >> reverted. A similar comment has been added to the code. >> >> -Chris. > From peter.levart at gmail.com Tue Jan 8 15:01:31 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jan 2013 16:01:31 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50E86CAC.8090606@oracle.com> References: <50E86CAC.8090606@oracle.com> Message-ID: <50EC34CB.50703@gmail.com> On 01/05/2013 07:10 PM, Chris Hegarty wrote: > As part of JEP 155 we are proposing to add the following public > classes to support Scalable Updatable Variables, DoubleAccumulator, > DoubleAdder, LongAccumulator and LongAdder. > > These have been written by Doug Lea, with assistance from members of > the former JCP JSR-166 Expert Group. > Hello Doug, These are very interesting and useful classes already as they are. They might be also used for other unintended purposes like scalable random generators, or unique identifier generators if their API would expose some more info. For example, I did an experiment and patched the code paths used in LongAccumulator so that: - accumulate(long x) returns the post-modification value of the modified cell or base (the returned value of the function that was used to update the state) - the accumulator function is always called for initial allocations of cells (with identity value as 1st argument, like when accumulating on the base) - the original code optimizes this situation and just installs the parameter x into the cell. With this modified API and a little copy-and-paste, I could quickly assemble the following MultiThreadedRandom: public class MultiThreadedRandom extends Random { private static final long multiplier = 0x5DEECE66DL; private static final long addend = 0xBL; private static final long mask = (1L << 48) - 1; private static final AtomicLong seedUniquifier = new AtomicLong(8682522807148012L); private static final LongSupplier defaultSeedSupplier = () -> { // L'Ecuyer, "Tables of Linear Congruential Generators of // Different Sizes and Good Lattice Structure", 1999 for (; ; ) { long current = seedUniquifier.get(); long next = current * 181783497276652981L; if (seedUniquifier.compareAndSet(current, next)) return next; } }; private final LongAccumulator rnd; public MultiThreadedRandom() { this(defaultSeedSupplier); } public MultiThreadedRandom(final LongSupplier seedSupplier) { super(0L); // ignored Objects.requireNonNull(seedSupplier); this.rnd = new LongAccumulator( (seed, _ignore) -> { if (seed == 0L) seed = (seedSupplier.getAsLong() ^ multiplier) & mask; return (seed * multiplier + addend) & mask; }, 0L ); } public void setSeed(long seed) { if (rnd != null) throw new UnsupportedOperationException(); } @Override protected int next(int bits) { long nextseed = rnd.accumulate(0L); return (int) (nextseed >>> (48 - bits)); } } ...which has great scalability, although it is about 3x slower then TreadLocalRandom.current().next()... I'm also thinking about what would be possible to do with DoubleAdder it it had a method like getAndAdd(double x) which returned the pre-modification state of the cell/base. It might be possible to use two DoubleAdders to devise a more accurate adder for example: public class MyDoubleAdder { private final DoubleAdder primary = new DoubleAdder(); private final DoubleAdder secondary = new DoubleAdder(); public void add(double x) { double prev = primary.getAndAdd(x); double next = prev + x; double diff = next - prev; double c = x - diff; secondary.add(c); } public double sum() { return primary.sum() + secondary.sum(); } } Regards, Peter P.S. Here's a patch I used: diff --git a/jdk/src/java/util/concurrent/atomic/LongAccumulator.java b/jdk/src/java/util/concurrent/atomic/LongAccumulator.java index 720722e..e84b9b3 100644 --- a/jdk/src/java/util/concurrent/atomic/LongAccumulator.java +++ b/jdk/src/java/util/concurrent/atomic/LongAccumulator.java @@ -86,8 +86,9 @@ public class LongAccumulator extends Striped64 implements Serializable { * Updates with the given value. * * @param x the value + * @return the returned value of the accumulator function that was used to update the state of this accumulator */ - public void accumulate(long x) { + public long accumulate(long x) { Cell[] as; long b, v, r; CellHashCode hc; Cell a; int m; if ((as = cells) != null || (r = function.applyAsLong(b = base, x)) != b && !casBase(b, r)) { // ## rename when JDK8 syncs with lambda, applyAsLong @@ -98,8 +99,9 @@ public class LongAccumulator extends Striped64 implements Serializable { !(uncontended = (r = function.applyAsLong(v = a.value, x)) == v || // ## rename when JDK8 syncs with lambda, applyAsLong a.cas(v, r))) - longAccumulate(x, hc, function, uncontended); + r = longAccumulate(x, hc, identity, function, uncontended); } + return r; } /** diff --git a/jdk/src/java/util/concurrent/atomic/LongAdder.java b/jdk/src/java/util/concurrent/atomic/LongAdder.java index f459dcc..c57afc5 100644 --- a/jdk/src/java/util/concurrent/atomic/LongAdder.java +++ b/jdk/src/java/util/concurrent/atomic/LongAdder.java @@ -98,7 +98,7 @@ public class LongAdder extends Striped64 implements Serializable { as == null || (m = as.length - 1) < 0 || (a = as[m & hc.code]) == null || !(uncontended = a.cas(v = a.value, v + x))) - longAccumulate(x, hc, null, uncontended); + longAccumulate(x, hc, 0L, null, uncontended); } } diff --git a/jdk/src/java/util/concurrent/atomic/Striped64.java b/jdk/src/java/util/concurrent/atomic/Striped64.java index 6a87020..4adde3c 100644 --- a/jdk/src/java/util/concurrent/atomic/Striped64.java +++ b/jdk/src/java/util/concurrent/atomic/Striped64.java @@ -213,13 +213,15 @@ abstract class Striped64 extends Number { * * @param x the value * @param hc the hash code holder + * @param identity the identity value used when {@code fn} is non-null * @param fn the update function, or null for add (this convention * avoids the need for an extra field or function in LongAdder). * @param wasUncontended false if CAS failed before call */ - final void longAccumulate(long x, CellHashCode hc, - LongBinaryOperator fn, + final long longAccumulate(long x, CellHashCode hc, + long identity, LongBinaryOperator fn, boolean wasUncontended) { + long res; int h; if (hc == null) { hc = new CellHashCode(); @@ -235,7 +237,8 @@ abstract class Striped64 extends Number { if ((as = cells) != null && (n = as.length) > 0) { if ((a = as[(n - 1) & h]) == null) { if (cellsBusy == 0) { // Try to attach new Cell - Cell r = new Cell(x); // Optimistically create + Cell r = new Cell(res = ((fn == null) ? x : + fn.applyAsLong(identity, x))); // Optimistically create if (cellsBusy == 0 && casCellsBusy()) { boolean created = false; try { // Recheck under lock @@ -258,7 +261,7 @@ abstract class Striped64 extends Number { } else if (!wasUncontended) // CAS already known to fail wasUncontended = true; // Continue after rehash - else if (a.cas(v = a.value, ((fn == null) ? v + x : + else if (a.cas(v = a.value, res = ((fn == null) ? v + x : fn.applyAsLong(v, x)))) // ## rename when JDK8 syncs with lambda, applyAsLong break; else if (n >= NCPU || cells != as) @@ -284,25 +287,24 @@ abstract class Striped64 extends Number { h ^= h << 5; } else if (cellsBusy == 0 && cells == as && casCellsBusy()) { - boolean init = false; try { // Initialize table if (cells == as) { Cell[] rs = new Cell[2]; - rs[h & 1] = new Cell(x); + rs[h & 1] = new Cell(res = ((fn == null) ? x : + fn.applyAsLong(identity, x))); cells = rs; - init = true; + break; } } finally { cellsBusy = 0; } - if (init) - break; } - else if (casBase(v = base, ((fn == null) ? v + x : + else if (casBase(v = base, res = ((fn == null) ? v + x : fn.applyAsLong(v, x)))) // ## rename when JDK8 syncs with lambda, applyAsLong break; // Fall back on using base } hc.code = h; // Record index for next time + return res; } /** From peter.levart at gmail.com Tue Jan 8 15:05:48 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 08 Jan 2013 16:05:48 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EC2F55.4070301@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EC2F55.4070301@gmail.com> Message-ID: <50EC35CC.5000708@gmail.com> On 01/08/2013 03:38 PM, Peter Levart wrote: > On 01/07/2013 08:07 PM, Joe Darcy wrote: >> Hello, >> >> I had a question about how the double accumulation logic was intended >> to be used. I've taken a quick look at the code and it uses >> straightforward "sum = sum + nextValue" code to compute the double >> sum. Summing doubles values with code numerical accuracy is >> surprisingly tricky and if the DoubleAccumulator code is meant for >> wide use, I'd recommend using instead some form of compensated >> summation: >> >> http://en.wikipedia.org/wiki/Kahan_summation_algorithm > > Hello Joe, > > It's very hard to program such algorithm in Java. Guess what prints > the following code: > > double x = 1.0E100; > double a = 1d; > double y = x + a; > double diff = y - x; > double c = a - diff; > System.out.println(diff); > System.out.println(c); > > Do you have any idea how to do that (still using local variables)? > > Regards, Peter Disregard this question. I thought I saw it reversed... Regards, Peter > > >> >> Thanks, >> >> -Joe >> >> On 1/5/2013 10:10 AM, Chris Hegarty wrote: >>> As part of JEP 155 we are proposing to add the following public >>> classes to support Scalable Updatable Variables, DoubleAccumulator, >>> DoubleAdder, LongAccumulator and LongAdder. >>> >>> These have been written by Doug Lea, with assistance from members of >>> the former JCP JSR-166 Expert Group. >>> >>> Webrev and javadoc are at: >>> http://cr.openjdk.java.net/~chegar/8005311/ver.00/ >>> >>> Since Doug is the author, I am taking a reviewer/sponsor role. >>> >>> Here are my initial comments. >>> - There are various places in DoubleAccmulator where there are broken >>> links to #sum ( I think it is just a cut'n'paste error ). These >>> should be #get. >>> - Accumulators >>> {@link #get} may read somewhat better as {@link #get current >>> value} ?? >>> - Accumulators >>> Does the 'identity' value need further explanation? >>> >>> Note: There is one minor change to the implementation. Currently in >>> the jdk8 repo j.u.f.DoubleBinaryOperator defines operateAsDouble. >>> This method has been renamed to applyAsDouble in the lambda/lambda >>> repo. When these changes are sync'ed from lambda/lambda this can be >>> reverted. A similar comment has been added to the code. >>> >>> -Chris. >> > From dl at cs.oswego.edu Tue Jan 8 15:32:35 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 08 Jan 2013 10:32:35 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EC34CB.50703@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EC34CB.50703@gmail.com> Message-ID: <50EC3C13.7050802@cs.oswego.edu> On 01/08/13 10:01, Peter Levart wrote: > - accumulate(long x) returns the post-modification value of the modified cell or > base (the returned value of the function that was used to update the state) To avoid what would be a serious and common usage error (people treating the return value as if it were the aggregate result), this would need to be exposed only in a suitably-name "protected" method. OK? > - the accumulator function is always called for initial allocations of cells > (with identity value as 1st argument, like when accumulating on the base) - the > original code optimizes this situation and just installs the parameter x into > the cell. Good idea; thanks. I see that this tiny and cheap change would just barely widen applicability. -Doug From chris.hegarty at oracle.com Tue Jan 8 16:07:10 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Jan 2013 16:07:10 +0000 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC0B88.3070102@cs.oswego.edu> References: <50EC0B88.3070102@cs.oswego.edu> Message-ID: <50EC442E.2070104@oracle.com> Doug, I have no objection as such to adding certain fields to j.l.Thread to support faster ThreadLocalRandom. Maybe it would help to see how they are to be used? Given, 1 and 2 below ( I'm not sure about 3 ), would having a direct reference from j.l.Thread to ThreadLocalRandom (rather than using ThreadLocal) resolve these problems? -Chris. On 01/08/2013 12:05 PM, Doug Lea wrote: > > When we introduced ThreadLocalRandom, we conservatively > implemented it to use an actual ThreadLocal. However, > as it becomes more widely used, it is worth improving > the implementation by housing ThreadLocalRandom state > (and related bookkeeping) in class Thread itself. > This would entail three fields (16 total bytes). > > So I propose adding the following to class Thread: > > // The following three initially uninitialized fields are exclusively > // managed by class java.util.concurrent.ThreadLocalRandom. > /** The current seed for a ThreadLocalRandom */ > long threadLocalRandomSeed; > /** Probe hash value; nonzero if threadLocalRandomSeed initialized */ > int threadLocalRandomProbe; > /** Secondary seed isolated from public ThreadLocalRandom sequence */ > int threadLocalRandomSecondarySeed; > > The reasons for doing it in this way are: > > 1. Uniformly faster access to ThreadLocalRandom state. While > ThreadLocal access is normally pretty fast already, this is > not only faster, it does not degrade in cases where user > programs create large numbers of ThreadLocals, which > may (probabilistically) cause any given access to become > slower. > > 2. Smaller total footprint for any program using ThreadLocalRandom. > Three fields require less space than boxing into a padded > ThreadLocal object. As ThreadLocalRandom becomes widely used > within JDK itself, this includes just about all programs. > > 3. Further time/space savings for java.util.concurrent ForkJoinPool, > ConcurrentHashMap, LongAdder, ConcurrentSkipList, and other > classes that could use this form of the unified ThreadLocalRandom > bookkeeping rather than their own special-purpose ThreadLocals > as they now do. > > Any objections? If not, I'd need the help of someone permitted to > paste the above into class Thread, review, and and commit. > > -Doug From dl at cs.oswego.edu Tue Jan 8 16:33:14 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 08 Jan 2013 11:33:14 -0500 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC442E.2070104@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> Message-ID: <50EC4A4A.1050009@cs.oswego.edu> On 01/08/13 11:07, Chris Hegarty wrote: > Doug, > > I have no objection as such to adding certain fields to j.l.Thread to support > faster ThreadLocalRandom. Maybe it would help to see how they are to be used? One use that reminded me that I ought to take this issue out of background and propose it was the the discussion surrounding the possible us of ThreadLocalRandom with HashMaps. It would be great if the 99% of all the uses of Random that could sensibly use ThreadLocalRandom did so. Improving the incentives to use it wouldn't hurt. > > Given, 1 and 2 below ( I'm not sure about 3 ), would having a direct reference > from j.l.Thread to ThreadLocalRandom (rather than using ThreadLocal) resolve > these problems? Yes, this is the Plan-B approach. It seems a little worse. For completeness, I should have mentioned it: By just keeping an initially-null pointer to a ThreadLocalRandom, you can reduce impact on class Thread itself from 16 to 4/8 bytes (depending on 32 vs 64bit pointers). However, the actual ThreadLocalRandom object is padded to avoid memory contention (which wouldn't be necessary or useful if already embedded withing Thread). It also adds (a tiny bit) to preventable GC load to have a pointer in Thread that is never collectable and must be scanned even if never used. While the decision depends in part on the probability of use, I can't think of a good reason to recommend this approach. -Doug From dl at cs.oswego.edu Tue Jan 8 17:33:32 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 08 Jan 2013 12:33:32 -0500 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC442E.2070104@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> Message-ID: <50EC586C.3090407@cs.oswego.edu> On 01/08/13 11:07, Chris Hegarty wrote: > Doug, > > I have no objection as such to adding certain fields to j.l.Thread to support > faster ThreadLocalRandom. Maybe it would help to see how they are to be used? Sorry, it just occurred to me that you surely meant: how would these Thread fields be used in ThreadLocalRandom. here's the basic plan: 1. There is a singleton TLR that is always returned by TLR.current after first checking (via nonzero probe) if initialized for this thread. 2. On a call to next() etc, this object accesses and updates threadLocalRandomSeed using Unsafe (to bypass access control). -Doug From xueming.shen at oracle.com Tue Jan 8 18:53:08 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 08 Jan 2013 10:53:08 -0800 Subject: Could you sponsor another simple fix? In-Reply-To: <50EC67A6.10806@oracle.com> References: <50EC4CA2.6080701@oracle.com> <50EC67A6.10806@oracle.com> Message-ID: <50EC6B14.30207@oracle.com> The correct list is core-libs-dev at openjdk.java.net I will be the sponsor for this change. -Sherman On 01/08/2013 10:38 AM, Coleen Phillimore wrote: > > Hi Ioi, > > I copied it to cr.openjdk.java.net/~coleenp/8005466_zip_util_001 > > I think the mailing list is jdk8-dev at openjdk.java.net. I don't know about jdk8. Since it's a tools/libraries fix, it should be relative to the TL repository (not sure if your fix is). > > I'm apparently "reviewer" on jdk8 and allowed to sponsor changes to jdk8 but I'd prefer if someone like Alan Bateman who actually works on the jdk do this. > > This fix seems cool. > > Thanks, > Coleen > > On 01/08/2013 11:43 AM, Ioi Lam wrote: >> Coleen, >> >> https://jbs.oracle.com/bugs/browse/JDK-8005466?focusedCommentId=13288645#comment-13288645 >> http://javaweb.us.oracle.com/~iklam/webrev/8005466_zip_util_001/ >> >> A one-liner would save about 540KB with Eclipse on 64-bit VMs. >> >> BTW, which mailing list should this be sent to? hotspot-dev at openjdk? >> >> Karen, would it be possible for this to get into JDK8? >> >> Thanks >> - Ioi > From martinrb at google.com Tue Jan 8 19:00:25 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Jan 2013 11:00:25 -0800 Subject: Could you sponsor another simple fix? In-Reply-To: <50EC6B14.30207@oracle.com> References: <50EC4CA2.6080701@oracle.com> <50EC67A6.10806@oracle.com> <50EC6B14.30207@oracle.com> Message-ID: Thanks! This change looks very good to me - why did we the maintainers of zip_util never notice it? It's worth a later backport to jdk7 as well. On Tue, Jan 8, 2013 at 10:53 AM, Xueming Shen wrote: > The correct list is core-libs-dev at openjdk.java.net > > I will be the sponsor for this change. > > -Sherman > > > On 01/08/2013 10:38 AM, Coleen Phillimore wrote: > >> >> Hi Ioi, >> >> I copied it to cr.openjdk.java.net/~coleenp/**8005466_zip_util_001 >> >> I think the mailing list is jdk8-dev at openjdk.java.net. I don't know >> about jdk8. Since it's a tools/libraries fix, it should be relative to >> the TL repository (not sure if your fix is). >> >> I'm apparently "reviewer" on jdk8 and allowed to sponsor changes to jdk8 >> but I'd prefer if someone like Alan Bateman who actually works on the jdk >> do this. >> >> This fix seems cool. >> >> Thanks, >> Coleen >> >> On 01/08/2013 11:43 AM, Ioi Lam wrote: >> >>> Coleen, >>> >>> https://jbs.oracle.com/bugs/**browse/JDK-8005466?** >>> focusedCommentId=13288645#**comment-13288645 >>> http://javaweb.us.oracle.com/~**iklam/webrev/8005466_zip_util_**001/< >>> http://javaweb.us.oracle.com/**%7Eiklam/webrev/8005466_zip_**util_001/ >>> > >>> >>> A one-liner would save about 540KB with Eclipse on 64-bit VMs. >>> >>> BTW, which mailing list should this be sent to? hotspot-dev at openjdk? >>> >>> Karen, would it be possible for this to get into JDK8? >>> >>> Thanks >>> - Ioi >>> >> >> > From kelly.ohair at oracle.com Tue Jan 8 19:59:04 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 8 Jan 2013 11:59:04 -0800 Subject: Review Request: 8005856: build-infra: Remove special handling of base module classes header generation In-Reply-To: <50EC283F.1050601@oracle.com> References: <50EC283F.1050601@oracle.com> Message-ID: <0A506F33-B14F-437E-A3B3-747A9A17D0FD@oracle.com> Looks good. -kto On Jan 8, 2013, at 6:07 AM, Erik Joelsson wrote: > Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotation javax.tools.annotation.GenerateNativeHeader is. Now there is a new annotation on fields, java.lang.annotation.Native, that can be used for these classes. > > Since this change touches java files, I'm adding core-libs to the review. > > Original change in build-infra was made by Fredrik Ohrstrom. > > http://cr.openjdk.java.net/~erikj/8005856/webrev.jdk.01/ > > /Erik From alan.bateman at oracle.com Tue Jan 8 20:48:41 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Jan 2013 20:48:41 +0000 Subject: hg: jdk8/tl/jdk: 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Message-ID: <20130108204915.2507F4710E@hg.openjdk.java.net> Changeset: d29a7ce28189 Author: dxu Date: 2013-01-08 20:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d29a7ce28189 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/PipeImpl.java + test/java/nio/channels/Pipe/PipeInterrupt.java From valerie.peng at oracle.com Tue Jan 8 21:07:27 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Tue, 08 Jan 2013 21:07:27 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20130108210812.56F8A4710F@hg.openjdk.java.net> Changeset: 46e6a4b7ca26 Author: valeriep Date: 2013-01-07 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e6a4b7ca26 6996769: support AEAD cipher Summary: Added implementation for GCM mode under AES cipher Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/share/classes/com/sun/crypto/provider/GCMParameters.java + src/share/classes/com/sun/crypto/provider/GCTR.java + src/share/classes/com/sun/crypto/provider/GHASH.java + src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512524.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512704.java ! test/com/sun/crypto/provider/Cipher/AES/Test4517355.java ! test/com/sun/crypto/provider/Cipher/AES/Test4626070.java + test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java + test/com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java ! test/javax/crypto/Cipher/GCMAPI.java Changeset: 5333a4c8cade Author: valeriep Date: 2013-01-07 14:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5333a4c8cade Merge Changeset: 3c5a62290939 Author: valeriep Date: 2013-01-08 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c5a62290939 8004044: Lazily instantiate SunJCE.RANDOM Summary: Replace the static initialization of SunJCE.RANDOM object w/ lazy initialization Reviewed-by: mchung ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9b6a29cb04ac Author: valeriep Date: 2013-01-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b6a29cb04ac Merge From joe.darcy at oracle.com Tue Jan 8 21:24:11 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Jan 2013 13:24:11 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries Message-ID: <50EC8E7B.807@oracle.com> Hello, As discussed over on one of the Project Lambda lists [1], we're adding an interface type to the platform to explicitly mark interface types as being functional interfaces suitable for use in lambda expressions. Please review the addition of this new type: http://cr.openjdk.java.net/~darcy/8005298.0/ Follow-up work will add @FunctionalInterface annotations to appropriate platform classes. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html From mike.duigou at oracle.com Tue Jan 8 21:49:28 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Jan 2013 13:49:28 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50EC8E7B.807@oracle.com> References: <50EC8E7B.807@oracle.com> Message-ID: Perhaps {@code} around java.lang.Object. The default method and overriding Object method sentences could perhaps be said more simply: {@linkplain java.lang.reflect.Method#isDefault() default methods} in interfaces do provide a method implementation and are not considered abstract. Interface methods which match methods of java.lang.Object are not considered abstract because an implementation (from java.lang.Object) is always available. Mostly it's enough to say that they aren't abstract. The part about abstract method count is superfluous. @jls ref for default methods. @jls ref for methods of Object. On Jan 8 2013, at 13:24 , Joe Darcy wrote: > Hello, > > As discussed over on one of the Project Lambda lists [1], we're adding an interface type to the platform to explicitly mark interface types as being functional interfaces suitable for use in lambda expressions. Please review the addition of this new type: > > http://cr.openjdk.java.net/~darcy/8005298.0/ > > Follow-up work will add @FunctionalInterface annotations to appropriate platform classes. > > Thanks, > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html From joe.darcy at oracle.com Tue Jan 8 22:00:55 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Jan 2013 14:00:55 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: References: <50EC8E7B.807@oracle.com> Message-ID: <50EC9717.2000400@oracle.com> Hi Mike, On 01/08/2013 01:49 PM, Mike Duigou wrote: > Perhaps {@code} around java.lang.Object. Agreed. > > The default method and overriding Object method sentences could perhaps be said more simply: > > {@linkplain java.lang.reflect.Method#isDefault() default methods} in interfaces do provide a method implementation and are not considered abstract. > > Interface methods which match methods of java.lang.Object are not considered abstract because an implementation (from java.lang.Object) is always available. > > Mostly it's enough to say that they aren't abstract. The part about abstract method count is superfluous. Okay; rewritten as: * Conceptually, a functional interface has exactly one abstract * method. Since {@linkplain java.lang.reflect.Method#isDefault() * default methods} have an implementation, they are not abstract. If * an interface declares an abstract method overriding one of the * public methods of {@code java.lang.Object}, that also does * not count toward the interface's abstract method count * since any implementation of the interface will have an * implementation from {@code java.lang.Object} or elsewhere. > > @jls ref for default methods. That is actually included in the draft text of 9.4.3 and so is covered by * @jls 9.4.3 Interface Method Body > > @jls ref for methods of Object. That is a good addition; I'll include * @jls 4.3.2. The Class Object Thanks, -Joe > > On Jan 8 2013, at 13:24 , Joe Darcy wrote: > >> Hello, >> >> As discussed over on one of the Project Lambda lists [1], we're adding an interface type to the platform to explicitly mark interface types as being functional interfaces suitable for use in lambda expressions. Please review the addition of this new type: >> >> http://cr.openjdk.java.net/~darcy/8005298.0/ >> >> Follow-up work will add @FunctionalInterface annotations to appropriate platform classes. >> >> Thanks, >> >> -Joe >> >> [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html From joe.darcy at oracle.com Tue Jan 8 22:43:57 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 08 Jan 2013 14:43:57 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50EC9717.2000400@oracle.com> References: <50EC8E7B.807@oracle.com> <50EC9717.2000400@oracle.com> Message-ID: <50ECA12D.4020300@oracle.com> PS The updated webrev is http://cr.openjdk.java.net/~darcy/8005298.1/ Thanks, -Joe On 01/08/2013 02:00 PM, Joe Darcy wrote: > Hi Mike, > > On 01/08/2013 01:49 PM, Mike Duigou wrote: >> Perhaps {@code} around java.lang.Object. > > Agreed. > >> >> The default method and overriding Object method sentences could >> perhaps be said more simply: >> >> {@linkplain java.lang.reflect.Method#isDefault() default methods} in >> interfaces do provide a method implementation and are not considered >> abstract. >> >> Interface methods which match methods of java.lang.Object are not >> considered abstract because an implementation (from java.lang.Object) >> is always available. >> >> Mostly it's enough to say that they aren't abstract. The part about >> abstract method count is superfluous. > > Okay; rewritten as: > > * Conceptually, a functional interface has exactly one abstract > * method. Since {@linkplain java.lang.reflect.Method#isDefault() > * default methods} have an implementation, they are not abstract. If > * an interface declares an abstract method overriding one of the > * public methods of {@code java.lang.Object}, that also does > * not count toward the interface's abstract method count > * since any implementation of the interface will have an > * implementation from {@code java.lang.Object} or elsewhere. > >> >> @jls ref for default methods. > > That is actually included in the draft text of 9.4.3 and so is covered by > > * @jls 9.4.3 Interface Method Body >> >> @jls ref for methods of Object. > > That is a good addition; I'll include > > * @jls 4.3.2. The Class Object > > Thanks, > > -Joe > >> >> On Jan 8 2013, at 13:24 , Joe Darcy wrote: >> >>> Hello, >>> >>> As discussed over on one of the Project Lambda lists [1], we're >>> adding an interface type to the platform to explicitly mark >>> interface types as being functional interfaces suitable for use in >>> lambda expressions. Please review the addition of this new type: >>> >>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>> >>> Follow-up work will add @FunctionalInterface annotations to >>> appropriate platform classes. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html > From stuart.marks at oracle.com Tue Jan 8 23:50:42 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 08 Jan 2013 15:50:42 -0800 Subject: RFR: 8005646: TEST_BUG: RMI UnregisterGroup test leaves process running Message-ID: <50ECB0D2.9050202@oracle.com> Hi all, Please review this fix: http://cr.openjdk.java.net/~smarks/reviews/8005646/webrev.0/ for this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005646 Many gory details are in that bug report. TL;DR the old test jumped through several hoops attempting to deactivate all the activated objects, but this sometimes failed. The revised test uses a better deactivation technique. This improves the reliability of the test, and it makes unnecessary a bunch of infrastructure that supported the old deactivation technique. I've also removed the RMI stubs from the checked-in sources, since they have been generated at runtime since Java 5. Thanks, s'marks From mike.duigou at oracle.com Wed Jan 9 00:02:30 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 8 Jan 2013 16:02:30 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50ECA12D.4020300@oracle.com> References: <50EC8E7B.807@oracle.com> <50EC9717.2000400@oracle.com> <50ECA12D.4020300@oracle.com> Message-ID: <5E56A286-787F-4C1D-9133-40F9714FA6F7@oracle.com> Looks good now. Mike On Jan 8 2013, at 14:43 , Joe Darcy wrote: > PS The updated webrev is > > http://cr.openjdk.java.net/~darcy/8005298.1/ > > Thanks, > > -Joe > > On 01/08/2013 02:00 PM, Joe Darcy wrote: >> Hi Mike, >> >> On 01/08/2013 01:49 PM, Mike Duigou wrote: >>> Perhaps {@code} around java.lang.Object. >> >> Agreed. >> >>> >>> The default method and overriding Object method sentences could perhaps be said more simply: >>> >>> {@linkplain java.lang.reflect.Method#isDefault() default methods} in interfaces do provide a method implementation and are not considered abstract. >>> >>> Interface methods which match methods of java.lang.Object are not considered abstract because an implementation (from java.lang.Object) is always available. >>> >>> Mostly it's enough to say that they aren't abstract. The part about abstract method count is superfluous. >> >> Okay; rewritten as: >> >> * Conceptually, a functional interface has exactly one abstract >> * method. Since {@linkplain java.lang.reflect.Method#isDefault() >> * default methods} have an implementation, they are not abstract. If >> * an interface declares an abstract method overriding one of the >> * public methods of {@code java.lang.Object}, that also does >> * not count toward the interface's abstract method count >> * since any implementation of the interface will have an >> * implementation from {@code java.lang.Object} or elsewhere. >> >>> >>> @jls ref for default methods. >> >> That is actually included in the draft text of 9.4.3 and so is covered by >> >> * @jls 9.4.3 Interface Method Body >>> >>> @jls ref for methods of Object. >> >> That is a good addition; I'll include >> >> * @jls 4.3.2. The Class Object >> >> Thanks, >> >> -Joe >> >>> >>> On Jan 8 2013, at 13:24 , Joe Darcy wrote: >>> >>>> Hello, >>>> >>>> As discussed over on one of the Project Lambda lists [1], we're adding an interface type to the platform to explicitly mark interface types as being functional interfaces suitable for use in lambda expressions. Please review the addition of this new type: >>>> >>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>>> >>>> Follow-up work will add @FunctionalInterface annotations to appropriate platform classes. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html >> > From joe.darcy at oracle.com Wed Jan 9 00:08:44 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 09 Jan 2013 00:08:44 +0000 Subject: hg: jdk8/tl/jdk: 8005298: Add FunctionalInterface type to the core libraries Message-ID: <20130109000855.ED2ED4711C@hg.openjdk.java.net> Changeset: ac5fd681a7a2 Author: darcy Date: 2013-01-08 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac5fd681a7a2 8005298: Add FunctionalInterface type to the core libraries Reviewed-by: mduigou + src/share/classes/java/lang/FunctionalInterface.java From vitalyd at gmail.com Wed Jan 9 00:10:13 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 8 Jan 2013 19:10:13 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50ECA935.2030703@oracle.com> References: <50ECA935.2030703@oracle.com> Message-ID: Hi Vladimir, encodeArray can be made static. Also, what's the purpose of overflow flag? Once you detect overflow can't you simply return the overflow result? What's the key piece that allows jit to generate better code? Is it the encodeArray which is nice, small, and isolated? Thanks Sent from my phone On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" wrote: > http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev > > Move encoding loop into separate method for which VM will use intrinsic on > x86. I want to get agreement on this jdk change before I submit VM part. > > This gives +1.6% performance improvement on SPECjAppServer2004 on x86. > Note, even without intrinsic (on other platforms) JIT will produce better > code for this loop. > > Thanks, > Vladimir > From weijun.wang at oracle.com Wed Jan 9 03:16:19 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Jan 2013 11:16:19 +0800 Subject: Build Failure in JPRT Job In-Reply-To: <50EBE1D8.9020708@oracle.com> References: <50EBC6AA.9040302@oracle.com> <50EBC8B2.1090600@oracle.com> <50EBCAFC.2010809@oracle.com> <50EBE1D8.9020708@oracle.com> Message-ID: <50ECE103.1010805@oracle.com> I'm not talking about JPRT build. I fetched all tl8 repos and do a full build, the jdeps command runs. Then I use this build as ALT_JDK_IMPORT_PATH to do a partial images build in jdk/make still shows com/sun/tools/jdeps : no such file or directory What am I missing here? Thanks Max On 01/08/2013 05:07 PM, Alan Bateman wrote: > On 08/01/2013 07:30, Dan Xu wrote: >> David, >> >> Thanks for your reply. >> >> I saw other jobs also had the similar jprt command. I wonder why >> others could succeed in the build. > If partial builds of jdk8/tl, ie: jdk repo only, are succeeding then the > repository is probably not up to date. Alternatively, they are partial > builds of the jdk repo in other forests, jdk8/awt/jdk for example. > > In general, partial builds are fragile and in the case of jdk8/tl then > there regular flag days where you need to build langtools+jdk, can't use > the langtools from a promoted build. > > -Alan From weijun.wang at oracle.com Wed Jan 9 03:25:49 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Jan 2013 11:25:49 +0800 Subject: Build Failure in JPRT Job In-Reply-To: <50ECE103.1010805@oracle.com> References: <50EBC6AA.9040302@oracle.com> <50EBC8B2.1090600@oracle.com> <50EBCAFC.2010809@oracle.com> <50EBE1D8.9020708@oracle.com> <50ECE103.1010805@oracle.com> Message-ID: <50ECE33D.5020405@oracle.com> Ah, it seems com/sun/tools/jdeps needs to be included in IMPORT_TOOLS_PACKAGES in jdk/make/common/internal/Defs-langtools.gmk. -Max On 01/09/2013 11:16 AM, Weijun Wang wrote: > I'm not talking about JPRT build. > > I fetched all tl8 repos and do a full build, the jdeps command runs. > > Then I use this build as ALT_JDK_IMPORT_PATH to do a partial images > build in jdk/make still shows > > com/sun/tools/jdeps : no such file or directory > > What am I missing here? > > Thanks > Max > > > On 01/08/2013 05:07 PM, Alan Bateman wrote: >> On 08/01/2013 07:30, Dan Xu wrote: >>> David, >>> >>> Thanks for your reply. >>> >>> I saw other jobs also had the similar jprt command. I wonder why >>> others could succeed in the build. >> If partial builds of jdk8/tl, ie: jdk repo only, are succeeding then the >> repository is probably not up to date. Alternatively, they are partial >> builds of the jdk repo in other forests, jdk8/awt/jdk for example. >> >> In general, partial builds are fragile and in the case of jdk8/tl then >> there regular flag days where you need to build langtools+jdk, can't use >> the langtools from a promoted build. >> >> -Alan From mandy.chung at oracle.com Wed Jan 9 03:58:26 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jan 2013 19:58:26 -0800 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50E68ABF.8090303@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> Message-ID: <50ECEAE2.2050903@oracle.com> On Jan 8, 2013, at 12:02 AM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/ Alan - I reviewed the new webrev and looks good. To follow up the comment about invalid profile attribute value: On 1/3/2013 11:54 PM, Alan Bateman wrote: >> >> L820: An empty "Profile" attribute is invalidand >> Version.supportsProfile >> returns false if requiredProfile parameter is empty even if the >> runtime >> is a full JRE. This is fine but I was wondering if the exception >> message >> can indicate if the attribute value is invalid to help diagnosis. > We could although I'm not sure how this could arise (as you can't set > an empty profile name with the "p" option, and the "m" option to > add/update a manifest also disallows empty values). > > Looks like the jar tool -m option allows an entry with a space "Profile: " (a space following ":") - an existing bug then. There may be other implementation to create a jar file that doesn't do the check though. >> >> sun.tools.jar.Main >> It would be helpful if the jar tool checks if the input profile >> name to the -p option is valid and outputs error. > I considered this when updating the jar tool but decided at the time > that it shouldn't know about the profile names. It would be easy to do > of course. I see no issue with the jar tool to know about the profile names as they will be standard and part of the platform. Having the jar tool to validate the profile name will help catch mistake at packaging time. This is minor and I'm fine to revisit this in the future. Mandy From Alan.Bateman at oracle.com Wed Jan 9 08:49:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Jan 2013 08:49:53 +0000 Subject: Could you sponsor another simple fix? In-Reply-To: <50EC6B14.30207@oracle.com> References: <50EC4CA2.6080701@oracle.com> <50EC67A6.10806@oracle.com> <50EC6B14.30207@oracle.com> Message-ID: <50ED2F31.7020409@oracle.com> This is a good find and the change looks good to me. cc'ing Ioi so that he knows he has a sponsor. -Alan. On 08/01/2013 18:53, Xueming Shen wrote: > The correct list is core-libs-dev at openjdk.java.net > > I will be the sponsor for this change. > > -Sherman > > On 01/08/2013 10:38 AM, Coleen Phillimore wrote: >> >> Hi Ioi, >> >> I copied it to cr.openjdk.java.net/~coleenp/8005466_zip_util_001 >> >> I think the mailing list is jdk8-dev at openjdk.java.net. I don't know >> about jdk8. Since it's a tools/libraries fix, it should be relative >> to the TL repository (not sure if your fix is). >> >> I'm apparently "reviewer" on jdk8 and allowed to sponsor changes to >> jdk8 but I'd prefer if someone like Alan Bateman who actually works >> on the jdk do this. >> >> This fix seems cool. >> >> Thanks, >> Coleen >> >> On 01/08/2013 11:43 AM, Ioi Lam wrote: >>> Coleen, >>> >>> https://jbs.oracle.com/bugs/browse/JDK-8005466?focusedCommentId=13288645#comment-13288645 >>> >>> http://javaweb.us.oracle.com/~iklam/webrev/8005466_zip_util_001/ >>> >>> >>> A one-liner would save about 540KB with Eclipse on 64-bit VMs. >>> >>> BTW, which mailing list should this be sent to? hotspot-dev at openjdk? >>> >>> Karen, would it be possible for this to get into JDK8? >>> >>> Thanks >>> - Ioi >> > From david.holmes at oracle.com Wed Jan 9 10:55:18 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Jan 2013 20:55:18 +1000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D36104.8000701@oracle.com> References: <50D36104.8000701@oracle.com> Message-ID: <50ED4C96.6070205@oracle.com> Aleksey, Not sure where this is now but FYI you needed two CRs for this: one for hotspot and one for the JDK. They have different target versions (hs25 vs 8) and depending on the path you use to integrate could end up in different builds - hence distinct CRs for accurate tracking purposes. I have a concern that the Long versions of these methods may be used directly without there being any check for supports_cx8 David On 21/12/2012 5:03 AM, Aleksey Shipilev wrote: > Hi, > > Sorry for cross-list posting, but this change affects both HS and JDK. > > This simple change is missing from recently committed CR 7023898. While > the VM support is there in Hotspot, no methods are exposed in Unsafe to > actually make use of those intrinsics. This is the webrev fixing that: > http://cr.openjdk.java.net/~shade/8004330/webrev.00/ > > It turns out the getAndSet intrinsics HotSpot are overloaded, which had > deluged both Doug and me in the previous patch. These namings are > inconsistent with other Unsafe intrinsic naming convention, so this > change fixes that as well. > > Testing: > - Built and tested in Linux x86_64 > - java-concurrency-torture [1] atomicity tests are passed for > AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics > on Linux x86_64 > - running the java-concurrency-torture tests "-XX:+PrintInlining | > grep Unsafe" tells all intrinsics have been successfully inlined > - no other testing is expected for this trivial change. > > I would need a sponsor to push this. Thanks for your patience and reviews! > > Contributors: > - dl: original patch, testing > - shade: due diligence, messing with reviews, tests, and rebuilds > > -Aleksey. > > [1] https://github.com/shipilev/java-concurrency-torture/ > [2] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java > [3] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java > From aleksey.shipilev at oracle.com Wed Jan 9 10:55:09 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 14:55:09 +0400 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC4A4A.1050009@cs.oswego.edu> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> <50EC4A4A.1050009@cs.oswego.edu> Message-ID: <50ED4C8D.1050703@oracle.com> On 01/08/2013 08:33 PM, Doug Lea wrote: > However, the actual ThreadLocalRandom object is padded to avoid > memory contention (which wouldn't be necessary or useful if already > embedded withing Thread). I'm tempted to disagree. While it is true most of the callers are accessing Thread in the context of currentThread(), and most of the Thread state is not updated, it can catastrophically break down once we cram in the heavily updated fields. E.g. this is the java.lang.Thread field layout as of 7u12: $ java -jar java-object-layout.jar java.lang.Thread Running 64-bit HotSpot VM. Using compressed references with 3-bit shift. Objects are 8 bytes aligned. java.lang.Thread offset size type description 0 12 (assumed to be the object header + first field alignment) 12 4 int Thread.priority 16 8 long Thread.eetop 24 8 long Thread.stackSize 32 8 long Thread.nativeParkEventPointer 40 8 long Thread.tid 48 4 int Thread.threadStatus 52 1 boolean Thread.single_step 53 1 boolean Thread.daemon 54 1 boolean Thread.stillborn 55 1 (alignment/padding gap) 56 4 char[] Thread.name 60 4 Thread Thread.threadQ 64 4 Runnable Thread.target 68 4 ThreadGroup Thread.group 72 4 ClassLoader Thread.contextClassLoader 76 4 AccessControlContext Thread.inheritedAccessControlContext 80 4 ThreadLocalMap Thread.threadLocals 84 4 ThreadLocalMap Thread.inheritableThreadLocals 88 4 Object Thread.parkBlocker 92 4 Interruptible Thread.blocker 96 4 Object Thread.blockerLock 100 4 UncaughtExceptionHandler Thread.uncaughtExceptionHandler 104 (object boundary, size estimate) That means adding a few primitive fields can easily overlap with the fields for another Thread and make the false sharing quite the issue. Padding out the inlined TLR state would save us from this trouble (thankfully, @Contended can make that without the magical field arrangements and finger crossing). We can @Contended the whole Thread, which means pushing Thread to consume 256 bytes instead of 104+ as it is now. While this seems to be the large increase, it is a global win since padded TLR state is gone, and we effectively hiding the Thread state in the "padding shadow". My 2c. -Aleksey. From scolebourne at joda.org Wed Jan 9 10:55:10 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 9 Jan 2013 10:55:10 +0000 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50ECA12D.4020300@oracle.com> References: <50EC8E7B.807@oracle.com> <50EC9717.2000400@oracle.com> <50ECA12D.4020300@oracle.com> Message-ID: You have

before each paragraph except the second. (Personally, I put the

between the paragraphs, as it makes things like this simpler to read. I would also avoid the trailing "If" and lone "Specification" by adjusting the line spacing. See http://blog.joda.org/2012/11/javadoc-coding-standards.html) Stephen On 8 January 2013 22:43, Joe Darcy wrote: > PS The updated webrev is > > http://cr.openjdk.java.net/~darcy/8005298.1/ > > Thanks, > > -Joe > > > On 01/08/2013 02:00 PM, Joe Darcy wrote: >> >> Hi Mike, >> >> On 01/08/2013 01:49 PM, Mike Duigou wrote: >>> >>> Perhaps {@code} around java.lang.Object. >> >> >> Agreed. >> >>> >>> The default method and overriding Object method sentences could perhaps >>> be said more simply: >>> >>> {@linkplain java.lang.reflect.Method#isDefault() default methods} in >>> interfaces do provide a method implementation and are not considered >>> abstract. >>> >>> Interface methods which match methods of java.lang.Object are not >>> considered abstract because an implementation (from java.lang.Object) is >>> always available. >>> >>> Mostly it's enough to say that they aren't abstract. The part about >>> abstract method count is superfluous. >> >> >> Okay; rewritten as: >> >> * Conceptually, a functional interface has exactly one abstract >> * method. Since {@linkplain java.lang.reflect.Method#isDefault() >> * default methods} have an implementation, they are not abstract. If >> * an interface declares an abstract method overriding one of the >> * public methods of {@code java.lang.Object}, that also does >> * not count toward the interface's abstract method count >> * since any implementation of the interface will have an >> * implementation from {@code java.lang.Object} or elsewhere. >> >>> >>> @jls ref for default methods. >> >> >> That is actually included in the draft text of 9.4.3 and so is covered by >> >> * @jls 9.4.3 Interface Method Body >>> >>> >>> @jls ref for methods of Object. >> >> >> That is a good addition; I'll include >> >> * @jls 4.3.2. The Class Object >> >> Thanks, >> >> -Joe >> >>> >>> On Jan 8 2013, at 13:24 , Joe Darcy wrote: >>> >>>> Hello, >>>> >>>> As discussed over on one of the Project Lambda lists [1], we're adding >>>> an interface type to the platform to explicitly mark interface types as >>>> being functional interfaces suitable for use in lambda expressions. Please >>>> review the addition of this new type: >>>> >>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>>> >>>> Follow-up work will add @FunctionalInterface annotations to appropriate >>>> platform classes. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2012-December/000846.html >> >> > From aleksey.shipilev at oracle.com Wed Jan 9 11:04:57 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 15:04:57 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4C96.6070205@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> Message-ID: <50ED4ED9.60102@oracle.com> Thanks, David. On 01/09/2013 02:55 PM, David Holmes wrote: > Not sure where this is now but FYI you needed two CRs for this: one for > hotspot and one for the JDK. They have different target versions (hs25 > vs 8) and depending on the path you use to integrate could end up in > different builds - hence distinct CRs for accurate tracking purposes. Too late, since these are already committed? I can submit another CR if we need that. > I have a concern that the Long versions of these methods may be used > directly without there being any check for supports_cx8 I actually have the question about this. What is the usual pattern for using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe directly without the checks. AtomicLongFieldUpdater does the checks. Something is fishy about this whole thing. I think this one tries to explain something, but I fail to grasp the intent: /** * Records whether the underlying JVM supports lockless * compareAndSwap for longs. While the Unsafe.compareAndSwapLong * method works in either case, some constructions should be * handled at Java level to avoid locking user-visible locks. */ static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8(); Doug? -Aleksey. From Ulf.Zibis at CoSoCo.de Wed Jan 9 11:08:09 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 09 Jan 2013 12:08:09 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> Message-ID: <50ED4F99.7030202@CoSoCo.de> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: > Hi Vladimir, > > encodeArray can be made static. > > Also, what's the purpose of overflow flag? Once you detect overflow can't > you simply return the overflow result? > > What's the key piece that allows jit to generate better code? Is it the > encodeArray which is nice, small, and isolated? > > Thanks > > Sent from my phone > On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > wrote: > >> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev I would code: 153 int i; 154 for (i = 0; i < len; i++) { 155 char c = sa[sp++]; 156 if (c > '\u00FF') 157 break; 158 da[dp++] = (byte)c; 159 } -Ulf From aleksey.shipilev at oracle.com Wed Jan 9 11:10:19 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 15:10:19 +0400 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50EC442E.2070104@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> Message-ID: <50ED501B.8030806@oracle.com> On 01/08/2013 08:07 PM, Chris Hegarty wrote: > I have no objection as such to adding certain fields to j.l.Thread to > support faster ThreadLocalRandom. Maybe it would help to see how they > are to be used? I have no objections for this as well. Submitted "CR 8005926: Merge ThreadLocalRandom state into java.lang.Thread" If no one picks that up, I would add this to my (long) todo list to provide the due diligence for. -Aleksey. From chris.hegarty at oracle.com Wed Jan 9 11:13:49 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 11:13:49 +0000 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50ED501B.8030806@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> <50ED501B.8030806@oracle.com> Message-ID: <50ED50ED.5090607@oracle.com> On 09/01/2013 11:10, Aleksey Shipilev wrote: > On 01/08/2013 08:07 PM, Chris Hegarty wrote: >> I have no objection as such to adding certain fields to j.l.Thread to >> support faster ThreadLocalRandom. Maybe it would help to see how they >> are to be used? > > I have no objections for this as well. Submitted > "CR 8005926: Merge ThreadLocalRandom state into java.lang.Thread" I think the complete set of changes, including the changes to ThreadLocalRandom, should be pushed at the same time. -Chris. > > If no one picks that up, I would add this to my (long) todo list to > provide the due diligence for. > > -Aleksey. > From dl at cs.oswego.edu Wed Jan 9 11:24:36 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 06:24:36 -0500 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50ED50ED.5090607@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> <50ED501B.8030806@oracle.com> <50ED50ED.5090607@oracle.com> Message-ID: <50ED5374.1090509@cs.oswego.edu> On 01/09/13 06:13, Chris Hegarty wrote: > I think the complete set of changes, including the changes to ThreadLocalRandom, > should be pushed at the same time. OK. I will try bootstrap up an environment where I can fully adapt and test all at the same time. -Doug From aleksey.shipilev at oracle.com Wed Jan 9 11:25:39 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 15:25:39 +0400 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50ED50ED.5090607@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> <50ED501B.8030806@oracle.com> <50ED50ED.5090607@oracle.com> Message-ID: <50ED53B3.8020101@oracle.com> On 01/09/2013 03:13 PM, Chris Hegarty wrote: > On 09/01/2013 11:10, Aleksey Shipilev wrote: >> On 01/08/2013 08:07 PM, Chris Hegarty wrote: >>> I have no objection as such to adding certain fields to j.l.Thread to >>> support faster ThreadLocalRandom. Maybe it would help to see how they >>> are to be used? >> >> I have no objections for this as well. Submitted >> "CR 8005926: Merge ThreadLocalRandom state into java.lang.Thread" > > I think the complete set of changes, including the changes to > ThreadLocalRandom, should be pushed at the same time. Yes, TLR changes are relatively hard to coordinate. I think the scope for that CR is the coordinated change in both j.u.c.TLR and j.l.Thread, maybe the CR synopsis is misleading? I think quite some prototyping work would be needed to pull this, including intricate performance work, since this touches hardcore use cases. Also, we might need to wait for @Contended (any time now) to account for the troubles listed in another note in this thread. -Aleksey. From dl at cs.oswego.edu Wed Jan 9 11:36:40 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 06:36:40 -0500 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4ED9.60102@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> Message-ID: <50ED5648.4000200@cs.oswego.edu> On 01/09/13 06:04, Aleksey Shipilev wrote: > I actually have the question about this. What is the usual pattern for > using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe > directly without the checks. AtomicLongFieldUpdater does the checks. > Something is fishy about this whole thing. Here's the story: Any implementation of Long-CAS on a machine that does not have any other way to support it is allowed to emulate by a synchronized block on enclosing object. For the AtomicXFieldUpdaters classes, there was, at the time they were introduced, no way to express the object to use, so the checks were done explicitly. I don't think this is even necessary anymore, but doesn't hurt. Further, I'm not sure that JDK8 is even targeted to any machines that require this kind of emulation. -Doug From Ulf.Zibis at CoSoCo.de Wed Jan 9 11:58:48 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 09 Jan 2013 12:58:48 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> Message-ID: <50ED5B78.2040309@CoSoCo.de> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: > On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" > wrote: > >> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev Another tweak: 168 char[] sa = src.array(); 169 int sp = src.arrayOffset() + src.position(); 170 int sr = src.remaining(); 171 int sl = sp + sr; 172 assert (sp <= sl); // superfluous, sr is always >= 0 173 sp = (sp <= sl ? sp : sl); // superfluous " 174 byte[] da = dst.array(); 175 int dp = dst.arrayOffset() + dst.position(); 170 int dr = dst.remaining(); 176 int dl = dp + dr; 177 assert (dp <= dl); // superfluous " 178 dp = (dp <= dl ? dp : dl); // superfluous " 179 boolean overflow = false; 180 if (sr > dr) { 181 sr = dr; 182 overflow = true; 183 } Why you called it "overflowflag", in that way, you could name each variable "myvaluevariable" or "myvaluefield" ;-) -Ulf From dl at cs.oswego.edu Wed Jan 9 12:07:59 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 07:07:59 -0500 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50ED4C8D.1050703@oracle.com> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> <50EC4A4A.1050009@cs.oswego.edu> <50ED4C8D.1050703@oracle.com> Message-ID: <50ED5D9F.9050800@cs.oswego.edu> On 01/09/13 05:55, Aleksey Shipilev wrote: > On 01/08/2013 08:33 PM, Doug Lea wrote: >> However, the actual ThreadLocalRandom object is padded to avoid >> memory contention (which wouldn't be necessary or useful if already >> embedded withing Thread). > > I'm tempted to disagree. While it is true most of the callers are > accessing Thread in the context of currentThread(), and most of the > Thread state is not updated, it can catastrophically break down once we > cram in the heavily updated fields. I think that adding @Contended to Thread will require some empirically-guided judgement. It is true that a bunch of Thread objects packed adjacently may (even now) memory-contend. But it is not a likely scenario because of garbage-collector policies. They start off with per-thread roots, so will not often relocate different Thread objects adjacently. We use various Thread subclasses in j.u.c that add some thread-local-like state, and I haven't ever traced a performance glitch to memory contention among them. But it would not be too hard to create empirical experiments to check this more systematically. -Doug From aleksey.shipilev at oracle.com Wed Jan 9 12:19:13 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 16:19:13 +0400 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50E9FEDB.8050800@oracle.com> References: <50E9FEDB.8050800@oracle.com> Message-ID: <50ED6041.90503@oracle.com> Good stuff. On 01/07/2013 02:46 AM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/8005232/webrev/ Sorry for obnoxious first-time reviewer questions: a) I think the CAS loop in newReflectionData() is misleading in its reuse of the parameters. Can we instead inline it? Or, can we read the fields for $reflectionData and $classRedefinedCount, with no parameters passed? b) Had we considered filling up the complete ReflectionData eagerly on first access? This will make ReflectionData completely final. I would guess this goes against the per-use laziness? c) What's the merit of using Unsafe instead of field updaters here? (Avoiding the dependency on j.u.c?) d) I think the code can be further simplified if we stick with reflectionData() returning non-null object all the time, and check for useCaches instead in the usages, at the expense of creating the methods which actually get the reflection data. e) Should useCaches be final? That will allow aggressive optimizations for (c). > This is a saving of 7 reference fields ie. 28 bytes, resulting in a new > Class instance size of 80 bytes. This saves a further 4 bytes due to the > fields being 8-byte aligned without any need for padding. So overall we > save 32 bytes per class instance. Shameless promotion follows. This tool [1] should help to estimate the class layout in the face of object alignment, compressed references, paddings, alignment and whatnot. -Aleksey. [1] https://github.com/shipilev/java-object-layout/ From aleksey.shipilev at oracle.com Wed Jan 9 12:20:40 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 16:20:40 +0400 Subject: Improving ThreadLocalRandom (and related classes) In-Reply-To: <50ED5D9F.9050800@cs.oswego.edu> References: <50EC0B88.3070102@cs.oswego.edu> <50EC442E.2070104@oracle.com> <50EC4A4A.1050009@cs.oswego.edu> <50ED4C8D.1050703@oracle.com> <50ED5D9F.9050800@cs.oswego.edu> Message-ID: <50ED6098.80200@oracle.com> On 01/09/2013 04:07 PM, Doug Lea wrote: > On 01/09/13 05:55, Aleksey Shipilev wrote: >> On 01/08/2013 08:33 PM, Doug Lea wrote: >>> However, the actual ThreadLocalRandom object is padded to avoid >>> memory contention (which wouldn't be necessary or useful if already >>> embedded withing Thread). >> >> I'm tempted to disagree. While it is true most of the callers are >> accessing Thread in the context of currentThread(), and most of the >> Thread state is not updated, it can catastrophically break down once we >> cram in the heavily updated fields. > > I think that adding @Contended to Thread will require > some empirically-guided judgement. It is true > that a bunch of Thread objects packed adjacently may > (even now) memory-contend. But it is not a likely > scenario because of garbage-collector policies. They > start off with per-thread roots, so will not often > relocate different Thread objects adjacently. > We use various Thread subclasses in j.u.c that add > some thread-local-like state, and I haven't ever > traced a performance glitch to memory contention > among them. But it would not be too hard to create > empirical experiments to check this more systematically. Fair enough. Let's go the optimistic route without @Contended then. Meanwhile, we can arrange some experiments to have some calamity. -Aleksey. From chris.hegarty at oracle.com Wed Jan 9 12:26:34 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 12:26:34 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4ED9.60102@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> Message-ID: <50ED61FA.2060900@oracle.com> On 09/01/2013 11:04, Aleksey Shipilev wrote: > Thanks, David. > > On 01/09/2013 02:55 PM, David Holmes wrote: >> Not sure where this is now but FYI you needed two CRs for this: one for >> hotspot and one for the JDK. They have different target versions (hs25 >> vs 8) and depending on the path you use to integrate could end up in >> different builds - hence distinct CRs for accurate tracking purposes. > > Too late, since these are already committed? I can submit another CR if > we need that. Since the changes to vmsymbols.hpp are already in, then I suggest we simply create a new bug to track the Unsafe.java changes into jdk8. I can sponsor this change to you Aleksey. -Chris >> I have a concern that the Long versions of these methods may be used >> directly without there being any check for supports_cx8 > > I actually have the question about this. What is the usual pattern for > using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe > directly without the checks. AtomicLongFieldUpdater does the checks. > Something is fishy about this whole thing. > > I think this one tries to explain something, but I fail to grasp the intent: > > /** > * Records whether the underlying JVM supports lockless > * compareAndSwap for longs. While the Unsafe.compareAndSwapLong > * method works in either case, some constructions should be > * handled at Java level to avoid locking user-visible locks. > */ > static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8(); > > Doug? > > -Aleksey. > From aleksey.shipilev at oracle.com Wed Jan 9 12:27:13 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 16:27:13 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED61FA.2060900@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> Message-ID: <50ED6221.2020902@oracle.com> On 01/09/2013 04:26 PM, Chris Hegarty wrote: > On 09/01/2013 11:04, Aleksey Shipilev wrote: >> Thanks, David. >> >> On 01/09/2013 02:55 PM, David Holmes wrote: >>> Not sure where this is now but FYI you needed two CRs for this: one for >>> hotspot and one for the JDK. They have different target versions (hs25 >>> vs 8) and depending on the path you use to integrate could end up in >>> different builds - hence distinct CRs for accurate tracking purposes. >> >> Too late, since these are already committed? I can submit another CR if >> we need that. > > Since the changes to vmsymbols.hpp are already in, then I suggest we > simply create a new bug to track the Unsafe.java changes into jdk8. > > I can sponsor this change to you Aleksey. Thanks, Chris. I think this had been already pushed by Vladimir: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 -Aleksey. From chris.hegarty at oracle.com Wed Jan 9 12:32:37 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Jan 2013 12:32:37 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED6221.2020902@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED61FA.2060900@oracle.com> <50ED6221.2020902@oracle.com> Message-ID: <50ED6365.2070003@oracle.com> On 09/01/2013 12:27, Aleksey Shipilev wrote: > On 01/09/2013 04:26 PM, Chris Hegarty wrote: >> On 09/01/2013 11:04, Aleksey Shipilev wrote: >>> Thanks, David. >>> >>> On 01/09/2013 02:55 PM, David Holmes wrote: >>>> Not sure where this is now but FYI you needed two CRs for this: one for >>>> hotspot and one for the JDK. They have different target versions (hs25 >>>> vs 8) and depending on the path you use to integrate could end up in >>>> different builds - hence distinct CRs for accurate tracking purposes. >>> >>> Too late, since these are already committed? I can submit another CR if >>> we need that. >> >> Since the changes to vmsymbols.hpp are already in, then I suggest we >> simply create a new bug to track the Unsafe.java changes into jdk8. >> >> I can sponsor this change to you Aleksey. > > Thanks, Chris. I think this had been already pushed by Vladimir: > http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cf5b18488d1 OK, so we got to wait for the next sync up to get these in jdk8/tl. -Chris. > > -Aleksey. > > > From aleksey.shipilev at oracle.com Wed Jan 9 12:42:28 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 16:42:28 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED5648.4000200@cs.oswego.edu> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED5648.4000200@cs.oswego.edu> Message-ID: <50ED65B4.3020602@oracle.com> On 01/09/2013 03:36 PM, Doug Lea wrote: > On 01/09/13 06:04, Aleksey Shipilev wrote: > >> I actually have the question about this. What is the usual pattern for >> using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe >> directly without the checks. AtomicLongFieldUpdater does the checks. >> Something is fishy about this whole thing. > > Here's the story: Any implementation of Long-CAS on a machine > that does not have any other way to support it is allowed to > emulate by a synchronized block on enclosing object. For the > AtomicXFieldUpdaters classes, there was, at the time they were > introduced, no way to express the object to use, so the checks > were done explicitly. Sorry, this confuses me even more. This [1] seems to be the version which does not take that flag into the consideration, and instead calls the plain Unsafe against the field. This seems to be the exact thing AtomicLong is doing, even the one dated back to the same change [2]. What's wrong with that construction? -Aleksey. [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/atomic/AtomicLongFieldUpdater.java?revision=1.21&view=markup [2] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/atomic/AtomicLong.java?revision=1.16&view=markup From dl at cs.oswego.edu Wed Jan 9 13:02:13 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 08:02:13 -0500 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED65B4.3020602@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED5648.4000200@cs.oswego.edu> <50ED65B4.3020602@oracle.com> Message-ID: <50ED6A55.3030803@cs.oswego.edu> On 01/09/13 07:42, Aleksey Shipilev wrote: > Sorry, this confuses me even more. This [1] seems to be the version Scavenging through 9-year-old change-logs is probably not the best path to resolving confusion :-) There were several stabs (and back then a highly non-transparent process!) at conforming to and helping to frame JDK5 VM expectations. The main point to keep in mind is that the fallback wrapper (unsafe.cpp Unsafe_CompareAndSwapLong) does what you expect (uses the enclosing lock), unless you are in an uncommon (and possibly non-existent) situation where you need/expect something else. -Doug From peter.levart at gmail.com Wed Jan 9 13:04:20 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Jan 2013 14:04:20 +0100 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50ED6041.90503@oracle.com> References: <50E9FEDB.8050800@oracle.com> <50ED6041.90503@oracle.com> Message-ID: <50ED6AD4.2000504@gmail.com> On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: > Good stuff. > > On 01/07/2013 02:46 AM, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/8005232/webrev/ > Sorry for obnoxious first-time reviewer questions: > a) I think the CAS loop in newReflectionData() is misleading in its > reuse of the parameters. Can we instead inline it? Or, can we read the > fields for $reflectionData and $classRedefinedCount, with no parameters > passed? It was originally written as one method. Performance tests showed that some (i think two more) of the public API methods were more aggressively in-lined when split in two methods. I think it would not hurt performance practically if the original variant was used. > b) Had we considered filling up the complete ReflectionData eagerly on > first access? This will make ReflectionData completely final. I would > guess this goes against the per-use laziness? Certainly there are usages where only one part is ever needed. For example only getDeclaredXXX but not getXXX which also triggers loading in superclasses and then aggregating... > c) What's the merit of using Unsafe instead of field updaters here? > (Avoiding the dependency on j.u.c?) Mainly because of initialization-loops. AtomicReferenceFieldUpdater uses Class.getDeclaredField(name), which in turn needs ReflectionData, ... Strictly speaking, CAS is actually not needed here. Since we keep classRedefinedCount snapshot inside the ReflectionData, any races that would install "older" ReflectionData over "newer", would be quickly caught at next invocation to reflectionData(). So if there are any objections to usage of Unsafe, it can be removed and replaced by simple volatile write. > d) I think the code can be further simplified if we stick with > reflectionData() returning non-null object all the time, and check for > useCaches instead in the usages, at the expense of creating the methods > which actually get the reflection data. I don't quite understand what you mean. Are you suggesting to double all the methods with variants that don't use reflectionData? If you check the usages you can see that the "caching aspect" is tested at two places in each method, the rest of code is the same for caching/non-caching variants. > e) Should useCaches be final? That will allow aggressive optimizations > for (c). Again the initialization order issues (see checkInitted()). The value for useCaches comes from system properties. Might be final and be later overwritten via Unsafe, but wouldn't this defeat optimizations? (or if not, wouldn't then those optimizations take the wrong code-path?) Regards, Peter > >> This is a saving of 7 reference fields ie. 28 bytes, resulting in a new >> Class instance size of 80 bytes. This saves a further 4 bytes due to the >> fields being 8-byte aligned without any need for padding. So overall we >> save 32 bytes per class instance. > Shameless promotion follows. This tool [1] should help to estimate the > class layout in the face of object alignment, compressed references, > paddings, alignment and whatnot. > > -Aleksey. > > [1] https://github.com/shipilev/java-object-layout/ > From aleksey.shipilev at oracle.com Wed Jan 9 13:04:32 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 17:04:32 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED6A55.3030803@cs.oswego.edu> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED5648.4000200@cs.oswego.edu> <50ED65B4.3020602@oracle.com> <50ED6A55.3030803@cs.oswego.edu> Message-ID: <50ED6AE0.6020405@oracle.com> On 01/09/2013 05:02 PM, Doug Lea wrote: > The main point to keep in mind is that the fallback wrapper > (unsafe.cpp Unsafe_CompareAndSwapLong) does what you > expect (uses the enclosing lock), unless you are in an > uncommon (and possibly non-existent) situation where > you need/expect something else. Ok, so the bottom-line seems to be: a) Unsafe provides the essential semantics for long updates, even in the absence of long CASes on target hardware. b) New Unsafe code from this CR relies on Unsafe methods semantics from (a), thus making David's worries ungrounded. c) While existing, Java-level AtomicLong.VM_SUPPORT_LONG_CAS is redundant, and can be eliminated. AtomicLongFieldUpdater can be rewritten to use Unsafe on all the paths. -Aleksey. From aleksey.shipilev at oracle.com Wed Jan 9 13:10:08 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Jan 2013 17:10:08 +0400 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50ED6AD4.2000504@gmail.com> References: <50E9FEDB.8050800@oracle.com> <50ED6041.90503@oracle.com> <50ED6AD4.2000504@gmail.com> Message-ID: <50ED6C30.9060001@oracle.com> Thanks for the explanations, Peter. Initialization loops are nasty. On 01/09/2013 05:04 PM, Peter Levart wrote: > On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: >> c) What's the merit of using Unsafe instead of field updaters >> here? (Avoiding the dependency on j.u.c?) > [snip] So if there are any objections to usage of Unsafe, it can be > removed and replaced by simple volatile write. Yes, I think that would be more clear without any adverse impacts on performance. Also, that better expresses the intent of requiring the visibility, not the atomicity of cache update. -Aleksey. From peter.levart at gmail.com Wed Jan 9 13:47:23 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Jan 2013 14:47:23 +0100 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50ED6041.90503@oracle.com> References: <50E9FEDB.8050800@oracle.com> <50ED6041.90503@oracle.com> Message-ID: <50ED74EB.3060405@gmail.com> On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: > e) Should useCaches be final? That will allow aggressive optimizations > for (c). It could be made final if moved into the ReflectionData class and initialized in static initializer of that class. Good idea! I'll check if this is doable. Regards, Peter From dl at cs.oswego.edu Wed Jan 9 13:54:09 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 08:54:09 -0500 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED6AE0.6020405@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED5648.4000200@cs.oswego.edu> <50ED65B4.3020602@oracle.com> <50ED6A55.3030803@cs.oswego.edu> <50ED6AE0.6020405@oracle.com> Message-ID: <50ED7681.7030501@cs.oswego.edu> On 01/09/13 08:04, Aleksey Shipilev wrote: > c) While existing, Java-level AtomicLong.VM_SUPPORT_LONG_CAS is > redundant, and can be eliminated. AtomicLongFieldUpdater can be > rewritten to use Unsafe on all the paths. > There is one little nicety here that does rely on VM_SUPPORT_LONG_CAS. There is a disclaimer somewhere that CAS is guaranteed to atomic only wrt other CASes. But in the emulation code for updaters, we also lock unconditional writes, because not doing so would be surprising. There is other code using Unsafe that is not so careful/forgiving. A good case can be made that the fallback wrapper for putLongVolatile should itself use a lock in this case but for reasons I don't remember, this wasn't done. (and in any case wouldn't trap syntactically generated volatile writes.) So there may be some usage code that is officially wrong/surprising on these grounds. -Doug From peter.levart at gmail.com Wed Jan 9 14:02:53 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 09 Jan 2013 15:02:53 +0100 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50ED74EB.3060405@gmail.com> References: <50E9FEDB.8050800@oracle.com> <50ED6041.90503@oracle.com> <50ED74EB.3060405@gmail.com> Message-ID: <50ED788D.6050506@gmail.com> On 01/09/2013 02:47 PM, Peter Levart wrote: > On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: >> e) Should useCaches be final? That will allow aggressive optimizations >> for (c). > It could be made final if moved into the ReflectionData class and > initialized in static initializer of that class. Good idea! > > I'll check if this is doable. > Sorry, no go: // To be able to query system properties as soon as they're available private static boolean initted = false; private static void checkInitted() { if (initted) return; AccessController.doPrivileged(new PrivilegedAction() { public Void run() { // Tests to ensure the system properties table is fully // initialized. This is needed because reflection code is // called very early in the initialization process (before // command-line arguments have been parsed and therefore // these user-settable properties installed.) We assume that // if System.out is non-null then the System class has been // fully initialized and that the bulk of the startup code // has been run. if (System.out == null) { // java.lang.System not yet fully initialized return null; } String val = System.getProperty("sun.reflect.noCaches"); if (val != null && val.equals("true")) { useCaches = false; } initted = true; return null; } }); } Regards, Peter From daniel.fuchs at oracle.com Wed Jan 9 14:28:12 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Jan 2013 15:28:12 +0100 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) Message-ID: <50ED7E7C.1030803@oracle.com> Hi, Here is a new webrev in the series that addresses using ServiceLoader in JAXP for JDK 8. 7169894: JAXP Plugability Layer: using service loader This changeset addresses modification in the javax.xml.validation package. It is a bit more complex than the changes required for the other packages because the newInstance methods takes an additional schemaLanguage parameter, and therefore we need to loop over the providers in order to find one that supports the language. Also this particular package did not have any specific configuration error to throw in case of misconfiguration (the xpath package in which the logic is very similar had one for instance), so we're adding a new SchemaFactoryConfigurationError for that purpose. best regards, -- daniel previous webrevs in the series: [1] javax.xml.parsers: [2] javax.xml.datatype: [3] javax.xml.stream [4] javax.xml.transform From sean.mullan at oracle.com Wed Jan 9 14:58:34 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 09 Jan 2013 14:58:34 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130109145938.EA84547143@hg.openjdk.java.net> Changeset: 86828e84654f Author: mullan Date: 2013-01-08 19:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86828e84654f 7019834: Eliminate dependency from PolicyFile to com.sun.security.auth.PrincipalComparator Summary: Add new java.security.Principal.implies method Reviewed-by: alanb ! src/share/classes/java/security/Principal.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + test/java/security/Principal/Implies.java ! test/sun/security/provider/PolicyFile/Comparator.java Changeset: bf6d0bca5ea7 Author: mullan Date: 2013-01-08 19:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf6d0bca5ea7 Merge - make/jdk/asm/Makefile - src/share/classes/sun/awt/TextureSizeConstraining.java - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: f0ed9ef84637 Author: mullan Date: 2013-01-09 08:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ed9ef84637 Merge From kumar.x.srinivasan at oracle.com Wed Jan 9 15:03:29 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 09 Jan 2013 07:03:29 -0800 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50ECEAE2.2050903@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> <50ECEAE2.2050903@oracle.com> Message-ID: <50ED86C1.3030703@oracle.com> Generally the changes looks good, I focused on pack200 and launcher, the src changes are fine. Some comments on the tests in test/tools/launcher/profiles, we have a test/tools/launcher/TestHelper.java which could make these new launcher tests in the profile directory simpler. Kumar > On Jan 8, 2013, at 12:02 AM, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/ > > Alan - I reviewed the new webrev and looks good. To follow up the > comment about invalid profile attribute value: > > On 1/3/2013 11:54 PM, Alan Bateman wrote: >>> >>> L820: An empty "Profile" attribute is invalidand >>> Version.supportsProfile >>> returns false if requiredProfile parameter is empty even if the >>> runtime >>> is a full JRE. This is fine but I was wondering if the exception >>> message >>> can indicate if the attribute value is invalid to help diagnosis. >> We could although I'm not sure how this could arise (as you can't set >> an empty profile name with the "p" option, and the "m" option to >> add/update a manifest also disallows empty values). >> >> > > Looks like the jar tool -m option allows an entry with a space > "Profile: " (a space following ":") - an existing bug then. There may > be other implementation to create a jar file that doesn't do the check > though. > >>> >>> sun.tools.jar.Main >>> It would be helpful if the jar tool checks if the input profile >>> name to the -p option is valid and outputs error. >> I considered this when updating the jar tool but decided at the time >> that it shouldn't know about the profile names. It would be easy to >> do of course. > > I see no issue with the jar tool to know about the profile names as > they will be standard and part of the platform. Having the jar tool > to validate the profile name will help catch mistake at packaging > time. This is minor and I'm fine to revisit this in the future. > > Mandy From Alan.Bateman at oracle.com Wed Jan 9 15:26:29 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Jan 2013 15:26:29 +0000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50ED86C1.3030703@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> <50ECEAE2.2050903@oracle.com> <50ED86C1.3030703@oracle.com> Message-ID: <50ED8C25.30902@oracle.com> On 09/01/2013 15:03, Kumar Srinivasan wrote: > Generally the changes looks good, I focused on pack200 and launcher, > the src changes are fine. > > Some comments on the tests in test/tools/launcher/profiles, we have a > test/tools/launcher/TestHelper.java which could make these new launcher > tests in the profile directory simpler. > > Kumar Thanks for looking at this. The reason that these tests are not using TestHelper it uses sun.tools.jar (the "jar" tool) and this is not in any of the runtime profiles. It also uses javax.compiler and this is only proposed for compact3 (even then it is only functional if tools.jar is copied in). At one point I looked into doing refactoring but decided it would be better to re-examine once the changes are in jdk8/tl. I hope that is okay with you. -Alan. From Alan.Bateman at oracle.com Wed Jan 9 15:43:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Jan 2013 15:43:37 +0000 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EC0F1F.2030403@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> Message-ID: <50ED9029.60705@oracle.com> On 08/01/2013 12:20, Daniel Fuchs wrote: > : > > I've clarified the spec. I also documented an additional step, which > was done by the implementation but not documented - which is that > the stream factory will also look up for properties in jaxp.properties > if stax.properties was not found. > > webrev: > > > > I have generated a spec diff for easier reading of the doc changes: > > I've gone through the spec changes and webrev and this is good work. I also agree with the option #3 that you proposed in one of the previous mails. A few small comments: In XMLEventFactory.newInstance the current wording is "Same as newFactory", I think it might be better if re-worded to: "Creates a new instance of the factory in exactly the same manner as the newFactory method". In XMLEventFactory.newFactory (also in XMLInputFactory and XMLOutputFactory) then it adds normative statements to specify that lib/jaxp.properties is checked when lib/stax.properties is not present. We need flexibility to change the layout of the JRE/JDK image so I think it would be better to leave this out of the spec. Otherwise I think this is good to go. -Alan. From Alan.Bateman at oracle.com Wed Jan 9 15:52:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Jan 2013 15:52:37 +0000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50ECEAE2.2050903@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> <50ECEAE2.2050903@oracle.com> Message-ID: <50ED9245.5010302@oracle.com> On 09/01/2013 03:58, Mandy Chung wrote: > : > > Looks like the jar tool -m option allows an entry with a space > "Profile: " (a space following ":") - an existing bug then. There > may be other implementation to create a jar file that doesn't do the > check though. There is a long standing issue (and bugs) related to trailing spaces. I'd like to stay clear of this one for this work. > : > > I see no issue with the jar tool to know about the profile names as > they will be standard and part of the platform. Having the jar tool > to validate the profile name will help catch mistake at packaging > time. This is minor and I'm fine to revisit this in the future. Okay, I'll go along with this and I've pushed a change to the jdk8/profiles forest to do this and also expanded the tests to ensure that the jar tool fails if an invalid profile is specified to -p. -Alan. From kumar.x.srinivasan at oracle.com Wed Jan 9 16:06:14 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 09 Jan 2013 08:06:14 -0800 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50ED8C25.30902@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> <50ECEAE2.2050903@oracle.com> <50ED86C1.3030703@oracle.com> <50ED8C25.30902@oracle.com> Message-ID: <50ED9576.4060407@oracle.com> On 1/9/2013 7:26 AM, Alan Bateman wrote: > On 09/01/2013 15:03, Kumar Srinivasan wrote: >> Generally the changes looks good, I focused on pack200 and launcher, >> the src changes are fine. >> >> Some comments on the tests in test/tools/launcher/profiles, we have a >> test/tools/launcher/TestHelper.java which could make these new launcher >> tests in the profile directory simpler. >> >> Kumar > Thanks for looking at this. > > The reason that these tests are not using TestHelper it uses > sun.tools.jar (the "jar" tool) and this is not in any of the runtime > profiles. It also uses javax.compiler and this is only proposed for > compact3 (even then it is only functional if tools.jar is copied in). > At one point I looked into doing refactoring but decided it would be > better to re-examine once the changes are in jdk8/tl. I hope that is > okay with you. Ah ok sounds good. I think we should make this fool proof after CF to prevent nightly test anomalies by someone introducing stray dependencies. Thanks Kumar > > -Alan. From daniel.fuchs at oracle.com Wed Jan 9 17:26:16 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Jan 2013 18:26:16 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50ED9029.60705@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> Message-ID: <50EDA838.5030203@oracle.com> Thanks for the comments Alan! I have implemented them and refreshed the webrev for the record: -- daniel On 1/9/13 4:43 PM, Alan Bateman wrote: > On 08/01/2013 12:20, Daniel Fuchs wrote: >> : >> >> I've clarified the spec. I also documented an additional step, which >> was done by the implementation but not documented - which is that >> the stream factory will also look up for properties in jaxp.properties >> if stax.properties was not found. >> >> webrev: >> >> >> >> I have generated a spec diff for easier reading of the doc changes: >> >> > I've gone through the spec changes and webrev and this is good work. I > also agree with the option #3 that you proposed in one of the previous > mails. A few small comments: > > In XMLEventFactory.newInstance the current wording is "Same as > newFactory", I think it might be better if re-worded to: "Creates a new > instance of the factory in exactly the same manner as the newFactory > method". > > In XMLEventFactory.newFactory (also in XMLInputFactory and > XMLOutputFactory) then it adds normative statements to specify that > lib/jaxp.properties is checked when lib/stax.properties is not present. > We need flexibility to change the layout of the JRE/JDK image so I think > it would be better to leave this out of the spec. > > Otherwise I think this is good to go. > > -Alan. > > > From stevenschlansker at gmail.com Wed Jan 9 17:51:47 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Wed, 9 Jan 2013 09:51:47 -0800 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> Message-ID: Hello again, I sent this email a week ago and have received no replies. Is there any step I have missed necessary to contribute to the JDK libraries? I am very interested in making your lives easier, so please let me know if I am in the wrong place or are otherwise misguided. Thanks! Steven On Dec 29, 2012, at 9:25 AM, Steven Schlansker wrote: > Hello core-libs-dev, > > My company uses UUIDs throughout our software. We recently identified that the java.util.UUID implementations of fromString and toString are horridly inefficient. > > An incomplete list of the inefficiencies: > > * fromString uses a regular expression that is not even precompiled > * fromString uses a regular expression to parse out the "-" markers, requiring the allocation of many String and String[] objects, when a simple linear scan works just fine > * fromString unnecessarily allocates multiple Long objects > > * toString creates a char[64], a String object which copies that, and a sub-String object for *each* of the 5 hex digit segments > * toString produces a fixed-length result but involves multiple StringBuilder concatenations > > Everyone that I have shown the relevant code to has been horrified by the complete lack of care towards object allocations. While I am a big fan of the "object allocation is free until otherwise proven" philosophy, we traced multiple production problems down to these hotspots. > > But instead of just whining about it, I wish to contribute a patch which I believe fixes the problem. This is my first attempt to submit anything to the JDK, so please be nice :-) > > My initial attempt has yielded micro benchmarks with very favorable outcomes. By taking the appropriate code from java.lang.Long, modifying it to work on a single pre-allocated array+offset rather than returning a String, and scanning for dashes instead of regex splitting I reduced times 3-6x and object allocations to the low single digits. > > My Google Caliper benchmark is available here, to ensure that I have not committed any benchmark sins: > https://gist.github.com/4356621 > > benchmark instances Bytes ns linear runtime > JdkUuidFromString 51.00 1544.0 608.2 ============================== > NewUuidFromString 2.00 72.0 179.1 ======== > > JdkUuidToString 31.00 1720.0 321.4 =============== > NewUuidToString 3.00 200.0 51.5 == > > In particular, the reduction of object allocations from ~1.5KB to 72/200 bytes dramatically reduces GC pressure when you sit in a tight loop deserializing millions of UUIDs from strings. > > I believe the same patch can (and should?) apply to jdk7u and jdk8, as the code does not seem to have changed. > > I would appreciate any feedback on the code style, efficiency, or correctness that you can offer. I have run the "java/util/UUID" jtreg suite against this and it passes. We stole the more thorough Apache Harmony tests for this and they pass as well: https://github.com/stevenschlansker/components-ness-core/blob/master/src/test/java/com/nesscomputing/uuid/TestNessUUID.java > > I have not yet secured a CLA, but my company is in the process of signing one. > > The rest of the message is a "hg export" of my change set, which is current to the tip of jdk7. > Happy holidays, and thank you for your time! > Steven Schlansker > > > > > # HG changeset patch > # User Steven Schlansker > # Date 1356737383 0 > # Node ID a812c963b96f08112f6805cbc380b12af196f788 > # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 > java.util.UUID: improve performance of UUID#toString and UUID#fromString by avoiding many unnecessary object allocations. > > benchmark instances Bytes ns linear runtime > JdkUuidFromString 51.00 1544.0 608.2 ============================== > NewUuidFromString 2.00 72.0 179.1 ======== > > JdkUuidToString 31.00 1720.0 321.4 =============== > NewUuidToString 3.00 200.0 51.5 == > > diff -r 9b8c96f96a0f -r a812c963b96f src/share/classes/java/util/UUID.java > --- a/src/share/classes/java/util/UUID.java Mon Jun 27 13:21:34 2011 -0700 > +++ b/src/share/classes/java/util/UUID.java Fri Dec 28 23:29:43 2012 +0000 > @@ -189,26 +189,79 @@ > * described in {@link #toString} > * > */ > - public static UUID fromString(String name) { > - String[] components = name.split("-"); > - if (components.length != 5) > - throw new IllegalArgumentException("Invalid UUID string: "+name); > - for (int i=0; i<5; i++) > - components[i] = "0x"+components[i]; > + public static UUID fromString(String str) { > + int dashCount = 4; > + int [] dashPos = new int [6]; > + dashPos[0] = -1; > + dashPos[5] = str.length(); > > - long mostSigBits = Long.decode(components[0]).longValue(); > + for (int i = str.length()-1; i >= 0; i--) { > + if (str.charAt(i) == '-') { > + if (dashCount == 0) { > + throw new IllegalArgumentException("Invalid UUID string: " + str); > + } > + dashPos[dashCount--] = i; > + } > + } > + > + if (dashCount > 0) { > + throw new IllegalArgumentException("Invalid UUID string: " + str); > + } > + > + long mostSigBits = decode(str, dashPos, 0) & 0xffffffffL; > mostSigBits <<= 16; > - mostSigBits |= Long.decode(components[1]).longValue(); > + mostSigBits |= decode(str, dashPos, 1) & 0xffffL; > mostSigBits <<= 16; > - mostSigBits |= Long.decode(components[2]).longValue(); > + mostSigBits |= decode(str, dashPos, 2) & 0xffff); > > - long leastSigBits = Long.decode(components[3]).longValue(); > + long leastSigBits = decode(str, dashPos, 3) & 0xffffL; > leastSigBits <<= 48; > - leastSigBits |= Long.decode(components[4]).longValue(); > + leastSigBits |= decode(str, dashPos, 4) & 0xffffffffffffL; > > return new UUID(mostSigBits, leastSigBits); > } > > + private static long decode(final String str, final int [] dashPos, final int field) { > + int start = dashPos[field]+1; > + int end = dashPos[field+1]; > + if (start >= end) { > + throw new IllegalArgumentException("Invalid UUID string: " + str); > + } > + long curr = 0; > + for (int i = start; i < end; i++) { > + int x = getNibbleFromChar(str.charAt(i)); > + curr <<= 4; > + if (curr < 0) { > + throw new NumberFormatException("long overflow"); > + } > + curr |= x; > + } > + return curr; > + } > + > + private static final int NUM_ALPHA_DIFF = 'A' - '9' - 1; > + private static final int LOWER_UPPER_DIFF = 'a' - 'A'; > + > + private static int getNibbleFromChar(final char c) > + { > + int x = c - '0'; > + if (x > 9) { > + x -= NUM_ALPHA_DIFF; // difference between '9' and 'A' > + if (x > 15) { > + x -= LOWER_UPPER_DIFF; // difference between 'a' and 'A' > + } > + if (x < 10) { > + throw new IllegalArgumentException(c + " is not a valid character for an UUID string"); > + } > + } > + > + if (x < 0 || x > 15) { > + throw new IllegalArgumentException(c + " is not a valid character for an UUID string"); > + } > + > + return x; > + } > + > // Field Accessor Methods > > /** > @@ -372,19 +425,46 @@ > * @return A string representation of this {@code UUID} > */ > public String toString() { > - return (digits(mostSigBits >> 32, 8) + "-" + > - digits(mostSigBits >> 16, 4) + "-" + > - digits(mostSigBits, 4) + "-" + > - digits(leastSigBits >> 48, 4) + "-" + > - digits(leastSigBits, 12)); > + return toString(getMostSignificantBits(), getLeastSignificantBits()); > } > > - /** Returns val represented by the specified number of hex digits. */ > - private static String digits(long val, int digits) { > - long hi = 1L << (digits * 4); > - return Long.toHexString(hi | (val & (hi - 1))).substring(1); > + public static String toString(long msb, long lsb) { > + char[] uuidChars = new char[36]; > + > + hexDigits(uuidChars, 0, 8, msb >> 32); > + uuidChars[8] = '-'; > + hexDigits(uuidChars, 9, 4, msb >> 16); > + uuidChars[13] = '-'; > + hexDigits(uuidChars, 14, 4, msb); > + uuidChars[18] = '-'; > + hexDigits(uuidChars, 19, 4, lsb >> 48); > + uuidChars[23] = '-'; > + hexDigits(uuidChars, 24, 12, lsb); > + > + return new String(uuidChars); > } > > + private static void hexDigits(char[] dest, int offset, int digits, long val) { > + long hi = 1L << (digits * 4); > + toUnsignedString(dest, offset, digits, hi | (val & (hi - 1)), 4); > + } > + > + private final static char[] HEX_DIGITS = { > + '0' , '1' , '2' , '3' , '4' , '5' , > + '6' , '7' , '8' , '9' , 'a' , 'b' , > + 'c' , 'd' , 'e' , 'f' > + }; > + > + private static void toUnsignedString(char[] dest, int offset, int len, long i, int shift) { > + int charPos = len; > + int radix = 1 << shift; > + long mask = radix - 1; > + do { > + dest[offset + --charPos] = HEX_DIGITS[(int)(i & mask)]; > + i >>>= shift; > + } while (i != 0 && charPos > 0); > + } > + > /** > * Returns a hash code for this {@code UUID}. > * From jonathan.gibbons at oracle.com Wed Jan 9 18:27:28 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Jan 2013 18:27:28 +0000 Subject: hg: jdk8/tl/langtools: 8005644: set default max errs and max warns Message-ID: <20130109182733.888E24714D@hg.openjdk.java.net> Changeset: d2eb08b3f64f Author: jjg Date: 2013-01-09 10:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2eb08b3f64f 8005644: set default max errs and max warns Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Messager.java + test/tools/javadoc/MaxWarns.java From jim.gish at oracle.com Wed Jan 9 18:49:15 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 09 Jan 2013 13:49:15 -0500 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures Message-ID: <50EDBBAB.7000500@oracle.com> Please review: http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/ Summary: this test, when run on Windows, fails intermittently because of asynchronous windows deletes. The test passes, deletes two files that it has created for the test in the scratch directory, and exits. Then, jtreg upon attempting to cleanup after the test, tries to delete the files after doing a listFiles() on the scratch directory, which despite the delete by the test itself, still contains the files. The jtreg delete fails and jtreg changes the state of the test from passed to failed. I'm in the process of adding deletion retry behavior to jtreg, but in the meantime we think it makes sense to provide a more stable test environment by simply getting rid of the redundant deletes by the test itself. There really is no need for tests to delete files from the scratch directory at the end of a test because jtreg carries a guarantee of cleanup. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From ioi.lam at oracle.com Wed Jan 9 19:05:50 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 09 Jan 2013 11:05:50 -0800 Subject: RFR: 8005466 zip_util.h Message-ID: <50EDBF8E.2090506@oracle.com> Please review: http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001/ bug: JAR file entry hash table uses too much memory (zip_util.c) https://jbs.oracle.com/bugs/browse/JDK-8005466 Summary: This submission is just a one-liner fix that changes 64-bit structure member alignment. The savings are only half as noted in the original bug description, but still significant: HelloWorld: about 150KB. Eclipse: about 540KB. This benefits all 64-bit VMs, as well as 32-bit VMs that are built with ABIs that require 8-byte structure alignment for jlong (e.g., as ARM EABI). (I have another fix that would reduce memory usage further, but it's too risky now and I may wait till JDK9). Repository used: I usedhttp://hg.openjdk.java.net/hsx/hotspot-rt/. Not sure if this is the right repo to use. Tests run: + JPRT -- To verify build-ability; JPRT also runs jtreg jdk/tools tests on all platforms. This includes basic JAR file tests. + Manually ran UTE/vm.quick.testlist on Linux/x64 Thanks, Ioi From martinrb at google.com Wed Jan 9 19:33:55 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Jan 2013 11:33:55 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EDBBAB.7000500@oracle.com> References: <50EDBBAB.7000500@oracle.com> Message-ID: On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish wrote: > > I'm in the process of adding deletion retry behavior to jtreg, but in the > meantime we think it makes sense to provide a more stable test environment > by simply getting rid of the redundant deletes by the test itself. There > really is no need for tests to delete files from the scratch directory at > the end of a test because jtreg carries a guarantee of cleanup. > I consider it good practice for a test to delete temporary files - it's just a java program that might be run outside of the test harness. Perhaps there's a deeper problem - why does the file system present inconsistent views? Is it a Windows bug? From Roger.Riggs at oracle.com Wed Jan 9 19:37:46 2013 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 09 Jan 2013 14:37:46 -0500 Subject: Integration of the Threeten/JSR 310 into JDK M6 Message-ID: <50EDC70A.2090004@oracle.com> The Threeten project [1] is planned to be integrated into OpenJDK with the M6 milestone. The javadoc [2] (aka JSR 310 specification) for the new Java Time packages is available for review. Comments can be sent to the threeten-dev email list [3] or entered in the issue tracker [4]. When Threeten is incorporated in M6, the regular jdk8 build can be used by developers to provide feedback based on concrete experience. The Threeten API will continue to be refined. Feedback will be evaluated for inclusion in the public review of JSR 310 and subsequent JDK builds. [1] http://openjdk.java.net/projects/threeten/ [2] http://cr.openjdk.java.net/~rriggs/threeten-javadoc/ [3] threeten-dev @ openjdk.java.net [4] https://github.com/ThreeTen/threeten/issues From jim.gish at oracle.com Wed Jan 9 19:46:59 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 09 Jan 2013 14:46:59 -0500 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: References: <50EDBBAB.7000500@oracle.com> Message-ID: <50EDC933.6010303@oracle.com> On 01/09/2013 02:33 PM, Martin Buchholz wrote: > > > On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish > wrote: > > > I'm in the process of adding deletion retry behavior to jtreg, but > in the meantime we think it makes sense to provide a more stable > test environment by simply getting rid of the redundant deletes by > the test itself. There really is no need for tests to delete > files from the scratch directory at the end of a test because > jtreg carries a guarantee of cleanup. > > > I consider it good practice for a test to delete temporary files - > it's just a java program that might be run outside of the test harness. In general, I totally agree with you, and in fact I'm ok with putting the deletes back in after we have the retry logic in place in jtreg. I'll be happy to file a bug to revert this change. For now, we are trying very hard to have a stable set of tests. This one has been failing every couple of days. > > Perhaps there's a deeper problem - why does the file system present > inconsistent views? Is it a Windows bug? It's a Windows feature. We discovered this recently in debugging another test failure. Windows is documented to do asynchronous deletes. You can't depend on a file.delete() which returns true to have actually deleted the file. It may be the case that another process has a file handle which it has not yet released, or it's simply a delay. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From brian.burkhalter at oracle.com Wed Jan 9 19:58:27 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Jan 2013 11:58:27 -0800 Subject: RFR 7103957: NegativeArraySizeException while initializing class IntegerCache Message-ID: <3D643335-3D39-4576-BBC3-D73423590305@oracle.com> Please review at your convenience. Issue https://jbs.oracle.com/bugs/browse/JDK-7103957 The problem and suggested fix provided in the issue description are accurate: the array is one element too large. Diff --- a/src/share/classes/java/lang/Integer.java Tue Nov 13 20:02:39 2012 -0800 +++ b/src/share/classes/java/lang/Integer.java Wed Jan 09 11:45:28 2013 -0800 @@ -772,7 +772,7 @@ int i = parseInt(integerCacheHighPropValue); i = Math.max(i, 127); // Maximum array size is Integer.MAX_VALUE - h = Math.min(i, Integer.MAX_VALUE - (-low)); + h = Math.min(i, Integer.MAX_VALUE - (-low) - 1); } high = h; Testing All java/lang tests passed on default array of platforms. Thanks, Brian From Alan.Bateman at oracle.com Wed Jan 9 20:15:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Jan 2013 20:15:07 +0000 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EDA838.5030203@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> Message-ID: <50EDCFCB.70407@oracle.com> On 09/01/2013 17:26, Daniel Fuchs wrote: > Thanks for the comments Alan! > > I have implemented them and refreshed the webrev for the record: > > > > > -- daniel You've addressed my comments so thumbs up from me on this chapter. -Alan From vladimir.kozlov at oracle.com Tue Jan 8 23:18:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Jan 2013 15:18:13 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Message-ID: <50ECA935.2030703@oracle.com> http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev Move encoding loop into separate method for which VM will use intrinsic on x86. I want to get agreement on this jdk change before I submit VM part. This gives +1.6% performance improvement on SPECjAppServer2004 on x86. Note, even without intrinsic (on other platforms) JIT will produce better code for this loop. Thanks, Vladimir From mandy.chung at oracle.com Wed Jan 9 20:30:46 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jan 2013 12:30:46 -0800 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EDA838.5030203@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> Message-ID: <50EDD376.9060401@oracle.com> On 1/9/2013 9:26 AM, Daniel Fuchs wrote: > > > Daniel - thanks for updating the spec for the newFactory(String, ClassLoader) method. In XMLEventFactory.java (and same comment apply to XMLInputFactory and XMLOutputFactory): Since there is a behavioral change, the following statements are not true any more and I think they can be removed. 166 * No changes in behavior are defined by this replacement method relative 167 * to the deprecated method. and 123 * The replacement {@link 124 * #newFactory(java.lang.String, java.lang.ClassLoader)} 125 * method defines no changes in behavior. L152: would it be better to replace "the base service class name" with the classname (i.e. javax.xml.XMLEventFactory) 152 * If {@code factoryId} is the base service class name, 153 * use the service-provider loading facilities, defined by the 154 * {@link java.util.ServiceLoader} class, to attempt to locate and load an 155 * implementation of the service. The classLoader parameter passed to the newFactory(String, ClassLoader) method is actually ignored. It might be good to clarify that since the spec is updated anyway. Mandy From joe.darcy at oracle.com Wed Jan 9 20:48:17 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jan 2013 12:48:17 -0800 Subject: RFR 7103957: NegativeArraySizeException while initializing class IntegerCache In-Reply-To: <3D643335-3D39-4576-BBC3-D73423590305@oracle.com> References: <3D643335-3D39-4576-BBC3-D73423590305@oracle.com> Message-ID: <50EDD791.4010507@oracle.com> Looks fine; approved. Cheers, -Joe On 1/9/2013 11:58 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue > https://jbs.oracle.com/bugs/browse/JDK-7103957 > > The problem and suggested fix provided in the issue description are accurate: the array is one element too large. > > Diff > --- a/src/share/classes/java/lang/Integer.java Tue Nov 13 20:02:39 2012 -0800 > +++ b/src/share/classes/java/lang/Integer.java Wed Jan 09 11:45:28 2013 -0800 > @@ -772,7 +772,7 @@ > int i = parseInt(integerCacheHighPropValue); > i = Math.max(i, 127); > // Maximum array size is Integer.MAX_VALUE > - h = Math.min(i, Integer.MAX_VALUE - (-low)); > + h = Math.min(i, Integer.MAX_VALUE - (-low) - 1); > } > high = h; > > Testing > All java/lang tests passed on default array of platforms. > > Thanks, > > Brian From aleksey.shipilev at oracle.com Wed Jan 9 20:52:48 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 00:52:48 +0400 Subject: RFR: 8005466 zip_util.h In-Reply-To: <50EDBF8E.2090506@oracle.com> References: <50EDBF8E.2090506@oracle.com> Message-ID: <50EDD8A0.3070207@oracle.com> On 01/09/2013 11:05 PM, Ioi Lam wrote: > http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001/ > (I'm not the sponsor). Nice patch, I can see the reasoning behind the issue and the fix. -Aleksey. From chris.hegarty at oracle.com Wed Jan 9 21:03:32 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Jan 2013 21:03:32 +0000 Subject: RFR: 8005466 zip_util.h In-Reply-To: <50EDD8A0.3070207@oracle.com> References: <50EDBF8E.2090506@oracle.com> <50EDD8A0.3070207@oracle.com> Message-ID: <7328B0A1-059A-4A78-AF59-916D5EEDA2D2@oracle.com> I think Sherman agreed to sponsor this change. If not, I can help get it on. -Chris On 9 Jan 2013, at 20:52, Aleksey Shipilev wrote: > On 01/09/2013 11:05 PM, Ioi Lam wrote: >> http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001/ >> > > (I'm not the sponsor). > Nice patch, I can see the reasoning behind the issue and the fix. > > -Aleksey. > From xueming.shen at oracle.com Wed Jan 9 21:07:43 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 09 Jan 2013 13:07:43 -0800 Subject: RFR: 8005466 zip_util.h In-Reply-To: <7328B0A1-059A-4A78-AF59-916D5EEDA2D2@oracle.com> References: <50EDBF8E.2090506@oracle.com> <50EDD8A0.3070207@oracle.com> <7328B0A1-059A-4A78-AF59-916D5EEDA2D2@oracle.com> Message-ID: <50EDDC1F.30700@oracle.com> I'm running it through jprt now. I will push this in for Ioi, if everything goes well. On 01/09/2013 01:03 PM, Chris Hegarty wrote: > I think Sherman agreed to sponsor this change. If not, I can help get it on. > > -Chris > > On 9 Jan 2013, at 20:52, Aleksey Shipilev wrote: > >> On 01/09/2013 11:05 PM, Ioi Lam wrote: >>> http://cr.openjdk.java.net/~coleenp/8005466_zip_util_001/ >>> >> (I'm not the sponsor). >> Nice patch, I can see the reasoning behind the issue and the fix. >> >> -Aleksey. >> From daniel.fuchs at oracle.com Wed Jan 9 21:13:35 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 09 Jan 2013 22:13:35 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EDD376.9060401@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> <50EDD376.9060401@oracle.com> Message-ID: <50EDDD7F.9050403@oracle.com> Hi Mandy, Please find clarifications in line: On 1/9/13 9:30 PM, Mandy Chung wrote: > On 1/9/2013 9:26 AM, Daniel Fuchs wrote: >> >> >> > > Daniel - thanks for updating the spec for the newFactory(String, > ClassLoader) method. > > In XMLEventFactory.java (and same comment apply to XMLInputFactory and > XMLOutputFactory): > > Since there is a behavioral change, the following statements are > not true > any more and I think they can be removed. > > 166 * No changes in behavior are defined by this replacement > method relative > 167 * to the deprecated method. The behavior change is the same in both the deprecated & the new method - since it occurred in the FactoryFinder which both methods are calling, so I think this statement is still true. > > and > > 123 * The replacement {@link > 124 * #newFactory(java.lang.String, > java.lang.ClassLoader)} > 125 * method defines no changes in behavior. > > L152: would it be better to replace "the base service class name" with > the classname (i.e. javax.xml.XMLEventFactory) Yes - I can do that. I was just being lazy :-) > 152 * If {@code factoryId} is the base service class name, > 153 * use the service-provider loading facilities, defined by the > 154 * {@link java.util.ServiceLoader} class, to attempt to > locate and load an > 155 * implementation of the service. > > The classLoader parameter passed to the newFactory(String, > ClassLoader) method > is actually ignored. It might be good to clarify that since the spec > is updated > anyway. I think it's a bug. I'm intending to log it as a separate issue. FWIW in the other factories (in other packages) the classloader is not ignored. So I think it would be wrong to document a bug :-) -- daniel > > Mandy > From chris.hegarty at oracle.com Wed Jan 9 21:17:12 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 9 Jan 2013 21:17:12 +0000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50D3654F.2030106@oracle.com> References: <50D36104.8000701@oracle.com> <50D3654F.2030106@oracle.com> Message-ID: On 20 Dec 2012, at 19:21, Vladimir Kozlov wrote: > Looks good for me. I will sponsor these changes after we get a review from JDK side. Have I missed something, or are these changes not already in? -Chris > > Thanks, > Vladimir > > On 12/20/12 11:03 AM, Aleksey Shipilev wrote: >> Hi, >> >> Sorry for cross-list posting, but this change affects both HS and JDK. >> >> This simple change is missing from recently committed CR 7023898. While >> the VM support is there in Hotspot, no methods are exposed in Unsafe to >> actually make use of those intrinsics. This is the webrev fixing that: >> http://cr.openjdk.java.net/~shade/8004330/webrev.00/ >> >> It turns out the getAndSet intrinsics HotSpot are overloaded, which had >> deluged both Doug and me in the previous patch. These namings are >> inconsistent with other Unsafe intrinsic naming convention, so this >> change fixes that as well. >> >> Testing: >> - Built and tested in Linux x86_64 >> - java-concurrency-torture [1] atomicity tests are passed for >> AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics >> on Linux x86_64 >> - running the java-concurrency-torture tests "-XX:+PrintInlining | >> grep Unsafe" tells all intrinsics have been successfully inlined >> - no other testing is expected for this trivial change. >> >> I would need a sponsor to push this. Thanks for your patience and reviews! >> >> Contributors: >> - dl: original patch, testing >> - shade: due diligence, messing with reviews, tests, and rebuilds >> >> -Aleksey. >> >> [1] https://github.com/shipilev/java-concurrency-torture/ >> [2] >> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >> [3] >> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java >> From martinrb at google.com Wed Jan 9 21:36:58 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Jan 2013 13:36:58 -0800 Subject: RFR: 8005466 zip_util.h In-Reply-To: <50EDBF8E.2090506@oracle.com> References: <50EDBF8E.2090506@oracle.com> Message-ID: On Wed, Jan 9, 2013 at 11:05 AM, Ioi Lam wrote: > > Repository used: > > I usedhttp://hg.openjdk.java.**net/hsx/hotspot-rt/. > Not sure if this is the > right repo to use. > This is not a hotspot change, so this doesn't go into a hotspot forest. It very likely belongs in tl. From eric.mccorkle at oracle.com Wed Jan 9 21:55:39 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 09 Jan 2013 16:55:39 -0500 Subject: Review request JDK-8004729: Parameter Reflection API Message-ID: <50EDE75B.4000308@oracle.com> Hello, Please review the core reflection API implementation of parameter reflection. This is the final component of method parameter reflection. This was posted for review before, then delayed until the check-in for JDK-8004728 (hotspot support for parameter reflection), which occurred yesterday. Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* jdk8/tl; therefore, it may be a while before the changeset makes its way into jdk8/tl. Also note: since the check-in of JDK-8004727 (javac support for parameter reflection), there has been a failure in the tests for Pack200. This is being addressed in a fix contributed by Kumar, which I believe has also been posted for review. The open webrev is here: http://cr.openjdk.java.net/~coleenp/JDK-8004729 The feature request is here: http://bugs.sun.com/view_bug.do?bug_id=8004729 The latest version of the spec can be found here: http://cr.openjdk.java.net/~abuckley/8misc.pdf Thanks, Eric From brian.burkhalter at oracle.com Wed Jan 9 22:19:24 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Jan 2013 14:19:24 -0800 Subject: RFR 7103957: NegativeArraySizeException while initializing class IntegerCache In-Reply-To: <50EDD791.4010507@oracle.com> References: <3D643335-3D39-4576-BBC3-D73423590305@oracle.com> <50EDD791.4010507@oracle.com> Message-ID: Is there someone willing to sponsor this fix? Thanks, Brian On Jan 9, 2013, at 12:48 PM, Joe Darcy wrote: > Looks fine; approved. > > Cheers, > > -Joe > > On 1/9/2013 11:58 AM, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue >> https://jbs.oracle.com/bugs/browse/JDK-7103957 >> >> The problem and suggested fix provided in the issue description are accurate: the array is one element too large. >> >> Diff >> --- a/src/share/classes/java/lang/Integer.java Tue Nov 13 20:02:39 2012 -0800 >> +++ b/src/share/classes/java/lang/Integer.java Wed Jan 09 11:45:28 2013 -0800 >> @@ -772,7 +772,7 @@ >> int i = parseInt(integerCacheHighPropValue); >> i = Math.max(i, 127); >> // Maximum array size is Integer.MAX_VALUE >> - h = Math.min(i, Integer.MAX_VALUE - (-low)); >> + h = Math.min(i, Integer.MAX_VALUE - (-low) - 1); >> } >> high = h; >> >> Testing >> All java/lang tests passed on default array of platforms. >> >> Thanks, >> >> Brian > From vladimir.kozlov at oracle.com Wed Jan 9 22:44:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Jan 2013 14:44:18 -0800 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: References: <50D36104.8000701@oracle.com> <50D3654F.2030106@oracle.com> Message-ID: <50EDF2C2.5090309@oracle.com> (resending to all lists) It is in promoted build jdk8b71 already: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/8cf5b18488d1 Vladimir On 1/9/13 1:17 PM, Chris Hegarty wrote: > > On 20 Dec 2012, at 19:21, Vladimir Kozlov wrote: > >> Looks good for me. I will sponsor these changes after we get a review from JDK side. > > Have I missed something, or are these changes not already in? > > -Chris > >> >> Thanks, >> Vladimir >> >> On 12/20/12 11:03 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Sorry for cross-list posting, but this change affects both HS and JDK. >>> >>> This simple change is missing from recently committed CR 7023898. While >>> the VM support is there in Hotspot, no methods are exposed in Unsafe to >>> actually make use of those intrinsics. This is the webrev fixing that: >>> http://cr.openjdk.java.net/~shade/8004330/webrev.00/ >>> >>> It turns out the getAndSet intrinsics HotSpot are overloaded, which had >>> deluged both Doug and me in the previous patch. These namings are >>> inconsistent with other Unsafe intrinsic naming convention, so this >>> change fixes that as well. >>> >>> Testing: >>> - Built and tested in Linux x86_64 >>> - java-concurrency-torture [1] atomicity tests are passed for >>> AtomicIntegerV8 [2] and AtomicLongV8 [3] making use of those intrinsics >>> on Linux x86_64 >>> - running the java-concurrency-torture tests "-XX:+PrintInlining | >>> grep Unsafe" tells all intrinsics have been successfully inlined >>> - no other testing is expected for this trivial change. >>> >>> I would need a sponsor to push this. Thanks for your patience and reviews! >>> >>> Contributors: >>> - dl: original patch, testing >>> - shade: due diligence, messing with reviews, tests, and rebuilds >>> >>> -Aleksey. >>> >>> [1] https://github.com/shipilev/java-concurrency-torture/ >>> [2] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/integer/AtomicIntegerV8PairwiseTests.java >>> [3] >>> https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/concurrent/torture/tests/atomics/longs/AtomicLongV8PairwiseTests.java >>> From jim.gish at oracle.com Wed Jan 9 22:46:40 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 09 Jan 2013 17:46:40 -0500 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent Message-ID: <50EDF350.7050302@oracle.com> Please review the following: Webrev: http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ Here's a specdiff: http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ Summary: This change replaces java/lang/*String*.java javadoc, method-specific @throws NullPointerException clauses with blanket null-handling statements like that currently in String.java That was motivated by a discussion awhile back, strongly favoring a blanket statement over individual @throws clauses. For String, the following blanket statement is already in place: *

Unless otherwise noted, passing a null argument to a constructor * or method in this class will cause a {@link NullPointerException} to be * thrown. However, despite the blanket statement, the following methods also have @throws clauses: public boolean contains(java.lang.CharSequence s) Throws: |java.lang.NullPointerException|- if|s|is|null| --------------------------------------------------------------- public staticString format(String format, java.lang.Object... args) Throws: |java.lang.NullPointerException|- If the|format|is|null |----------------------------------------------------------------------- || public staticString format(java.util.Locale l, String format, java.lang.Object... args) Throws: |java.lang.NullPointerException|- If the|format|is|null |-------------------------------------------------------------------------- All of the above are properly specified with the blanket statement or other parts of their spec (such as format w.r.t. null Locale) and the @throws can safely be removed. Because the blanket statement is already in effect for String.java, I wrote tests for all methods/constructors to ensure compliance. Running them revealed the following: public void getBytes(int srcBegin, int srcEnd, byte dst[], int dstBegin) - I would expect an NPE to be thrown if dst == null. However, this isn't always the case. If dst isn't accessed because of the values of the other parameters (as in getBytes(1,2,(byte[]null,1), then no NPE is thrown. - This brings up the question as to the correctness of the blanket statement w.r.t. this method. I think this method (and others like it) should use Objects.requireNonNull(dst). (The correspoding method public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin), does always throw NPE for dst==null) All other methods/constructors in StringBuffer and StringBuilder either correctly state null-handling behavior that differs from the blanket statement or are correct w.r.t. the blanket statement. This has been reviewed by the JCK team. It will require CCC approval (because of the new blanket statement, and the fact that some of the existing methods were previously silent on null handling, but all already conform to the blanket statement). Thanks, Jim Gish -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mike.duigou at oracle.com Wed Jan 9 23:09:13 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Jan 2013 15:09:13 -0800 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent In-Reply-To: <50EDF350.7050302@oracle.com> References: <50EDF350.7050302@oracle.com> Message-ID: AbstractStringBuilder probably needs the "Unless otherwise noted," blanket statement as well (Same as StringBuffer/StringBuilder) You might want to move the Objects.requireNonNull(dst); in String.getBytes() to after the existing checks so as not to unnecessarily change the exception thrown for bad inputs. An exception will still be thrown but some bad code may anticipate StringIndexOutOfBoundsException rather than NPE. This is a very minor matter though. Otherwise, it looks good. Mike On Jan 9 2013, at 14:46 , Jim Gish wrote: > Please review the following: > > Webrev: http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ > Here's a specdiff: http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ > > > Summary: This change replaces java/lang/*String*.java javadoc, method-specific @throws NullPointerException clauses with blanket null-handling statements like that currently in String.java > > That was motivated by a discussion awhile back, strongly favoring a blanket statement over individual @throws clauses. > > For String, the following blanket statement is already in place: > > *

Unless otherwise noted, passing a null argument to a constructor > * or method in this class will cause a {@link NullPointerException} to be > * thrown. > > > However, despite the blanket statement, the following methods also have @throws clauses: > > public boolean contains(java.lang.CharSequence s) > > Throws: > |java.lang.NullPointerException|- if|s|is|null| > --------------------------------------------------------------- > > public staticString format(String format, > java.lang.Object... args) > > > Throws: > |java.lang.NullPointerException|- If the|format|is|null > |----------------------------------------------------------------------- > || > > public staticString format(java.util.Locale l, > String format, > java.lang.Object... args) > > Throws: > |java.lang.NullPointerException|- If the|format|is|null > |-------------------------------------------------------------------------- > All of the above are properly specified with the blanket statement or other parts of their spec (such as format w.r.t. null Locale) and the @throws can safely be removed. > > Because the blanket statement is already in effect for String.java, I wrote tests for all methods/constructors to ensure compliance. Running them revealed the following: > > public void getBytes(int srcBegin, int srcEnd, byte dst[], int dstBegin) > - I would expect an NPE to be thrown if dst == null. However, this isn't always the case. If dst isn't accessed because of the values of the other parameters (as in getBytes(1,2,(byte[]null,1), then no NPE is thrown. > - This brings up the question as to the correctness of the blanket statement w.r.t. this method. I think this method (and others like it) should use Objects.requireNonNull(dst). (The correspoding method public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin), does always throw NPE for dst==null) > > All other methods/constructors in StringBuffer and StringBuilder either correctly state null-handling behavior that differs from the blanket statement or are correct w.r.t. the blanket statement. > > This has been reviewed by the JCK team. It will require CCC approval (because of the new blanket statement, and the fact that some of the existing methods were previously silent on null handling, but all already conform to the blanket statement). > > Thanks, > Jim Gish > > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > From mandy.chung at oracle.com Wed Jan 9 23:24:11 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jan 2013 15:24:11 -0800 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EDDD7F.9050403@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> <50EDD376.9060401@oracle.com> <50EDDD7F.9050403@oracle.com> Message-ID: <50EDFC1B.1050300@oracle.com> On 1/9/2013 1:13 PM, Daniel Fuchs wrote: > Hi Mandy, > > Please find clarifications in line: > > On 1/9/13 9:30 PM, Mandy Chung wrote: >> >> Since there is a behavioral change, the following statements are >> not true >> any more and I think they can be removed. >> >> 166 * No changes in behavior are defined by this replacement >> method relative >> 167 * to the deprecated method. > The behavior change is the same in both the deprecated & the new > method - since > it occurred in the FactoryFinder which both methods are calling, so I > think this statement is still true. I interpreted it differently comparing the old implementation of the deprecated newInstance method with the new implementation of newFactory method. My interpretation may be wrong and so will leave it to Joe to comment. I'm fine with what you currently have. >> >> The classLoader parameter passed to the newFactory(String, >> ClassLoader) method >> is actually ignored. It might be good to clarify that since the spec >> is updated >> anyway. > > I think it's a bug. I'm intending to log it as a separate issue. FWIW > in the other factories > (in other packages) the classloader is not ignored. In that case, please file a bug to track this. Thanks Mandy From Ulf.Zibis at CoSoCo.de Thu Jan 10 00:09:03 2013 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Thu, 10 Jan 2013 01:09:03 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EDB105.5080606@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> Message-ID: <50EE069F.4050704@CoSoCo.de> Another little simplification: 179 boolean overflow = sr > dr; 180 sr = overflow ? dr : sr; or in your existing logic: 178 int len = sl - sp; 179 boolean overflow = len > (dl - dp); 180 len = overflow ? dl - dp : len; (len is equivalent to sr) -Ulf Am 09.01.2013 19:03, schrieb Vladimir Kozlov: > Ulf, > > Thank you for this suggestion but I would like to keep surrounding code intact. I will rename > "overflowflag" to "overflow". It is used to indicate that we should return CoderResult.OVERFLOW > result. > > Thanks, > Vladimir > > On 1/9/13 3:58 AM, Ulf Zibis wrote: >> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >>> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >>> wrote: >>> >>>> http://cr.openjdk.java.net/~**kvn/6896617_jdk/webrev >>>> >>>> >> >> Another tweak: >> 168 char[] sa = src.array(); >> 169 int sp = src.arrayOffset() + src.position(); >> 170 int sr = src.remaining(); >> 171 int sl = sp + sr; >> 172 assert (sp <= sl); // superfluous, sr is always >= 0 >> 173 sp = (sp <= sl ? sp : sl); // superfluous " >> 174 byte[] da = dst.array(); >> 175 int dp = dst.arrayOffset() + dst.position(); >> 170 int dr = dst.remaining(); >> 176 int dl = dp + dr; >> 177 assert (dp <= dl); // superfluous " >> 178 dp = (dp <= dl ? dp : dl); // superfluous " >> 179 boolean overflow = false; >> 180 if (sr > dr) { >> 181 sr = dr; >> 182 overflow = true; >> 183 } >> >> Why you called it "overflowflag", in that way, you could name each >> variable "myvaluevariable" or "myvaluefield" ;-) >> >> >> -Ulf >> > From mandy.chung at oracle.com Thu Jan 10 00:45:10 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jan 2013 16:45:10 -0800 Subject: RFR 7103957: NegativeArraySizeException while initializing class IntegerCache In-Reply-To: References: <3D643335-3D39-4576-BBC3-D73423590305@oracle.com> <50EDD791.4010507@oracle.com> Message-ID: <50EE0F16.9060902@oracle.com> I can sponsor this fix. Mandy On 1/9/2013 2:19 PM, Brian Burkhalter wrote: > Is there someone willing to sponsor this fix? > > Thanks, > > Brian > > On Jan 9, 2013, at 12:48 PM, Joe Darcy wrote: > >> Looks fine; approved. >> >> Cheers, >> >> -Joe >> >> On 1/9/2013 11:58 AM, Brian Burkhalter wrote: >>> Please review at your convenience. >>> >>> Issue >>> https://jbs.oracle.com/bugs/browse/JDK-7103957 >>> >>> The problem and suggested fix provided in the issue description are accurate: the array is one element too large. >>> >>> Diff >>> --- a/src/share/classes/java/lang/Integer.java Tue Nov 13 20:02:39 2012 -0800 >>> +++ b/src/share/classes/java/lang/Integer.java Wed Jan 09 11:45:28 2013 -0800 >>> @@ -772,7 +772,7 @@ >>> int i = parseInt(integerCacheHighPropValue); >>> i = Math.max(i, 127); >>> // Maximum array size is Integer.MAX_VALUE >>> - h = Math.min(i, Integer.MAX_VALUE - (-low)); >>> + h = Math.min(i, Integer.MAX_VALUE - (-low) - 1); >>> } >>> high = h; >>> >>> Testing >>> All java/lang tests passed on default array of platforms. >>> >>> Thanks, >>> >>> Brian From stuart.marks at oracle.com Thu Jan 10 00:59:53 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 09 Jan 2013 16:59:53 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: References: <50EDBBAB.7000500@oracle.com> Message-ID: <50EE1289.40906@oracle.com> On 1/9/13 11:33 AM, Martin Buchholz wrote: > On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish wrote: >> >> I'm in the process of adding deletion retry behavior to jtreg, but in the >> meantime we think it makes sense to provide a more stable test environment >> by simply getting rid of the redundant deletes by the test itself. There >> really is no need for tests to delete files from the scratch directory at >> the end of a test because jtreg carries a guarantee of cleanup. >> > > I consider it good practice for a test to delete temporary files - it's > just a java program that might be run outside of the test harness. Hi Martin, In general it indeed is a good practice for things to clean up after themselves, but there are several different considerations. I was talking about this issue with Jon Gibbons, and he mentioned that it's often a good idea for tests to leave around files for diagnostic purposes, in case they fail, or in case they succeed unexpectedly. Tests cleaning up after themselves potentially destroys that information. That's why jtreg has the -retain option, that controls when (beginning of next test run, end of this test run), and under what circumstances (success, failure, error) the test's scratch files are removed. We're also moving toward an environment where we're running the test suite much more intensively than before, on all the platforms. Thus the tests are being run from jtreg very frequently, and while it's convenient for them to be invoked as standalone programs (outside the test harness) this is becoming relatively rare. Having options in the test to support the latter case is fine, but I think that running tests from jtreg needs to be considered the default case, and thus modify things to allow jtreg to determine the policy for file deletion/retention. > Perhaps there's a deeper problem - why does the file system present > inconsistent views? Is it a Windows bug? Jim answered this already, but I wanted to add that we've run into this problem before. See here for example: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012761.html This is with the Arrrghs test (which I'm sure you're familiar with). I guess it's a question of whether the file system is behaving inconsistently. From a Unix point of view asynchronous deletes are inconsistent, but on Windows this is apparently perfectly normal behavior. :-) s'marks From mandy.chung at oracle.com Thu Jan 10 01:12:23 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Jan 2013 01:12:23 +0000 Subject: hg: jdk8/tl/jdk: 7103957: NegativeArraySizeException while initializing class IntegerCache Message-ID: <20130110011234.EAE414715F@hg.openjdk.java.net> Changeset: 4c8b37f159f9 Author: mchung Date: 2013-01-09 16:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c8b37f159f9 7103957: NegativeArraySizeException while initializing class IntegerCache Reviewed-by: darcy, mchung Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/lang/Integer.java From martinrb at google.com Thu Jan 10 01:20:59 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Jan 2013 17:20:59 -0800 Subject: jtreg fails if directory timestamps are 0 (start of Unix epoch) Message-ID: Hey, This is a cute bug (maybe a bug in java.io or jtreg or jtharness; not sure). $ perl -e 'utime 0, 0, "java/lang/String"' && ls -ld java/lang/String && ~/jct-tools/jtreg-4.1-b5/linux/bin/jtreg java/lang/String/IsEmpty.java drwxr-x--- 2 martinrb eng 4096 Dec 31 1969 java/lang/String Error: Bad parameters specified: The following path does not identify a valid test or folder of tests: java/lang/String/IsEmpty.java jdk/test $ touch java/lang/String && ls -ld java/lang/String && ~/jct-tools/jtreg-4.1-b5/linux/bin/jtreg java/lang/String/IsEmpty.java drwxr-x--- 2 martinrb eng 4096 Jan 9 17:19 java/lang/String Test results: passed: 1 From dl at cs.oswego.edu Thu Jan 10 01:23:30 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 09 Jan 2013 20:23:30 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EC34CB.50703@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EC34CB.50703@gmail.com> Message-ID: <50EE1812.9040704@cs.oswego.edu> On further consideration... On 01/08/13 10:01, Peter Levart wrote: > - accumulate(long x) returns the post-modification value of the modified cell or > base (the returned value of the function that was used to update the state) > - the accumulator function is always called for initial allocations of cells > (with identity value as 1st argument, like when accumulating on the base) - the > original code optimizes this situation and just installs the parameter x into > the cell. > ... I'm no longer seeing a reason to support this kind of use, even with "protected" methods. The particular cells used, even for a particular thread, can and do change over time, so returning the pre-accumulate value for the cell used means only "this was at some moment a partial accumulation value". The next one returned after another call might be completely unrelated. The only possible uses I can imagine, for example a not-at-all random progress sampling mechanism, can be done in better ways. And as you showed, while you could make a sort of RNG out of it, it is not competitive with ThreadLocalRandom, and has unknowable statistical properties. So for now anyway, I don't plan on doing this. Thanks for the opportunity to do these thought experiments though :-) -Doug From mandy.chung at oracle.com Thu Jan 10 01:25:03 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Jan 2013 17:25:03 -0800 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50E9FEDB.8050800@oracle.com> References: <50E9FEDB.8050800@oracle.com> Message-ID: <50EE186F.2070602@oracle.com> On 1/6/2013 2:46 PM, David Holmes wrote: > > http://cr.openjdk.java.net/~dholmes/8005232/webrev/ This looks good to me. David - besides the footprint performance data, do you observe any performance difference in your performance testing (I think refworkload is what you ran)? On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: > On 01/09/2013 05:04 PM, Peter Levart wrote: > >> Strictly speaking, CAS is actually not needed here. Since we keep >> classRedefinedCount snapshot inside the ReflectionData, any races that >> would install "older" ReflectionData over "newer", would be quickly >> caught at next invocation to reflectionData(). So if there are any >> objections to usage of Unsafe, it can be removed and replaced by simple >> volatile write. >> > Yes, I think that would be more clear without any adverse impacts on > performance. Also, that better expresses the intent of requiring the > visibility, not the atomicity of cache update. I agree with Alekesey that it'd be simpler and clearer if CAS is replaced with the simple volatile write. But this change will require another round of performance measurement to determine its impact. I'd suggest to follow up this cleanup in a separate bug and changeset. Mandy From martinrb at google.com Thu Jan 10 01:26:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 9 Jan 2013 17:26:23 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EE1289.40906@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EE1289.40906@oracle.com> Message-ID: Well, if this is the behavior you can expect from Windows, carry on! But how can anyone get reliable behavior if a file delete can fail capriciously in two dimensions - it might be "in use" , or it might be an already deleted ghost? I'm not claiming to be a reviewer for this change. On Wed, Jan 9, 2013 at 4:59 PM, Stuart Marks wrote: > On 1/9/13 11:33 AM, Martin Buchholz wrote: > >> On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish wrote: >> >>> >>> I'm in the process of adding deletion retry behavior to jtreg, but in the >>> meantime we think it makes sense to provide a more stable test >>> environment >>> by simply getting rid of the redundant deletes by the test itself. There >>> really is no need for tests to delete files from the scratch directory at >>> the end of a test because jtreg carries a guarantee of cleanup. >>> >>> >> I consider it good practice for a test to delete temporary files - it's >> just a java program that might be run outside of the test harness. >> > > Hi Martin, > > In general it indeed is a good practice for things to clean up after > themselves, but there are several different considerations. > > I was talking about this issue with Jon Gibbons, and he mentioned that > it's often a good idea for tests to leave around files for diagnostic > purposes, in case they fail, or in case they succeed unexpectedly. Tests > cleaning up after themselves potentially destroys that information. That's > why jtreg has the -retain option, that controls when (beginning of next > test run, end of this test run), and under what circumstances (success, > failure, error) the test's scratch files are removed. > > We're also moving toward an environment where we're running the test suite > much more intensively than before, on all the platforms. Thus the tests are > being run from jtreg very frequently, and while it's convenient for them to > be invoked as standalone programs (outside the test harness) this is > becoming relatively rare. Having options in the test to support the latter > case is fine, but I think that running tests from jtreg needs to be > considered the default case, and thus modify things to allow jtreg to > determine the policy for file deletion/retention. > > > Perhaps there's a deeper problem - why does the file system present >> inconsistent views? Is it a Windows bug? >> > > Jim answered this already, but I wanted to add that we've run into this > problem before. See here for example: > > http://mail.openjdk.java.net/**pipermail/core-libs-dev/2012-** > December/012761.html > > This is with the Arrrghs test (which I'm sure you're familiar with). I > guess it's a question of whether the file system is behaving > inconsistently. From a Unix point of view asynchronous deletes are > inconsistent, but on Windows this is apparently perfectly normal behavior. > :-) > > s'marks > From david.holmes at oracle.com Thu Jan 10 03:24:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2013 13:24:20 +1000 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED4ED9.60102@oracle.com> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> Message-ID: <50EE3464.1070304@oracle.com> On 9/01/2013 9:04 PM, Aleksey Shipilev wrote: > Thanks, David. > > On 01/09/2013 02:55 PM, David Holmes wrote: >> Not sure where this is now but FYI you needed two CRs for this: one for >> hotspot and one for the JDK. They have different target versions (hs25 >> vs 8) and depending on the path you use to integrate could end up in >> different builds - hence distinct CRs for accurate tracking purposes. > > Too late, since these are already committed? I can submit another CR if > we need that. I'll fix it up - it is easier to do than explain. :) As it is, the fact these both went in through hotspot repo at least means they appeared in jdk8/jdk8 at the same time. >> I have a concern that the Long versions of these methods may be used >> directly without there being any check for supports_cx8 > > I actually have the question about this. What is the usual pattern for > using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe > directly without the checks. AtomicLongFieldUpdater does the checks. > Something is fishy about this whole thing. I had forgotten at what levels this operates too. As I think is now clear(er) there is a Java level check (and fallback to locks) for the AtomicLongFieldUpdater based on supports_cx8. Then there are further checks of supports_cx8 in unsafe.cpp. Critically in Unsafe_CompareAndSwapLong. (Still needed on some platforms) Also note that Unsafe_get/setLongVolatile are also gated, unnecessarily, on supports_cx8. We have to have atomic 64-bit read/write for direct Java volatile accesses anyway. There's also an open CR to define supports_atomic_long_ops so that supports_cx8 is only used for the CAS, where it is needed, rather than simple read/write ops. David ----- > > I think this one tries to explain something, but I fail to grasp the intent: > > /** > * Records whether the underlying JVM supports lockless > * compareAndSwap for longs. While the Unsafe.compareAndSwapLong > * method works in either case, some constructions should be > * handled at Java level to avoid locking user-visible locks. > */ > static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8(); > > Doug? > > -Aleksey. > From joe.darcy at oracle.com Thu Jan 10 04:03:14 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Jan 2013 04:03:14 +0000 Subject: hg: jdk8/tl/langtools: 8004730: Add language model support for parameter reflection Message-ID: <20130110040316.EE49E47166@hg.openjdk.java.net> Changeset: 7612fe48be90 Author: darcy Date: 2013-01-09 20:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7612fe48be90 8004730: Add language model support for parameter reflection Reviewed-by: abuckley ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java From joe.darcy at oracle.com Thu Jan 10 04:20:30 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Jan 2013 04:20:30 +0000 Subject: hg: jdk8/tl/jdk: 8005713: Simplify library support for repeating annotations in java.lang.annotation Message-ID: <20130110042043.518CA47167@hg.openjdk.java.net> Changeset: 4176e6cc499e Author: darcy Date: 2013-01-09 20:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4176e6cc499e 8005713: Simplify library support for repeating annotations in java.lang.annotation Reviewed-by: abuckley + src/share/classes/java/lang/annotation/Repeatable.java From stuart.marks at oracle.com Thu Jan 10 05:40:27 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 09 Jan 2013 21:40:27 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: References: <50EDBBAB.7000500@oracle.com> <50EE1289.40906@oracle.com> Message-ID: <50EE544B.10904@oracle.com> On 1/9/13 5:26 PM, Martin Buchholz wrote: > Well, if this is the behavior you can expect from Windows, carry on! > > But how can anyone get reliable behavior if a file delete can fail capriciously > in two dimensions - it might be "in use" , or it might be an already deleted ghost? In other words, how can anyone ever get any work done on Windows? That is an excellent question, one for which I do not have the answer. :-) I think the practical answer is that everybody puts up with it and tries to come up with hacky workarounds. For example, the Mercurial developers have run into this; see [1] and the links at the bottom of that page. They ended up with a policy of first renaming the file to a random name, retrying 10 times if necessary. Then they try to unlink. If at that point the unlink fails, they try to remove the READONLY attribute and retry. If the unlink still fails, they give up. See win32.unlink at line 344 in [2]. There is the inevitable stackoverflow page [3]. They basically ended up with something similar, renaming before deleting, although it's amusing that using GetTempFileName() creates a uniquely named temp file, which must be deleted before something can be renamed onto it, oh wait.... And then there is the rant at [4] which points the accusing finger at the Windows Application Experience server (same as DeHaven in his analysis of the Arrrghs fix), which also mentions the terrible consequences if you decide to disable this service in a vain attempt to speed up your system. I envision a task for someone in the near future of writing a rename-to-random-filename-then-delete utility function in Java (similar to Mercurial's win32.unlink) and converting the tests to use it. Maybe we should consider changing File.delete() and Files.delete() to do this by default on Windows... urgghhhh.... s'marks [1] http://mercurial.selenic.com/wiki/UnlinkingFilesOnWindows [2] http://selenic.com/hg/file/a4765077b65e/mercurial/win32.py [3] http://stackoverflow.com/questions/3764072/c-win32-how-to-wait-for-a-pending-delete-to-complete [4] http://www.retrocopy.com/blog/28/cant-delete-exe-files-in-vista--windows-7-solved.aspx From stuart.marks at oracle.com Thu Jan 10 05:41:49 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 09 Jan 2013 21:41:49 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EDBBAB.7000500@oracle.com> References: <50EDBBAB.7000500@oracle.com> Message-ID: <50EE549D.60606@oracle.com> On 1/9/13 10:49 AM, Jim Gish wrote: > Please review: > http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/ > > > Summary: this test, when run on Windows, fails intermittently because of > asynchronous windows deletes. The test passes, deletes two files that it has > created for the test in the scratch directory, and exits. Then, jtreg upon > attempting to cleanup after the test, tries to delete the files after doing a > listFiles() on the scratch directory, which despite the delete by the test > itself, still contains the files. The jtreg delete fails and jtreg changes the > state of the test from passed to failed. > > I'm in the process of adding deletion retry behavior to jtreg, but in the > meantime we think it makes sense to provide a more stable test environment by > simply getting rid of the redundant deletes by the test itself. There really > is no need for tests to delete files from the scratch directory at the end of a > test because jtreg carries a guarantee of cleanup. By the way, this fix looks fine to me. s'marks From youdwei at linux.vnet.ibm.com Thu Jan 10 05:49:44 2013 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 10 Jan 2013 13:49:44 +0800 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream In-Reply-To: References: <4FE81ED6.7020909@linux.vnet.ibm.com> <4FF16425.9070308@linux.vnet.ibm.com> <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com> <4FF533A4.80808@linux.vnet.ibm.com> <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com> <505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com> <508E3596.3070705@linux.vnet.ibm.com> <50AF2EBA.1050109@linux.vnet.ibm.com> Message-ID: <50EE5678.9090300@linux.vnet.ibm.com> Hi Lance, Is there any update for this issue. If you have anything I can do, please let me know. Thanks a lot! On 11/24/2012 12:45 AM, Lance Andersen - Oracle wrote: > It is on my list. to update the javadocs I need a ccc which I have > not done yet and is needed as part of this change > > On Nov 23, 2012, at 3:07 AM, Deven You wrote: > >> Hi Lance, >> >> Is there any plan for this issue, if any could you update to me? >> >> Thanks a lot! >> On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: >>> Hi Deven, >>> >>> I will address the needed updates a bit later. >>> >>> Thank you for your input >>> >>> Best >>> Lance >>> On Oct 29, 2012, at 3:51 AM, Deven You wrote: >>> >>>> Hi Alan, >>>> >>>> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. >>>> >>>> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method. >>>> >>>> Thanks for your suggestion for isFree, I will correct it later. >>>> >>>> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. >>>> >>>> Thanks a lot! >>>> >>>> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>>>> On 21/09/2012 04:21, Deven You wrote: >>>>>> Hi Lance, >>>>>> >>>>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. >>>>>> >>>>>> I have create a new webre[1] for this task, please review it. >>>>>> >>>>>> [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>>>> >>>>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? >>>>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. >>>>> >>>>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). >>>>> >>>>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. >>>>> >>>>> -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 >>> >> > > > 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 Thu Jan 10 06:23:50 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 09 Jan 2013 22:23:50 -0800 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EDE75B.4000308@oracle.com> References: <50EDE75B.4000308@oracle.com> Message-ID: <50EE5E76.9090008@oracle.com> Hi Eric, A few quick comments. In Executable, 228 /** 229 * Returns the number of formal parameters for the executable 230 * represented by this object. 231 * 232 * @return The number of formal parameters for the executable this 233 * object represents 234 */ 235 public abstract int getNumParameters(); I think it is important of the getNumParameters javadoc is clarified to state "... represented by this object, including any synthesized and synthetic parameters." In other words, the number of parameters of the VM view of the query and *not* (necessarily) the language view. Also in Executable, I think the body of 279 public Parameter[] getParameters() { 280 // TODO: This may eventually need to be guarded by security 281 // mechanisms similar to those in Field, Method, etc. 282 Parameter[] raw = privateGetParameters(); 283 Parameter[] out = new Parameter[raw.length]; 284 // Need to copy the cached array to prevent users from messing 285 // with it 286 for (int i = 0; i < raw.length; i++) { 287 out[i] = new Parameter(raw[i]); 288 } 289 return out; 290 } could be replaced with return privateGetParameters().clone(); IIRC, other parts of core reflection have similar calls to clone. I would prefer to see the getNumParameters method in Executable be declared to be non-abstract, but with a body that threw some kind of exception, even an abstract-method-error. Since only types within java.lang.reflect can subclass Executable, it is not generally extensible. Alternate implementations of java.lang.reflect should not be forced to not share a getNumParameters implementation from Executable. All the public methods and constructors in java.lang.reflect.Parameter need proper javadoc. I strongly recommend rewriting the tests in the style used, for example, here: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a1398021c7c where an annotation is used to record the expect result and then a simple checker loops over the reflective constructs and verifies that the computed values match the expected ones. The tests should include cases where the VM has a different notion of the number of parameter than the language; typical cases are constructors of inner classes (compiler is required to insert a leading other$this parameter) and constructors of enums (javac prepends two synthesized parameters). Cheers, -Joe On 01/09/2013 01:55 PM, Eric McCorkle wrote: > Hello, > > Please review the core reflection API implementation of parameter > reflection. This is the final component of method parameter reflection. > This was posted for review before, then delayed until the check-in for > JDK-8004728 (hotspot support for parameter reflection), which occurred > yesterday. > > Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* > jdk8/tl; therefore, it may be a while before the changeset makes its way > into jdk8/tl. > > Also note: since the check-in of JDK-8004727 (javac support for > parameter reflection), there has been a failure in the tests for > Pack200. This is being addressed in a fix contributed by Kumar, which I > believe has also been posted for review. > > The open webrev is here: > http://cr.openjdk.java.net/~coleenp/JDK-8004729 > > The feature request is here: > http://bugs.sun.com/view_bug.do?bug_id=8004729 > > The latest version of the spec can be found here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > > Thanks, > Eric From david.holmes at oracle.com Thu Jan 10 06:51:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2013 16:51:21 +1000 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50ED6041.90503@oracle.com> References: <50E9FEDB.8050800@oracle.com> <50ED6041.90503@oracle.com> Message-ID: <50EE64E9.8060606@oracle.com> Hi Aleksey, Thanks for the feedback. Let me prefix this by saying that time is of the essence here so unless there is a major issue things will go in as is, with follow ups for after M6 if needed. We can't miss M6 but we can tweak the initial changes after M6. On 9/01/2013 10:19 PM, Aleksey Shipilev wrote: > Good stuff. > > On 01/07/2013 02:46 AM, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/8005232/webrev/ > > Sorry for obnoxious first-time reviewer questions: No problem, I prepared suitably dismissive responses ;-) > a) I think the CAS loop in newReflectionData() is misleading in its > reuse of the parameters. Can we instead inline it? Or, can we read the > fields for $reflectionData and $classRedefinedCount, with no parameters > passed? As Peter commented this was out-lined for performance reasons. I can see your point over the reuse of the parameters as local variables but I don't have a problem with it. Arguably we save a couple of volatile field reads on the fastpath. > b) Had we considered filling up the complete ReflectionData eagerly on > first access? This will make ReflectionData completely final. I would > guess this goes against the per-use laziness? If we did that then every reflection using class would use more memory - which defeats the whole point of this memory reduction exercise. ??? > c) What's the merit of using Unsafe instead of field updaters here? > (Avoiding the dependency on j.u.c?) Yes, as Peter said, initialization order bites you. > d) I think the code can be further simplified if we stick with > reflectionData() returning non-null object all the time, and check for > useCaches instead in the usages, at the expense of creating the methods > which actually get the reflection data. I'm not quite sure what you mean, but assuming these are just stylistically different, there's no real motivation to make such a change. > e) Should useCaches be final? That will allow aggressive optimizations > for (c). It can't be final as it is controlled via a property query that can't be run during static initialization. >> This is a saving of 7 reference fields ie. 28 bytes, resulting in a new >> Class instance size of 80 bytes. This saves a further 4 bytes due to the >> fields being 8-byte aligned without any need for padding. So overall we >> save 32 bytes per class instance. > > Shameless promotion follows. This tool [1] should help to estimate the > class layout in the face of object alignment, compressed references, > paddings, alignment and whatnot. I plan to take a look at this tool sometime - I promise. :) Thanks, David > -Aleksey. > > [1] https://github.com/shipilev/java-object-layout/ > From david.holmes at oracle.com Thu Jan 10 06:59:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2013 16:59:08 +1000 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50EE186F.2070602@oracle.com> References: <50E9FEDB.8050800@oracle.com> <50EE186F.2070602@oracle.com> Message-ID: <50EE66BC.9080304@oracle.com> Hi Mandy, Thanks for the review. On 10/01/2013 11:25 AM, Mandy Chung wrote: > On 1/6/2013 2:46 PM, David Holmes wrote: >> >> http://cr.openjdk.java.net/~dholmes/8005232/webrev/ > > This looks good to me. David - besides the footprint performance data, > do you observe any performance difference in your performance testing > (I think refworkload is what you ran)? I added the performance numbers to the bug report: https://jbs.oracle.com/bugs/browse/JDK-8005232 No observable performance differences with refworkload. > > On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: >> On 01/09/2013 05:04 PM, Peter Levart wrote: >> >>> Strictly speaking, CAS is actually not needed here. Since we keep >>> classRedefinedCount snapshot inside the ReflectionData, any races that >>> would install "older" ReflectionData over "newer", would be quickly >>> caught at next invocation to reflectionData(). So if there are any >>> objections to usage of Unsafe, it can be removed and replaced by simple >>> volatile write. >>> >> Yes, I think that would be more clear without any adverse impacts on >> performance. Also, that better expresses the intent of requiring the >> visibility, not the atomicity of cache update. > > I agree with Alekesey that it'd be simpler and clearer if CAS is replaced > with the simple volatile write. But this change will require another round > of performance measurement to determine its impact. I'd suggest to follow > up this cleanup in a separate bug and changeset. I'm not sure about the validity of changing from CAS to a simpe write - would need to think more deeply on it. But I agree with Mandy that the performance impact would need to be investigated. In the normal case it would be faster with no CAS but if there were "collisions" that might change. Anyway something to consider for a follow-up. Thanks again, David > Mandy From forax at univ-mlv.fr Thu Jan 10 08:45:10 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 Jan 2013 09:45:10 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EE5E76.9090008@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE5E76.9090008@oracle.com> Message-ID: <50EE7F96.4040304@univ-mlv.fr> On 01/10/2013 07:23 AM, Joe Darcy wrote: > Hi Eric, > > A few quick comments. In Executable, > > 228 /** > 229 * Returns the number of formal parameters for the executable > 230 * represented by this object. > 231 * > 232 * @return The number of formal parameters for the executable > this > 233 * object represents > 234 */ > 235 public abstract int getNumParameters(); > > I think it is important of the getNumParameters javadoc is clarified > to state "... represented by this object, including any synthesized > and synthetic parameters." In other words, the number of parameters > of the VM view of the query and *not* (necessarily) the language view. And please rename getNumParameters to getParameterCount, so all methods related to parameters starts with the same prefix. > > Also in Executable, I think the body of > > 279 public Parameter[] getParameters() { > 280 // TODO: This may eventually need to be guarded by security > 281 // mechanisms similar to those in Field, Method, etc. > 282 Parameter[] raw = privateGetParameters(); > 283 Parameter[] out = new Parameter[raw.length]; > 284 // Need to copy the cached array to prevent users from > messing > 285 // with it > 286 for (int i = 0; i < raw.length; i++) { > 287 out[i] = new Parameter(raw[i]); > 288 } > 289 return out; > 290 } > > could be replaced with > > return privateGetParameters().clone(); > > IIRC, other parts of core reflection have similar calls to clone. yes, and the copy constructor in Parameter is not needed (we are in Java after all, not in C++). Also null == foo is not a standard idiom in Java because there is no operator overloading (likewise i++ doesn't need to be replaced by ++i). > > I would prefer to see the getNumParameters method in Executable be > declared to be non-abstract, but with a body that threw some kind of > exception, even an abstract-method-error. Since only types within > java.lang.reflect can subclass Executable, it is not generally > extensible. Alternate implementations of java.lang.reflect should not > be forced to not share a getNumParameters implementation from Executable. yes ! > > All the public methods and constructors in java.lang.reflect.Parameter > need proper javadoc. > > I strongly recommend rewriting the tests in the style used, for > example, here: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a1398021c7c > > where an annotation is used to record the expect result and then a > simple checker loops over the reflective constructs and verifies that > the computed values match the expected ones. > > The tests should include cases where the VM has a different notion of > the number of parameter than the language; typical cases are > constructors of inner classes (compiler is required to insert a > leading other$this parameter) and constructors of enums (javac > prepends two synthesized parameters). > > Cheers, > > -Joe cheers, R?mi > > On 01/09/2013 01:55 PM, Eric McCorkle wrote: >> Hello, >> >> Please review the core reflection API implementation of parameter >> reflection. This is the final component of method parameter reflection. >> This was posted for review before, then delayed until the check-in for >> JDK-8004728 (hotspot support for parameter reflection), which occurred >> yesterday. >> >> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >> jdk8/tl; therefore, it may be a while before the changeset makes its way >> into jdk8/tl. >> >> Also note: since the check-in of JDK-8004727 (javac support for >> parameter reflection), there has been a failure in the tests for >> Pack200. This is being addressed in a fix contributed by Kumar, which I >> believe has also been posted for review. >> >> The open webrev is here: >> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >> >> The feature request is here: >> http://bugs.sun.com/view_bug.do?bug_id=8004729 >> >> The latest version of the spec can be found here: >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> >> Thanks, >> Eric > From paul.sandoz at oracle.com Thu Jan 10 09:13:28 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Jan 2013 10:13:28 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EDE75B.4000308@oracle.com> References: <50EDE75B.4000308@oracle.com> Message-ID: <30C2E67D-E4D3-458C-A9AB-A616227859AB@oracle.com> Hi Eric, In Parameter.java: -- 31 public final class Parameter implements AnnotatedElement { 32 33 private String name; 34 private int modifiers; 35 private Executable executable; 36 private int index; 37 Can all the above fields be marked as final? -- 172 public T getDeclaredAnnotation(Class annotationClass) { 173 if (annotationClass == null) 174 throw new NullPointerException(); Objects.requireNonNull(annotationClass); -- 179 public T getDeclaredAnnotations(Class annotationClass) { 202 public T getAnnotations(Class annotationClass) { Should return T[] i presume. Likewise the spec needs to be updated on page 25. Paul. On Jan 9, 2013, at 10:55 PM, Eric McCorkle wrote: > Hello, > > Please review the core reflection API implementation of parameter > reflection. This is the final component of method parameter reflection. > This was posted for review before, then delayed until the check-in for > JDK-8004728 (hotspot support for parameter reflection), which occurred > yesterday. > > Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* > jdk8/tl; therefore, it may be a while before the changeset makes its way > into jdk8/tl. > > Also note: since the check-in of JDK-8004727 (javac support for > parameter reflection), there has been a failure in the tests for > Pack200. This is being addressed in a fix contributed by Kumar, which I > believe has also been posted for review. > > The open webrev is here: > http://cr.openjdk.java.net/~coleenp/JDK-8004729 > > The feature request is here: > http://bugs.sun.com/view_bug.do?bug_id=8004729 > > The latest version of the spec can be found here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > > Thanks, > Eric From peter.levart at gmail.com Thu Jan 10 09:19:08 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jan 2013 10:19:08 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EDE75B.4000308@oracle.com> References: <50EDE75B.4000308@oracle.com> Message-ID: <50EE878C.2040707@gmail.com> Hello Eric, You must have missed my comment from the previous webrev: 292 private Parameter[] privateGetParameters() { 293 if (null != parameters) 294 return parameters.get(); If/when the 'parameters' SoftReference is cleared, the method will be returning null forever after... You should also retrieve the referent and check for it's presence before returning it: Parameter[] res; if (parameters != null && (res = parameters.get()) != null) return res; ... ... Regards, Peter On 01/09/2013 10:55 PM, Eric McCorkle wrote: > Hello, > > Please review the core reflection API implementation of parameter > reflection. This is the final component of method parameter reflection. > This was posted for review before, then delayed until the check-in for > JDK-8004728 (hotspot support for parameter reflection), which occurred > yesterday. > > Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* > jdk8/tl; therefore, it may be a while before the changeset makes its way > into jdk8/tl. > > Also note: since the check-in of JDK-8004727 (javac support for > parameter reflection), there has been a failure in the tests for > Pack200. This is being addressed in a fix contributed by Kumar, which I > believe has also been posted for review. > > The open webrev is here: > http://cr.openjdk.java.net/~coleenp/JDK-8004729 > > The feature request is here: > http://bugs.sun.com/view_bug.do?bug_id=8004729 > > The latest version of the spec can be found here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > > Thanks, > Eric From fweimer at redhat.com Thu Jan 10 09:23:47 2013 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 10 Jan 2013 10:23:47 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50EC8E7B.807@oracle.com> References: <50EC8E7B.807@oracle.com> Message-ID: <50EE88A3.7050301@redhat.com> On 01/08/2013 10:24 PM, Joe Darcy wrote: > As discussed over on one of the Project Lambda lists [1], we're adding > an interface type to the platform to explicitly mark interface types as > being functional interfaces suitable for use in lambda expressions. > Please review the addition of this new type: > > http://cr.openjdk.java.net/~darcy/8005298.0/ Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), similar to the @Override annotation? -- Florian Weimer / Red Hat Product Security Team From peter.levart at gmail.com Thu Jan 10 09:53:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jan 2013 10:53:24 +0100 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50EE186F.2070602@oracle.com> References: <50E9FEDB.8050800@oracle.com> <50EE186F.2070602@oracle.com> Message-ID: <50EE8F94.6050103@gmail.com> On 01/10/2013 02:25 AM, Mandy Chung wrote: > On 1/6/2013 2:46 PM, David Holmes wrote: >> >> http://cr.openjdk.java.net/~dholmes/8005232/webrev/ > > This looks good to me. David - besides the footprint performance data, > do you observe any performance difference in your performance testing > (I think refworkload is what you ran)? > > On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: >> On 01/09/2013 05:04 PM, Peter Levart wrote: >> >>> Strictly speaking, CAS is actually not needed here. Since we keep >>> classRedefinedCount snapshot inside the ReflectionData, any races that >>> would install "older" ReflectionData over "newer", would be quickly >>> caught at next invocation to reflectionData(). So if there are any >>> objections to usage of Unsafe, it can be removed and replaced by simple >>> volatile write. >>> >> Yes, I think that would be more clear without any adverse impacts on >> performance. Also, that better expresses the intent of requiring the >> visibility, not the atomicity of cache update. > > I agree with Alekesey that it'd be simpler and clearer if CAS is replaced > with the simple volatile write. But this change will require another > round > of performance measurement to determine its impact. I'd suggest to > follow > up this cleanup in a separate bug and changeset. > > Mandy FWIW, I ran my micro benchmarks with the variant of using simple volatile write instead of CAS and there was no visible differences. But I don't have access to 256 core machines ;-). Anyway I think It should not present any performance difference, since the rate of class re-definitions is usually not very high... Although the slow-path is a simple as: this.reflectionData = new SoftReference<>(rd = new ReflectionData<>(classRedefinitionCount)); return rd; ... I had to split this too into a separate method to retain the same inlienability. Such fine-tunnings tend to be lost in other sub-optimalities of the code that implements public reflection API, such as copying the arrays and array elements in bulk-returning methods and linear searches for the elements in single-element returning methods... There is another simplification of code possible. The method checkInited() and its usages could be removed and it's logic incorporated into the slow-path newReflectionData() method while adding another boolean variable test into the fast-path. Regards, Peter From chris.hegarty at oracle.com Thu Jan 10 10:01:24 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2013 10:01:24 +0000 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EE1289.40906@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EE1289.40906@oracle.com> Message-ID: <50EE9174.2090107@oracle.com> On 01/10/2013 12:59 AM, Stuart Marks wrote: > On 1/9/13 11:33 AM, Martin Buchholz wrote: >> On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish wrote: >>> >>> I'm in the process of adding deletion retry behavior to jtreg, but in >>> the >>> meantime we think it makes sense to provide a more stable test >>> environment >>> by simply getting rid of the redundant deletes by the test itself. >>> There >>> really is no need for tests to delete files from the scratch >>> directory at >>> the end of a test because jtreg carries a guarantee of cleanup. >>> >> >> I consider it good practice for a test to delete temporary files - it's >> just a java program that might be run outside of the test harness. I'm in favor of tests cleaning up after themselves too, but am sympathetic to this issue ( I've seen this test fail too many times! ). > I'm in the process of adding deletion retry behavior to jtreg, but in > the meantime we think it makes sense to provide a more stable test I guess you could call these changes a "workaround" to the issue with the jtreg harness. Once Jim adds "deletion retry behavior" to jtreg these changes can be reverted, and the test can go back to being a good standalone citizen, right? If so, I agree with the changes. -Chris. From Alan.Bateman at oracle.com Thu Jan 10 11:34:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jan 2013 11:34:10 +0000 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EDC933.6010303@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EDC933.6010303@oracle.com> Message-ID: <50EEA732.4040101@oracle.com> On 09/01/2013 19:46, Jim Gish wrote: > It's a Windows feature. We discovered this recently in debugging > another test failure. Windows is documented to do asynchronous > deletes. You can't depend on a file.delete() which returns true to > have actually deleted the file. It may be the case that another > process has a file handle which it has not yet released, or it's > simply a delay. I don't get this, the issue sounds more like AV software or Windows application quality service/agent thing accessing the file but I might be wrong of course. Are you able to duplicate this reliably and if so, have you looked at it with any tools to see what/who is accessing it that is causing the delay? -Alan. From peter.levart at gmail.com Thu Jan 10 11:40:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jan 2013 12:40:57 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EE1812.9040704@cs.oswego.edu> References: <50E86CAC.8090606@oracle.com> <50EC34CB.50703@gmail.com> <50EE1812.9040704@cs.oswego.edu> Message-ID: <50EEA8C9.2070707@gmail.com> On 01/10/2013 02:23 AM, Doug Lea wrote: > On further consideration... > > On 01/08/13 10:01, Peter Levart wrote: > >> - accumulate(long x) returns the post-modification value of the >> modified cell or >> base (the returned value of the function that was used to update the >> state) >> - the accumulator function is always called for initial allocations >> of cells >> (with identity value as 1st argument, like when accumulating on the >> base) - the >> original code optimizes this situation and just installs the >> parameter x into >> the cell. >> > > ... I'm no longer seeing a reason to support this kind of use, > even with "protected" methods. > The particular cells used, even for a particular thread, can > and do change over time, so returning the pre-accumulate value for the > cell used means only "this was at some moment a partial accumulation > value". The next one returned after another call might be completely > unrelated. The only possible uses I can imagine, for example a > not-at-all random progress sampling mechanism, can be done in > better ways. And as you showed, while you could make a sort of > RNG out of it, it is not competitive with ThreadLocalRandom, > and has unknowable statistical properties. > So for now anyway, I don't plan on doing this. Another use could be a unique identifier generator. But all that is possible with ThreadLocal also... > > Thanks for the opportunity to do these thought experiments though :-) A related question: What do you think of a variant of [Double|Long]Adder.sumThenReset like the following: /** * Like {@link #sumThenReset()}, but with a guarantee that this adder's amount * is decreased by the same exact amount that was returned. Invoking this method * during frequent concurrent updates can disturb concurrent threads slightly, * so it is not advisable to call it very frequently... */ public long drain() { Cell[] as = cells; Cell a; long sum = gasBase(0L); if (as != null) { for (int i = 0; i < as.length; ++i) { if ((a = as[i]) != null) { sum += a.gas(0L); } } } return sum; } with the following additions in Striped64, using new Unsafe intrinsics: final long gasBase(long val) { return UNSAFE.getAndSetLong(this, BASE, val); } static final class Cell { ... final long gas(long val) { return UNSAFE.getAndSetLong(this, valueOffset, val); } Regards, Peter > > -Doug > From scolebourne at joda.org Thu Jan 10 11:47:57 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 10 Jan 2013 11:47:57 +0000 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent In-Reply-To: References: <50EDF350.7050302@oracle.com> Message-ID: I would encourage null checking to be done first, rather than sometimes getting StringIndexOutOfBoundsException for a null input. Reasoning about the JDK methods is much easier that way around. Stephen On 9 January 2013 23:09, Mike Duigou wrote: > AbstractStringBuilder probably needs the "Unless otherwise noted," blanket statement as well (Same as StringBuffer/StringBuilder) > > You might want to move the Objects.requireNonNull(dst); in String.getBytes() to after the existing checks so as not to unnecessarily change the exception thrown for bad inputs. An exception will still be thrown but some bad code may anticipate StringIndexOutOfBoundsException rather than NPE. This is a very minor matter though. > > Otherwise, it looks good. > > Mike > > On Jan 9 2013, at 14:46 , Jim Gish wrote: > >> Please review the following: >> >> Webrev: http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ >> Here's a specdiff: http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ >> >> >> Summary: This change replaces java/lang/*String*.java javadoc, method-specific @throws NullPointerException clauses with blanket null-handling statements like that currently in String.java >> >> That was motivated by a discussion awhile back, strongly favoring a blanket statement over individual @throws clauses. >> >> For String, the following blanket statement is already in place: >> >> *

Unless otherwise noted, passing a null argument to a constructor >> * or method in this class will cause a {@link NullPointerException} to be >> * thrown. >> >> >> However, despite the blanket statement, the following methods also have @throws clauses: >> >> public boolean contains(java.lang.CharSequence s) >> >> Throws: >> |java.lang.NullPointerException|- if|s|is|null| >> --------------------------------------------------------------- >> >> public staticString format(String format, >> java.lang.Object... args) >> >> >> Throws: >> |java.lang.NullPointerException|- If the|format|is|null >> |----------------------------------------------------------------------- >> || >> >> public staticString format(java.util.Locale l, >> String format, >> java.lang.Object... args) >> >> Throws: >> |java.lang.NullPointerException|- If the|format|is|null >> |-------------------------------------------------------------------------- >> All of the above are properly specified with the blanket statement or other parts of their spec (such as format w.r.t. null Locale) and the @throws can safely be removed. >> >> Because the blanket statement is already in effect for String.java, I wrote tests for all methods/constructors to ensure compliance. Running them revealed the following: >> >> public void getBytes(int srcBegin, int srcEnd, byte dst[], int dstBegin) >> - I would expect an NPE to be thrown if dst == null. However, this isn't always the case. If dst isn't accessed because of the values of the other parameters (as in getBytes(1,2,(byte[]null,1), then no NPE is thrown. >> - This brings up the question as to the correctness of the blanket statement w.r.t. this method. I think this method (and others like it) should use Objects.requireNonNull(dst). (The correspoding method public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin), does always throw NPE for dst==null) >> >> All other methods/constructors in StringBuffer and StringBuilder either correctly state null-handling behavior that differs from the blanket statement or are correct w.r.t. the blanket statement. >> >> This has been reviewed by the JCK team. It will require CCC approval (because of the new blanket statement, and the fact that some of the existing methods were previously silent on null handling, but all already conform to the blanket statement). >> >> Thanks, >> Jim Gish >> >> >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com >> >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com >> > From Lance.Andersen at oracle.com Thu Jan 10 12:31:19 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 10 Jan 2013 07:31:19 -0500 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream In-Reply-To: <50EE5678.9090300@linux.vnet.ibm.com> References: <4FE81ED6.7020909@linux.vnet.ibm.com> <4FF16425.9070308@linux.vnet.ibm.com> <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com> <4FF533A4.80808@linux.vnet.ibm.com> <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com> <505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com> <508E3596.3070705@linux.vnet.ibm.com> <50AF2EBA.1050109@linux.vnet.ibm.com> <50EE5678.9090300@linux.vnet.ibm.com> Message-ID: <9ED51030-5EFB-445A-A9AD-CDAF1CA31F73@oracle.com> Deven, This was pushed a while ago you should have seen the putback on the alias See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8978a5bb6e Best Lance On Jan 10, 2013, at 12:49 AM, Deven You wrote: > Hi Lance, > > Is there any update for this issue. If you have anything I can do, please let me know. > > Thanks a lot! > On 11/24/2012 12:45 AM, Lance Andersen - Oracle wrote: >> It is on my list. to update the javadocs I need a ccc which I have not done yet and is needed as part of this change >> >> On Nov 23, 2012, at 3:07 AM, Deven You wrote: >> >>> Hi Lance, >>> >>> Is there any plan for this issue, if any could you update to me? >>> >>> Thanks a lot! >>> On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: >>>> Hi Deven, >>>> >>>> I will address the needed updates a bit later. >>>> >>>> Thank you for your input >>>> >>>> Best >>>> Lance >>>> On Oct 29, 2012, at 3:51 AM, Deven You wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. >>>>> >>>>> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method. >>>>> >>>>> Thanks for your suggestion for isFree, I will correct it later. >>>>> >>>>> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. >>>>> >>>>> Thanks a lot! >>>>> >>>>> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>>>>> On 21/09/2012 04:21, Deven You wrote: >>>>>>> Hi Lance, >>>>>>> >>>>>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. >>>>>>> >>>>>>> I have create a new webre[1] for this task, please review it. >>>>>>> >>>>>>> [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>>>>> >>>>>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? >>>>>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. >>>>>> >>>>>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). >>>>>> >>>>>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. >>>>>> >>>>>> -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 >>>> >>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From aleksey.shipilev at oracle.com Thu Jan 10 12:50:56 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 16:50:56 +0400 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> Message-ID: <50EEB930.1090005@oracle.com> On 01/09/2013 09:51 PM, Steven Schlansker wrote: > Hello again, > > I sent this email a week ago and have received no replies. Is there > any step I have missed necessary to contribute to the JDK libraries? I think the crucial part is OCA, as per: http://openjdk.java.net/contribute/ > I am very interested in making your lives easier, so please let me > know if I am in the wrong place or are otherwise misguided. You are at the correct place. On the first glance, the change looks good for the start. A few comments though: a) Do you need the masks before or-ing with most/leastSigBits? b) Is there a more standard (and still performant) way to do the hex conversion? Look around JDK source, I think there should be something else needing the same kind of conversion. c) I'd go for making utility methods a bit more generic. For one, I would rather make decodeHex(String str, int start, int end), and encodeHex(char[] dest, int offset, int value). Microbenchmark glitches: a) % is the integer division, and at the scale of the operations you are measuring, it could incur significant costs; the usual practice is having power-of-2 size, and then (i % size) -> (i & (size - 1)). b) Not sure if you want to stick with random UUIDs for comparisons. While the law of large numbers is on your side, 1000 random UUIDs might be not random enough. -Aleksey. From Alan.Bateman at oracle.com Thu Jan 10 13:14:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Jan 2013 13:14:54 +0000 Subject: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Message-ID: <50EEBECE.6030001@oracle.com> I'm currently trying to run the jdk tests on the compact profiles. As the profile builds are runtimes only, they don't have tools such as javac and so need to be run with both -jdk and -compilejdk. That works okay except for the shell tests because many of them launch the "javac" or "jar" tools directly and so fail because the runtime under test ($TESTJAVA) is not a JDK. I'd like to update the shell tests to use the tools in $COMPILEJAVA, this is the JDK specified to jtreg with -compilejdk or it's the same as $TESTJAVA when -compilejdk is not specified. The webrev with the proposed changes is here: http://cr.openjdk.java.net/~alanb/8005978/webrev/ For the most part this is just s/TESTJAVA/COMPILEJAVA/ although there are a couple of subtle things to watch out for - for example tool tests should be testing the tools in $TESTJAVA, not $COMPILEJAVA. Many of the shell tests were created to be runnable outside of jtreg so I've preserved this where it was previously supported. I should note that this is not all of the shell tests, I don't have time to fix the tests in areas that aren't interesting for the profiles so contributions to do more would be welcome. Another thing is that a lot of these shell tests are old tests and a lot of them don't really need to be shell tests. I mention this because another great effort would be be gradually replace many of these shell tests. -Alan. From youdwei at linux.vnet.ibm.com Thu Jan 10 13:24:38 2013 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Thu, 10 Jan 2013 21:24:38 +0800 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream In-Reply-To: <9ED51030-5EFB-445A-A9AD-CDAF1CA31F73@oracle.com> References: <4FE81ED6.7020909@linux.vnet.ibm.com> <4FF16425.9070308@linux.vnet.ibm.com> <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com> <4FF533A4.80808@linux.vnet.ibm.com> <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com> <505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com> <508E3596.3070705@linux.vnet.ibm.com> <50AF2EBA.1050109@linux.vnet.ibm.com> <50EE5678.9090300@linux.vnet.ibm.com> <9ED51030-5EFB-445A-A9AD-CDAF1CA31F73@oracle.com> Message-ID: <50EEC116.7080503@linux.vnet.ibm.com> Hi Lance, I am glad to see the patch for implementing these methods are committed. Do you have a plan to add the test cases[1] I created too? Thanks a lot! [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ On 01/10/2013 08:31 PM, Lance Andersen - Oracle wrote: > Deven, > > This was pushed a while ago you should have seen the putback on the alias > > See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8978a5bb6e > > Best > Lance > > > On Jan 10, 2013, at 12:49 AM, Deven You wrote: > >> Hi Lance, >> >> Is there any update for this issue. If you have anything I can do, >> please let me know. >> >> Thanks a lot! >> On 11/24/2012 12:45 AM, Lance Andersen - Oracle wrote: >>> It is on my list. to update the javadocs I need a ccc which I have >>> not done yet and is needed as part of this change >>> >>> On Nov 23, 2012, at 3:07 AM, Deven You wrote: >>> >>>> Hi Lance, >>>> >>>> Is there any plan for this issue, if any could you update to me? >>>> >>>> Thanks a lot! >>>> On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: >>>>> Hi Deven, >>>>> >>>>> I will address the needed updates a bit later. >>>>> >>>>> Thank you for your input >>>>> >>>>> Best >>>>> Lance >>>>> On Oct 29, 2012, at 3:51 AM, Deven You wrote: >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. >>>>>> >>>>>> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method. >>>>>> >>>>>> Thanks for your suggestion for isFree, I will correct it later. >>>>>> >>>>>> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>>> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>>>>>> On 21/09/2012 04:21, Deven You wrote: >>>>>>>> Hi Lance, >>>>>>>> >>>>>>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. >>>>>>>> >>>>>>>> I have create a new webre[1] for this task, please review it. >>>>>>>> >>>>>>>> [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>>>>>> >>>>>>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? >>>>>>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. >>>>>>> >>>>>>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). >>>>>>> >>>>>>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. >>>>>>> >>>>>>> -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 >>>>> >>>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >> > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Ulf.Zibis at CoSoCo.de Thu Jan 10 14:03:50 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 10 Jan 2013 15:03:50 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EE235B.2080301@oracle.com> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> <50EE0D6C.40503@oracle.com> <50EE235B.2080301@oracle.com> Message-ID: <50EECA46.7090308@CoSoCo.de> Am 10.01.2013 03:11, schrieb Vladimir Kozlov: > On 1/9/13 5:11 PM, Vitaly Davidovich wrote: >> One could write this as: >> boolean overflow = false; >> if (len > (dl - dp)) >> { >> overflow = true; >> len = dl - dp; >> } >> >> One would hope jit can do this automatically and also CSE away the dl - >> dp bit. :) > > Yes, JIT can convert Ulf's code into above code - SplitIf optimization in C2. Yes, this I was assuming too. But I think, the correct code would be: Alternative (3): boolean overflow; if (len > (dl - dp)) { overflow = true; len = dl - dp; } else overflow = false; This would avoid first assigning overflow = false and later reverting it to overflow = true; ...or is JIT able to optimize this? > But it could be complicated by surrounding code. Could one check this by hsdis ? Anyway I suspect if JIT will optimise this snippet in a reasonable time, because it is only executed once in encodeArrayLoop(), + the compile threshold is high, as method encodeArrayLoop() is long. So maybe we should focus on the best performance in interpreter for the 3 alternatives. My assumption, the following would win, as it avoids to calculate dl - dp 2 times: Alternative (4): int slen = sl - sp; int dlen = dl - dp; boolean overflow; if (slen > dlen) { overflow = true; slen = dlen; } else overflow = false; ... but maybe Alternative (5) is not far from that: int slen = sl - sp; int dlen = dl - dp; boolean overflow = slen > dlen; slen ? overflow = dlen : slen; In case, if JIT comes in effect, both should optimize optimal. Looking at the calculation of slen/dlen: int sp = src.arrayOffset() + src.position(); int sl = src.arrayOffset() + src.limit(); assert (sp <= sl); sp = (sp <= sl ? sp : sl); int slen = sl - sp; My suggestion: int slen = src.remaining(); // should never be negative, so above 2 time (sp <= sl) are superfluous! Additionally calculation of sl could be faster: int sl = sp + src.remaining(); which could be again faster and is equivalent to: int sl = sp + slen; if slen is anyway calculated before. Same for dlen, with on top, that dl is never used later 8-) , so could be completely dropped. About the naming: According to sp, sl, dp, dl I would prefer: sr, dr over (x)len. About overflow: There was a question some posts above, if it is necessary at all. Can one please answer? The question is, if other error results have higher priority over CoderResult.OVERFLOW. -Ulf > And generating only one dl-dp is regular optimization which JIT does. > > Thanks, > Vladimir > >> >> Sent from my phone >> >> On Jan 9, 2013 7:39 PM, "Vladimir Kozlov" > > wrote: >> >> From JIT compiler view current code is better since it has only one >> compare. Your code has two compares: one to calculate "overflow" and >> an other (depended on first) to calculate "len". >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:57 PM, Ulf Zibis wrote: >> >> Another little simplification: >> 179 boolean overflow = sr > dr; >> 180 sr = overflow ? dr : sr; >> or in your existing logic: >> 178 int len = sl - sp; >> 179 boolean overflow = len > (dl - dp); >> 180 len = overflow ? dl - dp : len; >> (len is equivalent to sr) >> >> -Ulf >> >> Am 09.01.2013 19:03, schrieb Vladimir Kozlov: >> >> Ulf, >> >> Thank you for this suggestion but I would like to keep >> surrounding >> code intact. I will rename "overflowflag" to "overflow". It >> is used to >> indicate that we should return CoderResult.OVERFLOW result. >> >> Thanks, >> Vladimir >> >> On 1/9/13 3:58 AM, Ulf Zibis wrote: >> >> Am 09.01.2013 01:10, schrieb Vitaly Davidovich: >> >> On Jan 8, 2013 6:18 PM, "Vladimir Kozlov" >> > > >> wrote: >> >> http://cr.openjdk.java.net/~**__kvn/6896617_jdk/webrev >> > > >> >> >> >> Another tweak: >> 168 char[] sa = src.array(); >> 169 int sp = src.arrayOffset() + >> src.position(); >> 170 int sr = src.remaining(); >> 171 int sl = sp + sr; >> 172 assert (sp <= sl); // superfluous, sr >> is always >= 0 >> 173 sp = (sp <= sl ? sp : sl); // >> superfluous " >> 174 byte[] da = dst.array(); >> 175 int dp = dst.arrayOffset() + >> dst.position(); >> 170 int dr = dst.remaining(); >> 176 int dl = dp + dr; >> 177 assert (dp <= dl); // superfluous " >> 178 dp = (dp <= dl ? dp : dl); // >> superfluous " >> 179 boolean overflow = false; >> 180 if (sr > dr) { >> 181 sr = dr; >> 182 overflow = true; >> 183 } >> >> Why you called it "overflowflag", in that way, you could >> name each >> variable "myvaluevariable" or "myvaluefield" ;-) >> >> >> -Ulf >> >> >> > From Lance.Andersen at oracle.com Thu Jan 10 15:36:22 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 10 Jan 2013 10:36:22 -0500 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream In-Reply-To: <50EEC116.7080503@linux.vnet.ibm.com> References: <4FE81ED6.7020909@linux.vnet.ibm.com> <4FF16425.9070308@linux.vnet.ibm.com> <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com> <4FF533A4.80808@linux.vnet.ibm.com> <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com> <505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com> <508E3596.3070705@linux.vnet.ibm.com> <50AF2EBA.1050109@linux.vnet.ibm.com> <50EE5678.9090300@linux.vnet.ibm.com> <9ED51030-5EFB-445A-A9AD-CDAF1CA31F73@oracle.com> <50EEC116.7080503@linux.vnet.ibm.com> Message-ID: <689933A6-46CC-4580-96BD-1011CC78A1C9@oracle.com> The JCK and RowSet TCK will have base tests to validate. I have a separate set of unit tests for JDBC which includes more detailed tests than what you had suggested as well as end to end tests. Best Lance On Jan 10, 2013, at 8:24 AM, Deven You wrote: > Hi Lance, > > I am glad to see the patch for implementing these methods are committed. > > Do you have a plan to add the test cases[1] I created too? > > Thanks a lot! > > [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ > > > On 01/10/2013 08:31 PM, Lance Andersen - Oracle wrote: >> Deven, >> >> This was pushed a while ago you should have seen the putback on the alias >> >> See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8978a5bb6e >> >> Best >> Lance >> >> >> On Jan 10, 2013, at 12:49 AM, Deven You wrote: >> >>> Hi Lance, >>> >>> Is there any update for this issue. If you have anything I can do, please let me know. >>> >>> Thanks a lot! >>> On 11/24/2012 12:45 AM, Lance Andersen - Oracle wrote: >>>> It is on my list. to update the javadocs I need a ccc which I have not done yet and is needed as part of this change >>>> >>>> On Nov 23, 2012, at 3:07 AM, Deven You wrote: >>>> >>>>> Hi Lance, >>>>> >>>>> Is there any plan for this issue, if any could you update to me? >>>>> >>>>> Thanks a lot! >>>>> On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: >>>>>> Hi Deven, >>>>>> >>>>>> I will address the needed updates a bit later. >>>>>> >>>>>> Thank you for your input >>>>>> >>>>>> Best >>>>>> Lance >>>>>> On Oct 29, 2012, at 3:51 AM, Deven You wrote: >>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. >>>>>>> >>>>>>> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method. >>>>>>> >>>>>>> Thanks for your suggestion for isFree, I will correct it later. >>>>>>> >>>>>>> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. >>>>>>> >>>>>>> Thanks a lot! >>>>>>> >>>>>>> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>>>>>>> On 21/09/2012 04:21, Deven You wrote: >>>>>>>>> Hi Lance, >>>>>>>>> >>>>>>>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. >>>>>>>>> >>>>>>>>> I have create a new webre[1] for this task, please review it. >>>>>>>>> >>>>>>>>> [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>>>>>>> >>>>>>>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? >>>>>>>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. >>>>>>>> >>>>>>>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). >>>>>>>> >>>>>>>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. >>>>>>>> >>>>>>>> -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 >>>>>> >>>>> >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> > -------------- 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 jim.gish at oracle.com Thu Jan 10 16:00:05 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 10 Jan 2013 11:00:05 -0500 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent In-Reply-To: References: <50EDF350.7050302@oracle.com> Message-ID: <50EEE585.6000800@oracle.com> Stephen, Currently here's (a sampling) of how the other methods work. Although most check indices first, not all do... (The original bug was about this very inconsistency, however one answer given to it was that in general we don't say anything about order of exceptions). However, given that most of the methods do index checking first, I think I agree with Mike on this one. Jim getChars(int srcBegin, int srcEnd, char[]dst, int dstBegin) - will check for srcBegin, srcEnd first and throw StringIndexOutOfBoundsException - then System.arraycopy checks for null and throws NPE replace(int start, int end, String str) - same as above (checking start and end first) insert(int index, char[] str, int offset, int len) - same as above (checking index and offset first) insert(int offset, char[] str) - same (checking offset first) String(char value[], int offset, int count) - same String(int[] codePoints, int offset, int count) - same String(byte ascii[], int hibyte, int offset, int count) - same String(byte bytes[], int offset, int length, String charsetName) - same * String(byte bytes[], int offset, int length, Charset charset) - checks charset == null first! - then checks offset and length - and then checks bytes==null String.getChars(char dst[], int dstBegin) - checks for dst==null first - then for bad and throw ArrayIndexOutOfBoundsException On 01/10/2013 06:47 AM, Stephen Colebourne wrote: > I would encourage null checking to be done first, rather than > sometimes getting StringIndexOutOfBoundsException for a null input. > Reasoning about the JDK methods is much easier that way around. > > Stephen > > > On 9 January 2013 23:09, Mike Duigou wrote: >> AbstractStringBuilder probably needs the "Unless otherwise noted," blanket statement as well (Same as StringBuffer/StringBuilder) >> >> You might want to move the Objects.requireNonNull(dst); in String.getBytes() to after the existing checks so as not to unnecessarily change the exception thrown for bad inputs. An exception will still be thrown but some bad code may anticipate StringIndexOutOfBoundsException rather than NPE. This is a very minor matter though. >> >> Otherwise, it looks good. >> >> Mike >> >> On Jan 9 2013, at 14:46 , Jim Gish wrote: >> >>> Please review the following: >>> >>> Webrev: http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ >>> Here's a specdiff: http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ >>> >>> >>> Summary: This change replaces java/lang/*String*.java javadoc, method-specific @throws NullPointerException clauses with blanket null-handling statements like that currently in String.java >>> >>> That was motivated by a discussion awhile back, strongly favoring a blanket statement over individual @throws clauses. >>> >>> For String, the following blanket statement is already in place: >>> >>> *

Unless otherwise noted, passing a null argument to a constructor >>> * or method in this class will cause a {@link NullPointerException} to be >>> * thrown. >>> >>> >>> However, despite the blanket statement, the following methods also have @throws clauses: >>> >>> public boolean contains(java.lang.CharSequence s) >>> >>> Throws: >>> |java.lang.NullPointerException|- if|s|is|null| >>> --------------------------------------------------------------- >>> >>> public staticString format(String format, >>> java.lang.Object... args) >>> >>> >>> Throws: >>> |java.lang.NullPointerException|- If the|format|is|null >>> |----------------------------------------------------------------------- >>> || >>> >>> public staticString format(java.util.Locale l, >>> String format, >>> java.lang.Object... args) >>> >>> Throws: >>> |java.lang.NullPointerException|- If the|format|is|null >>> |-------------------------------------------------------------------------- >>> All of the above are properly specified with the blanket statement or other parts of their spec (such as format w.r.t. null Locale) and the @throws can safely be removed. >>> >>> Because the blanket statement is already in effect for String.java, I wrote tests for all methods/constructors to ensure compliance. Running them revealed the following: >>> >>> public void getBytes(int srcBegin, int srcEnd, byte dst[], int dstBegin) >>> - I would expect an NPE to be thrown if dst == null. However, this isn't always the case. If dst isn't accessed because of the values of the other parameters (as in getBytes(1,2,(byte[]null,1), then no NPE is thrown. >>> - This brings up the question as to the correctness of the blanket statement w.r.t. this method. I think this method (and others like it) should use Objects.requireNonNull(dst). (The correspoding method public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin), does always throw NPE for dst==null) >>> >>> All other methods/constructors in StringBuffer and StringBuilder either correctly state null-handling behavior that differs from the blanket statement or are correct w.r.t. the blanket statement. >>> >>> This has been reviewed by the JCK team. It will require CCC approval (because of the new blanket statement, and the fact that some of the existing methods were previously silent on null handling, but all already conform to the blanket statement). >>> >>> Thanks, >>> Jim Gish >>> >>> >>> -- >>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>> Oracle Java Platform Group | Core Libraries Team >>> 35 Network Drive >>> Burlington, MA 01803 >>> jim.gish at oracle.com >>> >>> -- >>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>> Oracle Java Platform Group | Core Libraries Team >>> 35 Network Drive >>> Burlington, MA 01803 >>> jim.gish at oracle.com >>> -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From jim.gish at oracle.com Thu Jan 10 16:14:13 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 10 Jan 2013 11:14:13 -0500 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EE549D.60606@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EE549D.60606@oracle.com> Message-ID: <50EEE8D5.2010300@oracle.com> Would you be so kind as to push it, please? Thanks, Jim On 01/10/2013 12:41 AM, Stuart Marks wrote: > On 1/9/13 10:49 AM, Jim Gish wrote: >> Please review: >> http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/ >> >> >> >> Summary: this test, when run on Windows, fails intermittently >> because of >> asynchronous windows deletes. The test passes, deletes two files >> that it has >> created for the test in the scratch directory, and exits. Then, jtreg >> upon >> attempting to cleanup after the test, tries to delete the files after >> doing a >> listFiles() on the scratch directory, which despite the delete by the >> test >> itself, still contains the files. The jtreg delete fails and jtreg >> changes the >> state of the test from passed to failed. >> >> I'm in the process of adding deletion retry behavior to jtreg, but in >> the >> meantime we think it makes sense to provide a more stable test >> environment by >> simply getting rid of the redundant deletes by the test itself. There >> really >> is no need for tests to delete files from the scratch directory at >> the end of a >> test because jtreg carries a guarantee of cleanup. > > By the way, this fix looks fine to me. > > s'marks > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From jim.gish at oracle.com Thu Jan 10 16:17:50 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 10 Jan 2013 11:17:50 -0500 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EEA732.4040101@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EDC933.6010303@oracle.com> <50EEA732.4040101@oracle.com> Message-ID: <50EEE9AE.2090806@oracle.com> I have not yet been able to reproduce it, but now that I have a Windows 7 VM setup, I'm going to try. Windows sysinternals has a program called handle.exe which I have used for years in determining who is holding file handles. If we could install this on our test machines and invoke it after a failed test like this, we'd have a better shot at tracking this down. Jim On 01/10/2013 06:34 AM, Alan Bateman wrote: > On 09/01/2013 19:46, Jim Gish wrote: >> It's a Windows feature. We discovered this recently in debugging >> another test failure. Windows is documented to do asynchronous >> deletes. You can't depend on a file.delete() which returns true to >> have actually deleted the file. It may be the case that another >> process has a file handle which it has not yet released, or it's >> simply a delay. > I don't get this, the issue sounds more like AV software or Windows > application quality service/agent thing accessing the file but I might > be wrong of course. Are you able to duplicate this reliably and if so, > have you looked at it with any tools to see what/who is accessing it > that is causing the delay? > > -Alan. -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From chris.hegarty at oracle.com Thu Jan 10 16:40:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2013 16:40:26 +0000 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Message-ID: <50EEEEFA.3010709@oracle.com> Doug, Aleksey, I updated the appropriate methods in the Atomic classes to use the instinsics defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, getAndAddLong, getAndSetLong, getAndSetObject. http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ This patch also includes some trivial cleanup and consistent style CAS loop from Dougs CVS, but excludes the new lambda versions of get/updateAndUpdate/Get and get/accumulateAndAccumulate/Get. These new methods are not impacted by the intrinsis. I will immediately follow these changes with a request to add these new methods, I just don't want to tie this update to a spec change request. Doug, If you are agree I will create a patch containing these changes, based on the sources in your CVS. -Chris. From dl at cs.oswego.edu Thu Jan 10 16:48:28 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 10 Jan 2013 11:48:28 -0500 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EEEEFA.3010709@oracle.com> References: <50EEEEFA.3010709@oracle.com> Message-ID: <50EEF0DC.9010209@cs.oswego.edu> On 01/10/13 11:40, Chris Hegarty wrote: > Doug, Aleksey, > > I updated the appropriate methods in the Atomic classes to use the instinsics > defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, getAndAddLong, > getAndSetLong, getAndSetObject. > > http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ > > This patch also includes some trivial cleanup and consistent style CAS loop from > Dougs CVS, but excludes the new lambda versions of get/updateAndUpdate/Get and > get/accumulateAndAccumulate/Get. These new methods are not impacted by the > intrinsis. I will immediately follow these changes with a request to add these > new methods, I just don't want to tie this update to a spec change request. > All OK by me. Too bad that you must make two webrevs for this. -Doug From chris.hegarty at oracle.com Thu Jan 10 17:02:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2013 17:02:15 +0000 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EEF0DC.9010209@cs.oswego.edu> References: <50EEEEFA.3010709@oracle.com> <50EEF0DC.9010209@cs.oswego.edu> Message-ID: <50EEF417.5050804@oracle.com> On 01/10/2013 04:48 PM, Doug Lea wrote: > On 01/10/13 11:40, Chris Hegarty wrote: >> Doug, Aleksey, >> >> I updated the appropriate methods in the Atomic classes to use the >> instinsics >> defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, getAndAddLong, >> getAndSetLong, getAndSetObject. >> >> http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ >> >> This patch also includes some trivial cleanup and consistent style CAS >> loop from >> Dougs CVS, but excludes the new lambda versions of >> get/updateAndUpdate/Get and >> get/accumulateAndAccumulate/Get. These new methods are not impacted by >> the >> intrinsis. I will immediately follow these changes with a request to >> add these >> new methods, I just don't want to tie this update to a spec change >> request. >> > > All OK by me. Too bad that you must make two webrevs for this. That's ok, at least these changes will hit tl later today. I'll prepare the request for the new methods now. -Chris. > > -Doug > From aleksey.shipilev at oracle.com Thu Jan 10 17:05:49 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 21:05:49 +0400 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EEEEFA.3010709@oracle.com> References: <50EEEEFA.3010709@oracle.com> Message-ID: <50EEF4ED.6000202@oracle.com> On 01/10/2013 08:40 PM, Chris Hegarty wrote: > Doug, Aleksey, > > I updated the appropriate methods in the Atomic classes to use the > instinsics defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, > getAndAddLong, getAndSetLong, getAndSetObject. > > http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ Good. Two comments: a) Any java-concurrency-torture [1] failures for these classes? b) Can we delegate all the suitable methods to Unsafe directly, without calling the middleman (i.e. getAndDec() -> getAndAdd() -> unsafe), as in [2]? -Aleksey. [1] https://github.com/shipilev/java-concurrency-torture/ [2] https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/util/concurrent/atomic/AtomicIntegerV8.java From chris.hegarty at oracle.com Thu Jan 10 17:15:47 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2013 17:15:47 +0000 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EEF4ED.6000202@oracle.com> References: <50EEEEFA.3010709@oracle.com> <50EEF4ED.6000202@oracle.com> Message-ID: <50EEF743.1070407@oracle.com> On 01/10/2013 05:05 PM, Aleksey Shipilev wrote: > On 01/10/2013 08:40 PM, Chris Hegarty wrote: >> Doug, Aleksey, >> >> I updated the appropriate methods in the Atomic classes to use the >> instinsics defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, >> getAndAddLong, getAndSetLong, getAndSetObject. >> >> http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ > > Good. Two comments: > a) Any java-concurrency-torture [1] failures for these classes? Can you give me a brief introduction to running these? I have run the JDK regression tests and the appropriate JCK tests, all pass. > b) Can we delegate all the suitable methods to Unsafe directly, without > calling the middleman (i.e. getAndDec() -> getAndAdd() -> unsafe), as in > [2]? Yes, we could. The existing implementation was not consistent. I took the view that this was not performance critical, since some existing methods already delegate, and my preference, for simplicity, is for the middleman ;-) Do you think there is a perf benefit to changing this, or is this a style issue? -Chris. > > -Aleksey. > > [1] https://github.com/shipilev/java-concurrency-torture/ > [2] > https://github.com/shipilev/java-concurrency-torture/blob/master/src/main/java/org/openjdk/util/concurrent/atomic/AtomicIntegerV8.java > From brent.christian at oracle.com Thu Jan 10 17:49:24 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 10 Jan 2013 09:49:24 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Message-ID: <50EEFF24.7090300@oracle.com> Hi, The test case for 8003228 fails in certain environments. Also the version that was pushed was missing a couple small changes. The code changes to fix these issues are here: http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ The test case will also be moved from java/util/Properties/ to java/lang/System/. Webrev wouldn't do well showing that part of the change, so it's not reflected there. Instead I generated a webrev to better show the code changes. Thanks, -Brent From naoto.sato at oracle.com Thu Jan 10 18:27:10 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 10 Jan 2013 10:27:10 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50EEFF24.7090300@oracle.com> References: <50EEFF24.7090300@oracle.com> Message-ID: <50EF07FE.10307@oracle.com> Looks good to me. BTW, I thought that webrev would effectively extract the diffs even when files were moved around. Naoto On 1/10/13 9:49 AM, Brent Christian wrote: > Hi, > > The test case for 8003228 fails in certain environments. Also the > version that was pushed was missing a couple small changes. > > The code changes to fix these issues are here: > http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ > > The test case will also be moved from java/util/Properties/ to > java/lang/System/. Webrev wouldn't do well showing that part of the > change, so it's not reflected there. Instead I generated a webrev to > better show the code changes. > > Thanks, > -Brent > From mike.duigou at oracle.com Thu Jan 10 19:02:24 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Jan 2013 11:02:24 -0800 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> Message-ID: <062E1F7B-A483-430C-82CD-FB253F78BC93@oracle.com> I apologize for the lack of reply. I had missed this thread while on holiday. As Aleksey suggests the first step is to complete the OCA/CLA. Until that step is complete we won't be able to act upon this contribution in any formal way. I encourage you to update the patch with any specific feedback you receive. Thanks in advance for this contribution! Mike On Jan 9 2013, at 09:51 , Steven Schlansker wrote: > Hello again, > > I sent this email a week ago and have received no replies. Is there any step I have missed necessary to contribute to the JDK libraries? > > I am very interested in making your lives easier, so please let me know if I am in the wrong place or are otherwise misguided. > > Thanks! > Steven > > > On Dec 29, 2012, at 9:25 AM, Steven Schlansker wrote: > >> Hello core-libs-dev, >> >> My company uses UUIDs throughout our software. We recently identified that the java.util.UUID implementations of fromString and toString are horridly inefficient. >> >> An incomplete list of the inefficiencies: >> >> * fromString uses a regular expression that is not even precompiled >> * fromString uses a regular expression to parse out the "-" markers, requiring the allocation of many String and String[] objects, when a simple linear scan works just fine >> * fromString unnecessarily allocates multiple Long objects >> >> * toString creates a char[64], a String object which copies that, and a sub-String object for *each* of the 5 hex digit segments >> * toString produces a fixed-length result but involves multiple StringBuilder concatenations >> >> Everyone that I have shown the relevant code to has been horrified by the complete lack of care towards object allocations. While I am a big fan of the "object allocation is free until otherwise proven" philosophy, we traced multiple production problems down to these hotspots. >> >> But instead of just whining about it, I wish to contribute a patch which I believe fixes the problem. This is my first attempt to submit anything to the JDK, so please be nice :-) >> >> My initial attempt has yielded micro benchmarks with very favorable outcomes. By taking the appropriate code from java.lang.Long, modifying it to work on a single pre-allocated array+offset rather than returning a String, and scanning for dashes instead of regex splitting I reduced times 3-6x and object allocations to the low single digits. >> >> My Google Caliper benchmark is available here, to ensure that I have not committed any benchmark sins: >> https://gist.github.com/4356621 >> >> benchmark instances Bytes ns linear runtime >> JdkUuidFromString 51.00 1544.0 608.2 ============================== >> NewUuidFromString 2.00 72.0 179.1 ======== >> >> JdkUuidToString 31.00 1720.0 321.4 =============== >> NewUuidToString 3.00 200.0 51.5 == >> >> In particular, the reduction of object allocations from ~1.5KB to 72/200 bytes dramatically reduces GC pressure when you sit in a tight loop deserializing millions of UUIDs from strings. >> >> I believe the same patch can (and should?) apply to jdk7u and jdk8, as the code does not seem to have changed. >> >> I would appreciate any feedback on the code style, efficiency, or correctness that you can offer. I have run the "java/util/UUID" jtreg suite against this and it passes. We stole the more thorough Apache Harmony tests for this and they pass as well: https://github.com/stevenschlansker/components-ness-core/blob/master/src/test/java/com/nesscomputing/uuid/TestNessUUID.java >> >> I have not yet secured a CLA, but my company is in the process of signing one. >> >> The rest of the message is a "hg export" of my change set, which is current to the tip of jdk7. >> Happy holidays, and thank you for your time! >> Steven Schlansker >> >> >> >> >> # HG changeset patch >> # User Steven Schlansker >> # Date 1356737383 0 >> # Node ID a812c963b96f08112f6805cbc380b12af196f788 >> # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 >> java.util.UUID: improve performance of UUID#toString and UUID#fromString by avoiding many unnecessary object allocations. >> >> benchmark instances Bytes ns linear runtime >> JdkUuidFromString 51.00 1544.0 608.2 ============================== >> NewUuidFromString 2.00 72.0 179.1 ======== >> >> JdkUuidToString 31.00 1720.0 321.4 =============== >> NewUuidToString 3.00 200.0 51.5 == >> >> diff -r 9b8c96f96a0f -r a812c963b96f src/share/classes/java/util/UUID.java >> --- a/src/share/classes/java/util/UUID.java Mon Jun 27 13:21:34 2011 -0700 >> +++ b/src/share/classes/java/util/UUID.java Fri Dec 28 23:29:43 2012 +0000 >> @@ -189,26 +189,79 @@ >> * described in {@link #toString} >> * >> */ >> - public static UUID fromString(String name) { >> - String[] components = name.split("-"); >> - if (components.length != 5) >> - throw new IllegalArgumentException("Invalid UUID string: "+name); >> - for (int i=0; i<5; i++) >> - components[i] = "0x"+components[i]; >> + public static UUID fromString(String str) { >> + int dashCount = 4; >> + int [] dashPos = new int [6]; >> + dashPos[0] = -1; >> + dashPos[5] = str.length(); >> >> - long mostSigBits = Long.decode(components[0]).longValue(); >> + for (int i = str.length()-1; i >= 0; i--) { >> + if (str.charAt(i) == '-') { >> + if (dashCount == 0) { >> + throw new IllegalArgumentException("Invalid UUID string: " + str); >> + } >> + dashPos[dashCount--] = i; >> + } >> + } >> + >> + if (dashCount > 0) { >> + throw new IllegalArgumentException("Invalid UUID string: " + str); >> + } >> + >> + long mostSigBits = decode(str, dashPos, 0) & 0xffffffffL; >> mostSigBits <<= 16; >> - mostSigBits |= Long.decode(components[1]).longValue(); >> + mostSigBits |= decode(str, dashPos, 1) & 0xffffL; >> mostSigBits <<= 16; >> - mostSigBits |= Long.decode(components[2]).longValue(); >> + mostSigBits |= decode(str, dashPos, 2) & 0xffff); >> >> - long leastSigBits = Long.decode(components[3]).longValue(); >> + long leastSigBits = decode(str, dashPos, 3) & 0xffffL; >> leastSigBits <<= 48; >> - leastSigBits |= Long.decode(components[4]).longValue(); >> + leastSigBits |= decode(str, dashPos, 4) & 0xffffffffffffL; >> >> return new UUID(mostSigBits, leastSigBits); >> } >> >> + private static long decode(final String str, final int [] dashPos, final int field) { >> + int start = dashPos[field]+1; >> + int end = dashPos[field+1]; >> + if (start >= end) { >> + throw new IllegalArgumentException("Invalid UUID string: " + str); >> + } >> + long curr = 0; >> + for (int i = start; i < end; i++) { >> + int x = getNibbleFromChar(str.charAt(i)); >> + curr <<= 4; >> + if (curr < 0) { >> + throw new NumberFormatException("long overflow"); >> + } >> + curr |= x; >> + } >> + return curr; >> + } >> + >> + private static final int NUM_ALPHA_DIFF = 'A' - '9' - 1; >> + private static final int LOWER_UPPER_DIFF = 'a' - 'A'; >> + >> + private static int getNibbleFromChar(final char c) >> + { >> + int x = c - '0'; >> + if (x > 9) { >> + x -= NUM_ALPHA_DIFF; // difference between '9' and 'A' >> + if (x > 15) { >> + x -= LOWER_UPPER_DIFF; // difference between 'a' and 'A' >> + } >> + if (x < 10) { >> + throw new IllegalArgumentException(c + " is not a valid character for an UUID string"); >> + } >> + } >> + >> + if (x < 0 || x > 15) { >> + throw new IllegalArgumentException(c + " is not a valid character for an UUID string"); >> + } >> + >> + return x; >> + } >> + >> // Field Accessor Methods >> >> /** >> @@ -372,19 +425,46 @@ >> * @return A string representation of this {@code UUID} >> */ >> public String toString() { >> - return (digits(mostSigBits >> 32, 8) + "-" + >> - digits(mostSigBits >> 16, 4) + "-" + >> - digits(mostSigBits, 4) + "-" + >> - digits(leastSigBits >> 48, 4) + "-" + >> - digits(leastSigBits, 12)); >> + return toString(getMostSignificantBits(), getLeastSignificantBits()); >> } >> >> - /** Returns val represented by the specified number of hex digits. */ >> - private static String digits(long val, int digits) { >> - long hi = 1L << (digits * 4); >> - return Long.toHexString(hi | (val & (hi - 1))).substring(1); >> + public static String toString(long msb, long lsb) { >> + char[] uuidChars = new char[36]; >> + >> + hexDigits(uuidChars, 0, 8, msb >> 32); >> + uuidChars[8] = '-'; >> + hexDigits(uuidChars, 9, 4, msb >> 16); >> + uuidChars[13] = '-'; >> + hexDigits(uuidChars, 14, 4, msb); >> + uuidChars[18] = '-'; >> + hexDigits(uuidChars, 19, 4, lsb >> 48); >> + uuidChars[23] = '-'; >> + hexDigits(uuidChars, 24, 12, lsb); >> + >> + return new String(uuidChars); >> } >> >> + private static void hexDigits(char[] dest, int offset, int digits, long val) { >> + long hi = 1L << (digits * 4); >> + toUnsignedString(dest, offset, digits, hi | (val & (hi - 1)), 4); >> + } >> + >> + private final static char[] HEX_DIGITS = { >> + '0' , '1' , '2' , '3' , '4' , '5' , >> + '6' , '7' , '8' , '9' , 'a' , 'b' , >> + 'c' , 'd' , 'e' , 'f' >> + }; >> + >> + private static void toUnsignedString(char[] dest, int offset, int len, long i, int shift) { >> + int charPos = len; >> + int radix = 1 << shift; >> + long mask = radix - 1; >> + do { >> + dest[offset + --charPos] = HEX_DIGITS[(int)(i & mask)]; >> + i >>>= shift; >> + } while (i != 0 && charPos > 0); >> + } >> + >> /** >> * Returns a hash code for this {@code UUID}. >> * > From stuart.marks at oracle.com Thu Jan 10 19:09:11 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Jan 2013 11:09:11 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EEA732.4040101@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EDC933.6010303@oracle.com> <50EEA732.4040101@oracle.com> Message-ID: <50EF11D7.1010207@oracle.com> On 1/10/13 3:34 AM, Alan Bateman wrote: > On 09/01/2013 19:46, Jim Gish wrote: >> It's a Windows feature. We discovered this recently in debugging another >> test failure. Windows is documented to do asynchronous deletes. You can't >> depend on a file.delete() which returns true to have actually deleted the >> file. It may be the case that another process has a file handle which it has >> not yet released, or it's simply a delay. > I don't get this, the issue sounds more like AV software or Windows application > quality service/agent thing accessing the file but I might be wrong of course. > Are you able to duplicate this reliably and if so, have you looked at it with > any tools to see what/who is accessing it that is causing the delay? Dave DeHaven was able to reproduce this in his diagnosis of the Arrrghs test failure. It's a race condition, because the Windows Application Experience daemon opens up files with certain extensions (.bat, .cmd ?). I suspect it gets a filesystem notification that a file matching the right pattern has been created, so some time later it gets around to opening the file; and then after processing it, it closes the file. That a file remains in the filesystem after having been "deleted" indeed is documented Windows behavior. The doc for the DeleteFile function [1] says, << The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. >> (I'm not a Windows developer, so I may be looking in the wrong place or misinterpreting something. Please correct me if I'm wrong.) If the AE daemon has the file open the moment the test deletes it, the file will remain present until the AE daemon has closed it. This seems built into Windows. I think we have to live with it. Presumably these various daemons open the file with CreateFile(FILE_SHARE_DELETE) [2] allowing the "owner" of the file to delete it (eventually). Note this also allows renaming of the file. So the rename-before-delete technique seems like the most promising approach. s'marks [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx From brent.christian at oracle.com Thu Jan 10 19:13:21 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 10 Jan 2013 11:13:21 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50EF07FE.10307@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> Message-ID: <50EF12D1.8010305@oracle.com> Thanks, Naoto. AFAICT, in a case like this there where a file is moved *and* changes are made to it, webrev shows that the new file is renamed from the old file, but doesn't provide cdiffs/sdiffs/etc for the code changes. 'hg diff' behaves the same way WRT the code changes - it tells you that the old file was removed and the new file was added, but you don't get code diffs for the changes. (Interestingly, the NetBeans editor seemed to figure out what was happening.) That's how it works for me, anyway. -Brent On 1/10/13 10:27 AM, Naoto Sato wrote: > Looks good to me. > > BTW, I thought that webrev would effectively extract the diffs even when > files were moved around. > > Naoto > > On 1/10/13 9:49 AM, Brent Christian wrote: >> Hi, >> >> The test case for 8003228 fails in certain environments. Also the >> version that was pushed was missing a couple small changes. >> >> The code changes to fix these issues are here: >> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >> >> The test case will also be moved from java/util/Properties/ to >> java/lang/System/. Webrev wouldn't do well showing that part of the >> change, so it's not reflected there. Instead I generated a webrev to >> better show the code changes. >> >> Thanks, >> -Brent >> > From naoto.sato at oracle.com Thu Jan 10 19:36:17 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 10 Jan 2013 19:36:17 +0000 Subject: hg: jdk8/tl/jdk: 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Message-ID: <20130110193629.349734718F@hg.openjdk.java.net> Changeset: c622df692bfb Author: bchristi Date: 2013-01-10 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c622df692bfb 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Summary: Test script now sets LC_ALL, other small changes, relocate test Reviewed-by: naoto, alanb + test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java + test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From aleksey.shipilev at oracle.com Thu Jan 10 19:48:50 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 10 Jan 2013 23:48:50 +0400 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EEF743.1070407@oracle.com> References: <50EEEEFA.3010709@oracle.com> <50EEF4ED.6000202@oracle.com> <50EEF743.1070407@oracle.com> Message-ID: <50EF1B22.8020109@oracle.com> On 01/10/2013 09:15 PM, Chris Hegarty wrote: > On 01/10/2013 05:05 PM, Aleksey Shipilev wrote: >> On 01/10/2013 08:40 PM, Chris Hegarty wrote: >>> Doug, Aleksey, >>> >>> I updated the appropriate methods in the Atomic classes to use the >>> instinsics defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, >>> getAndAddLong, getAndSetLong, getAndSetObject. >>> >>> http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ >> >> Good. Two comments: >> a) Any java-concurrency-torture [1] failures for these classes? > > Can you give me a brief introduction to running these? I have run the > JDK regression tests and the appropriate JCK tests, all pass. Build it, run it, see results/index.html. Should be 100% pass rate. If not, drill down to exact tests. >> b) Can we delegate all the suitable methods to Unsafe directly, without >> calling the middleman (i.e. getAndDec() -> getAndAdd() -> unsafe), as in >> [2]? > > Yes, we could. The existing implementation was not consistent. > > I took the view that this was not performance critical, since some > existing methods already delegate, and my preference, for simplicity, is > for the middleman ;-) Do you think there is a perf benefit to changing > this, or is this a style issue? Yeah, that's mostly stylistic issue. If that's not in Doug's repo, you can just disregard this. (There is a tempting desire to not to blow up the call tree to help inliner, since the delegating method is not private). -Aleksey. From chris.hegarty at oracle.com Thu Jan 10 20:36:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2013 20:36:48 +0000 Subject: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools In-Reply-To: <50EEBECE.6030001@oracle.com> References: <50EEBECE.6030001@oracle.com> Message-ID: <50EF2660.1040406@oracle.com> Skimming over this it looks fine to me. You could add TESTTOOLVMOPTS while there ;-) -Chris. On 01/10/2013 01:14 PM, Alan Bateman wrote: > > I'm currently trying to run the jdk tests on the compact profiles. As > the profile builds are runtimes only, they don't have tools such as > javac and so need to be run with both -jdk and -compilejdk. That works > okay except for the shell tests because many of them launch the "javac" > or "jar" tools directly and so fail because the runtime under test > ($TESTJAVA) is not a JDK. I'd like to update the shell tests to use the > tools in $COMPILEJAVA, this is the JDK specified to jtreg with > -compilejdk or it's the same as $TESTJAVA when -compilejdk is not > specified. > > The webrev with the proposed changes is here: > > http://cr.openjdk.java.net/~alanb/8005978/webrev/ > > For the most part this is just s/TESTJAVA/COMPILEJAVA/ although there > are a couple of subtle things to watch out for - for example tool tests > should be testing the tools in $TESTJAVA, not $COMPILEJAVA. Many of the > shell tests were created to be runnable outside of jtreg so I've > preserved this where it was previously supported. > > I should note that this is not all of the shell tests, I don't have time > to fix the tests in areas that aren't interesting for the profiles so > contributions to do more would be welcome. Another thing is that a lot > of these shell tests are old tests and a lot of them don't really need > to be shell tests. I mention this because another great effort would be > be gradually replace many of these shell tests. > > -Alan. > > > > From eric.mccorkle at oracle.com Thu Jan 10 20:42:16 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 10 Jan 2013 15:42:16 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EE878C.2040707@gmail.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> Message-ID: <50EF27A8.1060505@oracle.com> Thanks to all for initial reviews; however, it appears that the version you saw was somewhat stale. I've applied your comments (and some changes that I'd made since the version that was posted). Please take a second look. Thanks, Eric On 01/10/13 04:19, Peter Levart wrote: > Hello Eric, > > You must have missed my comment from the previous webrev: > > 292 private Parameter[] privateGetParameters() { > 293 if (null != parameters) > 294 return parameters.get(); > > If/when the 'parameters' SoftReference is cleared, the method will be > returning null forever after... > > You should also retrieve the referent and check for it's presence before > returning it: > > Parameter[] res; > if (parameters != null && (res = parameters.get()) != null) > return res; > ... > ... > > Regards, Peter > > On 01/09/2013 10:55 PM, Eric McCorkle wrote: >> Hello, >> >> Please review the core reflection API implementation of parameter >> reflection. This is the final component of method parameter reflection. >> This was posted for review before, then delayed until the check-in for >> JDK-8004728 (hotspot support for parameter reflection), which occurred >> yesterday. >> >> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >> jdk8/tl; therefore, it may be a while before the changeset makes its way >> into jdk8/tl. >> >> Also note: since the check-in of JDK-8004727 (javac support for >> parameter reflection), there has been a failure in the tests for >> Pack200. This is being addressed in a fix contributed by Kumar, which I >> believe has also been posted for review. >> >> The open webrev is here: >> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >> >> The feature request is here: >> http://bugs.sun.com/view_bug.do?bug_id=8004729 >> >> The latest version of the spec can be found here: >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> >> Thanks, >> Eric > From peter.levart at gmail.com Thu Jan 10 20:47:09 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jan 2013 21:47:09 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF14FD.60907@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF14FD.60907@oracle.com> Message-ID: <50EF28CD.7000202@gmail.com> A apologise. I don't know how that happened (browser cache? strange - the URL is different)... Regards, Peter On 01/10/2013 08:22 PM, Eric McCorkle wrote: > Thanks to all for initial reviews; however, it appears that the version > you saw was somewhat stale. I've applied your comments (and some > changes that I'd made since the version that was posted). > > Please take a second look. > > Thanks, > Eric > > On 01/10/13 04:19, Peter Levart wrote: >> Hello Eric, >> >> You must have missed my comment from the previous webrev: >> >> 292 private Parameter[] privateGetParameters() { >> 293 if (null != parameters) >> 294 return parameters.get(); >> >> If/when the 'parameters' SoftReference is cleared, the method will be >> returning null forever after... >> >> You should also retrieve the referent and check for it's presence before >> returning it: >> >> Parameter[] res; >> if (parameters != null && (res = parameters.get()) != null) >> return res; >> ... >> ... >> >> Regards, Peter >> >> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review the core reflection API implementation of parameter >>> reflection. This is the final component of method parameter reflection. >>> This was posted for review before, then delayed until the check-in for >>> JDK-8004728 (hotspot support for parameter reflection), which occurred >>> yesterday. >>> >>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >>> jdk8/tl; therefore, it may be a while before the changeset makes its way >>> into jdk8/tl. >>> >>> Also note: since the check-in of JDK-8004727 (javac support for >>> parameter reflection), there has been a failure in the tests for >>> Pack200. This is being addressed in a fix contributed by Kumar, which I >>> believe has also been posted for review. >>> >>> The open webrev is here: >>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >>> >>> The feature request is here: >>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >>> >>> The latest version of the spec can be found here: >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>> >>> Thanks, >>> Eric From Lance.Andersen at oracle.com Thu Jan 10 21:00:48 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 10 Jan 2013 16:00:48 -0500 Subject: Review request 8005080: JDBC 4.2 Message-ID: <40B58252-4FF6-4F51-A4D3-53B354D2B14D@oracle.com> The following webrev has the bulk of the JDBC 4.2 changes: http://cr.openjdk.java.net/~lancea/8005080/webrev.00/ There will be additional updates to java.sql.Date/TIme/Timestamp (by Sherman) once JSR 310 is integrated to aide in moving to and from the new date time datatypes. I will also probably have one more set of minor changes once 310 is integrated. The CCC has been approved for these changes the specdiff of the javadocs is still available at http://cr.openjdk.java.net/~lancea/8005080/specdiffs.02/ (note some of the changes highlighted were put back previously) 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 peter.levart at gmail.com Thu Jan 10 21:10:46 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 10 Jan 2013 22:10:46 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF27A8.1060505@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> Message-ID: <50EF2E56.7070007@gmail.com> Hello Eric, I have another one. Although not very likely, the reference to the same Method/Constructor can be shared among multiple threads. The publication of a parameters array should therefore be performed via a volatile write / volatile read, otherwise it can happen that some thread sees half-initialized array content. The 'parameters' field in Executable should be declared as volatile and there should be a single read from it and a single write to it in the privateGetParameters() method (you need a local variable to hold intermediate states)... Regards, Peter On 01/10/2013 09:42 PM, Eric McCorkle wrote: > Thanks to all for initial reviews; however, it appears that the version > you saw was somewhat stale. I've applied your comments (and some > changes that I'd made since the version that was posted). > > Please take a second look. > > Thanks, > Eric > > > On 01/10/13 04:19, Peter Levart wrote: >> Hello Eric, >> >> You must have missed my comment from the previous webrev: >> >> 292 private Parameter[] privateGetParameters() { >> 293 if (null != parameters) >> 294 return parameters.get(); >> >> If/when the 'parameters' SoftReference is cleared, the method will be >> returning null forever after... >> >> You should also retrieve the referent and check for it's presence before >> returning it: >> >> Parameter[] res; >> if (parameters != null && (res = parameters.get()) != null) >> return res; >> ... >> ... >> >> Regards, Peter >> >> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review the core reflection API implementation of parameter >>> reflection. This is the final component of method parameter reflection. >>> This was posted for review before, then delayed until the check-in for >>> JDK-8004728 (hotspot support for parameter reflection), which occurred >>> yesterday. >>> >>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >>> jdk8/tl; therefore, it may be a while before the changeset makes its way >>> into jdk8/tl. >>> >>> Also note: since the check-in of JDK-8004727 (javac support for >>> parameter reflection), there has been a failure in the tests for >>> Pack200. This is being addressed in a fix contributed by Kumar, which I >>> believe has also been posted for review. >>> >>> The open webrev is here: >>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >>> >>> The feature request is here: >>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >>> >>> The latest version of the spec can be found here: >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>> >>> Thanks, >>> Eric From chris.hegarty at oracle.com Thu Jan 10 21:46:06 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Jan 2013 21:46:06 +0000 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EF1B22.8020109@oracle.com> References: <50EEEEFA.3010709@oracle.com> <50EEF4ED.6000202@oracle.com> <50EEF743.1070407@oracle.com> <50EF1B22.8020109@oracle.com> Message-ID: <50EF369E.2080309@oracle.com> On 01/10/2013 07:48 PM, Aleksey Shipilev wrote: > On 01/10/2013 09:15 PM, Chris Hegarty wrote: >> On 01/10/2013 05:05 PM, Aleksey Shipilev wrote: >>> On 01/10/2013 08:40 PM, Chris Hegarty wrote: >>>> Doug, Aleksey, >>>> >>>> I updated the appropriate methods in the Atomic classes to use the >>>> instinsics defined by 7023898 , Unsafe getAndAddInt, getAndSetInt, >>>> getAndAddLong, getAndSetLong, getAndSetObject. >>>> >>>> http://cr.openjdk.java.net/~chegar/8006007/webrev.00/webrev/ >>> >>> Good. Two comments: >>> a) Any java-concurrency-torture [1] failures for these classes? >> >> Can you give me a brief introduction to running these? I have run the >> JDK regression tests and the appropriate JCK tests, all pass. > > Build it, run it, see results/index.html. Should be 100% pass rate. If > not, drill down to exact tests. Maven has just finished downloading the dependencies to build this project! ;-) All tests pass. You can probably remove the *.atomic.*V8 source and tests once these changes are integrated. > >>> b) Can we delegate all the suitable methods to Unsafe directly, without >>> calling the middleman (i.e. getAndDec() -> getAndAdd() -> unsafe), as in >>> [2]? >> >> Yes, we could. The existing implementation was not consistent. >> >> I took the view that this was not performance critical, since some >> existing methods already delegate, and my preference, for simplicity, is >> for the middleman ;-) Do you think there is a perf benefit to changing >> this, or is this a style issue? > > Yeah, that's mostly stylistic issue. If that's not in Doug's repo, you > can just disregard this. (There is a tempting desire to not to blow up > the call tree to help inliner, since the delegating method is not private). I'll leave it as is, I find it much less error prone. We can revisit if necessary. Thanks, -Chris. > > -Aleksey. > From stuart.marks at oracle.com Thu Jan 10 21:50:38 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 10 Jan 2013 21:50:38 +0000 Subject: hg: jdk8/tl/jdk: 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Message-ID: <20130110215100.F093A4719D@hg.openjdk.java.net> Changeset: 13ff1089e625 Author: jgish Date: 2013-01-10 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ff1089e625 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Summary: Remove file-deletion code at cleanup which conflicts with jtreg cleanup Reviewed-by: chegar ! test/java/lang/Runtime/exec/WinCommand.java From chris.hegarty at oracle.com Thu Jan 10 21:53:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 10 Jan 2013 21:53:49 +0000 Subject: hg: jdk8/tl/jdk: 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Message-ID: <20130110215400.8B9C54719E@hg.openjdk.java.net> Changeset: 3e906ccad412 Author: chegar Date: 2013-01-10 21:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e906ccad412 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Reviewed-by: dl, shade ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.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 From jonathan.gibbons at oracle.com Thu Jan 10 22:10:01 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Jan 2013 22:10:01 +0000 Subject: hg: jdk8/tl/langtools: 8006037: extra space in javac -help for -J and @ options Message-ID: <20130110221004.60C4A4719F@hg.openjdk.java.net> Changeset: d462da465da6 Author: jjg Date: 2013-01-10 14:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d462da465da6 8006037: extra space in javac -help for -J and @ options Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java + test/tools/javac/main/Option_J_At_Test.java From aleksey.shipilev at oracle.com Thu Jan 10 22:15:51 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Jan 2013 02:15:51 +0400 Subject: RFR 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 In-Reply-To: <50EF369E.2080309@oracle.com> References: <50EEEEFA.3010709@oracle.com> <50EEF4ED.6000202@oracle.com> <50EEF743.1070407@oracle.com> <50EF1B22.8020109@oracle.com> <50EF369E.2080309@oracle.com> Message-ID: <50EF3D97.9040800@oracle.com> On 01/11/2013 01:46 AM, Chris Hegarty wrote: > Maven has just finished downloading the dependencies to build this > project! ;-) All tests pass. Nice. So, you didn't broke most of the things ;) > You can probably remove the *.atomic.*V8 source and tests once these > changes are integrated. Already did. > I'll leave it as is, I find it much less error prone. We can revisit if > necessary. Fine with me. -Aleksey. From eric.mccorkle at oracle.com Thu Jan 10 22:29:54 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 10 Jan 2013 17:29:54 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF2E56.7070007@gmail.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> Message-ID: <50EF40E2.1060305@oracle.com> Good catch there. I made the field volatile, and I also did the same with the cache fields in Parameter. It is possible with what exists that you could wind up with multiple copies of identical parameter objects in existence. It goes something like this thread A sees Executable.parameters is null, goes into the VM to get them thread B sees Executable.parameters is null, goes into the VM to get them thread A stores to Executable.parameters thread B stores to Executable.parameters Since Parameters is immutable (except for its caches, which will always end up containing the same things), this *should* have no visible effects, unless someone does == instead of .equals. This can be avoided by doing a CAS, which is more expensive execution-wise. My vote is to *not* do a CAS, and accept that (in extremely rare cases, even as far as concurrency-related anomalies go), you may end up with duplicates, and document that very well. Thoughts? On 01/10/13 16:10, Peter Levart wrote: > Hello Eric, > > I have another one. Although not very likely, the reference to the same > Method/Constructor can be shared among multiple threads. The publication > of a parameters array should therefore be performed via a volatile write > / volatile read, otherwise it can happen that some thread sees > half-initialized array content. The 'parameters' field in Executable > should be declared as volatile and there should be a single read from it > and a single write to it in the privateGetParameters() method (you need > a local variable to hold intermediate states)... > > Regards, Peter > > On 01/10/2013 09:42 PM, Eric McCorkle wrote: >> Thanks to all for initial reviews; however, it appears that the version >> you saw was somewhat stale. I've applied your comments (and some >> changes that I'd made since the version that was posted). >> >> Please take a second look. >> >> Thanks, >> Eric >> >> >> On 01/10/13 04:19, Peter Levart wrote: >>> Hello Eric, >>> >>> You must have missed my comment from the previous webrev: >>> >>> 292 private Parameter[] privateGetParameters() { >>> 293 if (null != parameters) >>> 294 return parameters.get(); >>> >>> If/when the 'parameters' SoftReference is cleared, the method will be >>> returning null forever after... >>> >>> You should also retrieve the referent and check for it's presence before >>> returning it: >>> >>> Parameter[] res; >>> if (parameters != null && (res = parameters.get()) != null) >>> return res; >>> ... >>> ... >>> >>> Regards, Peter >>> >>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review the core reflection API implementation of parameter >>>> reflection. This is the final component of method parameter reflection. >>>> This was posted for review before, then delayed until the check-in for >>>> JDK-8004728 (hotspot support for parameter reflection), which occurred >>>> yesterday. >>>> >>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >>>> jdk8/tl; therefore, it may be a while before the changeset makes its way >>>> into jdk8/tl. >>>> >>>> Also note: since the check-in of JDK-8004727 (javac support for >>>> parameter reflection), there has been a failure in the tests for >>>> Pack200. This is being addressed in a fix contributed by Kumar, which I >>>> believe has also been posted for review. >>>> >>>> The open webrev is here: >>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >>>> >>>> The feature request is here: >>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >>>> >>>> The latest version of the spec can be found here: >>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>> >>>> >>>> Thanks, >>>> Eric > From aleksey.shipilev at oracle.com Thu Jan 10 22:31:31 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Jan 2013 02:31:31 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread Message-ID: <50EF4143.4090008@oracle.com> Hi, Submitting this on behalf of Doug Lea. The webrev is here: http://cr.openjdk.java.net/~shade/8005926/webrev.00/ Bottom-line: merge ThreadLocalRandom state into Thread, to optimize many use cases around j.u.c.* code. The simple performance tests on 2x2 i5, Linux x86_64, 4 threads, 5 forks, 3x3s warmup, 5x3s measurement: JDK8 (baseline) TLR.nextInt(): 6.4 +- 0.1 ns/op TLR.current().nextInt(): 16.1 +- 0.4 ns/op TL.get().nextInt(): 19.1 +- 0.6 ns/op JDK8 (patched) TLR.nextInt(): 6.5 +- 0.2 ns/op TLR.current().nextInt(): 6.4 +- 0.1 ns/op TL.get().nextInt(): 17.2 +- 2.0 ns/op First line shows the peak performance of TLR itself, everything over that is the ThreadLocal overhead. One can see the patched version bypasses ThreadLocal machinery completely, and the overhead is slim to none. N.B. It gets especially interesting when there are many ThreadLocals registered. Making 1M ThreadLocals and pre-touching them bloats the thread-local maps, and we get: JDK8 (baseline), contaminators = 1M: TLR.nextInt(): 6.4 +- 0.1 ns/op TLR.current().nextInt(): 21.7 +- 5.3 ns/op TL.get().nextInt(): 28.7 +- 1.1 ns/op JDK8 (patched), contaminators = 1M: TLR.nextInt(): 6.6 +- 0.2 ns/op TLR.current().nextInt(): 6.5 +- 0.1 ns/op TL.get().nextInt(): 29.4 +- 0.5 ns/op Note that patched version successfully dodges this pathological case. Testing: - Doug tested on his platforms - Tested Linux x86_64 to build and run successfully - JPRT builds are OK - JPRT tests are OK (modulo some weird lambda/default-methods test failures in jdk8/tl) Attribution: - dl: original patch - shade: testing, copyright headers, etc. -Aleksey. From aleksey.shipilev at oracle.com Thu Jan 10 23:03:44 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 11 Jan 2013 03:03:44 +0400 Subject: RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family In-Reply-To: <50ED7681.7030501@cs.oswego.edu> References: <50D36104.8000701@oracle.com> <50ED4C96.6070205@oracle.com> <50ED4ED9.60102@oracle.com> <50ED5648.4000200@cs.oswego.edu> <50ED65B4.3020602@oracle.com> <50ED6A55.3030803@cs.oswego.edu> <50ED6AE0.6020405@oracle.com> <50ED7681.7030501@cs.oswego.edu> Message-ID: <50EF48D0.8010303@oracle.com> On 01/09/2013 05:54 PM, Doug Lea wrote: > On 01/09/13 08:04, Aleksey Shipilev wrote: >> c) While existing, Java-level AtomicLong.VM_SUPPORT_LONG_CAS is >> redundant, and can be eliminated. AtomicLongFieldUpdater can be >> rewritten to use Unsafe on all the paths. >> > > There is one little nicety here that does rely on > VM_SUPPORT_LONG_CAS. There is a disclaimer somewhere that CAS is > guaranteed to atomic only wrt other CASes. But in the emulation code > for updaters, we also lock unconditional writes, because not doing so > would be surprising. Ok, I spent some time thinking about this, so I can ask the stupid question now. What's surprising? I can't understand how that blows up if we do put/getLongVolatile() in ALFU.LockedUpdater, and do get()/set() without the locking. > A good case can be made that the fallback wrapper for > putLongVolatile should itself use a lock in this case but for reasons > I don't remember, this wasn't done. (and in any case wouldn't trap > syntactically generated volatile writes.) So there may be some usage > code that is officially wrong/surprising on these grounds. Ummm. Examples? I'm OK with exploring the darkest side of Unsafe :) -Aleksey. From eric.mccorkle at oracle.com Thu Jan 10 23:04:40 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 10 Jan 2013 18:04:40 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF40E2.1060305@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> Message-ID: <50EF4908.7050002@oracle.com> The webrev has been refreshed with the solution I describe below implemented. Please make additional comments. On 01/10/13 17:29, Eric McCorkle wrote: > Good catch there. I made the field volatile, and I also did the same > with the cache fields in Parameter. > > It is possible with what exists that you could wind up with multiple > copies of identical parameter objects in existence. It goes something > like this > > thread A sees Executable.parameters is null, goes into the VM to get them > thread B sees Executable.parameters is null, goes into the VM to get them > thread A stores to Executable.parameters > thread B stores to Executable.parameters > > Since Parameters is immutable (except for its caches, which will always > end up containing the same things), this *should* have no visible > effects, unless someone does == instead of .equals. > > This can be avoided by doing a CAS, which is more expensive execution-wise. > > My vote is to *not* do a CAS, and accept that (in extremely rare cases, > even as far as concurrency-related anomalies go), you may end up with > duplicates, and document that very well. > > Thoughts? > > On 01/10/13 16:10, Peter Levart wrote: >> Hello Eric, >> >> I have another one. Although not very likely, the reference to the same >> Method/Constructor can be shared among multiple threads. The publication >> of a parameters array should therefore be performed via a volatile write >> / volatile read, otherwise it can happen that some thread sees >> half-initialized array content. The 'parameters' field in Executable >> should be declared as volatile and there should be a single read from it >> and a single write to it in the privateGetParameters() method (you need >> a local variable to hold intermediate states)... >> >> Regards, Peter >> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>> Thanks to all for initial reviews; however, it appears that the version >>> you saw was somewhat stale. I've applied your comments (and some >>> changes that I'd made since the version that was posted). >>> >>> Please take a second look. >>> >>> Thanks, >>> Eric >>> >>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>> Hello Eric, >>>> >>>> You must have missed my comment from the previous webrev: >>>> >>>> 292 private Parameter[] privateGetParameters() { >>>> 293 if (null != parameters) >>>> 294 return parameters.get(); >>>> >>>> If/when the 'parameters' SoftReference is cleared, the method will be >>>> returning null forever after... >>>> >>>> You should also retrieve the referent and check for it's presence before >>>> returning it: >>>> >>>> Parameter[] res; >>>> if (parameters != null && (res = parameters.get()) != null) >>>> return res; >>>> ... >>>> ... >>>> >>>> Regards, Peter >>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>>> Hello, >>>>> >>>>> Please review the core reflection API implementation of parameter >>>>> reflection. This is the final component of method parameter reflection. >>>>> This was posted for review before, then delayed until the check-in for >>>>> JDK-8004728 (hotspot support for parameter reflection), which occurred >>>>> yesterday. >>>>> >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >>>>> jdk8/tl; therefore, it may be a while before the changeset makes its way >>>>> into jdk8/tl. >>>>> >>>>> Also note: since the check-in of JDK-8004727 (javac support for >>>>> parameter reflection), there has been a failure in the tests for >>>>> Pack200. This is being addressed in a fix contributed by Kumar, which I >>>>> believe has also been posted for review. >>>>> >>>>> The open webrev is here: >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >>>>> >>>>> The feature request is here: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >>>>> >>>>> The latest version of the spec can be found here: >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>>> >>>>> >>>>> Thanks, >>>>> Eric >> From jonathan.gibbons at oracle.com Thu Jan 10 23:49:08 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Jan 2013 23:49:08 +0000 Subject: hg: jdk8/tl/langtools: 8006033: bug in Pretty.toSimpleString Message-ID: <20130110234910.ABCC9471AD@hg.openjdk.java.net> Changeset: 7d2f628f04f1 Author: jjg Date: 2013-01-10 15:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d2f628f04f1 8006033: bug in Pretty.toSimpleString Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/PrettySimpleStringTest.java From vitalyd at gmail.com Fri Jan 11 00:50:37 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 10 Jan 2013 19:50:37 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF4908.7050002@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> Message-ID: Hi Eric, Parameter.equals() doesn't need null check - instanceof covers that already. Maybe this has been mentioned already, but personally I'm not a fan of null checks such as "if (null == x)" - I prefer the null on the right hand side, but that's just stylistic. Perhaps I'm looking at a stale webrev but Executable.privateGetParameters() reads and writes from/to the volatile field more than once. I think Peter already mentioned that it should use one read into a local and one write to publish the final version to the field (it can return the temp as well). Thanks Sent from my phone On Jan 10, 2013 6:05 PM, "Eric McCorkle" wrote: > The webrev has been refreshed with the solution I describe below > implemented. Please make additional comments. > > On 01/10/13 17:29, Eric McCorkle wrote: > > Good catch there. I made the field volatile, and I also did the same > > with the cache fields in Parameter. > > > > It is possible with what exists that you could wind up with multiple > > copies of identical parameter objects in existence. It goes something > > like this > > > > thread A sees Executable.parameters is null, goes into the VM to get them > > thread B sees Executable.parameters is null, goes into the VM to get them > > thread A stores to Executable.parameters > > thread B stores to Executable.parameters > > > > Since Parameters is immutable (except for its caches, which will always > > end up containing the same things), this *should* have no visible > > effects, unless someone does == instead of .equals. > > > > This can be avoided by doing a CAS, which is more expensive > execution-wise. > > > > My vote is to *not* do a CAS, and accept that (in extremely rare cases, > > even as far as concurrency-related anomalies go), you may end up with > > duplicates, and document that very well. > > > > Thoughts? > > > > On 01/10/13 16:10, Peter Levart wrote: > >> Hello Eric, > >> > >> I have another one. Although not very likely, the reference to the same > >> Method/Constructor can be shared among multiple threads. The publication > >> of a parameters array should therefore be performed via a volatile write > >> / volatile read, otherwise it can happen that some thread sees > >> half-initialized array content. The 'parameters' field in Executable > >> should be declared as volatile and there should be a single read from it > >> and a single write to it in the privateGetParameters() method (you need > >> a local variable to hold intermediate states)... > >> > >> Regards, Peter > >> > >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: > >>> Thanks to all for initial reviews; however, it appears that the version > >>> you saw was somewhat stale. I've applied your comments (and some > >>> changes that I'd made since the version that was posted). > >>> > >>> Please take a second look. > >>> > >>> Thanks, > >>> Eric > >>> > >>> > >>> On 01/10/13 04:19, Peter Levart wrote: > >>>> Hello Eric, > >>>> > >>>> You must have missed my comment from the previous webrev: > >>>> > >>>> 292 private Parameter[] privateGetParameters() { > >>>> 293 if (null != parameters) > >>>> 294 return parameters.get(); > >>>> > >>>> If/when the 'parameters' SoftReference is cleared, the method will be > >>>> returning null forever after... > >>>> > >>>> You should also retrieve the referent and check for it's presence > before > >>>> returning it: > >>>> > >>>> Parameter[] res; > >>>> if (parameters != null && (res = parameters.get()) != null) > >>>> return res; > >>>> ... > >>>> ... > >>>> > >>>> Regards, Peter > >>>> > >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: > >>>>> Hello, > >>>>> > >>>>> Please review the core reflection API implementation of parameter > >>>>> reflection. This is the final component of method parameter > reflection. > >>>>> This was posted for review before, then delayed until the check-in > for > >>>>> JDK-8004728 (hotspot support for parameter reflection), which > occurred > >>>>> yesterday. > >>>>> > >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* > >>>>> jdk8/tl; therefore, it may be a while before the changeset makes its > way > >>>>> into jdk8/tl. > >>>>> > >>>>> Also note: since the check-in of JDK-8004727 (javac support for > >>>>> parameter reflection), there has been a failure in the tests for > >>>>> Pack200. This is being addressed in a fix contributed by Kumar, > which I > >>>>> believe has also been posted for review. > >>>>> > >>>>> The open webrev is here: > >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 > >>>>> > >>>>> The feature request is here: > >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 > >>>>> > >>>>> The latest version of the spec can be found here: > >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Eric > >> > From stuart.marks at oracle.com Fri Jan 11 02:25:42 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 10 Jan 2013 18:25:42 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50EF12D1.8010305@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> Message-ID: <50EF7826.2050809@oracle.com> FYI, if the file is moved using 'hg mv' then 'hg log -f' will show the history across the rename, and 'hg diff --git' will show the rename plus diffs instead of all-lines-deleted followed by all-lines-added. Looks like this was done using rm + add instead of mv. Too late now, oh well. s'marks On 1/10/13 11:13 AM, Brent Christian wrote: > Thanks, Naoto. > > AFAICT, in a case like this there where a file is moved *and* changes are made > to it, webrev shows that the new file is renamed from the old file, but doesn't > provide cdiffs/sdiffs/etc for the code changes. > > 'hg diff' behaves the same way WRT the code changes - it tells you that the old > file was removed and the new file was added, but you don't get code diffs for > the changes. > > (Interestingly, the NetBeans editor seemed to figure out what was happening.) > > That's how it works for me, anyway. > > -Brent > > On 1/10/13 10:27 AM, Naoto Sato wrote: >> Looks good to me. >> >> BTW, I thought that webrev would effectively extract the diffs even when >> files were moved around. >> >> Naoto >> >> On 1/10/13 9:49 AM, Brent Christian wrote: >>> Hi, >>> >>> The test case for 8003228 fails in certain environments. Also the >>> version that was pushed was missing a couple small changes. >>> >>> The code changes to fix these issues are here: >>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >>> >>> The test case will also be moved from java/util/Properties/ to >>> java/lang/System/. Webrev wouldn't do well showing that part of the >>> change, so it's not reflected there. Instead I generated a webrev to >>> better show the code changes. >>> >>> Thanks, >>> -Brent >>> >> From Lance.Andersen at oracle.com Fri Jan 11 02:24:23 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Thu, 10 Jan 2013 21:24:23 -0500 Subject: Fwd: code review request : 8003147 port fix for BCEL bug 39695 References: <50EF7724.3030705@oracle.com> Message-ID: <466DC384-746E-43A1-A66A-8763E82321B0@oracle.com> Looks good > > -------- Original Message -------- > Subject: code review request : 8003147 port fix for BCEL bug 39695 > Date: Mon, 10 Dec 2012 15:25:54 +0900 > From: David Buck > To: core-libs-dev at openjdk.java.net > > Hi! > > I would like to request a code review of my JDK8 fix for the following > issue: > > [ 8003147 : port fix for BCEL bug 39695 to our copy bundled as part of > jaxp ] > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003147 > > In addition to the fix that the BCEL project had for this issue, I > needed to "port" some of their support for LocalVariableTypeTable:s to > our copy of BCEL as well. Implementing support for LVTT is very > straightforward and does not add much to the complexity or risk of this > change (especially considering the limited scope of jaxp's use of BCEL). > > Here is the webrev for my fix: > > [ Code Review for jaxp ] > http://cr.openjdk.java.net/~dbuck/8003147/webrev.00/ > > My understanding is that the test cases for our copy of the jaxp code > are handled in a separate repository / test suite. I have been in > contact with Patrick Zhang (Oracle QA) and Joe Wang and have provided a > junit test for this issue as requested. Please see bug report for a > simpler (non-junit) test-case. If for some reason anyone wants to see > the junit-based test, please let me know and I can provide a copy of > that as well. > > Best Regards, > -Buck From eric.mccorkle at oracle.com Fri Jan 11 02:47:22 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 10 Jan 2013 21:47:22 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> Message-ID: <50EF7D3A.8080106@oracle.com> On 01/10/13 19:50, Vitaly Davidovich wrote: > Hi Eric, > > Parameter.equals() doesn't need null check - instanceof covers that already. > Removed. > Maybe this has been mentioned already, but personally I'm not a fan of > null checks such as "if (null == x)" - I prefer the null on the right > hand side, but that's just stylistic. Changed. > > Perhaps I'm looking at a stale webrev but > Executable.privateGetParameters() reads and writes from/to the volatile > field more than once. I think Peter already mentioned that it should > use one read into a local and one write to publish the final version to > the field (it can return the temp as well). > You weren't. From a pure correctness standpoint, there is nothing wrong with what is there. getParameters0 is a constant function, and parameters is writable only if null. Hence, we only every see one nontrivial write to it. But you are right, it should probably be reduced to a single write, for performance reasons (to avoid unnecessary memory barriers). Therefore, I changed it. However, I won't be able to refresh the webrev until tomorrow. > Thanks > > Sent from my phone > > On Jan 10, 2013 6:05 PM, "Eric McCorkle" > wrote: > > The webrev has been refreshed with the solution I describe below > implemented. Please make additional comments. > > On 01/10/13 17:29, Eric McCorkle wrote: > > Good catch there. I made the field volatile, and I also did the same > > with the cache fields in Parameter. > > > > It is possible with what exists that you could wind up with multiple > > copies of identical parameter objects in existence. It goes something > > like this > > > > thread A sees Executable.parameters is null, goes into the VM to > get them > > thread B sees Executable.parameters is null, goes into the VM to > get them > > thread A stores to Executable.parameters > > thread B stores to Executable.parameters > > > > Since Parameters is immutable (except for its caches, which will > always > > end up containing the same things), this *should* have no visible > > effects, unless someone does == instead of .equals. > > > > This can be avoided by doing a CAS, which is more expensive > execution-wise. > > > > My vote is to *not* do a CAS, and accept that (in extremely rare > cases, > > even as far as concurrency-related anomalies go), you may end up with > > duplicates, and document that very well. > > > > Thoughts? > > > > On 01/10/13 16:10, Peter Levart wrote: > >> Hello Eric, > >> > >> I have another one. Although not very likely, the reference to > the same > >> Method/Constructor can be shared among multiple threads. The > publication > >> of a parameters array should therefore be performed via a > volatile write > >> / volatile read, otherwise it can happen that some thread sees > >> half-initialized array content. The 'parameters' field in Executable > >> should be declared as volatile and there should be a single read > from it > >> and a single write to it in the privateGetParameters() method > (you need > >> a local variable to hold intermediate states)... > >> > >> Regards, Peter > >> > >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: > >>> Thanks to all for initial reviews; however, it appears that the > version > >>> you saw was somewhat stale. I've applied your comments (and some > >>> changes that I'd made since the version that was posted). > >>> > >>> Please take a second look. > >>> > >>> Thanks, > >>> Eric > >>> > >>> > >>> On 01/10/13 04:19, Peter Levart wrote: > >>>> Hello Eric, > >>>> > >>>> You must have missed my comment from the previous webrev: > >>>> > >>>> 292 private Parameter[] privateGetParameters() { > >>>> 293 if (null != parameters) > >>>> 294 return parameters.get(); > >>>> > >>>> If/when the 'parameters' SoftReference is cleared, the method > will be > >>>> returning null forever after... > >>>> > >>>> You should also retrieve the referent and check for it's > presence before > >>>> returning it: > >>>> > >>>> Parameter[] res; > >>>> if (parameters != null && (res = parameters.get()) != null) > >>>> return res; > >>>> ... > >>>> ... > >>>> > >>>> Regards, Peter > >>>> > >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: > >>>>> Hello, > >>>>> > >>>>> Please review the core reflection API implementation of parameter > >>>>> reflection. This is the final component of method parameter > reflection. > >>>>> This was posted for review before, then delayed until the > check-in for > >>>>> JDK-8004728 (hotspot support for parameter reflection), which > occurred > >>>>> yesterday. > >>>>> > >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* > >>>>> jdk8/tl; therefore, it may be a while before the changeset > makes its way > >>>>> into jdk8/tl. > >>>>> > >>>>> Also note: since the check-in of JDK-8004727 (javac support for > >>>>> parameter reflection), there has been a failure in the tests for > >>>>> Pack200. This is being addressed in a fix contributed by > Kumar, which I > >>>>> believe has also been posted for review. > >>>>> > >>>>> The open webrev is here: > >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 > >>>>> > >>>>> The feature request is here: > >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 > >>>>> > >>>>> The latest version of the spec can be found here: > >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Eric > >> > From xueming.shen at oracle.com Fri Jan 11 02:50:38 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Jan 2013 18:50:38 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50EF12D1.8010305@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> Message-ID: <50EF7DFE.2040301@oracle.com> I may not understand the real issue here, but if you list the "new" and "old" file names at the same line in the "list" file, the webrev should generate the diff for you. -Sherman On 1/10/13 11:13 AM, Brent Christian wrote: > Thanks, Naoto. > > AFAICT, in a case like this there where a file is moved *and* changes > are made to it, webrev shows that the new file is renamed from the old > file, but doesn't provide cdiffs/sdiffs/etc for the code changes. > > 'hg diff' behaves the same way WRT the code changes - it tells you > that the old file was removed and the new file was added, but you > don't get code diffs for the changes. > > (Interestingly, the NetBeans editor seemed to figure out what was > happening.) > > That's how it works for me, anyway. > > -Brent > > On 1/10/13 10:27 AM, Naoto Sato wrote: >> Looks good to me. >> >> BTW, I thought that webrev would effectively extract the diffs even when >> files were moved around. >> >> Naoto >> >> On 1/10/13 9:49 AM, Brent Christian wrote: >>> Hi, >>> >>> The test case for 8003228 fails in certain environments. Also the >>> version that was pushed was missing a couple small changes. >>> >>> The code changes to fix these issues are here: >>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >>> >>> The test case will also be moved from java/util/Properties/ to >>> java/lang/System/. Webrev wouldn't do well showing that part of the >>> change, so it's not reflected there. Instead I generated a webrev to >>> better show the code changes. >>> >>> Thanks, >>> -Brent >>> >> From vitalyd at gmail.com Fri Jan 11 03:23:04 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 10 Jan 2013 22:23:04 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF7D3A.8080106@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> Message-ID: Yup, avoiding multiple read/write ops on the volatile field is just for perf - I saw the null guard there; sorry, should've been clearer. Thanks Sent from my phone On Jan 10, 2013 9:47 PM, "Eric McCorkle" wrote: > On 01/10/13 19:50, Vitaly Davidovich wrote: > > Hi Eric, > > > > Parameter.equals() doesn't need null check - instanceof covers that > already. > > > > Removed. > > > Maybe this has been mentioned already, but personally I'm not a fan of > > null checks such as "if (null == x)" - I prefer the null on the right > > hand side, but that's just stylistic. > > Changed. > > > > > Perhaps I'm looking at a stale webrev but > > Executable.privateGetParameters() reads and writes from/to the volatile > > field more than once. I think Peter already mentioned that it should > > use one read into a local and one write to publish the final version to > > the field (it can return the temp as well). > > > > You weren't. From a pure correctness standpoint, there is nothing wrong > with what is there. getParameters0 is a constant function, and > parameters is writable only if null. Hence, we only every see one > nontrivial write to it. > > But you are right, it should probably be reduced to a single write, for > performance reasons (to avoid unnecessary memory barriers). Therefore, > I changed it. > > However, I won't be able to refresh the webrev until tomorrow. > > > Thanks > > > > Sent from my phone > > > > On Jan 10, 2013 6:05 PM, "Eric McCorkle" > > wrote: > > > > The webrev has been refreshed with the solution I describe below > > implemented. Please make additional comments. > > > > On 01/10/13 17:29, Eric McCorkle wrote: > > > Good catch there. I made the field volatile, and I also did the > same > > > with the cache fields in Parameter. > > > > > > It is possible with what exists that you could wind up with > multiple > > > copies of identical parameter objects in existence. It goes > something > > > like this > > > > > > thread A sees Executable.parameters is null, goes into the VM to > > get them > > > thread B sees Executable.parameters is null, goes into the VM to > > get them > > > thread A stores to Executable.parameters > > > thread B stores to Executable.parameters > > > > > > Since Parameters is immutable (except for its caches, which will > > always > > > end up containing the same things), this *should* have no visible > > > effects, unless someone does == instead of .equals. > > > > > > This can be avoided by doing a CAS, which is more expensive > > execution-wise. > > > > > > My vote is to *not* do a CAS, and accept that (in extremely rare > > cases, > > > even as far as concurrency-related anomalies go), you may end up > with > > > duplicates, and document that very well. > > > > > > Thoughts? > > > > > > On 01/10/13 16:10, Peter Levart wrote: > > >> Hello Eric, > > >> > > >> I have another one. Although not very likely, the reference to > > the same > > >> Method/Constructor can be shared among multiple threads. The > > publication > > >> of a parameters array should therefore be performed via a > > volatile write > > >> / volatile read, otherwise it can happen that some thread sees > > >> half-initialized array content. The 'parameters' field in > Executable > > >> should be declared as volatile and there should be a single read > > from it > > >> and a single write to it in the privateGetParameters() method > > (you need > > >> a local variable to hold intermediate states)... > > >> > > >> Regards, Peter > > >> > > >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: > > >>> Thanks to all for initial reviews; however, it appears that the > > version > > >>> you saw was somewhat stale. I've applied your comments (and some > > >>> changes that I'd made since the version that was posted). > > >>> > > >>> Please take a second look. > > >>> > > >>> Thanks, > > >>> Eric > > >>> > > >>> > > >>> On 01/10/13 04:19, Peter Levart wrote: > > >>>> Hello Eric, > > >>>> > > >>>> You must have missed my comment from the previous webrev: > > >>>> > > >>>> 292 private Parameter[] privateGetParameters() { > > >>>> 293 if (null != parameters) > > >>>> 294 return parameters.get(); > > >>>> > > >>>> If/when the 'parameters' SoftReference is cleared, the method > > will be > > >>>> returning null forever after... > > >>>> > > >>>> You should also retrieve the referent and check for it's > > presence before > > >>>> returning it: > > >>>> > > >>>> Parameter[] res; > > >>>> if (parameters != null && (res = parameters.get()) != null) > > >>>> return res; > > >>>> ... > > >>>> ... > > >>>> > > >>>> Regards, Peter > > >>>> > > >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: > > >>>>> Hello, > > >>>>> > > >>>>> Please review the core reflection API implementation of > parameter > > >>>>> reflection. This is the final component of method parameter > > reflection. > > >>>>> This was posted for review before, then delayed until the > > check-in for > > >>>>> JDK-8004728 (hotspot support for parameter reflection), which > > occurred > > >>>>> yesterday. > > >>>>> > > >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, > *not* > > >>>>> jdk8/tl; therefore, it may be a while before the changeset > > makes its way > > >>>>> into jdk8/tl. > > >>>>> > > >>>>> Also note: since the check-in of JDK-8004727 (javac support for > > >>>>> parameter reflection), there has been a failure in the tests > for > > >>>>> Pack200. This is being addressed in a fix contributed by > > Kumar, which I > > >>>>> believe has also been posted for review. > > >>>>> > > >>>>> The open webrev is here: > > >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 > > >>>>> > > >>>>> The feature request is here: > > >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 > > >>>>> > > >>>>> The latest version of the spec can be found here: > > >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> Eric > > >> > > > From jonathan.gibbons at oracle.com Fri Jan 11 03:39:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:39:02 +0000 Subject: hg: jdk8/tl/langtools: 8004834: Add doclint support into javadoc Message-ID: <20130111033905.490CC471B9@hg.openjdk.java.net> Changeset: fc4cb1577ad6 Author: jjg Date: 2013-01-10 19:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fc4cb1577ad6 8004834: Add doclint support into javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.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/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/5093723/T5093723.java ! test/com/sun/javadoc/testBadSourceFile/TestBadSourceFile.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testReturnTag/TestReturnTag.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnBadParamNames/TestWarnBadParamNames.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/tools/javadoc/6958836/Test.java ! test/tools/javadoc/6964914/Test.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/MaxWarns.java ! test/tools/javadoc/T6551367.java + test/tools/javadoc/doclint/DocLintTest.java From jonathan.gibbons at oracle.com Fri Jan 11 03:39:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:39:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130111033950.61FC7471BA@hg.openjdk.java.net> Changeset: c6e8a518c3cd Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6e8a518c3cd 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! make/docs/Makefile Changeset: c9308137ad9e Author: jjg Date: 2013-01-10 19:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9308137ad9e Merge - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From jonathan.gibbons at oracle.com Fri Jan 11 03:40:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:40:02 +0000 Subject: hg: jdk8/tl: 8004834: Add doclint support into javadoc Message-ID: <20130111034003.326D6471BB@hg.openjdk.java.net> Changeset: 1129fb75f611 Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1129fb75f611 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! common/makefiles/javadoc/Javadoc.gmk From vikram.aroskar at oracle.com Fri Jan 11 05:10:12 2013 From: vikram.aroskar at oracle.com (vikram.aroskar at oracle.com) Date: Fri, 11 Jan 2013 05:10:12 +0000 Subject: hg: jdk8/tl/jaxp: 8003147: port fix for BCEL bug 39695 Message-ID: <20130111051017.93E67471DA@hg.openjdk.java.net> Changeset: 47738fa4d411 Author: dbuck Date: 2013-01-10 20:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/47738fa4d411 8003147: port fix for BCEL bug 39695 Summary: Added support for Local Variable Type Table so that BCEL library can be used to modify methods with generics-related debug data without violating class file format Reviewed-by: lancea ! src/com/sun/org/apache/bcel/internal/Constants.java ! src/com/sun/org/apache/bcel/internal/classfile/Attribute.java ! src/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java ! src/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java + src/com/sun/org/apache/bcel/internal/classfile/LocalVariableTypeTable.java ! src/com/sun/org/apache/bcel/internal/classfile/Visitor.java ! src/com/sun/org/apache/bcel/internal/generic/MethodGen.java From joe.darcy at oracle.com Fri Jan 11 05:12:36 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 11 Jan 2013 05:12:36 +0000 Subject: hg: jdk8/tl/jdk: 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Message-ID: <20130111051247.E47CC471DB@hg.openjdk.java.net> Changeset: 86c563dc70ca Author: darcy Date: 2013-01-10 21:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c563dc70ca 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Reviewed-by: jjg ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java From xueming.shen at oracle.com Fri Jan 11 05:47:20 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Jan 2013 21:47:20 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50ECA935.2030703@oracle.com> References: <50ECA935.2030703@oracle.com> Message-ID: <50EFA768.40006@oracle.com> Vladimir, (1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here should not change the real "sp" after "break+return". (2) maybe the "overflowflag" can just be replaced by "CoderResult cr", with init value of CoderResult.UNDERFLOW;", then "cr = CoderResult.OVERFLOW" at ln#182, and simply "return cr" at ln#193, without another "if". (3) change in encode(char[], int, int, byte[]) does not appear to be correct. I doubt the slen will get calculated correctly for next round of encoding, if "len" is used for the src side length without considering the "ret". Maybe ln#259 should be slen = Math.min(sl -sp, dst.length - dp); I'm surprised we only get 1.6% boost. Maybe it is worth measuring the performance of some "small" buf/array encoding? I'm a little concerned that the overhead may slow down the small size buf/array encoding. There is a simple benchmark for String en/decoding at test/sun/nio/cs/StrCodingBenchmark. -Sherman On 1/8/13 3:18 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev > > Move encoding loop into separate method for which VM will use > intrinsic on x86. I want to get agreement on this jdk change before I > submit VM part. > > This gives +1.6% performance improvement on SPECjAppServer2004 on x86. > Note, even without intrinsic (on other platforms) JIT will produce > better code for this loop. > > Thanks, > Vladimir From xueming.shen at oracle.com Fri Jan 11 06:10:26 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 10 Jan 2013 22:10:26 -0800 (PST) Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EECA46.7090308@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50ED5B78.2040309@CoSoCo.de> <50EDB105.5080606@oracle.com> <50EE03CE.4040701@CoSoCo.de> <50EE0D6C.40503@oracle.com> <50EE235B.2080301@oracle.com> <50EECA46.7090308@CoSoCo.de> Message-ID: <50EFACD1.30704@oracle.com> On 1/10/13 6:03 AM, Ulf Zibis wrote: > > About overflow: > There was a question some posts above, if it is necessary at all. Can > one please answer? > Other error results do not have higher priority. But you need to keep encoding/updating the buffer until you really "overflow", since the overflow "detecting" in the proposed change is at the very beginning, yes, something need to be marked, not necessary to be a boolean "overflow" though. Personally I think a direct CoderResult cr may be better as I suggested in my previous email. -Sherman > The question is, if other error results have higher priority over > CoderResult.OVERFLOW. > > -Ulf From zhouyx at linux.vnet.ibm.com Fri Jan 11 10:02:38 2013 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Fri, 11 Jan 2013 18:02:38 +0800 Subject: PPC Linux 64 needs -fsigned-char option for gcc In-Reply-To: References: Message-ID: Hi Volker, Do you have any idea about the modification considering David Holmes' comments ? On Fri, Dec 21, 2012 at 6:48 PM, Volker Simonis wrote: > Hi Sean, > > honestly speaking, I wasn't aware of this problem until now and I just > checked that we currently don't use this option, neither internally nor in > our port. > I found the following nice explanation of the issue: > http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html > > It seems that you only get problems if your programs relies on the fact > that 'char' is either unsigned or signed. I suppose that the current > OpenJDK doesn't rely on such assumptions (which is good) because we didn't > saw any of them until now. > > If I understand you right, you add some closed code the the JDK which has > problems because it makes such assumptions. Is that right? If yes, you > should probably first fix that code in the way described in the referenced > document. Wouldn't that be possible? > > Regarding your patch: I suppose you took it against an original JDK and > not our port, because in our port we already have the following lines (at > least in http://hg.openjdk.java.net/ppc-aix-port/jdk7u//jdk because we > haven't started to work on jdk8 until now) > > CFLAGS_REQUIRED_arm += -fsigned-char -D_LITTLE_ENDIAN > CFLAGS_REQUIRED_ppc += -fsigned-char -D_BIG_ENDIAN > CFLAGS_REQUIRED_ppc64 += -m64 > LDFLAGS_COMMON_ppc64 += -m64 -L/lib64 -Wl,-melf64ppc > > Notice that we don't set '-D_BIG_ENDIAN' because it is the default. > > Didn't you observed your problems with jdk7 on Linux/PPC? I think we > should patch JDK7 first if this is really necessary. > > Regards, > Volker > > > > On Fri, Dec 21, 2012 at 10:40 AM, Sean Chou wrote: > >> Hello, >> >> We found -fsigned-char is added to ppc platform, but not added to ppc64 >> platform. As they are different platforms, I think it is needed for ppc64 >> as well. Currently I just added one line modification as follow, but there >> may be more places to modify. If some one can give some comments, I can >> make a complete webrev. >> >> The buggy scenario we found needs closed code to reproduce, so it is not >> reproduced with current openjdk build on ppc linux from AIX porting >> project. I tested with ibmjdk, the patch works. >> >> I found CFLAGS_REQUIRED_ppc is from changeset >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/54d8193f177b . Is it >> enough to add ppc64 option for places ppc appears in that patch? >> >> ///////////////////////// the patch //////////////////////// >> >> diff --git a/make/common/Defs-linux.gmk b/make/common/Defs-linux.gmk >> --- a/make/common/Defs-linux.gmk >> +++ b/make/common/Defs-linux.gmk >> @@ -196,6 +196,7 @@ >> LDFLAGS_COMMON_sparc += -m32 -mcpu=v9 >> CFLAGS_REQUIRED_arm += -fsigned-char -D_LITTLE_ENDIAN >> CFLAGS_REQUIRED_ppc += -fsigned-char -D_BIG_ENDIAN >> +CFLAGS_REQUIRED_ppc64 += -fsigned-char -D_BIG_ENDIAN >> ifeq ($(ZERO_BUILD), true) >> CFLAGS_REQUIRED = $(ZERO_ARCHFLAG) >> ifeq ($(ZERO_ENDIANNESS), little) >> >> >> -- >> >> Best Regards, >> Sean Chou >> > > -- Best Regards, Sean Chou From peter.levart at gmail.com Fri Jan 11 11:29:55 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Jan 2013 12:29:55 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF40E2.1060305@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> Message-ID: <50EFF7B3.3040501@gmail.com> On 01/10/2013 11:29 PM, Eric McCorkle wrote: > Good catch there. I made the field volatile, and I also did the same > with the cache fields in Parameter. > > It is possible with what exists that you could wind up with multiple > copies of identical parameter objects in existence. It goes something > like this > > thread A sees Executable.parameters is null, goes into the VM to get them > thread B sees Executable.parameters is null, goes into the VM to get them > thread A stores to Executable.parameters > thread B stores to Executable.parameters > > Since Parameters is immutable (except for its caches, which will always > end up containing the same things), this *should* have no visible > effects, unless someone does == instead of .equals. > > This can be avoided by doing a CAS, which is more expensive execution-wise. > > My vote is to *not* do a CAS, and accept that (in extremely rare cases, > even as far as concurrency-related anomalies go), you may end up with > duplicates, and document that very well. > > Thoughts? We can not guarantee the singularity of a Parameter instance (like for example Class instance) because of various reasons, among them: - the Method/Constructor instances that are available via public API are allways copied and caching of Parameter instances is performed on each individual copied Method/Constructor instance. I already had a patch which moved caching of annotations, for example, to the "root" instance, but it has been postponed because of big anticipated annotations changes comming in. Maybe we should revisit the same also for Parameter instances when time comes... - even if caching of Parameters/annotations is performed on "root" instances, the root instances can change over time because they are cached in j.l.Class via a SoftReference which can be cleared and new "root" instances can be created for the same methods/constructors. So as currently stands, the effort to do CAS for Parameters is useless. Regards, Peter > > On 01/10/13 16:10, Peter Levart wrote: >> Hello Eric, >> >> I have another one. Although not very likely, the reference to the same >> Method/Constructor can be shared among multiple threads. The publication >> of a parameters array should therefore be performed via a volatile write >> / volatile read, otherwise it can happen that some thread sees >> half-initialized array content. The 'parameters' field in Executable >> should be declared as volatile and there should be a single read from it >> and a single write to it in the privateGetParameters() method (you need >> a local variable to hold intermediate states)... >> >> Regards, Peter >> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>> Thanks to all for initial reviews; however, it appears that the version >>> you saw was somewhat stale. I've applied your comments (and some >>> changes that I'd made since the version that was posted). >>> >>> Please take a second look. >>> >>> Thanks, >>> Eric >>> >>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>> Hello Eric, >>>> >>>> You must have missed my comment from the previous webrev: >>>> >>>> 292 private Parameter[] privateGetParameters() { >>>> 293 if (null != parameters) >>>> 294 return parameters.get(); >>>> >>>> If/when the 'parameters' SoftReference is cleared, the method will be >>>> returning null forever after... >>>> >>>> You should also retrieve the referent and check for it's presence before >>>> returning it: >>>> >>>> Parameter[] res; >>>> if (parameters != null && (res = parameters.get()) != null) >>>> return res; >>>> ... >>>> ... >>>> >>>> Regards, Peter >>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>>> Hello, >>>>> >>>>> Please review the core reflection API implementation of parameter >>>>> reflection. This is the final component of method parameter reflection. >>>>> This was posted for review before, then delayed until the check-in for >>>>> JDK-8004728 (hotspot support for parameter reflection), which occurred >>>>> yesterday. >>>>> >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >>>>> jdk8/tl; therefore, it may be a while before the changeset makes its way >>>>> into jdk8/tl. >>>>> >>>>> Also note: since the check-in of JDK-8004727 (javac support for >>>>> parameter reflection), there has been a failure in the tests for >>>>> Pack200. This is being addressed in a fix contributed by Kumar, which I >>>>> believe has also been posted for review. >>>>> >>>>> The open webrev is here: >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >>>>> >>>>> The feature request is here: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >>>>> >>>>> The latest version of the spec can be found here: >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>>> >>>>> >>>>> Thanks, >>>>> Eric From alan.bateman at oracle.com Fri Jan 11 12:29:23 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Jan 2013 12:29:23 +0000 Subject: hg: jdk8/tl/jdk: 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Message-ID: <20130111123228.01781471E5@hg.openjdk.java.net> Changeset: 0ca2e39a110d Author: alanb Date: 2013-01-11 12:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ca2e39a110d 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! test/java/nio/file/Files/Misc.java From daniel.fuchs at oracle.com Fri Jan 11 13:59:25 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2013 14:59:25 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50EDD376.9060401@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> <50EDD376.9060401@oracle.com> Message-ID: <50F01ABD.9070602@oracle.com> On 1/9/13 9:30 PM, Mandy Chung wrote: > L152: would it be better to replace "the base service class name" with > the classname (i.e. javax.xml.XMLEventFactory) > > 152 * If {@code factoryId} is the base service class name, > 153 * use the service-provider loading facilities, defined by the > 154 * {@link java.util.ServiceLoader} class, to attempt to locate > and load an > 155 * implementation of the service. Hi Mandy, This is done. I have updated the webrev: best regards, -- daniel From daniel.fuchs at oracle.com Fri Jan 11 14:27:41 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2013 15:27:41 +0100 Subject: RFR: javax.xml.xpath: Using ServiceLoader to load JAXP XPath factories (7169894: JAXP Plugability Layer: using service loader) Message-ID: <50F0215D.2030600@oracle.com> Hi, Here is a new webrev in the series that addresses using ServiceLoader in JAXP for JDK 8. 7169894: JAXP Plugability Layer: using service loader This changeset addresses modification in the javax.xml.xpath package. This changes are very similar to the changes proposed for the javax.xml.validation package, except that here we didn't need to add a new Error class. best regards, -- daniel previous unreviewed webrevs in the series: [5] javax.xml.validation: previous reviewed webrevs: [1] javax.xml.parsers: [2] javax.xml.datatype: [3] javax.xml.stream [4] javax.xml.transform From Alan.Bateman at oracle.com Fri Jan 11 14:37:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jan 2013 14:37:51 +0000 Subject: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools In-Reply-To: <50EF2660.1040406@oracle.com> References: <50EEBECE.6030001@oracle.com> <50EF2660.1040406@oracle.com> Message-ID: <50F023BF.9010805@oracle.com> On 10/01/2013 20:36, Chris Hegarty wrote: > Skimming over this it looks fine to me. > > You could add TESTTOOLVMOPTS while there ;-) > > -Chris. We probably should have added ${TESTTOOLVMOPTS} as part of Mark Sheppard's work in 8003890. Anyway as I'm adding ${TESTJAVACOPTS} to the javac usages then it's easy to add ${TESTTOOLVMOPTS} too, I've also added to the other "tools" used by the tests that I'm changing. There are a couple of cases where it's not possible to do this, for example there are number of older security tests that compile with -source and -target 1.4 and these will conflict if I run jtreg with something like -javacoptions:"-profile compac1". I've created a bug for this as it's not clear why these tests want to target 1.4. Another one is the security tests that use NSS where VM options such as -d64 will not work because the tests are choosing the architecture of the shared library to use. I've also added a few ${TESTVMOPTS} to tests that were skipped by 8003890. Interestingly, adding this to the Formater/Basic.sh test exposes a bug in Formatter when running the tests with -esa. Previously the VM options were being dropped on the floor so this was not noticed. I've created a bug for this too and added the test to the ProblemList.txt until this gets fixed. The webrev is updated: http://cr.openjdk.java.net/~alanb/8005978/webrev/ I'd like to this out of the way, and I will of course run the tests on all platforms before pushing it. -Alan. From chris.hegarty at oracle.com Fri Jan 11 15:09:37 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 15:09:37 +0000 Subject: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools In-Reply-To: <50F023BF.9010805@oracle.com> References: <50EEBECE.6030001@oracle.com> <50EF2660.1040406@oracle.com> <50F023BF.9010805@oracle.com> Message-ID: <50F02B31.7040008@oracle.com> Wow, you've actually done it, I was only joking! The updated webrev ( after a quick skim ) looks great. -Chris. On 11/01/2013 14:37, Alan Bateman wrote: > On 10/01/2013 20:36, Chris Hegarty wrote: >> Skimming over this it looks fine to me. >> >> You could add TESTTOOLVMOPTS while there ;-) >> >> -Chris. > We probably should have added ${TESTTOOLVMOPTS} as part of Mark > Sheppard's work in 8003890. > > Anyway as I'm adding ${TESTJAVACOPTS} to the javac usages then it's easy > to add ${TESTTOOLVMOPTS} too, I've also added to the other "tools" used > by the tests that I'm changing. There are a couple of cases where it's > not possible to do this, for example there are number of older security > tests that compile with -source and -target 1.4 and these will conflict > if I run jtreg with something like -javacoptions:"-profile compac1". > I've created a bug for this as it's not clear why these tests want to > target 1.4. Another one is the security tests that use NSS where VM > options such as -d64 will not work because the tests are choosing the > architecture of the shared library to use. > > I've also added a few ${TESTVMOPTS} to tests that were skipped by > 8003890. Interestingly, adding this to the Formater/Basic.sh test > exposes a bug in Formatter when running the tests with -esa. Previously > the VM options were being dropped on the floor so this was not noticed. > I've created a bug for this too and added the test to the > ProblemList.txt until this gets fixed. > > The webrev is updated: > > http://cr.openjdk.java.net/~alanb/8005978/webrev/ > > I'd like to this out of the way, and I will of course run the tests on > all platforms before pushing it. > > -Alan. > From chris.hegarty at oracle.com Fri Jan 11 15:25:15 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 15:25:15 +0000 Subject: 8001666: Add updateAndGet, getAndUpdate, getAndAccumulate, accumulateAndGet methods to AtomicXXX Message-ID: <50F02EDB.5000703@oracle.com> This proposal is to add lambda-compatible atomics and accumulators to the ActomicXXX classes. Webrev: http://cr.openjdk.java.net/~chegar/8001666/ver.00/webrev/ SpecDiff: http://cr.openjdk.java.net/~chegar/8001666/ver.00/specdiff/java/util/concurrent/atomic/package-summary.html This changes come from Doug, with the exception of the AtomicXXXArray classes. Doug, You have not added the equivalent atomics and accumulators the Array classes. Was this intentional? I no reason why this shouldn't be done, so went ahead and did it. -Chris. From dl at cs.oswego.edu Fri Jan 11 15:35:55 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 11 Jan 2013 10:35:55 -0500 Subject: 8001666: Add updateAndGet, getAndUpdate, getAndAccumulate, accumulateAndGet methods to AtomicXXX In-Reply-To: <50F02EDB.5000703@oracle.com> References: <50F02EDB.5000703@oracle.com> Message-ID: <50F0315B.30202@cs.oswego.edu> On 01/11/13 10:25, Chris Hegarty wrote: > This proposal is to add lambda-compatible atomics and accumulators to the > ActomicXXX classes. > > Webrev: > http://cr.openjdk.java.net/~chegar/8001666/ver.00/webrev/ > SpecDiff: > > Doug, > You have not added the equivalent atomics and accumulators the Array classes. > Was this intentional? I no reason why this shouldn't be done, so went ahead and > did it. > I vaguely recall doing these but they must not have gotten committed :-) Thanks for make sure they are all complete. (Life will be easier when lambda, hotspot, and tl start converging...) -Doug From chris.hegarty at oracle.com Fri Jan 11 15:42:34 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 15:42:34 +0000 Subject: 8001666: Add updateAndGet, getAndUpdate, getAndAccumulate, accumulateAndGet methods to AtomicXXX In-Reply-To: <50F0315B.30202@cs.oswego.edu> References: <50F02EDB.5000703@oracle.com> <50F0315B.30202@cs.oswego.edu> Message-ID: <50F032EA.7040809@oracle.com> On 11/01/2013 15:35, Doug Lea wrote: > On 01/11/13 10:25, Chris Hegarty wrote: >> This proposal is to add lambda-compatible atomics and accumulators to the >> ActomicXXX classes. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8001666/ver.00/webrev/ >> SpecDiff: >> >> Doug, >> You have not added the equivalent atomics and accumulators the Array >> classes. >> Was this intentional? I no reason why this shouldn't be done, so went >> ahead and >> did it. >> > > I vaguely recall doing these but they must not have gotten committed :-) > Thanks for make sure they are all complete. > (Life will be easier when lambda, hotspot, and tl start converging...) Nearly there, with the Atomics anyway. Once these changes get in, for once jdk8/tl will be ahead of the others (first time ever?) I'll create and send you a patch based on your CVS, to make it easier for you to update to the new intrinsics and these Array changes. -Chris. > > -Doug > > > From eric.mccorkle at oracle.com Fri Jan 11 15:54:19 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 11 Jan 2013 10:54:19 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50EF7D3A.8080106@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> Message-ID: <50F035AB.6090400@oracle.com> The webrev has been updated again. The multiple writes to parameters have been removed, and the tests have been expanded to look at inner classes, and to test modifiers. Please look over it again. Test-wise, I've got a clean run on JPRT (there were some failures in lambda stuff, but I've been seeing that for some time now). On 01/10/13 21:47, Eric McCorkle wrote: > On 01/10/13 19:50, Vitaly Davidovich wrote: >> Hi Eric, >> >> Parameter.equals() doesn't need null check - instanceof covers that already. >> > > Removed. > >> Maybe this has been mentioned already, but personally I'm not a fan of >> null checks such as "if (null == x)" - I prefer the null on the right >> hand side, but that's just stylistic. > > Changed. > >> >> Perhaps I'm looking at a stale webrev but >> Executable.privateGetParameters() reads and writes from/to the volatile >> field more than once. I think Peter already mentioned that it should >> use one read into a local and one write to publish the final version to >> the field (it can return the temp as well). >> > > You weren't. From a pure correctness standpoint, there is nothing wrong > with what is there. getParameters0 is a constant function, and > parameters is writable only if null. Hence, we only every see one > nontrivial write to it. > > But you are right, it should probably be reduced to a single write, for > performance reasons (to avoid unnecessary memory barriers). Therefore, > I changed it. > > However, I won't be able to refresh the webrev until tomorrow. > >> Thanks >> >> Sent from my phone >> >> On Jan 10, 2013 6:05 PM, "Eric McCorkle" > > wrote: >> >> The webrev has been refreshed with the solution I describe below >> implemented. Please make additional comments. >> >> On 01/10/13 17:29, Eric McCorkle wrote: >> > Good catch there. I made the field volatile, and I also did the same >> > with the cache fields in Parameter. >> > >> > It is possible with what exists that you could wind up with multiple >> > copies of identical parameter objects in existence. It goes something >> > like this >> > >> > thread A sees Executable.parameters is null, goes into the VM to >> get them >> > thread B sees Executable.parameters is null, goes into the VM to >> get them >> > thread A stores to Executable.parameters >> > thread B stores to Executable.parameters >> > >> > Since Parameters is immutable (except for its caches, which will >> always >> > end up containing the same things), this *should* have no visible >> > effects, unless someone does == instead of .equals. >> > >> > This can be avoided by doing a CAS, which is more expensive >> execution-wise. >> > >> > My vote is to *not* do a CAS, and accept that (in extremely rare >> cases, >> > even as far as concurrency-related anomalies go), you may end up with >> > duplicates, and document that very well. >> > >> > Thoughts? >> > >> > On 01/10/13 16:10, Peter Levart wrote: >> >> Hello Eric, >> >> >> >> I have another one. Although not very likely, the reference to >> the same >> >> Method/Constructor can be shared among multiple threads. The >> publication >> >> of a parameters array should therefore be performed via a >> volatile write >> >> / volatile read, otherwise it can happen that some thread sees >> >> half-initialized array content. The 'parameters' field in Executable >> >> should be declared as volatile and there should be a single read >> from it >> >> and a single write to it in the privateGetParameters() method >> (you need >> >> a local variable to hold intermediate states)... >> >> >> >> Regards, Peter >> >> >> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >> >>> Thanks to all for initial reviews; however, it appears that the >> version >> >>> you saw was somewhat stale. I've applied your comments (and some >> >>> changes that I'd made since the version that was posted). >> >>> >> >>> Please take a second look. >> >>> >> >>> Thanks, >> >>> Eric >> >>> >> >>> >> >>> On 01/10/13 04:19, Peter Levart wrote: >> >>>> Hello Eric, >> >>>> >> >>>> You must have missed my comment from the previous webrev: >> >>>> >> >>>> 292 private Parameter[] privateGetParameters() { >> >>>> 293 if (null != parameters) >> >>>> 294 return parameters.get(); >> >>>> >> >>>> If/when the 'parameters' SoftReference is cleared, the method >> will be >> >>>> returning null forever after... >> >>>> >> >>>> You should also retrieve the referent and check for it's >> presence before >> >>>> returning it: >> >>>> >> >>>> Parameter[] res; >> >>>> if (parameters != null && (res = parameters.get()) != null) >> >>>> return res; >> >>>> ... >> >>>> ... >> >>>> >> >>>> Regards, Peter >> >>>> >> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >> >>>>> Hello, >> >>>>> >> >>>>> Please review the core reflection API implementation of parameter >> >>>>> reflection. This is the final component of method parameter >> reflection. >> >>>>> This was posted for review before, then delayed until the >> check-in for >> >>>>> JDK-8004728 (hotspot support for parameter reflection), which >> occurred >> >>>>> yesterday. >> >>>>> >> >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >> >>>>> jdk8/tl; therefore, it may be a while before the changeset >> makes its way >> >>>>> into jdk8/tl. >> >>>>> >> >>>>> Also note: since the check-in of JDK-8004727 (javac support for >> >>>>> parameter reflection), there has been a failure in the tests for >> >>>>> Pack200. This is being addressed in a fix contributed by >> Kumar, which I >> >>>>> believe has also been posted for review. >> >>>>> >> >>>>> The open webrev is here: >> >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >> >>>>> >> >>>>> The feature request is here: >> >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >> >>>>> >> >>>>> The latest version of the spec can be found here: >> >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> Eric >> >> >> From chris.hegarty at oracle.com Fri Jan 11 16:18:42 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 16:18:42 +0000 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50EB24AA.40101@cs.oswego.edu> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> Message-ID: <50F03B62.5060308@oracle.com> Now with explicit disclaimer on DoubleA* "The order of accumulation within or across threads is not guaranteed. Thus, this class may not be applicable if numerical stability is required when combining values of substantially different orders of magnitude." Updated spec: http://cr.openjdk.java.net/~chegar/8005311/ver.02/specdiff/java/util/concurrent/atomic/package-summary.html Unless there are any objections, I'll finalize this spec and seek approval for its integration. -Chris. On 07/01/2013 19:40, Doug Lea wrote: > On 01/07/13 14:07, Joe Darcy wrote: >> Hello, >> >> I had a question about how the double accumulation logic was intended >> to be >> used. I've taken a quick look at the code and it uses straightforward >> "sum = >> sum + nextValue" code to compute the double sum. Summing doubles >> values with >> code numerical accuracy is surprisingly tricky and if the >> DoubleAccumulator code >> is meant for wide use, I'd recommend using instead some form of >> compensated >> summation: >> >> http://en.wikipedia.org/wiki/Kahan_summation_algorithm >> > > I'm sympathetic... > Complete lack of control over arithmetic issues (here and for > plain atomics) led me to resist offering Double versions for > years. But many people are content with the scalability vs > numerical stability tradeoffs intrinsic here (and I think > unsolvable). I suppose it could stand an explicit disclaimer > rather than the implicit one there now. > > How about: "The order of accumulation of sums across threads is > uncontrolled. Numerical stability of results is not guaranteed > when values of substantially different orders of magnitude are > combined" > > Or something better? > > -Doug > From peter.levart at gmail.com Fri Jan 11 16:25:12 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Jan 2013 17:25:12 +0100 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F035AB.6090400@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> Message-ID: <50F03CE8.2010805@gmail.com> On 01/11/2013 04:54 PM, Eric McCorkle wrote: > The webrev has been updated again. > > The multiple writes to parameters have been removed, and the tests have > been expanded to look at inner classes, and to test modifiers. > > Please look over it again. Hello Eric, You still have 2 reads of volatile even in fast path. I would do it this way: private Parameter[] privateGetParameters() { Parameter[] tmp = parameters; // one and only read if (tmp != null) return tmp; // Otherwise, go to the JVM to get them tmp = getParameters0(); // If we get back nothing, then synthesize parameters if (tmp == null) { final int num = getParameterCount(); tmp = new Parameter[num]; for (int i = 0; i < num; i++) // TODO: is there a way to synthetically derive the // modifiers? Probably not in the general case, since // we'd have no way of knowing about them, but there // may be specific cases. tmp[i] = new Parameter("arg" + i, 0, this, i); // This avoids possible races from seeing a // half-initialized parameters cache. } parameters = tmp; return tmp; } Regards, Peter > > Test-wise, I've got a clean run on JPRT (there were some failures in > lambda stuff, but I've been seeing that for some time now). > > On 01/10/13 21:47, Eric McCorkle wrote: >> On 01/10/13 19:50, Vitaly Davidovich wrote: >>> Hi Eric, >>> >>> Parameter.equals() doesn't need null check - instanceof covers that already. >>> >> Removed. >> >>> Maybe this has been mentioned already, but personally I'm not a fan of >>> null checks such as "if (null == x)" - I prefer the null on the right >>> hand side, but that's just stylistic. >> Changed. >> >>> Perhaps I'm looking at a stale webrev but >>> Executable.privateGetParameters() reads and writes from/to the volatile >>> field more than once. I think Peter already mentioned that it should >>> use one read into a local and one write to publish the final version to >>> the field (it can return the temp as well). >>> >> You weren't. From a pure correctness standpoint, there is nothing wrong >> with what is there. getParameters0 is a constant function, and >> parameters is writable only if null. Hence, we only every see one >> nontrivial write to it. >> >> But you are right, it should probably be reduced to a single write, for >> performance reasons (to avoid unnecessary memory barriers). Therefore, >> I changed it. >> >> However, I won't be able to refresh the webrev until tomorrow. >> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >> > wrote: >>> >>> The webrev has been refreshed with the solution I describe below >>> implemented. Please make additional comments. >>> >>> On 01/10/13 17:29, Eric McCorkle wrote: >>> > Good catch there. I made the field volatile, and I also did the same >>> > with the cache fields in Parameter. >>> > >>> > It is possible with what exists that you could wind up with multiple >>> > copies of identical parameter objects in existence. It goes something >>> > like this >>> > >>> > thread A sees Executable.parameters is null, goes into the VM to >>> get them >>> > thread B sees Executable.parameters is null, goes into the VM to >>> get them >>> > thread A stores to Executable.parameters >>> > thread B stores to Executable.parameters >>> > >>> > Since Parameters is immutable (except for its caches, which will >>> always >>> > end up containing the same things), this *should* have no visible >>> > effects, unless someone does == instead of .equals. >>> > >>> > This can be avoided by doing a CAS, which is more expensive >>> execution-wise. >>> > >>> > My vote is to *not* do a CAS, and accept that (in extremely rare >>> cases, >>> > even as far as concurrency-related anomalies go), you may end up with >>> > duplicates, and document that very well. >>> > >>> > Thoughts? >>> > >>> > On 01/10/13 16:10, Peter Levart wrote: >>> >> Hello Eric, >>> >> >>> >> I have another one. Although not very likely, the reference to >>> the same >>> >> Method/Constructor can be shared among multiple threads. The >>> publication >>> >> of a parameters array should therefore be performed via a >>> volatile write >>> >> / volatile read, otherwise it can happen that some thread sees >>> >> half-initialized array content. The 'parameters' field in Executable >>> >> should be declared as volatile and there should be a single read >>> from it >>> >> and a single write to it in the privateGetParameters() method >>> (you need >>> >> a local variable to hold intermediate states)... >>> >> >>> >> Regards, Peter >>> >> >>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>> >>> Thanks to all for initial reviews; however, it appears that the >>> version >>> >>> you saw was somewhat stale. I've applied your comments (and some >>> >>> changes that I'd made since the version that was posted). >>> >>> >>> >>> Please take a second look. >>> >>> >>> >>> Thanks, >>> >>> Eric >>> >>> >>> >>> >>> >>> On 01/10/13 04:19, Peter Levart wrote: >>> >>>> Hello Eric, >>> >>>> >>> >>>> You must have missed my comment from the previous webrev: >>> >>>> >>> >>>> 292 private Parameter[] privateGetParameters() { >>> >>>> 293 if (null != parameters) >>> >>>> 294 return parameters.get(); >>> >>>> >>> >>>> If/when the 'parameters' SoftReference is cleared, the method >>> will be >>> >>>> returning null forever after... >>> >>>> >>> >>>> You should also retrieve the referent and check for it's >>> presence before >>> >>>> returning it: >>> >>>> >>> >>>> Parameter[] res; >>> >>>> if (parameters != null && (res = parameters.get()) != null) >>> >>>> return res; >>> >>>> ... >>> >>>> ... >>> >>>> >>> >>>> Regards, Peter >>> >>>> >>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>> >>>>> Hello, >>> >>>>> >>> >>>>> Please review the core reflection API implementation of parameter >>> >>>>> reflection. This is the final component of method parameter >>> reflection. >>> >>>>> This was posted for review before, then delayed until the >>> check-in for >>> >>>>> JDK-8004728 (hotspot support for parameter reflection), which >>> occurred >>> >>>>> yesterday. >>> >>>>> >>> >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, *not* >>> >>>>> jdk8/tl; therefore, it may be a while before the changeset >>> makes its way >>> >>>>> into jdk8/tl. >>> >>>>> >>> >>>>> Also note: since the check-in of JDK-8004727 (javac support for >>> >>>>> parameter reflection), there has been a failure in the tests for >>> >>>>> Pack200. This is being addressed in a fix contributed by >>> Kumar, which I >>> >>>>> believe has also been posted for review. >>> >>>>> >>> >>>>> The open webrev is here: >>> >>>>> http://cr.openjdk.java.net/~coleenp/JDK-8004729 >>> >>>>> >>> >>>>> The feature request is here: >>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=8004729 >>> >>>>> >>> >>>>> The latest version of the spec can be found here: >>> >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Eric >>> >> >>> From peter.levart at gmail.com Fri Jan 11 16:35:30 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 11 Jan 2013 17:35:30 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F03B62.5060308@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> Message-ID: <50F03F52.1050504@gmail.com> On 01/11/2013 05:18 PM, Chris Hegarty wrote: > Now with explicit disclaimer on DoubleA* > > "The order of accumulation within or across threads is not guaranteed. > Thus, this class may not be applicable if numerical stability is > required when combining values of substantially different orders of > magnitude." It doesn't have to be substantially different order of magnitude. For example: double a = 1d/3d; double b = 1d; double x = a + a + a + b; double y = b + a + a + a; System.out.println(x == y); ... prints false. Regards, Peter > > Updated spec: > > http://cr.openjdk.java.net/~chegar/8005311/ver.02/specdiff/java/util/concurrent/atomic/package-summary.html > > > Unless there are any objections, I'll finalize this spec and seek > approval for its integration. > > -Chris. > > On 07/01/2013 19:40, Doug Lea wrote: >> On 01/07/13 14:07, Joe Darcy wrote: >>> Hello, >>> >>> I had a question about how the double accumulation logic was intended >>> to be >>> used. I've taken a quick look at the code and it uses straightforward >>> "sum = >>> sum + nextValue" code to compute the double sum. Summing doubles >>> values with >>> code numerical accuracy is surprisingly tricky and if the >>> DoubleAccumulator code >>> is meant for wide use, I'd recommend using instead some form of >>> compensated >>> summation: >>> >>> http://en.wikipedia.org/wiki/Kahan_summation_algorithm >>> >> >> I'm sympathetic... >> Complete lack of control over arithmetic issues (here and for >> plain atomics) led me to resist offering Double versions for >> years. But many people are content with the scalability vs >> numerical stability tradeoffs intrinsic here (and I think >> unsolvable). I suppose it could stand an explicit disclaimer >> rather than the implicit one there now. >> >> How about: "The order of accumulation of sums across threads is >> uncontrolled. Numerical stability of results is not guaranteed >> when values of substantially different orders of magnitude are >> combined" >> >> Or something better? >> >> -Doug >> From vitalyd at gmail.com Fri Jan 11 16:54:05 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 11 Jan 2013 11:54:05 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F03CE8.2010805@gmail.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> Message-ID: Yes that's exactly what I'm looking for as well. Sent from my phone On Jan 11, 2013 11:25 AM, "Peter Levart" wrote: > On 01/11/2013 04:54 PM, Eric McCorkle wrote: > >> The webrev has been updated again. >> >> The multiple writes to parameters have been removed, and the tests have >> been expanded to look at inner classes, and to test modifiers. >> >> Please look over it again. >> > > Hello Eric, > > You still have 2 reads of volatile even in fast path. I would do it this > way: > > > private Parameter[] privateGetParameters() { > Parameter[] tmp = parameters; // one and only read > if (tmp != null) > return tmp; > > // Otherwise, go to the JVM to get them > tmp = getParameters0(); > > // If we get back nothing, then synthesize parameters > if (tmp == null) { > final int num = getParameterCount(); > tmp = new Parameter[num]; > for (int i = 0; i < num; i++) > // TODO: is there a way to synthetically derive the > // modifiers? Probably not in the general case, since > // we'd have no way of knowing about them, but there > // may be specific cases. > tmp[i] = new Parameter("arg" + i, 0, this, i); > // This avoids possible races from seeing a > // half-initialized parameters cache. > } > > parameters = tmp; > > return tmp; > } > > > Regards, Peter > > >> Test-wise, I've got a clean run on JPRT (there were some failures in >> lambda stuff, but I've been seeing that for some time now). >> >> On 01/10/13 21:47, Eric McCorkle wrote: >> >>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>> >>>> Hi Eric, >>>> >>>> Parameter.equals() doesn't need null check - instanceof covers that >>>> already. >>>> >>>> Removed. >>> >>> Maybe this has been mentioned already, but personally I'm not a fan of >>>> null checks such as "if (null == x)" - I prefer the null on the right >>>> hand side, but that's just stylistic. >>>> >>> Changed. >>> >>> Perhaps I'm looking at a stale webrev but >>>> Executable.**privateGetParameters() reads and writes from/to the >>>> volatile >>>> field more than once. I think Peter already mentioned that it should >>>> use one read into a local and one write to publish the final version to >>>> the field (it can return the temp as well). >>>> >>>> You weren't. From a pure correctness standpoint, there is nothing >>> wrong >>> with what is there. getParameters0 is a constant function, and >>> parameters is writable only if null. Hence, we only every see one >>> nontrivial write to it. >>> >>> But you are right, it should probably be reduced to a single write, for >>> performance reasons (to avoid unnecessary memory barriers). Therefore, >>> I changed it. >>> >>> However, I won't be able to refresh the webrev until tomorrow. >>> >>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>> >> wrote: >>>> >>>> The webrev has been refreshed with the solution I describe below >>>> implemented. Please make additional comments. >>>> >>>> On 01/10/13 17:29, Eric McCorkle wrote: >>>> > Good catch there. I made the field volatile, and I also did the >>>> same >>>> > with the cache fields in Parameter. >>>> > >>>> > It is possible with what exists that you could wind up with >>>> multiple >>>> > copies of identical parameter objects in existence. It goes >>>> something >>>> > like this >>>> > >>>> > thread A sees Executable.parameters is null, goes into the VM to >>>> get them >>>> > thread B sees Executable.parameters is null, goes into the VM to >>>> get them >>>> > thread A stores to Executable.parameters >>>> > thread B stores to Executable.parameters >>>> > >>>> > Since Parameters is immutable (except for its caches, which will >>>> always >>>> > end up containing the same things), this *should* have no visible >>>> > effects, unless someone does == instead of .equals. >>>> > >>>> > This can be avoided by doing a CAS, which is more expensive >>>> execution-wise. >>>> > >>>> > My vote is to *not* do a CAS, and accept that (in extremely rare >>>> cases, >>>> > even as far as concurrency-related anomalies go), you may end up >>>> with >>>> > duplicates, and document that very well. >>>> > >>>> > Thoughts? >>>> > >>>> > On 01/10/13 16:10, Peter Levart wrote: >>>> >> Hello Eric, >>>> >> >>>> >> I have another one. Although not very likely, the reference to >>>> the same >>>> >> Method/Constructor can be shared among multiple threads. The >>>> publication >>>> >> of a parameters array should therefore be performed via a >>>> volatile write >>>> >> / volatile read, otherwise it can happen that some thread sees >>>> >> half-initialized array content. The 'parameters' field in >>>> Executable >>>> >> should be declared as volatile and there should be a single read >>>> from it >>>> >> and a single write to it in the privateGetParameters() method >>>> (you need >>>> >> a local variable to hold intermediate states)... >>>> >> >>>> >> Regards, Peter >>>> >> >>>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>>> >>> Thanks to all for initial reviews; however, it appears that the >>>> version >>>> >>> you saw was somewhat stale. I've applied your comments (and >>>> some >>>> >>> changes that I'd made since the version that was posted). >>>> >>> >>>> >>> Please take a second look. >>>> >>> >>>> >>> Thanks, >>>> >>> Eric >>>> >>> >>>> >>> >>>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>> >>>> Hello Eric, >>>> >>>> >>>> >>>> You must have missed my comment from the previous webrev: >>>> >>>> >>>> >>>> 292 private Parameter[] privateGetParameters() { >>>> >>>> 293 if (null != parameters) >>>> >>>> 294 return parameters.get(); >>>> >>>> >>>> >>>> If/when the 'parameters' SoftReference is cleared, the method >>>> will be >>>> >>>> returning null forever after... >>>> >>>> >>>> >>>> You should also retrieve the referent and check for it's >>>> presence before >>>> >>>> returning it: >>>> >>>> >>>> >>>> Parameter[] res; >>>> >>>> if (parameters != null && (res = parameters.get()) != null) >>>> >>>> return res; >>>> >>>> ... >>>> >>>> ... >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>> >>>>> Hello, >>>> >>>>> >>>> >>>>> Please review the core reflection API implementation of >>>> parameter >>>> >>>>> reflection. This is the final component of method parameter >>>> reflection. >>>> >>>>> This was posted for review before, then delayed until the >>>> check-in for >>>> >>>>> JDK-8004728 (hotspot support for parameter reflection), which >>>> occurred >>>> >>>>> yesterday. >>>> >>>>> >>>> >>>>> Note: The check-in of JDK-8004728 was into hsx/hotspot-rt, >>>> *not* >>>> >>>>> jdk8/tl; therefore, it may be a while before the changeset >>>> makes its way >>>> >>>>> into jdk8/tl. >>>> >>>>> >>>> >>>>> Also note: since the check-in of JDK-8004727 (javac support >>>> for >>>> >>>>> parameter reflection), there has been a failure in the tests >>>> for >>>> >>>>> Pack200. This is being addressed in a fix contributed by >>>> Kumar, which I >>>> >>>>> believe has also been posted for review. >>>> >>>>> >>>> >>>>> The open webrev is here: >>>> >>>>> http://cr.openjdk.java.net/~**coleenp/JDK-8004729 >>>> >>>>> >>>> >>>>> The feature request is here: >>>> >>>>> http://bugs.sun.com/view_bug.**do?bug_id=8004729 >>>> >>>>> >>>> >>>>> The latest version of the spec can be found here: >>>> >>>>> http://cr.openjdk.java.net/~**abuckley/8misc.pdf >>>> >>>>> >>>> >>>>> >>>> >>>>> Thanks, >>>> >>>>> Eric >>>> >> >>>> >>>> > From dl at cs.oswego.edu Fri Jan 11 16:57:50 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 11 Jan 2013 11:57:50 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F03F52.1050504@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> Message-ID: <50F0448E.5060108@cs.oswego.edu> On 01/11/13 11:35, Peter Levart wrote: > On 01/11/2013 05:18 PM, Chris Hegarty wrote: >> Now with explicit disclaimer on DoubleA* >> >> "The order of accumulation within or across threads is not guaranteed. Thus, >> this class may not be applicable if numerical stability is required when >> combining values of substantially different orders of magnitude." > > It doesn't have to be substantially different order of magnitude. > Thanks. Chris, please add "especially": "The order of accumulation within or across threads is not guaranteed. Thus, this class may not be applicable if numerical stability is required, especially when combining values of substantially different orders of magnitude." -Doug From Alan.Bateman at oracle.com Fri Jan 11 16:58:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jan 2013 16:58:37 +0000 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50ED7E7C.1030803@oracle.com> References: <50ED7E7C.1030803@oracle.com> Message-ID: <50F044BD.30503@oracle.com> On 09/01/2013 14:28, Daniel Fuchs wrote: > Hi, > > Here is a new webrev in the series that addresses using ServiceLoader in > JAXP for JDK 8. > > 7169894: JAXP Plugability Layer: using service loader > > This changeset addresses modification in the javax.xml.validation > package. > > It is a bit more complex than the changes required for the other > packages because the newInstance methods takes an additional > schemaLanguage parameter, and therefore we need to loop over > the providers in order to find one that supports the language. > > > > > > Also this particular package did not have any specific configuration > error to throw in case of misconfiguration (the xpath package in which > the logic is very similar had one for instance), so we're adding a new > SchemaFactoryConfigurationError for that purpose. I've taken an initial look at this and I'm wondering about SchemeFactory.newInstance throwing SchemaFactoryConfigurationError. Technically this is an incompatible change but in practical terms it may not be concern as this provider interface may not be used very much. Joe Wang - have you come across SchemaFactory implementations, I'm trying to get a feel for how much this is used, if ever. -Alan From eric.mccorkle at oracle.com Fri Jan 11 17:03:34 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 11 Jan 2013 12:03:34 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> Message-ID: <50F045E6.40709@oracle.com> Update should be visible now. On 01/11/13 11:54, Vitaly Davidovich wrote: > Yes that's exactly what I'm looking for as well. > > Sent from my phone > > On Jan 11, 2013 11:25 AM, "Peter Levart" > wrote: > > On 01/11/2013 04:54 PM, Eric McCorkle wrote: > > The webrev has been updated again. > > The multiple writes to parameters have been removed, and the > tests have > been expanded to look at inner classes, and to test modifiers. > > Please look over it again. > > > Hello Eric, > > You still have 2 reads of volatile even in fast path. I would do it > this way: > > > private Parameter[] privateGetParameters() { > Parameter[] tmp = parameters; // one and only read > if (tmp != null) > return tmp; > > // Otherwise, go to the JVM to get them > tmp = getParameters0(); > > // If we get back nothing, then synthesize parameters > if (tmp == null) { > final int num = getParameterCount(); > tmp = new Parameter[num]; > for (int i = 0; i < num; i++) > // TODO: is there a way to synthetically derive the > // modifiers? Probably not in the general case, since > // we'd have no way of knowing about them, but there > // may be specific cases. > tmp[i] = new Parameter("arg" + i, 0, this, i); > // This avoids possible races from seeing a > // half-initialized parameters cache. > } > > parameters = tmp; > > return tmp; > } > > > Regards, Peter > > > Test-wise, I've got a clean run on JPRT (there were some failures in > lambda stuff, but I've been seeing that for some time now). > > On 01/10/13 21:47, Eric McCorkle wrote: > > On 01/10/13 19:50, Vitaly Davidovich wrote: > > Hi Eric, > > Parameter.equals() doesn't need null check - instanceof > covers that already. > > Removed. > > Maybe this has been mentioned already, but personally > I'm not a fan of > null checks such as "if (null == x)" - I prefer the null > on the right > hand side, but that's just stylistic. > > Changed. > > Perhaps I'm looking at a stale webrev but > Executable.__privateGetParameters() reads and writes > from/to the volatile > field more than once. I think Peter already mentioned > that it should > use one read into a local and one write to publish the > final version to > the field (it can return the temp as well). > > You weren't. From a pure correctness standpoint, there is > nothing wrong > with what is there. getParameters0 is a constant function, and > parameters is writable only if null. Hence, we only every > see one > nontrivial write to it. > > But you are right, it should probably be reduced to a single > write, for > performance reasons (to avoid unnecessary memory barriers). > Therefore, > I changed it. > > However, I won't be able to refresh the webrev until tomorrow. > > Thanks > > Sent from my phone > > On Jan 10, 2013 6:05 PM, "Eric McCorkle" > > >> wrote: > > The webrev has been refreshed with the solution I > describe below > implemented. Please make additional comments. > > On 01/10/13 17:29, Eric McCorkle wrote: > > Good catch there. I made the field volatile, and > I also did the same > > with the cache fields in Parameter. > > > > It is possible with what exists that you could > wind up with multiple > > copies of identical parameter objects in > existence. It goes something > > like this > > > > thread A sees Executable.parameters is null, goes > into the VM to > get them > > thread B sees Executable.parameters is null, goes > into the VM to > get them > > thread A stores to Executable.parameters > > thread B stores to Executable.parameters > > > > Since Parameters is immutable (except for its > caches, which will > always > > end up containing the same things), this *should* > have no visible > > effects, unless someone does == instead of .equals. > > > > This can be avoided by doing a CAS, which is more > expensive > execution-wise. > > > > My vote is to *not* do a CAS, and accept that (in > extremely rare > cases, > > even as far as concurrency-related anomalies go), > you may end up with > > duplicates, and document that very well. > > > > Thoughts? > > > > On 01/10/13 16:10, Peter Levart wrote: > >> Hello Eric, > >> > >> I have another one. Although not very likely, > the reference to > the same > >> Method/Constructor can be shared among multiple > threads. The > publication > >> of a parameters array should therefore be > performed via a > volatile write > >> / volatile read, otherwise it can happen that > some thread sees > >> half-initialized array content. The 'parameters' > field in Executable > >> should be declared as volatile and there should > be a single read > from it > >> and a single write to it in the > privateGetParameters() method > (you need > >> a local variable to hold intermediate states)... > >> > >> Regards, Peter > >> > >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: > >>> Thanks to all for initial reviews; however, it > appears that the > version > >>> you saw was somewhat stale. I've applied your > comments (and some > >>> changes that I'd made since the version that > was posted). > >>> > >>> Please take a second look. > >>> > >>> Thanks, > >>> Eric > >>> > >>> > >>> On 01/10/13 04:19, Peter Levart wrote: > >>>> Hello Eric, > >>>> > >>>> You must have missed my comment from the > previous webrev: > >>>> > >>>> 292 private Parameter[] > privateGetParameters() { > >>>> 293 if (null != parameters) > >>>> 294 return parameters.get(); > >>>> > >>>> If/when the 'parameters' SoftReference is > cleared, the method > will be > >>>> returning null forever after... > >>>> > >>>> You should also retrieve the referent and > check for it's > presence before > >>>> returning it: > >>>> > >>>> Parameter[] res; > >>>> if (parameters != null && (res = > parameters.get()) != null) > >>>> return res; > >>>> ... > >>>> ... > >>>> > >>>> Regards, Peter > >>>> > >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: > >>>>> Hello, > >>>>> > >>>>> Please review the core reflection API > implementation of parameter > >>>>> reflection. This is the final component of > method parameter > reflection. > >>>>> This was posted for review before, then > delayed until the > check-in for > >>>>> JDK-8004728 (hotspot support for parameter > reflection), which > occurred > >>>>> yesterday. > >>>>> > >>>>> Note: The check-in of JDK-8004728 was into > hsx/hotspot-rt, *not* > >>>>> jdk8/tl; therefore, it may be a while before > the changeset > makes its way > >>>>> into jdk8/tl. > >>>>> > >>>>> Also note: since the check-in of JDK-8004727 > (javac support for > >>>>> parameter reflection), there has been a > failure in the tests for > >>>>> Pack200. This is being addressed in a fix > contributed by > Kumar, which I > >>>>> believe has also been posted for review. > >>>>> > >>>>> The open webrev is here: > >>>>> > http://cr.openjdk.java.net/~__coleenp/JDK-8004729 > > >>>>> > >>>>> The feature request is here: > >>>>> > http://bugs.sun.com/view_bug.__do?bug_id=8004729 > > >>>>> > >>>>> The latest version of the spec can be found here: > >>>>> > http://cr.openjdk.java.net/~__abuckley/8misc.pdf > > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Eric > >> > > From chris.hegarty at oracle.com Fri Jan 11 17:18:27 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 17:18:27 +0000 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F0448E.5060108@cs.oswego.edu> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> Message-ID: <50F04963.6030302@oracle.com> On 11/01/2013 16:57, Doug Lea wrote: > On 01/11/13 11:35, Peter Levart wrote: >> On 01/11/2013 05:18 PM, Chris Hegarty wrote: >>> Now with explicit disclaimer on DoubleA* >>> >>> "The order of accumulation within or across threads is not >>> guaranteed. Thus, >>> this class may not be applicable if numerical stability is required when >>> combining values of substantially different orders of magnitude." >> >> It doesn't have to be substantially different order of magnitude. >> > > Thanks. Chris, please add "especially": Thanks Doug, done. -Chris. > > "The order of accumulation within or across threads is not guaranteed. > Thus, this class may not be applicable if numerical stability is > required, especially when combining values of substantially different > orders of magnitude." > > > -Doug > From mandy.chung at oracle.com Fri Jan 11 17:23:47 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 11 Jan 2013 09:23:47 -0800 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F01ABD.9070602@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> <50EDD376.9060401@oracle.com> <50F01ABD.9070602@oracle.com> Message-ID: <50F04AA3.7020008@oracle.com> On 1/11/2013 5:59 AM, Daniel Fuchs wrote: > Hi Mandy, > > This is done. I have updated the webrev: > > > > typo in: 242 * If {@code factoryId} is "javax.xml.stream.XMLIntputFactory", Otherwise, looks good. Thanks for the update. Mandy From brent.christian at oracle.com Fri Jan 11 17:50:02 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 11 Jan 2013 09:50:02 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50EF7826.2050809@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> <50EF7826.2050809@oracle.com> Message-ID: <50F050CA.9010202@oracle.com> Thanks, Stuart. I did an 'hg mv' of the directory containing the (two) test files. But I then had to 'hg export' to send the changeset for pushing. I'm guessing that the export wasn't able to preserve the history across the rename. -Brent On 1/10/13 6:25 PM, Stuart Marks wrote: > FYI, if the file is moved using 'hg mv' then 'hg log -f' will show the > history across the rename, and 'hg diff --git' will show the rename plus > diffs instead of all-lines-deleted followed by all-lines-added. Looks > like this was done using rm + add instead of mv. Too late now, oh well. > > s'marks > > On 1/10/13 11:13 AM, Brent Christian wrote: >> Thanks, Naoto. >> >> AFAICT, in a case like this there where a file is moved *and* changes >> are made >> to it, webrev shows that the new file is renamed from the old file, >> but doesn't >> provide cdiffs/sdiffs/etc for the code changes. >> >> 'hg diff' behaves the same way WRT the code changes - it tells you >> that the old >> file was removed and the new file was added, but you don't get code >> diffs for >> the changes. >> >> (Interestingly, the NetBeans editor seemed to figure out what was >> happening.) >> >> That's how it works for me, anyway. >> >> -Brent >> >> On 1/10/13 10:27 AM, Naoto Sato wrote: >>> Looks good to me. >>> >>> BTW, I thought that webrev would effectively extract the diffs even when >>> files were moved around. >>> >>> Naoto >>> >>> On 1/10/13 9:49 AM, Brent Christian wrote: >>>> Hi, >>>> >>>> The test case for 8003228 fails in certain environments. Also the >>>> version that was pushed was missing a couple small changes. >>>> >>>> The code changes to fix these issues are here: >>>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >>>> >>>> The test case will also be moved from java/util/Properties/ to >>>> java/lang/System/. Webrev wouldn't do well showing that part of the >>>> change, so it's not reflected there. Instead I generated a webrev to >>>> better show the code changes. >>>> >>>> Thanks, >>>> -Brent >>>> >>> From chris.hegarty at oracle.com Fri Jan 11 17:54:42 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 11 Jan 2013 17:54:42 +0000 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50F050CA.9010202@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> <50EF7826.2050809@oracle.com> <50F050CA.9010202@oracle.com> Message-ID: <50F051E2.6010606@oracle.com> On 11/01/2013 17:50, Brent Christian wrote: > Thanks, Stuart. > > I did an 'hg mv' of the directory containing the (two) test files. But I > then had to 'hg export' to send the changeset for pushing. I'm guessing Yes, I noticed this before. 'hg export' and 'hg mv' are not friends. -Chris. > that the export wasn't able to preserve the history across the rename. > > -Brent > > On 1/10/13 6:25 PM, Stuart Marks wrote: >> FYI, if the file is moved using 'hg mv' then 'hg log -f' will show the >> history across the rename, and 'hg diff --git' will show the rename plus >> diffs instead of all-lines-deleted followed by all-lines-added. Looks >> like this was done using rm + add instead of mv. Too late now, oh well. >> >> s'marks >> >> On 1/10/13 11:13 AM, Brent Christian wrote: >>> Thanks, Naoto. >>> >>> AFAICT, in a case like this there where a file is moved *and* changes >>> are made >>> to it, webrev shows that the new file is renamed from the old file, >>> but doesn't >>> provide cdiffs/sdiffs/etc for the code changes. >>> >>> 'hg diff' behaves the same way WRT the code changes - it tells you >>> that the old >>> file was removed and the new file was added, but you don't get code >>> diffs for >>> the changes. >>> >>> (Interestingly, the NetBeans editor seemed to figure out what was >>> happening.) >>> >>> That's how it works for me, anyway. >>> >>> -Brent >>> >>> On 1/10/13 10:27 AM, Naoto Sato wrote: >>>> Looks good to me. >>>> >>>> BTW, I thought that webrev would effectively extract the diffs even >>>> when >>>> files were moved around. >>>> >>>> Naoto >>>> >>>> On 1/10/13 9:49 AM, Brent Christian wrote: >>>>> Hi, >>>>> >>>>> The test case for 8003228 fails in certain environments. Also the >>>>> version that was pushed was missing a couple small changes. >>>>> >>>>> The code changes to fix these issues are here: >>>>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >>>>> >>>>> The test case will also be moved from java/util/Properties/ to >>>>> java/lang/System/. Webrev wouldn't do well showing that part of the >>>>> change, so it's not reflected there. Instead I generated a webrev to >>>>> better show the code changes. >>>>> >>>>> Thanks, >>>>> -Brent >>>>> >>>> From brent.christian at oracle.com Fri Jan 11 17:53:18 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 11 Jan 2013 09:53:18 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50EF7DFE.2040301@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> <50EF7DFE.2040301@oracle.com> Message-ID: <50F0518E.8030604@oracle.com> I've been using 'webrev -N' and leaving it to webrev to determine which files to include based on the hg status. I'll try giving webrev a filelist the next time I encounter this situation. Thanks, -Brent On 1/10/13 6:50 PM, Xueming Shen wrote: > I may not understand the real issue here, but if you list the "new" and > "old" file > names at the same line in the "list" file, the webrev should generate > the diff for > you. > > -Sherman > > On 1/10/13 11:13 AM, Brent Christian wrote: >> Thanks, Naoto. >> >> AFAICT, in a case like this there where a file is moved *and* changes >> are made to it, webrev shows that the new file is renamed from the old >> file, but doesn't provide cdiffs/sdiffs/etc for the code changes. >> >> 'hg diff' behaves the same way WRT the code changes - it tells you >> that the old file was removed and the new file was added, but you >> don't get code diffs for the changes. >> >> (Interestingly, the NetBeans editor seemed to figure out what was >> happening.) >> >> That's how it works for me, anyway. >> >> -Brent >> >> On 1/10/13 10:27 AM, Naoto Sato wrote: >>> Looks good to me. >>> >>> BTW, I thought that webrev would effectively extract the diffs even when >>> files were moved around. >>> >>> Naoto >>> >>> On 1/10/13 9:49 AM, Brent Christian wrote: >>>> Hi, >>>> >>>> The test case for 8003228 fails in certain environments. Also the >>>> version that was pushed was missing a couple small changes. >>>> >>>> The code changes to fix these issues are here: >>>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >>>> >>>> The test case will also be moved from java/util/Properties/ to >>>> java/lang/System/. Webrev wouldn't do well showing that part of the >>>> change, so it's not reflected there. Instead I generated a webrev to >>>> better show the code changes. >>>> >>>> Thanks, >>>> -Brent >>>> >>> > From brent.christian at oracle.com Fri Jan 11 17:57:26 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 11 Jan 2013 09:57:26 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50F051E2.6010606@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> <50EF7826.2050809@oracle.com> <50F050CA.9010202@oracle.com> <50F051E2.6010606@oracle.com> Message-ID: <50F05286.604@oracle.com> On 1/11/13 9:54 AM, Chris Hegarty wrote: > On 11/01/2013 17:50, Brent Christian wrote: >> >> I did an 'hg mv' of the directory containing the (two) test files. But I >> then had to 'hg export' to send the changeset for pushing. I'm guessing > > Yes, I noticed this before. 'hg export' and 'hg mv' are not friends. > > -Chris. I see that hg also has a 'bundle' and 'unbundle'. Has anyone used it? Would that have been better in this situation? -Brent >> On 1/10/13 6:25 PM, Stuart Marks wrote: >>> FYI, if the file is moved using 'hg mv' then 'hg log -f' will show the >>> history across the rename, and 'hg diff --git' will show the rename plus >>> diffs instead of all-lines-deleted followed by all-lines-added. Looks >>> like this was done using rm + add instead of mv. Too late now, oh well. >>> >>> s'marks >>> >>> On 1/10/13 11:13 AM, Brent Christian wrote: >>>> Thanks, Naoto. >>>> >>>> AFAICT, in a case like this there where a file is moved *and* changes >>>> are made >>>> to it, webrev shows that the new file is renamed from the old file, >>>> but doesn't >>>> provide cdiffs/sdiffs/etc for the code changes. >>>> >>>> 'hg diff' behaves the same way WRT the code changes - it tells you >>>> that the old >>>> file was removed and the new file was added, but you don't get code >>>> diffs for >>>> the changes. >>>> >>>> (Interestingly, the NetBeans editor seemed to figure out what was >>>> happening.) >>>> >>>> That's how it works for me, anyway. >>>> >>>> -Brent >>>> >>>> On 1/10/13 10:27 AM, Naoto Sato wrote: >>>>> Looks good to me. >>>>> >>>>> BTW, I thought that webrev would effectively extract the diffs even >>>>> when >>>>> files were moved around. >>>>> >>>>> Naoto >>>>> >>>>> On 1/10/13 9:49 AM, Brent Christian wrote: >>>>>> Hi, >>>>>> >>>>>> The test case for 8003228 fails in certain environments. Also the >>>>>> version that was pushed was missing a couple small changes. >>>>>> >>>>>> The code changes to fix these issues are here: >>>>>> http://cr.openjdk.java.net/~bchristi/8005962/webrev.00/ >>>>>> >>>>>> The test case will also be moved from java/util/Properties/ to >>>>>> java/lang/System/. Webrev wouldn't do well showing that part of the >>>>>> change, so it's not reflected there. Instead I generated a webrev to >>>>>> better show the code changes. >>>>>> >>>>>> Thanks, >>>>>> -Brent >>>>>> >>>>> From Ulf.Zibis at CoSoCo.de Fri Jan 11 18:19:04 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 11 Jan 2013 19:19:04 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50EFA768.40006@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> Message-ID: <50F05798.30306@CoSoCo.de> Hi Sherman, Am 11.01.2013 06:47, schrieb Xueming Shen: > (1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here should > not change the real "sp" after "break+return". > (2) maybe the "overflowflag" can just be replaced by "CoderResult cr", with init value > of CoderResult.UNDERFLOW;", then "cr = CoderResult.OVERFLOW" at ln#182, and > simply "return cr" at ln#193, without another "if". I've enhanced your suggestions, see more below... Additionally, some part of encodeArrayLoop(...) maybe could be moved into a separate method, to be reused by encode(char[] src, int sp, int len, byte[] dst). Some of the re-engineering could be adapted to the Decoder methods. > I'm surprised we only get 1.6% boost. Maybe it is worth measuring the performance > of some "small" buf/array encoding? I'm a little concerned that the overhead may > slow down the small size buf/array encoding. There is a simple benchmark for String > en/decoding at test/sun/nio/cs/StrCodingBenchmark. I think we should balance 4 cases in rating the performance: a) few loops, small buf/array b) few loops, big buf/array c) many loops, small buf/array d) many loops, big buf/array In a), b) the loop surrounding code will not be JIT-compiled, so should be optimized for interpreter. In c) d) the loop surrounding code *may be* JIT-compiled and consequtively inline the inner loop, should be verified. In b), d) the small inner loop, as demonstrated below, will be JIT-compiled, regardless if moved into separate method. -Ulf 1) Check for (sp >= sl) is superfluous. ====================================== private static int copyISOs( char[] sa, int sp, byte[] da, int dp, int len) { int i = 0; for (; i < len; i++) { char c = sa[sp++]; // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 break; da[dp++] = (byte)c; } return i; } private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); int sl = sp + sr; byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; try { int ret = copyISOs(sa, sp, da, dp, sr); sp = sp + ret; dp = dp + ret; if (ret != sr) { if (sgp.parse(sa[sp], sa, sp, sl) < 0) return sgp.error(); return sgp.unmappableResult(); } return cr; } finally { src.position(sp - soff); dst.position(dp - doff); } } 2) Avoids sp, dp to be recalculated; shorter surrounding code -> best chance to become JIT-compiled. ====================================== // while inlinig, JIT will erase the surrounding int[] p private static boolean copyISOs( char[] sa, byte[] da, final int[] p, int sl) { for (int sp = p[0], dp = p[1]; sp < sl; sp++) { char c = sa[sp]; // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 return false; da[dp++] = (byte)c; } return true; } private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; try { int sl = sp + sr; final int[] p = { sp, dp }; if (!copyISOs(sa, da, p, sl)) { if (sgp.parse(sa[sp], sa, sp, sl) < 0) return sgp.error(); return sgp.unmappableResult(); } return cr; } finally { src.position(sp - soff); dst.position(dp - doff); } } 3) No more needs try...finally block. ====================================== private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; int sl = sp + sr; for (; sp < sl; sp++) { char c = sa[sp]; // if (c & '\uFF00' != 0) { // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) { // temporary replacement, fast byte-length operation on x86 cr = null; break; } da[dp++] = (byte)c; } src.position(sp - soff); dst.position(dp - doff); return result(cr, sa, sp, sl); } // if adapted, maybe could also be reused in encodeBufferLoop() private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) { return cr != null ? cr : sgp.parse(sa[sp], sa, sp, sl) < 0 ? sgp.error(); : sgp.unmappableResult(); } From joe.darcy at oracle.com Fri Jan 11 18:27:59 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jan 2013 10:27:59 -0800 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F045E6.40709@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> Message-ID: <50F059AF.1000706@oracle.com> Hi Eric, Taking another look at the code, some extra logic / checking is needed in cases where the number of source parameters (non-synthetic and non-synthesized) disagrees with the number of actual parameters at a class file level. For example, if the single source parameter of an inner class constructor is annotated, the annotation should be associated with the *second* parameter since the first class file parameter is a synthesized constructor added by the compiler. I think generally annotations should not be associated with synthesized or synthetic parameters. -Joe On 1/11/2013 9:03 AM, Eric McCorkle wrote: > Update should be visible now. > > On 01/11/13 11:54, Vitaly Davidovich wrote: >> Yes that's exactly what I'm looking for as well. >> >> Sent from my phone >> >> On Jan 11, 2013 11:25 AM, "Peter Levart" > > wrote: >> >> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >> >> The webrev has been updated again. >> >> The multiple writes to parameters have been removed, and the >> tests have >> been expanded to look at inner classes, and to test modifiers. >> >> Please look over it again. >> >> >> Hello Eric, >> >> You still have 2 reads of volatile even in fast path. I would do it >> this way: >> >> >> private Parameter[] privateGetParameters() { >> Parameter[] tmp = parameters; // one and only read >> if (tmp != null) >> return tmp; >> >> // Otherwise, go to the JVM to get them >> tmp = getParameters0(); >> >> // If we get back nothing, then synthesize parameters >> if (tmp == null) { >> final int num = getParameterCount(); >> tmp = new Parameter[num]; >> for (int i = 0; i < num; i++) >> // TODO: is there a way to synthetically derive the >> // modifiers? Probably not in the general case, since >> // we'd have no way of knowing about them, but there >> // may be specific cases. >> tmp[i] = new Parameter("arg" + i, 0, this, i); >> // This avoids possible races from seeing a >> // half-initialized parameters cache. >> } >> >> parameters = tmp; >> >> return tmp; >> } >> >> >> Regards, Peter >> >> >> Test-wise, I've got a clean run on JPRT (there were some failures in >> lambda stuff, but I've been seeing that for some time now). >> >> On 01/10/13 21:47, Eric McCorkle wrote: >> >> On 01/10/13 19:50, Vitaly Davidovich wrote: >> >> Hi Eric, >> >> Parameter.equals() doesn't need null check - instanceof >> covers that already. >> >> Removed. >> >> Maybe this has been mentioned already, but personally >> I'm not a fan of >> null checks such as "if (null == x)" - I prefer the null >> on the right >> hand side, but that's just stylistic. >> >> Changed. >> >> Perhaps I'm looking at a stale webrev but >> Executable.__privateGetParameters() reads and writes >> from/to the volatile >> field more than once. I think Peter already mentioned >> that it should >> use one read into a local and one write to publish the >> final version to >> the field (it can return the temp as well). >> >> You weren't. From a pure correctness standpoint, there is >> nothing wrong >> with what is there. getParameters0 is a constant function, and >> parameters is writable only if null. Hence, we only every >> see one >> nontrivial write to it. >> >> But you are right, it should probably be reduced to a single >> write, for >> performance reasons (to avoid unnecessary memory barriers). >> Therefore, >> I changed it. >> >> However, I won't be able to refresh the webrev until tomorrow. >> >> Thanks >> >> Sent from my phone >> >> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >> >> > >> wrote: >> >> The webrev has been refreshed with the solution I >> describe below >> implemented. Please make additional comments. >> >> On 01/10/13 17:29, Eric McCorkle wrote: >> > Good catch there. I made the field volatile, and >> I also did the same >> > with the cache fields in Parameter. >> > >> > It is possible with what exists that you could >> wind up with multiple >> > copies of identical parameter objects in >> existence. It goes something >> > like this >> > >> > thread A sees Executable.parameters is null, goes >> into the VM to >> get them >> > thread B sees Executable.parameters is null, goes >> into the VM to >> get them >> > thread A stores to Executable.parameters >> > thread B stores to Executable.parameters >> > >> > Since Parameters is immutable (except for its >> caches, which will >> always >> > end up containing the same things), this *should* >> have no visible >> > effects, unless someone does == instead of .equals. >> > >> > This can be avoided by doing a CAS, which is more >> expensive >> execution-wise. >> > >> > My vote is to *not* do a CAS, and accept that (in >> extremely rare >> cases, >> > even as far as concurrency-related anomalies go), >> you may end up with >> > duplicates, and document that very well. >> > >> > Thoughts? >> > >> > On 01/10/13 16:10, Peter Levart wrote: >> >> Hello Eric, >> >> >> >> I have another one. Although not very likely, >> the reference to >> the same >> >> Method/Constructor can be shared among multiple >> threads. The >> publication >> >> of a parameters array should therefore be >> performed via a >> volatile write >> >> / volatile read, otherwise it can happen that >> some thread sees >> >> half-initialized array content. The 'parameters' >> field in Executable >> >> should be declared as volatile and there should >> be a single read >> from it >> >> and a single write to it in the >> privateGetParameters() method >> (you need >> >> a local variable to hold intermediate states)... >> >> >> >> Regards, Peter >> >> >> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >> >>> Thanks to all for initial reviews; however, it >> appears that the >> version >> >>> you saw was somewhat stale. I've applied your >> comments (and some >> >>> changes that I'd made since the version that >> was posted). >> >>> >> >>> Please take a second look. >> >>> >> >>> Thanks, >> >>> Eric >> >>> >> >>> >> >>> On 01/10/13 04:19, Peter Levart wrote: >> >>>> Hello Eric, >> >>>> >> >>>> You must have missed my comment from the >> previous webrev: >> >>>> >> >>>> 292 private Parameter[] >> privateGetParameters() { >> >>>> 293 if (null != parameters) >> >>>> 294 return parameters.get(); >> >>>> >> >>>> If/when the 'parameters' SoftReference is >> cleared, the method >> will be >> >>>> returning null forever after... >> >>>> >> >>>> You should also retrieve the referent and >> check for it's >> presence before >> >>>> returning it: >> >>>> >> >>>> Parameter[] res; >> >>>> if (parameters != null && (res = >> parameters.get()) != null) >> >>>> return res; >> >>>> ... >> >>>> ... >> >>>> >> >>>> Regards, Peter >> >>>> >> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >> >>>>> Hello, >> >>>>> >> >>>>> Please review the core reflection API >> implementation of parameter >> >>>>> reflection. This is the final component of >> method parameter >> reflection. >> >>>>> This was posted for review before, then >> delayed until the >> check-in for >> >>>>> JDK-8004728 (hotspot support for parameter >> reflection), which >> occurred >> >>>>> yesterday. >> >>>>> >> >>>>> Note: The check-in of JDK-8004728 was into >> hsx/hotspot-rt, *not* >> >>>>> jdk8/tl; therefore, it may be a while before >> the changeset >> makes its way >> >>>>> into jdk8/tl. >> >>>>> >> >>>>> Also note: since the check-in of JDK-8004727 >> (javac support for >> >>>>> parameter reflection), there has been a >> failure in the tests for >> >>>>> Pack200. This is being addressed in a fix >> contributed by >> Kumar, which I >> >>>>> believe has also been posted for review. >> >>>>> >> >>>>> The open webrev is here: >> >>>>> >> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >> >> >>>>> >> >>>>> The feature request is here: >> >>>>> >> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >> >> >>>>> >> >>>>> The latest version of the spec can be found here: >> >>>>> >> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >> >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> Eric >> >> >> >> From david.dehaven at oracle.com Fri Jan 11 18:44:35 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 11 Jan 2013 10:44:35 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <50EF11D7.1010207@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EDC933.6010303@oracle.com> <50EEA732.4040101@oracle.com> <50EF11D7.1010207@oracle.com> Message-ID: <23172795-7365-42CA-82EB-7352233CC8DD@oracle.com> >>> It's a Windows feature. We discovered this recently in debugging another >>> test failure. Windows is documented to do asynchronous deletes. You can't >>> depend on a file.delete() which returns true to have actually deleted the >>> file. It may be the case that another process has a file handle which it has >>> not yet released, or it's simply a delay. >> I don't get this, the issue sounds more like AV software or Windows application >> quality service/agent thing accessing the file but I might be wrong of course. >> Are you able to duplicate this reliably and if so, have you looked at it with >> any tools to see what/who is accessing it that is causing the delay? > > Dave DeHaven was able to reproduce this in his diagnosis of the Arrrghs test failure. That was a fun one to track down... > << The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. >> > > (I'm not a Windows developer, so I may be looking in the wrong place or misinterpreting something. Please correct me if I'm wrong.) No, you have it :) The call to DeleteFile does not actually *delete* the file, it simply marks it for deletion at some point in the future. > If the AE daemon has the file open the moment the test deletes it, the file will remain present until the AE daemon has closed it. > > This seems built into Windows. I think we have to live with it. Presumably these various daemons open the file with CreateFile(FILE_SHARE_DELETE) [2] allowing the "owner" of the file to delete it (eventually). Note this also allows renaming of the file. So the rename-before-delete technique seems like the most promising approach. I concur. -DrD- From daniel.fuchs at oracle.com Fri Jan 11 19:05:21 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2013 20:05:21 +0100 Subject: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F04AA3.7020008@oracle.com> References: <50CF59DF.2040006@oracle.com> <50D08508.3040903@oracle.com> <50D09C4D.9030404@oracle.com> <50D0A816.7010201@oracle.com> <50D0AF49.5030505@oracle.com> <50D0BD64.2090502@oracle.com> <50D0ECF5.3020205@oracle.com> <50D0F803.9070208@oracle.com> <50D18CC0.3080308@oracle.com> <50E6E7B7.1030708@oracle.com> <50E724B5.1030408@oracle.com> <50EAA4C2.5070002@oracle.com> <50EB9CDF.1050908@oracle.com> <50EC0F1F.2030403@oracle.com> <50ED9029.60705@oracle.com> <50EDA838.5030203@oracle.com> <50EDD376.9060401@oracle.com> <50F01ABD.9070602@oracle.com> <50F04AA3.7020008@oracle.com> Message-ID: <50F06271.40201@oracle.com> Thanks Mandy! Good catch! I've updated the webrev: -- daniel On 1/11/13 6:23 PM, Mandy Chung wrote: > On 1/11/2013 5:59 AM, Daniel Fuchs wrote: >> Hi Mandy, >> >> This is done. I have updated the webrev: >> >> >> >> > > typo in: > > 242 * If {@code factoryId} is "javax.xml.stream.XMLIntputFactory", > > > Otherwise, looks good. Thanks for the update. > Mandy From huizhe.wang at oracle.com Fri Jan 11 19:05:34 2013 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 11 Jan 2013 11:05:34 -0800 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F044BD.30503@oracle.com> References: <50ED7E7C.1030803@oracle.com> <50F044BD.30503@oracle.com> Message-ID: <50F0627E.7010404@oracle.com> On 1/11/2013 8:58 AM, Alan Bateman wrote: > On 09/01/2013 14:28, Daniel Fuchs wrote: >> Hi, >> >> Here is a new webrev in the series that addresses using ServiceLoader in >> JAXP for JDK 8. >> >> 7169894: JAXP Plugability Layer: using service loader >> >> This changeset addresses modification in the javax.xml.validation >> package. >> >> It is a bit more complex than the changes required for the other >> packages because the newInstance methods takes an additional >> schemaLanguage parameter, and therefore we need to loop over >> the providers in order to find one that supports the language. >> >> >> >> >> >> Also this particular package did not have any specific configuration >> error to throw in case of misconfiguration (the xpath package in which >> the logic is very similar had one for instance), so we're adding a new >> SchemaFactoryConfigurationError for that purpose. > I've taken an initial look at this and I'm wondering about > SchemeFactory.newInstance throwing SchemaFactoryConfigurationError. > Technically this is an incompatible change but in practical terms it > may not be concern as this provider interface may not be used very much. > > Joe Wang - have you come across SchemaFactory implementations, I'm > trying to get a feel for how much this is used, if ever. I don't have any data on how much the service mechanism may be used, Xerces would surely be the one most frequently used. I'm more concerned with the spec change that would require TCK change (the addition of SchemaFactoryConfigurationError related tests). Would that require MR? We probably need to run it with the JCK engineers. Joe > > -Alan From daniel.fuchs at oracle.com Fri Jan 11 19:14:15 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Jan 2013 20:14:15 +0100 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F0627E.7010404@oracle.com> References: <50ED7E7C.1030803@oracle.com> <50F044BD.30503@oracle.com> <50F0627E.7010404@oracle.com> Message-ID: <50F06487.3040705@oracle.com> On 1/11/13 8:05 PM, Joe Wang wrote: > I don't have any data on how much the service mechanism may be used, > Xerces would surely be the one most frequently used. I'm more concerned > with the spec change that would require TCK change (the addition of > SchemaFactoryConfigurationError related tests). Although it seems cleaner to use a SchemaFactoryConfigurationError, we could wrap the ServiceConfigurationError in an IllegalArgumentException - which is what would have eventually been thrown in the old code. If that seems like a safer strategy I could update the changes in this sense. Best regards, -- daniel From huizhe.wang at oracle.com Fri Jan 11 19:41:11 2013 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 11 Jan 2013 11:41:11 -0800 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F06487.3040705@oracle.com> References: <50ED7E7C.1030803@oracle.com> <50F044BD.30503@oracle.com> <50F0627E.7010404@oracle.com> <50F06487.3040705@oracle.com> Message-ID: <50F06AD7.1000602@oracle.com> On 1/11/2013 11:14 AM, Daniel Fuchs wrote: > On 1/11/13 8:05 PM, Joe Wang wrote: >> I don't have any data on how much the service mechanism may be used, >> Xerces would surely be the one most frequently used. I'm more concerned >> with the spec change that would require TCK change (the addition of >> SchemaFactoryConfigurationError related tests). > > Although it seems cleaner to use a SchemaFactoryConfigurationError, > we could wrap the ServiceConfigurationError in > an IllegalArgumentException - which is what would have eventually > been thrown in the old code. > > If that seems like a safer strategy I could update the changes in > this sense. I agree. It's safer in that we could move forward with the change. FF for JDK8 is 1/23. Joe > > Best regards, > > -- daniel From Alan.Bateman at oracle.com Fri Jan 11 20:05:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Jan 2013 20:05:47 +0000 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F0627E.7010404@oracle.com> References: <50ED7E7C.1030803@oracle.com> <50F044BD.30503@oracle.com> <50F0627E.7010404@oracle.com> Message-ID: <50F0709B.6090406@oracle.com> On 11/01/2013 19:05, Joe Wang wrote: > : > > I don't have any data on how much the service mechanism may be used, > Xerces would surely be the one most frequently used. I'm more > concerned with the spec change that would require TCK change (the > addition of SchemaFactoryConfigurationError related tests). Would > that require MR? Yes, there will be a MR of JSR-206 required for this work. -Alan. From alan.bateman at oracle.com Fri Jan 11 20:22:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Jan 2013 20:22:17 +0000 Subject: hg: jdk8/tl/jdk: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Message-ID: <20130111202241.5D59A47203@hg.openjdk.java.net> Changeset: 7da291690aa0 Author: alanb Date: 2013-01-11 20:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Reviewed-by: chegar ! test/ProblemList.txt ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/getEnclosingClass/build.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh ! test/java/lang/Thread/UncaughtExceptions.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/AppendToBootstrapClassPathSetUp.sh ! test/java/lang/instrument/AppendToClassPathSetUp.sh ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/MakeJAR.sh ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/MakeJAR3.sh ! test/java/lang/instrument/MakeJAR4.sh ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/PremainClass/NoPremainAgent.sh ! test/java/lang/instrument/PremainClass/PremainClassTest.sh ! test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/RedefineSetUp.sh ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/build.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/charset/spi/basic.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/PrefsSpi.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/script/CommonSetup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/security/krb5/config/dns.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/ClassPathWildCard.sh ! test/tools/launcher/MultipleJRE.sh From stuart.marks at oracle.com Fri Jan 11 20:35:36 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Jan 2013 12:35:36 -0800 Subject: RFR 8005962 : TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments In-Reply-To: <50F05286.604@oracle.com> References: <50EEFF24.7090300@oracle.com> <50EF07FE.10307@oracle.com> <50EF12D1.8010305@oracle.com> <50EF7826.2050809@oracle.com> <50F050CA.9010202@oracle.com> <50F051E2.6010606@oracle.com> <50F05286.604@oracle.com> Message-ID: <50F07798.1020509@oracle.com> On 1/11/13 9:57 AM, Brent Christian wrote: > On 1/11/13 9:54 AM, Chris Hegarty wrote: >> On 11/01/2013 17:50, Brent Christian wrote: >>> >>> I did an 'hg mv' of the directory containing the (two) test files. But I >>> then had to 'hg export' to send the changeset for pushing. I'm guessing >> >> Yes, I noticed this before. 'hg export' and 'hg mv' are not friends. >> >> -Chris. > > I see that hg also has a 'bundle' and 'unbundle'. Has anyone used it? Would > that have been better in this situation? Aha, so it was 'hg export' that was the culprit. I should have figured that since you (Brent) authored the changeset but Naoto had pushed it. In any case, "hg export --git" will export the changeset in a fashion that preserves the rename history. This should work fine with "hg import". As far as I know, the --git option isn't the default because other patch-importing programs (such as "patch" itself) don't understand it. Bundles will also preserve rename information. I was a fan of bundles for a while. They're more difficult to work with, though. First, they're binary. Second, if you don't have the parent changeset of what's in the bundle, it's totally opaque; you can't see what's inside of it. I'd recommend using "hg export --git". s'marks From martinrb at google.com Fri Jan 11 21:02:18 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 11 Jan 2013 13:02:18 -0800 Subject: RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures In-Reply-To: <23172795-7365-42CA-82EB-7352233CC8DD@oracle.com> References: <50EDBBAB.7000500@oracle.com> <50EDC933.6010303@oracle.com> <50EEA732.4040101@oracle.com> <50EF11D7.1010207@oracle.com> <23172795-7365-42CA-82EB-7352233CC8DD@oracle.com> Message-ID: Thanks all for the entertaining horror story - glad I no longer need to fight with Windoze. From christian.thalinger at oracle.com Fri Jan 11 22:53:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Jan 2013 14:53:41 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F05798.30306@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> Message-ID: <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> On Jan 11, 2013, at 10:19 AM, Ulf Zibis wrote: > Hi Sherman, > > Am 11.01.2013 06:47, schrieb Xueming Shen: >> (1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here should >> not change the real "sp" after "break+return". >> (2) maybe the "overflowflag" can just be replaced by "CoderResult cr", with init value >> of CoderResult.UNDERFLOW;", then "cr = CoderResult.OVERFLOW" at ln#182, and >> simply "return cr" at ln#193, without another "if". > > I've enhanced your suggestions, see more below... > Additionally, some part of encodeArrayLoop(...) maybe could be moved into a separate method, to be reused by encode(char[] src, int sp, int len, byte[] dst). > Some of the re-engineering could be adapted to the Decoder methods. > >> I'm surprised we only get 1.6% boost. Maybe it is worth measuring the performance >> of some "small" buf/array encoding? I'm a little concerned that the overhead may >> slow down the small size buf/array encoding. There is a simple benchmark for String >> en/decoding at test/sun/nio/cs/StrCodingBenchmark. > > I think we should balance 4 cases in rating the performance: > a) few loops, small buf/array > b) few loops, big buf/array > c) many loops, small buf/array > d) many loops, big buf/array > In a), b) the loop surrounding code will not be JIT-compiled, so should be optimized for interpreter. > In c) d) the loop surrounding code *may be* JIT-compiled and consequtively inline the inner loop, should be verified. > In b), d) the small inner loop, as demonstrated below, will be JIT-compiled, regardless if moved into separate method. But you guys noticed that sentence in the initial review request, right? "Move encoding loop into separate method for which VM will use intrinsic on x86." Just wanted to make sure ;-) -- Chris > > -Ulf > > 1) Check for (sp >= sl) is superfluous. > ====================================== > private static int copyISOs( > char[] sa, int sp, byte[] da, int dp, int len) { > int i = 0; > for (; i < len; i++) { > char c = sa[sp++]; > // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest > if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 > break; > da[dp++] = (byte)c; > } > return i; > } > > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > int sl = sp + sr; > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > try { > int ret = copyISOs(sa, sp, da, dp, sr); > sp = sp + ret; > dp = dp + ret; > if (ret != sr) { > if (sgp.parse(sa[sp], sa, sp, sl) < 0) > return sgp.error(); > return sgp.unmappableResult(); > } > return cr; > } finally { > src.position(sp - soff); > dst.position(dp - doff); > } > } > > 2) Avoids sp, dp to be recalculated; shorter surrounding code -> best chance to become JIT-compiled. > ====================================== > // while inlinig, JIT will erase the surrounding int[] p > private static boolean copyISOs( > char[] sa, byte[] da, final int[] p, int sl) { > for (int sp = p[0], dp = p[1]; sp < sl; sp++) { > char c = sa[sp]; > // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest > if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 > return false; > da[dp++] = (byte)c; > } > return true; > } > > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > try { > int sl = sp + sr; > final int[] p = { sp, dp }; > if (!copyISOs(sa, da, p, sl)) { > if (sgp.parse(sa[sp], sa, sp, sl) < 0) > return sgp.error(); > return sgp.unmappableResult(); > } > return cr; > } finally { > src.position(sp - soff); > dst.position(dp - doff); > } > } > > 3) No more needs try...finally block. > ====================================== > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > int sl = sp + sr; > for (; sp < sl; sp++) { > char c = sa[sp]; > // if (c & '\uFF00' != 0) { // needs bug 6935994 to be fixed, would be fastest > if ((byte)(c >> 8) != 0) { // temporary replacement, fast byte-length operation on x86 > cr = null; > break; > } > da[dp++] = (byte)c; > } > src.position(sp - soff); > dst.position(dp - doff); > return result(cr, sa, sp, sl); > } > > // if adapted, maybe could also be reused in encodeBufferLoop() > private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) { > return cr != null ? cr : > sgp.parse(sa[sp], sa, sp, sl) < 0 > ? sgp.error(); > : sgp.unmappableResult(); > } > From xueming.shen at oracle.com Fri Jan 11 23:18:52 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 11 Jan 2013 15:18:52 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> Message-ID: <50F09DDC.4010306@oracle.com> Yes, I think I fully understand the purpose of the proposed change. This has been on the list for years. Just want to make sure we don't pay an unexpected price on use scenario that the "intrinsic on x86" does not kick in. -Sherman On 01/11/2013 02:53 PM, Christian Thalinger wrote: > > But you guys noticed that sentence in the initial review request, right? > > "Move encoding loop into separate method for which VM will use intrinsic on x86." > > Just wanted to make sure ;-) > > -- Chris > From aleksey.shipilev at oracle.com Fri Jan 11 23:23:24 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 12 Jan 2013 03:23:24 +0400 Subject: RFR (XS): CR 8003985: Support @Contended annotation Message-ID: <50F09EEC.1030009@oracle.com> Hi guys, This is the JDK side of changes for supporting @Contended: http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ Status: - This change is ready to be pushed; due to licensing reasons with jsr166, we can only commit the stub; regular jsr166 sync will bring the updated annotation later. - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) - CCC is in place, and Approved. I need a sponsor to push this. Thanks, -Aleksey. From joe.darcy at oracle.com Fri Jan 11 23:36:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jan 2013 15:36:30 -0800 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F09EEC.1030009@oracle.com> References: <50F09EEC.1030009@oracle.com> Message-ID: <50F0A1FE.9090804@oracle.com> On 01/11/2013 03:23 PM, Aleksey Shipilev wrote: > Hi guys, > > This is the JDK side of changes for supporting @Contended: > http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ > > Status: > - This change is ready to be pushed; due to licensing reasons with > jsr166, we can only commit the stub; regular jsr166 sync will bring the > updated annotation later. > - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) > - CCC is in place, and Approved. > > I need a sponsor to push this. > > Thanks, > -Aleksey. Looks fine; approved. Thanks, -Joe From Lance.Andersen at oracle.com Fri Jan 11 23:31:28 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 11 Jan 2013 18:31:28 -0500 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F0627E.7010404@oracle.com> References: <50ED7E7C.1030803@oracle.com> <50F044BD.30503@oracle.com> <50F0627E.7010404@oracle.com> Message-ID: <71C736BE-9D24-4846-80EB-C1DFCB026F7D@oracle.com> On Jan 11, 2013, at 2:05 PM, Joe Wang wrote: > > > On 1/11/2013 8:58 AM, Alan Bateman wrote: >> On 09/01/2013 14:28, Daniel Fuchs wrote: >>> Hi, >>> >>> Here is a new webrev in the series that addresses using ServiceLoader in >>> JAXP for JDK 8. >>> >>> 7169894: JAXP Plugability Layer: using service loader >>> >>> This changeset addresses modification in the javax.xml.validation >>> package. >>> >>> It is a bit more complex than the changes required for the other >>> packages because the newInstance methods takes an additional >>> schemaLanguage parameter, and therefore we need to loop over >>> the providers in order to find one that supports the language. >>> >>> >>> >>> >>> Also this particular package did not have any specific configuration >>> error to throw in case of misconfiguration (the xpath package in which >>> the logic is very similar had one for instance), so we're adding a new >>> SchemaFactoryConfigurationError for that purpose. >> I've taken an initial look at this and I'm wondering about SchemeFactory.newInstance throwing SchemaFactoryConfigurationError. Technically this is an incompatible change but in practical terms it may not be concern as this provider interface may not be used very much. >> >> Joe Wang - have you come across SchemaFactory implementations, I'm trying to get a feel for how much this is used, if ever. > > I don't have any data on how much the service mechanism may be used, Xerces would surely be the one most frequently used. I'm more concerned with the spec change that would require TCK change (the addition of SchemaFactoryConfigurationError related tests). Would that require MR? We probably need to run it with the JCK engineers. If you are changing the exception, then you would need an MR for this and want to update any TCK/JCK tests (or add tests) > > Joe > >> >> -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 joe.darcy at oracle.com Fri Jan 11 23:39:20 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 11 Jan 2013 23:39:20 +0000 Subject: hg: jdk8/tl/jdk: 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Message-ID: <20130111233932.0041F4720E@hg.openjdk.java.net> Changeset: bc1f16f5566f Author: darcy Date: 2013-01-11 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc1f16f5566f 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Reviewed-by: darcy Contributed-by: olivier.lagneau at oracle.com ! src/share/classes/java/text/DigitList.java ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/text/Format/DecimalFormat/TieRoundingTest.java From joe.darcy at oracle.com Sat Jan 12 02:37:51 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 11 Jan 2013 18:37:51 -0800 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F04963.6030302@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> Message-ID: <50F0CC7F.9030305@oracle.com> On 01/11/2013 09:18 AM, Chris Hegarty wrote: > On 11/01/2013 16:57, Doug Lea wrote: >> On 01/11/13 11:35, Peter Levart wrote: >>> On 01/11/2013 05:18 PM, Chris Hegarty wrote: >>>> Now with explicit disclaimer on DoubleA* >>>> >>>> "The order of accumulation within or across threads is not >>>> guaranteed. Thus, >>>> this class may not be applicable if numerical stability is required >>>> when >>>> combining values of substantially different orders of magnitude." >>> >>> It doesn't have to be substantially different order of magnitude. >>> >> >> Thanks. Chris, please add "especially": Hello, I would prefer to cautionary note along the lines of "if you want numerical accuracy, take care to use a summation algorithm with defined worst-case behavior." (Varying magnitude is not so much of a problem if you add things up in the right order.) -Joe > > Thanks Doug, done. > > -Chris. > >> >> "The order of accumulation within or across threads is not guaranteed. >> Thus, this class may not be applicable if numerical stability is >> required, especially when combining values of substantially different >> orders of magnitude." >> >> >> -Doug >> From eric.mccorkle at oracle.com Sat Jan 12 05:14:16 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Sat, 12 Jan 2013 00:14:16 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F059AF.1000706@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> Message-ID: <50F0F128.5060000@oracle.com> I got halfway through implementing a change that would synthesize Parameter's for the static links (this for the inner classes), when it occurred to me: is there really a case for allowing reflection on those parameters. Put another way, public class Foo { public class Bar { int baz(int qux) { } } } Should baz.getParameters() return just qux, or should it expose Foo.this? On second thought, I can't think of a good reason why you *want* to reflect on Foo.this. Also, the logic is much simpler. You just have to figure out how deep you are in inner classes, store that information somewhere, and offset by that much every time a Parameter calls back to its Executable to get information. The logic for synthesizing the this parameters is much more complex. Thoughts? On 01/11/13 13:27, Joe Darcy wrote: > Hi Eric, > > Taking another look at the code, some extra logic / checking is needed > in cases where the number of source parameters (non-synthetic and > non-synthesized) disagrees with the number of actual parameters at a > class file level. > > For example, if the single source parameter of an inner class > constructor is annotated, the annotation should be associated with the > *second* parameter since the first class file parameter is a synthesized > constructor added by the compiler. I think generally annotations should > not be associated with synthesized or synthetic parameters. > > -Joe > > On 1/11/2013 9:03 AM, Eric McCorkle wrote: >> Update should be visible now. >> >> On 01/11/13 11:54, Vitaly Davidovich wrote: >>> Yes that's exactly what I'm looking for as well. >>> >>> Sent from my phone >>> >>> On Jan 11, 2013 11:25 AM, "Peter Levart" >> > wrote: >>> >>> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >>> >>> The webrev has been updated again. >>> >>> The multiple writes to parameters have been removed, and the >>> tests have >>> been expanded to look at inner classes, and to test modifiers. >>> >>> Please look over it again. >>> >>> >>> Hello Eric, >>> >>> You still have 2 reads of volatile even in fast path. I would do it >>> this way: >>> >>> >>> private Parameter[] privateGetParameters() { >>> Parameter[] tmp = parameters; // one and only read >>> if (tmp != null) >>> return tmp; >>> >>> // Otherwise, go to the JVM to get them >>> tmp = getParameters0(); >>> >>> // If we get back nothing, then synthesize parameters >>> if (tmp == null) { >>> final int num = getParameterCount(); >>> tmp = new Parameter[num]; >>> for (int i = 0; i < num; i++) >>> // TODO: is there a way to synthetically derive the >>> // modifiers? Probably not in the general case, since >>> // we'd have no way of knowing about them, but there >>> // may be specific cases. >>> tmp[i] = new Parameter("arg" + i, 0, this, i); >>> // This avoids possible races from seeing a >>> // half-initialized parameters cache. >>> } >>> >>> parameters = tmp; >>> >>> return tmp; >>> } >>> >>> >>> Regards, Peter >>> >>> >>> Test-wise, I've got a clean run on JPRT (there were some >>> failures in >>> lambda stuff, but I've been seeing that for some time now). >>> >>> On 01/10/13 21:47, Eric McCorkle wrote: >>> >>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>> >>> Hi Eric, >>> >>> Parameter.equals() doesn't need null check - instanceof >>> covers that already. >>> >>> Removed. >>> >>> Maybe this has been mentioned already, but personally >>> I'm not a fan of >>> null checks such as "if (null == x)" - I prefer the >>> null >>> on the right >>> hand side, but that's just stylistic. >>> >>> Changed. >>> >>> Perhaps I'm looking at a stale webrev but >>> Executable.__privateGetParameters() reads and writes >>> from/to the volatile >>> field more than once. I think Peter already mentioned >>> that it should >>> use one read into a local and one write to publish the >>> final version to >>> the field (it can return the temp as well). >>> >>> You weren't. From a pure correctness standpoint, there is >>> nothing wrong >>> with what is there. getParameters0 is a constant >>> function, and >>> parameters is writable only if null. Hence, we only every >>> see one >>> nontrivial write to it. >>> >>> But you are right, it should probably be reduced to a >>> single >>> write, for >>> performance reasons (to avoid unnecessary memory barriers). >>> Therefore, >>> I changed it. >>> >>> However, I won't be able to refresh the webrev until >>> tomorrow. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>> >> >>> >> >> wrote: >>> >>> The webrev has been refreshed with the solution I >>> describe below >>> implemented. Please make additional comments. >>> >>> On 01/10/13 17:29, Eric McCorkle wrote: >>> > Good catch there. I made the field volatile, >>> and >>> I also did the same >>> > with the cache fields in Parameter. >>> > >>> > It is possible with what exists that you could >>> wind up with multiple >>> > copies of identical parameter objects in >>> existence. It goes something >>> > like this >>> > >>> > thread A sees Executable.parameters is null, >>> goes >>> into the VM to >>> get them >>> > thread B sees Executable.parameters is null, >>> goes >>> into the VM to >>> get them >>> > thread A stores to Executable.parameters >>> > thread B stores to Executable.parameters >>> > >>> > Since Parameters is immutable (except for its >>> caches, which will >>> always >>> > end up containing the same things), this >>> *should* >>> have no visible >>> > effects, unless someone does == instead of >>> .equals. >>> > >>> > This can be avoided by doing a CAS, which is >>> more >>> expensive >>> execution-wise. >>> > >>> > My vote is to *not* do a CAS, and accept that >>> (in >>> extremely rare >>> cases, >>> > even as far as concurrency-related anomalies >>> go), >>> you may end up with >>> > duplicates, and document that very well. >>> > >>> > Thoughts? >>> > >>> > On 01/10/13 16:10, Peter Levart wrote: >>> >> Hello Eric, >>> >> >>> >> I have another one. Although not very likely, >>> the reference to >>> the same >>> >> Method/Constructor can be shared among multiple >>> threads. The >>> publication >>> >> of a parameters array should therefore be >>> performed via a >>> volatile write >>> >> / volatile read, otherwise it can happen that >>> some thread sees >>> >> half-initialized array content. The >>> 'parameters' >>> field in Executable >>> >> should be declared as volatile and there should >>> be a single read >>> from it >>> >> and a single write to it in the >>> privateGetParameters() method >>> (you need >>> >> a local variable to hold intermediate >>> states)... >>> >> >>> >> Regards, Peter >>> >> >>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>> >>> Thanks to all for initial reviews; however, it >>> appears that the >>> version >>> >>> you saw was somewhat stale. I've applied your >>> comments (and some >>> >>> changes that I'd made since the version that >>> was posted). >>> >>> >>> >>> Please take a second look. >>> >>> >>> >>> Thanks, >>> >>> Eric >>> >>> >>> >>> >>> >>> On 01/10/13 04:19, Peter Levart wrote: >>> >>>> Hello Eric, >>> >>>> >>> >>>> You must have missed my comment from the >>> previous webrev: >>> >>>> >>> >>>> 292 private Parameter[] >>> privateGetParameters() { >>> >>>> 293 if (null != parameters) >>> >>>> 294 return parameters.get(); >>> >>>> >>> >>>> If/when the 'parameters' SoftReference is >>> cleared, the method >>> will be >>> >>>> returning null forever after... >>> >>>> >>> >>>> You should also retrieve the referent and >>> check for it's >>> presence before >>> >>>> returning it: >>> >>>> >>> >>>> Parameter[] res; >>> >>>> if (parameters != null && (res = >>> parameters.get()) != null) >>> >>>> return res; >>> >>>> ... >>> >>>> ... >>> >>>> >>> >>>> Regards, Peter >>> >>>> >>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>> >>>>> Hello, >>> >>>>> >>> >>>>> Please review the core reflection API >>> implementation of parameter >>> >>>>> reflection. This is the final component of >>> method parameter >>> reflection. >>> >>>>> This was posted for review before, then >>> delayed until the >>> check-in for >>> >>>>> JDK-8004728 (hotspot support for parameter >>> reflection), which >>> occurred >>> >>>>> yesterday. >>> >>>>> >>> >>>>> Note: The check-in of JDK-8004728 was into >>> hsx/hotspot-rt, *not* >>> >>>>> jdk8/tl; therefore, it may be a while before >>> the changeset >>> makes its way >>> >>>>> into jdk8/tl. >>> >>>>> >>> >>>>> Also note: since the check-in of JDK-8004727 >>> (javac support for >>> >>>>> parameter reflection), there has been a >>> failure in the tests for >>> >>>>> Pack200. This is being addressed in a fix >>> contributed by >>> Kumar, which I >>> >>>>> believe has also been posted for review. >>> >>>>> >>> >>>>> The open webrev is here: >>> >>>>> >>> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >>> >>> >>>>> >>> >>>>> The feature request is here: >>> >>>>> >>> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >>> >>> >>>>> >>> >>>>> The latest version of the spec can be >>> found here: >>> >>>>> >>> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >>> >>> >>>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Eric >>> >> >>> >>> > From xueming.shen at oracle.com Sat Jan 12 06:43:14 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sat, 12 Jan 2013 06:43:14 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130112064336.B631A47222@hg.openjdk.java.net> Changeset: 6f6246aced89 Author: sherman Date: 2013-01-11 22:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f6246aced89 8005466: JAR file entry hash table uses too much memory (zlib_util.c) Summary: realign the fields of jzcell struct Reviewed-by: sherman Contributed-by: ioi.lam at oracle.com ! src/share/native/java/util/zip/zip_util.h Changeset: 8009c7e3899e Author: sherman Date: 2013-01-11 22:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8009c7e3899e Merge From Ulf.Zibis at CoSoCo.de Sat Jan 12 08:37:33 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 12 Jan 2013 09:37:33 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> Message-ID: <50F120CD.6020207@CoSoCo.de> Am 11.01.2013 23:53, schrieb Christian Thalinger: > But you guys noticed that sentence in the initial review request, right? > > "Move encoding loop into separate method for which VM will use intrinsic on x86." > > Just wanted to make sure ;-) Good question Christian! This is, how it shows up to me: 1) The bug synopsis is unspecific about intrinsc, so ... 2) the mentioned 1st sentence could be one of many solutions. 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is not available. 4) What specific operation should be done by the intrinsic, i.e. is there a fixed API for that method ??? 5) Can an intrinsic write back more than 1 value (see my hack via int[] p) ? 6) Vladimir's webrev shows an integer as return type for that method, I've added a variant with boolean return type, and the code from my last approach could be transformed to a method with Object return type. ... so waiting for Vladimir's feedback :-[ (especially on performance/hsdis results) (Can someone push the bug to the public?) -Ulf From dl at cs.oswego.edu Sat Jan 12 15:04:33 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 12 Jan 2013 10:04:33 -0500 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F0CC7F.9030305@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> Message-ID: <50F17B81.6010603@cs.oswego.edu> On 01/11/13 21:37, Joe Darcy wrote: > I would prefer to cautionary note along the lines of "if you want numerical > accuracy, take care to use a summation algorithm with defined worst-case behavior." > > (Varying magnitude is not so much of a problem if you add things up in the right > order.) Thanks. I do not believe such an algorithm exists, because no ordering control is possible, and all other known accuracy improvements (like Kahn) require multiword atomicity, which we explicitly do not provide. Which leaves me thinking that the current disclaimer (below) is the best we can do. -Doug >>> "The order of accumulation within or across threads is not guaranteed. >>> Thus, this class may not be applicable if numerical stability is >>> required, especially when combining values of substantially different >>> orders of magnitude." >>> From joe.darcy at oracle.com Sat Jan 12 18:36:19 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 12 Jan 2013 10:36:19 -0800 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F0F128.5060000@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F0F128.5060000@oracle.com> Message-ID: <50F1AD23.3010604@oracle.com> Hi Eric, On 1/11/2013 9:14 PM, Eric McCorkle wrote: > I got halfway through implementing a change that would synthesize > Parameter's for the static links (this for the inner classes), when it > occurred to me: is there really a case for allowing reflection on those > parameters. > > Put another way, > > public class Foo { > public class Bar { > int baz(int qux) { } > } > } > > Should baz.getParameters() return just qux, or should it expose > Foo.this? On second thought, I can't think of a good reason why you > *want* to reflect on Foo.this. You need to reflect on that parameter so you can call the constructor properly using reflection :-) > > Also, the logic is much simpler. You just have to figure out how deep > you are in inner classes, store that information somewhere, and offset > by that much every time a Parameter calls back to its Executable to get > information. The logic for synthesizing the this parameters is much > more complex. > > Thoughts? We may need some more help from javac to mark parameters as synthesized or synthetic, which can be done as follow-up work. For inner classes that are members of types, the outer this parameters are required to be a certain way by the platform specification to make linkage work. *However*, local and anonymous classes only have to obey a compiler's contract with itself and are not specified. In particular, not all such inner classes constructors even have an outer this parameter. For example, with javac the constructor of an anonymous class in a static initializer will *not* have an other this parameter. -Joe > > On 01/11/13 13:27, Joe Darcy wrote: >> Hi Eric, >> >> Taking another look at the code, some extra logic / checking is needed >> in cases where the number of source parameters (non-synthetic and >> non-synthesized) disagrees with the number of actual parameters at a >> class file level. >> >> For example, if the single source parameter of an inner class >> constructor is annotated, the annotation should be associated with the >> *second* parameter since the first class file parameter is a synthesized >> constructor added by the compiler. I think generally annotations should >> not be associated with synthesized or synthetic parameters. >> >> -Joe >> >> On 1/11/2013 9:03 AM, Eric McCorkle wrote: >>> Update should be visible now. >>> >>> On 01/11/13 11:54, Vitaly Davidovich wrote: >>>> Yes that's exactly what I'm looking for as well. >>>> >>>> Sent from my phone >>>> >>>> On Jan 11, 2013 11:25 AM, "Peter Levart" >>> > wrote: >>>> >>>> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >>>> >>>> The webrev has been updated again. >>>> >>>> The multiple writes to parameters have been removed, and the >>>> tests have >>>> been expanded to look at inner classes, and to test modifiers. >>>> >>>> Please look over it again. >>>> >>>> >>>> Hello Eric, >>>> >>>> You still have 2 reads of volatile even in fast path. I would do it >>>> this way: >>>> >>>> >>>> private Parameter[] privateGetParameters() { >>>> Parameter[] tmp = parameters; // one and only read >>>> if (tmp != null) >>>> return tmp; >>>> >>>> // Otherwise, go to the JVM to get them >>>> tmp = getParameters0(); >>>> >>>> // If we get back nothing, then synthesize parameters >>>> if (tmp == null) { >>>> final int num = getParameterCount(); >>>> tmp = new Parameter[num]; >>>> for (int i = 0; i < num; i++) >>>> // TODO: is there a way to synthetically derive the >>>> // modifiers? Probably not in the general case, since >>>> // we'd have no way of knowing about them, but there >>>> // may be specific cases. >>>> tmp[i] = new Parameter("arg" + i, 0, this, i); >>>> // This avoids possible races from seeing a >>>> // half-initialized parameters cache. >>>> } >>>> >>>> parameters = tmp; >>>> >>>> return tmp; >>>> } >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> Test-wise, I've got a clean run on JPRT (there were some >>>> failures in >>>> lambda stuff, but I've been seeing that for some time now). >>>> >>>> On 01/10/13 21:47, Eric McCorkle wrote: >>>> >>>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>>> >>>> Hi Eric, >>>> >>>> Parameter.equals() doesn't need null check - instanceof >>>> covers that already. >>>> >>>> Removed. >>>> >>>> Maybe this has been mentioned already, but personally >>>> I'm not a fan of >>>> null checks such as "if (null == x)" - I prefer the >>>> null >>>> on the right >>>> hand side, but that's just stylistic. >>>> >>>> Changed. >>>> >>>> Perhaps I'm looking at a stale webrev but >>>> Executable.__privateGetParameters() reads and writes >>>> from/to the volatile >>>> field more than once. I think Peter already mentioned >>>> that it should >>>> use one read into a local and one write to publish the >>>> final version to >>>> the field (it can return the temp as well). >>>> >>>> You weren't. From a pure correctness standpoint, there is >>>> nothing wrong >>>> with what is there. getParameters0 is a constant >>>> function, and >>>> parameters is writable only if null. Hence, we only every >>>> see one >>>> nontrivial write to it. >>>> >>>> But you are right, it should probably be reduced to a >>>> single >>>> write, for >>>> performance reasons (to avoid unnecessary memory barriers). >>>> Therefore, >>>> I changed it. >>>> >>>> However, I won't be able to refresh the webrev until >>>> tomorrow. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>>> >>> >>>> >>> >> wrote: >>>> >>>> The webrev has been refreshed with the solution I >>>> describe below >>>> implemented. Please make additional comments. >>>> >>>> On 01/10/13 17:29, Eric McCorkle wrote: >>>> > Good catch there. I made the field volatile, >>>> and >>>> I also did the same >>>> > with the cache fields in Parameter. >>>> > >>>> > It is possible with what exists that you could >>>> wind up with multiple >>>> > copies of identical parameter objects in >>>> existence. It goes something >>>> > like this >>>> > >>>> > thread A sees Executable.parameters is null, >>>> goes >>>> into the VM to >>>> get them >>>> > thread B sees Executable.parameters is null, >>>> goes >>>> into the VM to >>>> get them >>>> > thread A stores to Executable.parameters >>>> > thread B stores to Executable.parameters >>>> > >>>> > Since Parameters is immutable (except for its >>>> caches, which will >>>> always >>>> > end up containing the same things), this >>>> *should* >>>> have no visible >>>> > effects, unless someone does == instead of >>>> .equals. >>>> > >>>> > This can be avoided by doing a CAS, which is >>>> more >>>> expensive >>>> execution-wise. >>>> > >>>> > My vote is to *not* do a CAS, and accept that >>>> (in >>>> extremely rare >>>> cases, >>>> > even as far as concurrency-related anomalies >>>> go), >>>> you may end up with >>>> > duplicates, and document that very well. >>>> > >>>> > Thoughts? >>>> > >>>> > On 01/10/13 16:10, Peter Levart wrote: >>>> >> Hello Eric, >>>> >> >>>> >> I have another one. Although not very likely, >>>> the reference to >>>> the same >>>> >> Method/Constructor can be shared among multiple >>>> threads. The >>>> publication >>>> >> of a parameters array should therefore be >>>> performed via a >>>> volatile write >>>> >> / volatile read, otherwise it can happen that >>>> some thread sees >>>> >> half-initialized array content. The >>>> 'parameters' >>>> field in Executable >>>> >> should be declared as volatile and there should >>>> be a single read >>>> from it >>>> >> and a single write to it in the >>>> privateGetParameters() method >>>> (you need >>>> >> a local variable to hold intermediate >>>> states)... >>>> >> >>>> >> Regards, Peter >>>> >> >>>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>>> >>> Thanks to all for initial reviews; however, it >>>> appears that the >>>> version >>>> >>> you saw was somewhat stale. I've applied your >>>> comments (and some >>>> >>> changes that I'd made since the version that >>>> was posted). >>>> >>> >>>> >>> Please take a second look. >>>> >>> >>>> >>> Thanks, >>>> >>> Eric >>>> >>> >>>> >>> >>>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>> >>>> Hello Eric, >>>> >>>> >>>> >>>> You must have missed my comment from the >>>> previous webrev: >>>> >>>> >>>> >>>> 292 private Parameter[] >>>> privateGetParameters() { >>>> >>>> 293 if (null != parameters) >>>> >>>> 294 return parameters.get(); >>>> >>>> >>>> >>>> If/when the 'parameters' SoftReference is >>>> cleared, the method >>>> will be >>>> >>>> returning null forever after... >>>> >>>> >>>> >>>> You should also retrieve the referent and >>>> check for it's >>>> presence before >>>> >>>> returning it: >>>> >>>> >>>> >>>> Parameter[] res; >>>> >>>> if (parameters != null && (res = >>>> parameters.get()) != null) >>>> >>>> return res; >>>> >>>> ... >>>> >>>> ... >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>> >>>>> Hello, >>>> >>>>> >>>> >>>>> Please review the core reflection API >>>> implementation of parameter >>>> >>>>> reflection. This is the final component of >>>> method parameter >>>> reflection. >>>> >>>>> This was posted for review before, then >>>> delayed until the >>>> check-in for >>>> >>>>> JDK-8004728 (hotspot support for parameter >>>> reflection), which >>>> occurred >>>> >>>>> yesterday. >>>> >>>>> >>>> >>>>> Note: The check-in of JDK-8004728 was into >>>> hsx/hotspot-rt, *not* >>>> >>>>> jdk8/tl; therefore, it may be a while before >>>> the changeset >>>> makes its way >>>> >>>>> into jdk8/tl. >>>> >>>>> >>>> >>>>> Also note: since the check-in of JDK-8004727 >>>> (javac support for >>>> >>>>> parameter reflection), there has been a >>>> failure in the tests for >>>> >>>>> Pack200. This is being addressed in a fix >>>> contributed by >>>> Kumar, which I >>>> >>>>> believe has also been posted for review. >>>> >>>>> >>>> >>>>> The open webrev is here: >>>> >>>>> >>>> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >>>> >>>> >>>>> >>>> >>>>> The feature request is here: >>>> >>>>> >>>> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >>>> >>>> >>>>> >>>> >>>>> The latest version of the spec can be >>>> found here: >>>> >>>>> >>>> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Thanks, >>>> >>>>> Eric >>>> >> >>>> >>>> From joe.darcy at oracle.com Sat Jan 12 18:36:57 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 12 Jan 2013 10:36:57 -0800 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F1AD23.3010604@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F0F128.5060000@oracle.com> <50F1AD23.3010604@oracle.com> Message-ID: <50F1AD49.30301@oracle.com> PS The link to the blog entry I meant to include: https://blogs.oracle.com/darcy/entry/nested_inner_member_and_top -Joe On 1/12/2013 10:36 AM, Joe Darcy wrote: > Hi Eric, > > On 1/11/2013 9:14 PM, Eric McCorkle wrote: >> I got halfway through implementing a change that would synthesize >> Parameter's for the static links (this for the inner classes), when it >> occurred to me: is there really a case for allowing reflection on those >> parameters. >> >> Put another way, >> >> public class Foo { >> public class Bar { >> int baz(int qux) { } >> } >> } >> >> Should baz.getParameters() return just qux, or should it expose >> Foo.this? On second thought, I can't think of a good reason why you >> *want* to reflect on Foo.this. > > You need to reflect on that parameter so you can call the constructor > properly using reflection :-) > >> >> Also, the logic is much simpler. You just have to figure out how deep >> you are in inner classes, store that information somewhere, and offset >> by that much every time a Parameter calls back to its Executable to get >> information. The logic for synthesizing the this parameters is much >> more complex. >> >> Thoughts? > > We may need some more help from javac to mark parameters as > synthesized or synthetic, which can be done as follow-up work. For > inner classes that are members of types, the outer this parameters are > required to be a certain way by the platform specification to make > linkage work. *However*, local and anonymous classes only have to > obey a compiler's contract with itself and are not specified. In > particular, not all such inner classes constructors even have an outer > this parameter. For example, with javac the constructor of an > anonymous class in a static initializer will *not* have an other this > parameter. > > -Joe > >> >> On 01/11/13 13:27, Joe Darcy wrote: >>> Hi Eric, >>> >>> Taking another look at the code, some extra logic / checking is needed >>> in cases where the number of source parameters (non-synthetic and >>> non-synthesized) disagrees with the number of actual parameters at a >>> class file level. >>> >>> For example, if the single source parameter of an inner class >>> constructor is annotated, the annotation should be associated with the >>> *second* parameter since the first class file parameter is a >>> synthesized >>> constructor added by the compiler. I think generally annotations >>> should >>> not be associated with synthesized or synthetic parameters. >>> >>> -Joe >>> >>> On 1/11/2013 9:03 AM, Eric McCorkle wrote: >>>> Update should be visible now. >>>> >>>> On 01/11/13 11:54, Vitaly Davidovich wrote: >>>>> Yes that's exactly what I'm looking for as well. >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 11, 2013 11:25 AM, "Peter Levart" >>>> > wrote: >>>>> >>>>> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >>>>> >>>>> The webrev has been updated again. >>>>> >>>>> The multiple writes to parameters have been removed, and >>>>> the >>>>> tests have >>>>> been expanded to look at inner classes, and to test >>>>> modifiers. >>>>> >>>>> Please look over it again. >>>>> >>>>> >>>>> Hello Eric, >>>>> >>>>> You still have 2 reads of volatile even in fast path. I >>>>> would do it >>>>> this way: >>>>> >>>>> >>>>> private Parameter[] privateGetParameters() { >>>>> Parameter[] tmp = parameters; // one and only read >>>>> if (tmp != null) >>>>> return tmp; >>>>> >>>>> // Otherwise, go to the JVM to get them >>>>> tmp = getParameters0(); >>>>> >>>>> // If we get back nothing, then synthesize parameters >>>>> if (tmp == null) { >>>>> final int num = getParameterCount(); >>>>> tmp = new Parameter[num]; >>>>> for (int i = 0; i < num; i++) >>>>> // TODO: is there a way to synthetically derive the >>>>> // modifiers? Probably not in the general case, since >>>>> // we'd have no way of knowing about them, but there >>>>> // may be specific cases. >>>>> tmp[i] = new Parameter("arg" + i, 0, this, i); >>>>> // This avoids possible races from seeing a >>>>> // half-initialized parameters cache. >>>>> } >>>>> >>>>> parameters = tmp; >>>>> >>>>> return tmp; >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> Test-wise, I've got a clean run on JPRT (there were some >>>>> failures in >>>>> lambda stuff, but I've been seeing that for some time now). >>>>> >>>>> On 01/10/13 21:47, Eric McCorkle wrote: >>>>> >>>>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>>>> >>>>> Hi Eric, >>>>> >>>>> Parameter.equals() doesn't need null check - >>>>> instanceof >>>>> covers that already. >>>>> >>>>> Removed. >>>>> >>>>> Maybe this has been mentioned already, but >>>>> personally >>>>> I'm not a fan of >>>>> null checks such as "if (null == x)" - I prefer the >>>>> null >>>>> on the right >>>>> hand side, but that's just stylistic. >>>>> >>>>> Changed. >>>>> >>>>> Perhaps I'm looking at a stale webrev but >>>>> Executable.__privateGetParameters() reads and >>>>> writes >>>>> from/to the volatile >>>>> field more than once. I think Peter already >>>>> mentioned >>>>> that it should >>>>> use one read into a local and one write to >>>>> publish the >>>>> final version to >>>>> the field (it can return the temp as well). >>>>> >>>>> You weren't. From a pure correctness standpoint, >>>>> there is >>>>> nothing wrong >>>>> with what is there. getParameters0 is a constant >>>>> function, and >>>>> parameters is writable only if null. Hence, we only >>>>> every >>>>> see one >>>>> nontrivial write to it. >>>>> >>>>> But you are right, it should probably be reduced to a >>>>> single >>>>> write, for >>>>> performance reasons (to avoid unnecessary memory >>>>> barriers). >>>>> Therefore, >>>>> I changed it. >>>>> >>>>> However, I won't be able to refresh the webrev until >>>>> tomorrow. >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>>>> >>>> >>>>> >>>> >> wrote: >>>>> >>>>> The webrev has been refreshed with the >>>>> solution I >>>>> describe below >>>>> implemented. Please make additional comments. >>>>> >>>>> On 01/10/13 17:29, Eric McCorkle wrote: >>>>> > Good catch there. I made the field >>>>> volatile, >>>>> and >>>>> I also did the same >>>>> > with the cache fields in Parameter. >>>>> > >>>>> > It is possible with what exists that you >>>>> could >>>>> wind up with multiple >>>>> > copies of identical parameter objects in >>>>> existence. It goes something >>>>> > like this >>>>> > >>>>> > thread A sees Executable.parameters is null, >>>>> goes >>>>> into the VM to >>>>> get them >>>>> > thread B sees Executable.parameters is null, >>>>> goes >>>>> into the VM to >>>>> get them >>>>> > thread A stores to Executable.parameters >>>>> > thread B stores to Executable.parameters >>>>> > >>>>> > Since Parameters is immutable (except for >>>>> its >>>>> caches, which will >>>>> always >>>>> > end up containing the same things), this >>>>> *should* >>>>> have no visible >>>>> > effects, unless someone does == instead of >>>>> .equals. >>>>> > >>>>> > This can be avoided by doing a CAS, which is >>>>> more >>>>> expensive >>>>> execution-wise. >>>>> > >>>>> > My vote is to *not* do a CAS, and accept >>>>> that >>>>> (in >>>>> extremely rare >>>>> cases, >>>>> > even as far as concurrency-related anomalies >>>>> go), >>>>> you may end up with >>>>> > duplicates, and document that very well. >>>>> > >>>>> > Thoughts? >>>>> > >>>>> > On 01/10/13 16:10, Peter Levart wrote: >>>>> >> Hello Eric, >>>>> >> >>>>> >> I have another one. Although not very >>>>> likely, >>>>> the reference to >>>>> the same >>>>> >> Method/Constructor can be shared among >>>>> multiple >>>>> threads. The >>>>> publication >>>>> >> of a parameters array should therefore be >>>>> performed via a >>>>> volatile write >>>>> >> / volatile read, otherwise it can happen >>>>> that >>>>> some thread sees >>>>> >> half-initialized array content. The >>>>> 'parameters' >>>>> field in Executable >>>>> >> should be declared as volatile and there >>>>> should >>>>> be a single read >>>>> from it >>>>> >> and a single write to it in the >>>>> privateGetParameters() method >>>>> (you need >>>>> >> a local variable to hold intermediate >>>>> states)... >>>>> >> >>>>> >> Regards, Peter >>>>> >> >>>>> >> On 01/10/2013 09:42 PM, Eric McCorkle >>>>> wrote: >>>>> >>> Thanks to all for initial reviews; >>>>> however, it >>>>> appears that the >>>>> version >>>>> >>> you saw was somewhat stale. I've >>>>> applied your >>>>> comments (and some >>>>> >>> changes that I'd made since the version >>>>> that >>>>> was posted). >>>>> >>> >>>>> >>> Please take a second look. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> Eric >>>>> >>> >>>>> >>> >>>>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>>> >>>> Hello Eric, >>>>> >>>> >>>>> >>>> You must have missed my comment from the >>>>> previous webrev: >>>>> >>>> >>>>> >>>> 292 private Parameter[] >>>>> privateGetParameters() { >>>>> >>>> 293 if (null != parameters) >>>>> >>>> 294 return parameters.get(); >>>>> >>>> >>>>> >>>> If/when the 'parameters' SoftReference is >>>>> cleared, the method >>>>> will be >>>>> >>>> returning null forever after... >>>>> >>>> >>>>> >>>> You should also retrieve the referent and >>>>> check for it's >>>>> presence before >>>>> >>>> returning it: >>>>> >>>> >>>>> >>>> Parameter[] res; >>>>> >>>> if (parameters != null && (res = >>>>> parameters.get()) != null) >>>>> >>>> return res; >>>>> >>>> ... >>>>> >>>> ... >>>>> >>>> >>>>> >>>> Regards, Peter >>>>> >>>> >>>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> Please review the core reflection API >>>>> implementation of parameter >>>>> >>>>> reflection. This is the final >>>>> component of >>>>> method parameter >>>>> reflection. >>>>> >>>>> This was posted for review before, >>>>> then >>>>> delayed until the >>>>> check-in for >>>>> >>>>> JDK-8004728 (hotspot support for >>>>> parameter >>>>> reflection), which >>>>> occurred >>>>> >>>>> yesterday. >>>>> >>>>> >>>>> >>>>> Note: The check-in of JDK-8004728 was >>>>> into >>>>> hsx/hotspot-rt, *not* >>>>> >>>>> jdk8/tl; therefore, it may be a while >>>>> before >>>>> the changeset >>>>> makes its way >>>>> >>>>> into jdk8/tl. >>>>> >>>>> >>>>> >>>>> Also note: since the check-in of >>>>> JDK-8004727 >>>>> (javac support for >>>>> >>>>> parameter reflection), there has been a >>>>> failure in the tests for >>>>> >>>>> Pack200. This is being addressed in >>>>> a fix >>>>> contributed by >>>>> Kumar, which I >>>>> >>>>> believe has also been posted for review. >>>>> >>>>> >>>>> >>>>> The open webrev is here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >>>>> >>>>> >>>>> >>>>> >>>>> The feature request is here: >>>>> >>>>> >>>>> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >>>>> >>>>> >>>>> >>>>> >>>>> The latest version of the spec can be >>>>> found here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Eric >>>>> >> >>>>> >>>>> > From Lance.Andersen at oracle.com Sat Jan 12 21:56:34 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 12 Jan 2013 16:56:34 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl Message-ID: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> Hi This is a review request for 8006139 which adds missing methods to SQLInput/Output The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ 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 Ulf.Zibis at CoSoCo.de Sun Jan 13 10:56:06 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 11:56:06 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> Message-ID: <50F292C6.1000508@CoSoCo.de> Am 12.01.2013 22:56, schrieb Lance Andersen - Oracle: > Hi > This is a review request for 8006139 which adds missing methods to SQLInput/Output > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ Hi, are you paid by code lines ;-) Additionally you have left out one opportunity ... or is it new code style, having 2 wrong indented closing braces in one line? I would code: 811 public String readNString() throws SQLException { 812 String attrib = (String)getNextAttribute(); 813 lastValueWasNull =attrib == null; 814return attrib; 815 } Additionally I'm wondering, whether getNextAttribute() could be generified. -Ulf From Ulf.Zibis at CoSoCo.de Sun Jan 13 11:13:42 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 12:13:42 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F292C6.1000508@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> Message-ID: <50F296E6.90801@CoSoCo.de> Oops, missing spaces by Thunderbird failure, correction: 811 public String readNString() throws SQLException { 812 String attrib = (String)getNextAttribute(); 813 lastValueWasNull = attrib == null; 814 return attrib; 815 } Additionally I'm wondering, whether getNextAttribute() could be generified. ... and again more general: xxx private T readNext() throws SQLException { xxx T attrib = (T)getNextAttribute(); xxx lastValueWasNull = attrib == null; xxx return attrib; xxx } 811 public String readNString() throws SQLException { 812 return readNext(); 813 } -Ulf Am 13.01.2013 11:56, schrieb Ulf Zibis: > Am 12.01.2013 22:56, schrieb Lance Andersen - Oracle: >> Hi >> This is a review request for 8006139 which adds missing methods to SQLInput/Output >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ > > Hi, > > are you paid by code lines ;-) > Additionally you have left out one opportunity > ... or is it new code style, having 2 wrong indented closing braces in one line? > > I would code: > > 811 public String readNString() throws SQLException { > 812 String attrib = (String)getNextAttribute(); > 813 lastValueWasNull =attrib == null; > 814return attrib; > 815 } > > Additionally I'm wondering, whether getNextAttribute() could be generified. > > -Ulf > From Ulf.Zibis at CoSoCo.de Sun Jan 13 11:45:43 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 12:45:43 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F296E6.90801@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> <50F296E6.90801@CoSoCo.de> Message-ID: <50F29E67.7020306@CoSoCo.de> Hi again, as you imported java.net.URL, you do not need to outline it in the code any more, e.g. line 769. Am 13.01.2013 12:13, schrieb Ulf Zibis: > ... and again more general: > xxx private T readNext() throws SQLException { > xxx T attrib = (T)getNextAttribute(); > xxx lastValueWasNull = attrib == null; > xxx return attrib; > xxx } > > 811 public String readNString() throws SQLException { > 812 return readNext(); > 813 } Again more simplified: 141 private T getNextAttribute() throws SQLException { 142 if (++idx >= attrib.length) { 143 throw new SQLException("SQLInputImpl exception: Invalid read " + 144 "position"); 145 } else { 146 lastValueWasNull = attrib[idx] == null; 146 return (T)attrib[idx]; 147 } 148 } 811 public String readNString() throws SQLException { 812 return getNextAttribute(); 813 } -Ulf From lance.andersen at oracle.com Sun Jan 13 12:24:13 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Sun, 13 Jan 2013 07:24:13 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F292C6.1000508@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> Message-ID: 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 Sent from my iPad On Jan 13, 2013, at 5:56 AM, Ulf Zibis wrote: > Am 12.01.2013 22:56, schrieb Lance Andersen - Oracle: >> Hi >> This is a review request for 8006139 which adds missing methods to SQLInput/Output >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ > > Hi, > > are you paid by code lines ;-) > Additionally you have left out one opportunity > ... or is it new code style, having 2 wrong indented closing braces in one line? > Yes I should have caught that and will fix > I would code: > > 811 public String readNString() throws SQLException { > 812 String attrib = (String)getNextAttribute(); > 813 lastValueWasNull =attrib == null; > 814return attrib; > 815 } > > Additionally I'm wondering, whether getNextAttribute() could be generified. Yes it probably could however I do no want to do this as part of this change > > -Ulf > From Ulf.Zibis at CoSoCo.de Sun Jan 13 12:26:48 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 13:26:48 +0100 Subject: Can't report bug Message-ID: <50F2A808.4070809@CoSoCo.de> Hi, what's about http://bugreport.sun.com/bugreport/ ? I get "Server not available" Is this temporary, or is it disabled because of new infrastructure? Thanks, -Ulf From Ulf.Zibis at CoSoCo.de Sun Jan 13 12:28:47 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 13:28:47 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> Message-ID: <50F2A87F.4080200@CoSoCo.de> Am 12.01.2013 22:56, schrieb Lance Andersen - Oracle: > Hi > This is a review request for 8006139 which adds missing methods to SQLInput/Output > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ All @since tags are missing in these classes :-( -Ulf From lance.andersen at oracle.com Sun Jan 13 12:33:43 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Sun, 13 Jan 2013 07:33:43 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F2A87F.4080200@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2A87F.4080200@CoSoCo.de> Message-ID: Yes I just noticed this The code was written before my time I will add them though 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 Sent from my iPad On Jan 13, 2013, at 7:28 AM, Ulf Zibis wrote: > > Am 12.01.2013 22:56, schrieb Lance Andersen - Oracle: >> Hi >> This is a review request for 8006139 which adds missing methods to SQLInput/Output >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ > > All @since tags are missing in these classes :-( > > -Ulf > From forax at univ-mlv.fr Sun Jan 13 12:33:35 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 13 Jan 2013 13:33:35 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> Message-ID: <50F2A99F.4010304@univ-mlv.fr> On 01/13/2013 01:24 PM, Lance @ Oracle wrote: > On Jan 13, 2013, at 5:56 AM, Ulf Zibis wrote: > >> Am 12.01.2013 22:56, schrieb Lance Andersen - Oracle: >>> Hi >>> This is a review request for 8006139 which adds missing methods to SQLInput/Output >>> >>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ >> Hi, >> >> are you paid by code lines ;-) >> Additionally you have left out one opportunity >> ... or is it new code style, having 2 wrong indented closing braces in one line? >> > Yes I should have caught that and will fix >> I would code: >> >> 811 public String readNString() throws SQLException { >> 812 String attrib = (String)getNextAttribute(); >> 813 lastValueWasNull =attrib == null; >> 814return attrib; >> 815 } >> >> Additionally I'm wondering, whether getNextAttribute() could be generified. > Yes it probably could however I do no want to do this as part of this change I disagree, it should not be generified, getNextAttribute() should return Object and be casted at callsite, it will more clear if a ClassCastException occurs. Relying on inference to ask the compiler to insert the cast is dubious, >> -Ulf >> R?mi From Ulf.Zibis at CoSoCo.de Sun Jan 13 13:20:29 2013 From: Ulf.Zibis at CoSoCo.de (Ulf) Date: Sun, 13 Jan 2013 14:20:29 +0100 Subject: RFE - add generic accessors to SQLInput, SQLOutput Message-ID: <50F2B49D.9060202@CoSoCo.de> Hi, because bugparade is not working, I post this here :-( There could be: public T read() throws SQLException; public void write(T obj) throws SQLException; Alternatively, maybe readObject(), writeObject() could be re-engineered with generic API. All other methods then could be deprecated ! E.g. in javax.sql.rowset.serial.SQLInputImpl the code simply could be: (private getNextAttribute() could be dropped) // rename Object[] attrib to attribs !!! public T readObject() throws SQLException { if (++idx >= attribs.length) { throw new SQLException("SQLInputImpl exception: Invalid read " + "position"); } Object attrib = attribs[idx]; lastValueWasNull = attrib == null; if (attrib instanceof Struct) { ... ... ... } return (T)attrib; } -Ulf From Ulf.Zibis at CoSoCo.de Sun Jan 13 13:26:17 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 14:26:17 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F2A99F.4010304@univ-mlv.fr> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> <50F2A99F.4010304@univ-mlv.fr> Message-ID: <50F2B5F9.4050606@CoSoCo.de> Am 13.01.2013 13:33, schrieb Remi Forax: >>> Additionally I'm wondering, whether getNextAttribute() could be generified. >> Yes it probably could however I do no want to do this as part of this change > > I disagree, it should not be generified, getNextAttribute() should return Object and be casted at > callsite, > it will more clear if a ClassCastException occurs. > Relying on inference to ask the compiler to insert the cast is dubious, I must admit, I do not understand. What would be wrong with that? : xxx private T readNext() throws SQLException { xxx T attrib = (T)getNextAttribute(); xxx lastValueWasNull = attrib == null; xxx return attrib; xxx } 811 public String readNString() throws SQLException { 812 return readNext(); 813 } ... so why not generifying getNextAttribute() directly? -Ulf From Alan.Bateman at oracle.com Sun Jan 13 13:37:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Jan 2013 13:37:48 +0000 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> Message-ID: <50F2B8AC.6080807@oracle.com> On 12/01/2013 21:56, Lance Andersen - Oracle wrote: > Hi > This is a review request for 8006139 which adds missing methods to SQLInput/Output > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ > Lance - I think this will require a spec clarification so that it's clear that ClassCastException can be thrown by these methods. Since this doesn't appear to have been specifically previously then I think you might need to check the current behavior of existing drivers (as they will need to be changed if they don't throw CCE already). -Alan From Lance.Andersen at oracle.com Sun Jan 13 14:17:06 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Sun, 13 Jan 2013 09:17:06 -0500 Subject: RFE - add generic accessors to SQLInput, SQLOutput In-Reply-To: <50F2B49D.9060202@CoSoCo.de> References: <50F2B49D.9060202@CoSoCo.de> Message-ID: <2B55706C-1432-4335-851C-CB907FC1D3D2@oracle.com> I. Will enter a feature request but I do not plan on a change for this release 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 Sent from my iPhone On Jan 13, 2013, at 8:20 AM, Ulf wrote: > Hi, > > because bugparade is not working, I post this here :-( > > There could be: > > public T read() throws SQLException; > public void write(T obj) throws SQLException; > > Alternatively, maybe readObject(), writeObject() could be re-engineered with generic API. > > All other methods then could be deprecated ! > > E.g. in javax.sql.rowset.serial.SQLInputImpl the code simply could be: > (private getNextAttribute() could be dropped) > > // rename Object[] attrib to attribs !!! > > public T readObject() throws SQLException { > if (++idx >= attribs.length) { > throw new SQLException("SQLInputImpl exception: Invalid read " + > "position"); > } > Object attrib = attribs[idx]; > lastValueWasNull = attrib == null; > if (attrib instanceof Struct) { > ... > ... > ... > } > return (T)attrib; > } > > > -Ulf > From Alan.Bateman at oracle.com Sun Jan 13 15:05:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Jan 2013 15:05:58 +0000 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F09EEC.1030009@oracle.com> References: <50F09EEC.1030009@oracle.com> Message-ID: <50F2CD56.4050904@oracle.com> On 11/01/2013 23:23, Aleksey Shipilev wrote: > Hi guys, > > This is the JDK side of changes for supporting @Contended: > http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ > > Status: > - This change is ready to be pushed; due to licensing reasons with > jsr166, we can only commit the stub; regular jsr166 sync will bring the > updated annotation later. > - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) > - CCC is in place, and Approved. > > I need a sponsor to push this. > Looks fine (although I do not like seeing this going into sun.misc). Do you want this to go into in via jdk8/tl? If so I can push it for you today, just let me know. -Alan. From Lance.Andersen at oracle.com Sun Jan 13 15:07:23 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Sun, 13 Jan 2013 10:07:23 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F2B8AC.6080807@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> Message-ID: I will enter a jbs entry on Monday for this Have a good weekend 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 Sent from my iPhone On Jan 13, 2013, at 8:37 AM, Alan Bateman wrote: > On 12/01/2013 21:56, Lance Andersen - Oracle wrote: >> Hi >> This is a review request for 8006139 which adds missing methods to SQLInput/Output >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8006139/webrev.00/ > Lance - I think this will require a spec clarification so that it's clear that ClassCastException can be thrown by these methods. Since this doesn't appear to have been specifically previously then I think you might need to check the current behavior of existing drivers (as they will need to be changed if they don't throw CCE already). > > -Alan From forax at univ-mlv.fr Sun Jan 13 15:11:10 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 13 Jan 2013 16:11:10 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F2B5F9.4050606@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> <50F2A99F.4010304@univ-mlv.fr> <50F2B5F9.4050606@CoSoCo.de> Message-ID: <50F2CE8E.8050007@univ-mlv.fr> On 01/13/2013 02:26 PM, Ulf Zibis wrote: > Am 13.01.2013 13:33, schrieb Remi Forax: >>>> Additionally I'm wondering, whether getNextAttribute() could be >>>> generified. >>> Yes it probably could however I do no want to do this as part of >>> this change >> >> I disagree, it should not be generified, getNextAttribute() should >> return Object and be casted at callsite, >> it will more clear if a ClassCastException occurs. >> Relying on inference to ask the compiler to insert the cast is dubious, > > I must admit, I do not understand. > > What would be wrong with that? : > xxx private T readNext() throws SQLException { > xxx T attrib = (T)getNextAttribute(); > xxx lastValueWasNull = attrib == null; > xxx return attrib; > xxx } > > 811 public String readNString() throws SQLException { > 812 return readNext(); > 813 } > > ... so why not generifying getNextAttribute() directly? because it's unclear in readNString() that you can have a ClassCastException, there is no cast in readNString. > > -Ulf > R?mi From kumar.x.srinivasan at oracle.com Sun Jan 13 16:42:43 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sun, 13 Jan 2013 08:42:43 -0800 Subject: RFR: 8005252: pack200 support for MethodParameters Message-ID: <50F2E403.1000505@oracle.com> Hi All, Please let me know if you have any comments on this enhancement, which makes pack200 understand and compress class files containing MethodParameters. This also reinstates a test which was disabled when the corresponding javac changes went in earlier. http://cr.openjdk.java.net/~ksrini/8005252/webrev.1/ Thanks Kumar From eric.mccorkle at oracle.com Sun Jan 13 17:30:35 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Sun, 13 Jan 2013 12:30:35 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F1AD23.3010604@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F0F128.5060000@oracle.com> <50F1AD23.3010604@oracle.com> Message-ID: <50F2EF3B.8070008@oracle.com> On 01/12/13 13:36, Joe Darcy wrote: > Hi Eric, > > On 1/11/2013 9:14 PM, Eric McCorkle wrote: >> I got halfway through implementing a change that would synthesize >> Parameter's for the static links (this for the inner classes), when it >> occurred to me: is there really a case for allowing reflection on those >> parameters. >> >> Put another way, >> >> public class Foo { >> public class Bar { >> int baz(int qux) { } >> } >> } >> >> Should baz.getParameters() return just qux, or should it expose >> Foo.this? On second thought, I can't think of a good reason why you >> *want* to reflect on Foo.this. > > You need to reflect on that parameter so you can call the constructor > properly using reflection :-) > Alright, I will make the logic changes and post for review. >> >> Also, the logic is much simpler. You just have to figure out how deep >> you are in inner classes, store that information somewhere, and offset >> by that much every time a Parameter calls back to its Executable to get >> information. The logic for synthesizing the this parameters is much >> more complex. >> >> Thoughts? > > We may need some more help from javac to mark parameters as synthesized > or synthetic, which can be done as follow-up work. For inner classes > that are members of types, the outer this parameters are required to be > a certain way by the platform specification to make linkage work. > *However*, local and anonymous classes only have to obey a compiler's > contract with itself and are not specified. In particular, not all such > inner classes constructors even have an outer this parameter. For > example, with javac the constructor of an anonymous class in a static > initializer will *not* have an other this parameter. > Is there any compelling reason that javac should generate information about the link parameters? They don't have a name, and have standard modifiers (presumably final and synthesized). It seems to me they ought to be synthesized by the reflection API. From zhong.j.yu at gmail.com Sun Jan 13 17:50:03 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Sun, 13 Jan 2013 11:50:03 -0600 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F2CE8E.8050007@univ-mlv.fr> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F292C6.1000508@CoSoCo.de> <50F2A99F.4010304@univ-mlv.fr> <50F2B5F9.4050606@CoSoCo.de> <50F2CE8E.8050007@univ-mlv.fr> Message-ID: Why not pass the target class, like private T getNextAttribute(Class clazz) throws SQLException { if (++idx >= attrib.length) { throw new SQLException("SQLInputImpl exception: Invalid read " + "position"); } else { Object attr = attrib[idx]; if(clazz.isInstance(attr)) return (T)attr; else throw new SQLException("Incorrect atribute type: "+clazz+" vs "+attr.getClass()); } } We can generate a more appropriate error (the ClassCastException is too general, the caller may not understand what caused it) More importantly, the type check is done much earlier. For example, in xxx private T readNext() throws SQLException { 001 T attrib = (T)getNextAttribute(); 002 lastValueWasNull = attrib == null; xxx return attrib; xxx } if the wrong attribute type is requested, line 001 does not throw, so line 002 is also executed, which is probably a bug. If line 001 throws, we won't have this bug. Zhong Yu On Sun, Jan 13, 2013 at 9:11 AM, Remi Forax wrote: > On 01/13/2013 02:26 PM, Ulf Zibis wrote: >> >> Am 13.01.2013 13:33, schrieb Remi Forax: >>>>> >>>>> Additionally I'm wondering, whether getNextAttribute() could be >>>>> generified. >>>> >>>> Yes it probably could however I do no want to do this as part of this >>>> change >>> >>> >>> I disagree, it should not be generified, getNextAttribute() should return >>> Object and be casted at callsite, >>> it will more clear if a ClassCastException occurs. >>> Relying on inference to ask the compiler to insert the cast is dubious, >> >> >> I must admit, I do not understand. >> >> What would be wrong with that? : >> xxx private T readNext() throws SQLException { >> xxx T attrib = (T)getNextAttribute(); >> xxx lastValueWasNull = attrib == null; >> xxx return attrib; >> xxx } >> >> 811 public String readNString() throws SQLException { >> 812 return readNext(); >> 813 } >> >> ... so why not generifying getNextAttribute() directly? > > > because it's unclear in readNString() that you can have a > ClassCastException, > there is no cast in readNString. > >> >> -Ulf >> > > R?mi > From vladimir.kozlov at oracle.com Sun Jan 13 18:30:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 13 Jan 2013 10:30:57 -0800 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F2CD56.4050904@oracle.com> References: <50F09EEC.1030009@oracle.com> <50F2CD56.4050904@oracle.com> Message-ID: <50F2FD61.2090107@oracle.com> Thank you, Alan I already pushed it into hotspot/jdk: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 We will promote it as we did before with similar changes together with Hotspot changes. Thanks, Vladimir On 1/13/13 7:05 AM, Alan Bateman wrote: > On 11/01/2013 23:23, Aleksey Shipilev wrote: >> Hi guys, >> >> This is the JDK side of changes for supporting @Contended: >> http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ >> >> Status: >> - This change is ready to be pushed; due to licensing reasons with >> jsr166, we can only commit the stub; regular jsr166 sync will bring the >> updated annotation later. >> - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) >> - CCC is in place, and Approved. >> >> I need a sponsor to push this. >> > Looks fine (although I do not like seeing this going into sun.misc). > > Do you want this to go into in via jdk8/tl? If so I can push it for you > today, just let me know. > > -Alan. From Alan.Bateman at oracle.com Sun Jan 13 20:08:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 13 Jan 2013 20:08:35 +0000 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> Message-ID: <50F31442.8090302@oracle.com> On 13/01/2013 15:07, Lance Andersen wrote: > I will enter a jbs entry on Monday for this > Assuming CCE is long standing behavior then it would be good to update the spec of all the other read* methods too. Alternatively a statement in the class description to cover it. One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. -Alan From Ulf.Zibis at CoSoCo.de Sun Jan 13 21:25:39 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 13 Jan 2013 22:25:39 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F31442.8090302@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> Message-ID: <50F32653.9070106@CoSoCo.de> Am 13.01.2013 21:08, schrieb Alan Bateman: > Assuming CCE is long standing behavior then it would be good to update the spec of all the other > read* methods too. Alternatively a statement in the class description to cover it. Only using a generified version of readObject(), a CCE would be less surprisingly to the user. The other methods then could be deprecated. > > One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The > methods could be changed to peek at the next attribute but that wouldn't work without > synchronization or making it clear in the spec that the it is not a thread-safe implementation of > SQLInput. Maybe we could add a move-back method, so the stream-like behaviour would be more clear. Was this API ever thread-safe? Does it make any sense to use it multi-threaded? -Ulf From chris.hegarty at oracle.com Sun Jan 13 22:14:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 13 Jan 2013 22:14:36 +0000 Subject: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API Message-ID: <20130113221518.BD0B247237@hg.openjdk.java.net> Changeset: 7db04ae3378f Author: chegar Date: 2013-01-13 22:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f 8006153: HTTP protocol handler authenication should use Base64 API Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java From david.holmes at oracle.com Sun Jan 13 23:23:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 09:23:10 +1000 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F2FD61.2090107@oracle.com> References: <50F09EEC.1030009@oracle.com> <50F2CD56.4050904@oracle.com> <50F2FD61.2090107@oracle.com> Message-ID: <50F341DE.6000908@oracle.com> On 14/01/2013 4:30 AM, Vladimir Kozlov wrote: > Thank you, Alan > > I already pushed it into hotspot/jdk: > > http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 > > We will promote it as we did before with similar changes together with > Hotspot changes. So this seem to be becoming a new process for avoiding flag days - which is not a bad thing. But previously this was only a special exception for jsr-292 and now we seem to be generalizing it without there being any proper discussion to ensure all the right pieces are place to do this and so that everyone knows what is being done. David ----- > Thanks, > Vladimir > > On 1/13/13 7:05 AM, Alan Bateman wrote: >> On 11/01/2013 23:23, Aleksey Shipilev wrote: >>> Hi guys, >>> >>> This is the JDK side of changes for supporting @Contended: >>> http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ >>> >>> Status: >>> - This change is ready to be pushed; due to licensing reasons with >>> jsr166, we can only commit the stub; regular jsr166 sync will bring the >>> updated annotation later. >>> - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) >>> - CCC is in place, and Approved. >>> >>> I need a sponsor to push this. >>> >> Looks fine (although I do not like seeing this going into sun.misc). >> >> Do you want this to go into in via jdk8/tl? If so I can push it for you >> today, just let me know. >> >> -Alan. From Lance.Andersen at oracle.com Sun Jan 13 23:51:44 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sun, 13 Jan 2013 18:51:44 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F32653.9070106@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> Message-ID: On Jan 13, 2013, at 4:25 PM, Ulf Zibis wrote: > > Am 13.01.2013 21:08, schrieb Alan Bateman: >> Assuming CCE is long standing behavior then it would be good to update the spec of all the other read* methods too. Alternatively a statement in the class description to cover it. Yes that is my plan. > > Only using a generified version of readObject(), a CCE would be less surprisingly to the user. The other methods then could be deprecated. Deprecation is not needed here, especially the compiler warnings. > >> >> One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. > > Maybe we could add a move-back method, so the stream-like behaviour would be more clear. > Was this API ever thread-safe? No, this code has not changed since it was written by the original authors in 2003 .and it was expected the user would deal with thread safety if required. > Does it make any sense to use it multi-threaded? Not worth the time given the rarity of this class being used. There are other other areas that are more important to spend time on . I do not see a need to spend a lot of cycles on something that is barely used unless someone in the community wants take it on as activity. This can be something that can be revisited once we get past the Java SE 8 hump 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 david.holmes at oracle.com Mon Jan 14 00:57:35 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 14 Jan 2013 00:57:35 +0000 Subject: hg: jdk8/tl/jdk: 8005232: (JEP-149) Class Instance size reduction Message-ID: <20130114005756.0533447239@hg.openjdk.java.net> Changeset: 1109bfff4e92 Author: dholmes Date: 2013-01-13 19:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 8005232: (JEP-149) Class Instance size reduction Summary: Moved the fields for cached reflection objects into a seperate ReflectionData object to reduce dynamic footprint. Reviewed-by: dholmes, mchung, shade Contributed-by: Peter Levart ! src/share/classes/java/lang/Class.java From david.holmes at oracle.com Mon Jan 14 01:04:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 11:04:27 +1000 Subject: Final RFR: 8005232 (JEP-149) Class Instance size reduction In-Reply-To: <50EE66BC.9080304@oracle.com> References: <50E9FEDB.8050800@oracle.com> <50EE186F.2070602@oracle.com> <50EE66BC.9080304@oracle.com> Message-ID: <50F3599B.6010505@oracle.com> Thanks everyone, this work has now been committed: author dholmes Sun Jan 13 19:57:06 2013 -0500 (5 minutes ago) changeset 6357 1109bfff4e92 parent 6356 7db04ae3378f 8005232: (JEP-149) Class Instance size reduction Summary: Moved the fields for cached reflection objects into a seperate ReflectionData object to reduce dynamic footprint. Reviewed-by: dholmes, mchung, shade Contributed-by: Peter Levart David ----- On 10/01/2013 4:59 PM, David Holmes wrote: > Hi Mandy, > > Thanks for the review. > > On 10/01/2013 11:25 AM, Mandy Chung wrote: >> On 1/6/2013 2:46 PM, David Holmes wrote: >>> >>> http://cr.openjdk.java.net/~dholmes/8005232/webrev/ >> >> This looks good to me. David - besides the footprint performance data, >> do you observe any performance difference in your performance testing >> (I think refworkload is what you ran)? > > I added the performance numbers to the bug report: > > https://jbs.oracle.com/bugs/browse/JDK-8005232 > > No observable performance differences with refworkload. > >> >> On 01/09/2013 01:19 PM, Aleksey Shipilev wrote: >>> On 01/09/2013 05:04 PM, Peter Levart wrote: >>> >>>> Strictly speaking, CAS is actually not needed here. Since we keep >>>> classRedefinedCount snapshot inside the ReflectionData, any races that >>>> would install "older" ReflectionData over "newer", would be quickly >>>> caught at next invocation to reflectionData(). So if there are any >>>> objections to usage of Unsafe, it can be removed and replaced by simple >>>> volatile write. >>>> >>> Yes, I think that would be more clear without any adverse impacts on >>> performance. Also, that better expresses the intent of requiring the >>> visibility, not the atomicity of cache update. >> >> I agree with Alekesey that it'd be simpler and clearer if CAS is replaced >> with the simple volatile write. But this change will require another >> round >> of performance measurement to determine its impact. I'd suggest to follow >> up this cleanup in a separate bug and changeset. > > I'm not sure about the validity of changing from CAS to a simpe write - > would need to think more deeply on it. But I agree with Mandy that the > performance impact would need to be investigated. In the normal case it > would be faster with no CAS but if there were "collisions" that might > change. Anyway something to consider for a follow-up. > > Thanks again, > David > >> Mandy From david.holmes at oracle.com Mon Jan 14 04:55:06 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2013 14:55:06 +1000 Subject: Request for Review: Java SE 8 Compact Profiles In-Reply-To: <50ED9245.5010302@oracle.com> References: <50D3FF29.6010005@oracle.com> <50E48239.9070505@oracle.com> <50E68ABF.8090303@oracle.com> <50ECEAE2.2050903@oracle.com> <50ED9245.5010302@oracle.com> Message-ID: <50F38FAA.5030404@oracle.com> Thanks Alan. Updated webrev just for good measure: http://cr.openjdk.java.net/~dholmes/8004265.v3/webrev.jdk/ David On 10/01/2013 1:52 AM, Alan Bateman wrote: > On 09/01/2013 03:58, Mandy Chung wrote: >> : >> >> Looks like the jar tool -m option allows an entry with a space >> "Profile: " (a space following ":") - an existing bug then. There may >> be other implementation to create a jar file that doesn't do the check >> though. > There is a long standing issue (and bugs) related to trailing spaces. > I'd like to stay clear of this one for this work. > >> : >> >> I see no issue with the jar tool to know about the profile names as >> they will be standard and part of the platform. Having the jar tool to >> validate the profile name will help catch mistake at packaging time. >> This is minor and I'm fine to revisit this in the future. > Okay, I'll go along with this and I've pushed a change to the > jdk8/profiles forest to do this and also expanded the tests to ensure > that the jar tool fails if an invalid profile is specified to -p. > > -Alan. From howard.lovatt at gmail.com Mon Jan 14 06:18:59 2013 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Mon, 14 Jan 2013 17:18:59 +1100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F17B81.6010603@cs.oswego.edu> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> <50F17B81.6010603@cs.oswego.edu> Message-ID: If you make a binary tree and sum it, the rounding errors aren't that bad and this algorithm is easy to parallelise. Higham, Nicholas J 1993 the accuracy of floating point summation SIAM Sci Comp 14 (4) 783-799 Also see Wikipedia for a description of Kahan summation and a general discussion of this topic. Why not commit to binary tree reductions and that will allow everyone to understand what is going on and design lambdas accordingly. -- Howard. Sent from my iPad On 13/01/2013, at 2:04 AM, Doug Lea

wrote: > On 01/11/13 21:37, Joe Darcy wrote: > >> I would prefer to cautionary note along the lines of "if you want numerical >> accuracy, take care to use a summation algorithm with defined worst-case behavior." >> >> (Varying magnitude is not so much of a problem if you add things up in the right >> order.) > > Thanks. I do not believe such an algorithm exists, because > no ordering control is possible, and all other known accuracy > improvements (like Kahn) require multiword atomicity, which we > explicitly do not provide. > > Which leaves me thinking that the current disclaimer (below) > is the best we can do. > > -Doug > >>>> "The order of accumulation within or across threads is not guaranteed. >>>> Thus, this class may not be applicable if numerical stability is >>>> required, especially when combining values of substantially different >>>> orders of magnitude." >>>> From chris.hegarty at oracle.com Mon Jan 14 10:07:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Jan 2013 10:07:09 +0000 Subject: RFR (XS): CR 8003985: Support @Contended annotation In-Reply-To: <50F341DE.6000908@oracle.com> References: <50F09EEC.1030009@oracle.com> <50F2CD56.4050904@oracle.com> <50F2FD61.2090107@oracle.com> <50F341DE.6000908@oracle.com> Message-ID: <50F3D8CD.3040603@oracle.com> On 13/01/2013 23:23, David Holmes wrote: > On 14/01/2013 4:30 AM, Vladimir Kozlov wrote: >> Thank you, Alan >> >> I already pushed it into hotspot/jdk: >> >> http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 >> >> We will promote it as we did before with similar changes together with >> Hotspot changes. > > So this seem to be becoming a new process for avoiding flag days - which > is not a bad thing. Agreed. > But previously this was only a special exception for > jsr-292 and now we seem to be generalizing it without there being any > proper discussion to ensure all the right pieces are place to do this > and so that everyone knows what is being done. I hope this "new" process can work both ways, push changes into the hotspot repo from TL. -Chris. > > David > ----- > >> Thanks, >> Vladimir >> >> On 1/13/13 7:05 AM, Alan Bateman wrote: >>> On 11/01/2013 23:23, Aleksey Shipilev wrote: >>>> Hi guys, >>>> >>>> This is the JDK side of changes for supporting @Contended: >>>> http://cr.openjdk.java.net/~shade/8003985/webrev.jdk.02/ >>>> >>>> Status: >>>> - This change is ready to be pushed; due to licensing reasons with >>>> jsr166, we can only commit the stub; regular jsr166 sync will bring the >>>> updated annotation later. >>>> - JEP-142 is in Funded state (http://openjdk.java.net/jeps/142) >>>> - CCC is in place, and Approved. >>>> >>>> I need a sponsor to push this. >>>> >>> Looks fine (although I do not like seeing this going into sun.misc). >>> >>> Do you want this to go into in via jdk8/tl? If so I can push it for you >>> today, just let me know. >>> >>> -Alan. From Alan.Bateman at oracle.com Mon Jan 14 10:11:16 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2013 10:11:16 +0000 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> Message-ID: <50F3D9C4.9050805@oracle.com> On 13/01/2013 23:51, Lance Andersen - Oracle wrote: > : > >>> One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. > I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. I understand, but if you add a catch-all in the class description to cover the CCE case then this could be part of the same paragraph. -Alan From lance.andersen at oracle.com Mon Jan 14 11:50:59 2013 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Mon, 14 Jan 2013 06:50:59 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F3D9C4.9050805@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> Message-ID: Yes sorry if that was not clear but that is my plan with the ccc and javadoc update I will get the JBS entry and ccc submitted later today and make a few of the minor suggestions from ulf and push out the revised webrev later today or Tuesday 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 Sent from my iPad On Jan 14, 2013, at 5:11 AM, Alan Bateman wrote: > On 13/01/2013 23:51, Lance Andersen - Oracle wrote: >> : >> >>>> One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. >> I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. > I understand, but if you add a catch-all in the class description to cover the CCE case then this could be part of the same paragraph. > > -Alan From aleksey.shipilev at oracle.com Mon Jan 14 13:31:59 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jan 2013 17:31:59 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50EF4143.4090008@oracle.com> References: <50EF4143.4090008@oracle.com> Message-ID: <50F408CF.6060207@oracle.com> I understand everyone is busy with JDK8 milestone, but maybe some critical people have missed this note? It would be terrific if someone could review this (or even sponsor it!). Thanks, Aleksey. On 01/11/2013 02:31 AM, Aleksey Shipilev wrote: > Hi, > > Submitting this on behalf of Doug Lea. The webrev is here: > http://cr.openjdk.java.net/~shade/8005926/webrev.00/ > > Bottom-line: merge ThreadLocalRandom state into Thread, to optimize many > use cases around j.u.c.* code. The simple performance tests on 2x2 i5, > Linux x86_64, 4 threads, 5 forks, 3x3s warmup, 5x3s measurement: > > JDK8 (baseline) > TLR.nextInt(): 6.4 +- 0.1 ns/op > TLR.current().nextInt(): 16.1 +- 0.4 ns/op > TL.get().nextInt(): 19.1 +- 0.6 ns/op > > JDK8 (patched) > TLR.nextInt(): 6.5 +- 0.2 ns/op > TLR.current().nextInt(): 6.4 +- 0.1 ns/op > TL.get().nextInt(): 17.2 +- 2.0 ns/op > > First line shows the peak performance of TLR itself, everything over > that is the ThreadLocal overhead. One can see the patched version > bypasses ThreadLocal machinery completely, and the overhead is slim to none. > > N.B. It gets especially interesting when there are many ThreadLocals > registered. Making 1M ThreadLocals and pre-touching them bloats the > thread-local maps, and we get: > > JDK8 (baseline), contaminators = 1M: > TLR.nextInt(): 6.4 +- 0.1 ns/op > TLR.current().nextInt(): 21.7 +- 5.3 ns/op > TL.get().nextInt(): 28.7 +- 1.1 ns/op > > JDK8 (patched), contaminators = 1M: > TLR.nextInt(): 6.6 +- 0.2 ns/op > TLR.current().nextInt(): 6.5 +- 0.1 ns/op > TL.get().nextInt(): 29.4 +- 0.5 ns/op > > Note that patched version successfully dodges this pathological case. > > Testing: > - Doug tested on his platforms > - Tested Linux x86_64 to build and run successfully > - JPRT builds are OK > - JPRT tests are OK (modulo some weird lambda/default-methods test > failures in jdk8/tl) > > Attribution: > - dl: original patch > - shade: testing, copyright headers, etc. > > -Aleksey. > From chris.hegarty at oracle.com Mon Jan 14 13:52:21 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Jan 2013 13:52:21 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F408CF.6060207@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> Message-ID: <50F40D95.9050402@oracle.com> For what it is worth, it is on my list for today. -Chris. On 14/01/2013 13:31, Aleksey Shipilev wrote: > I understand everyone is busy with JDK8 milestone, but maybe some > critical people have missed this note? It would be terrific if someone > could review this (or even sponsor it!). > > Thanks, > Aleksey. > > On 01/11/2013 02:31 AM, Aleksey Shipilev wrote: >> Hi, >> >> Submitting this on behalf of Doug Lea. The webrev is here: >> http://cr.openjdk.java.net/~shade/8005926/webrev.00/ >> >> Bottom-line: merge ThreadLocalRandom state into Thread, to optimize many >> use cases around j.u.c.* code. The simple performance tests on 2x2 i5, >> Linux x86_64, 4 threads, 5 forks, 3x3s warmup, 5x3s measurement: >> >> JDK8 (baseline) >> TLR.nextInt(): 6.4 +- 0.1 ns/op >> TLR.current().nextInt(): 16.1 +- 0.4 ns/op >> TL.get().nextInt(): 19.1 +- 0.6 ns/op >> >> JDK8 (patched) >> TLR.nextInt(): 6.5 +- 0.2 ns/op >> TLR.current().nextInt(): 6.4 +- 0.1 ns/op >> TL.get().nextInt(): 17.2 +- 2.0 ns/op >> >> First line shows the peak performance of TLR itself, everything over >> that is the ThreadLocal overhead. One can see the patched version >> bypasses ThreadLocal machinery completely, and the overhead is slim to none. >> >> N.B. It gets especially interesting when there are many ThreadLocals >> registered. Making 1M ThreadLocals and pre-touching them bloats the >> thread-local maps, and we get: >> >> JDK8 (baseline), contaminators = 1M: >> TLR.nextInt(): 6.4 +- 0.1 ns/op >> TLR.current().nextInt(): 21.7 +- 5.3 ns/op >> TL.get().nextInt(): 28.7 +- 1.1 ns/op >> >> JDK8 (patched), contaminators = 1M: >> TLR.nextInt(): 6.6 +- 0.2 ns/op >> TLR.current().nextInt(): 6.5 +- 0.1 ns/op >> TL.get().nextInt(): 29.4 +- 0.5 ns/op >> >> Note that patched version successfully dodges this pathological case. >> >> Testing: >> - Doug tested on his platforms >> - Tested Linux x86_64 to build and run successfully >> - JPRT builds are OK >> - JPRT tests are OK (modulo some weird lambda/default-methods test >> failures in jdk8/tl) >> >> Attribution: >> - dl: original patch >> - shade: testing, copyright headers, etc. >> >> -Aleksey. >> > From peter.levart at gmail.com Mon Jan 14 14:38:20 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jan 2013 15:38:20 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> <50F17B81.6010603@cs.oswego.edu> Message-ID: <50F4185C.5070803@gmail.com> I think these classes are targeted at use cases such as gathering real-time statistics of profiling or business data, where data comes in from various sources in real-time and statistics are sampled in real-time too... For bulk processing, the new streams API seems more appropriate. I think the user might be able to control the order of operations applied (j.u.stream.Spliterator API indicates that the spliting of work among FJP threads could be controled and we can hope that the order of reduction of intermediary results would also be controllable by the user or at least defined). Can streams API developers shed some light on that? Regards, Peter On 01/14/2013 07:18 AM, Howard Lovatt wrote: > If you make a binary tree and sum it, the rounding errors aren't that bad and this algorithm is easy to parallelise. > > Higham, Nicholas J 1993 the accuracy of floating point summation SIAM Sci Comp 14 (4) 783-799 > > Also see Wikipedia for a description of Kahan summation and a general discussion of this topic. > > Why not commit to binary tree reductions and that will allow everyone to understand what is going on and design lambdas accordingly. > > -- Howard. > > Sent from my iPad > > On 13/01/2013, at 2:04 AM, Doug Lea
wrote: > >> On 01/11/13 21:37, Joe Darcy wrote: >> >>> I would prefer to cautionary note along the lines of "if you want numerical >>> accuracy, take care to use a summation algorithm with defined worst-case behavior." >>> >>> (Varying magnitude is not so much of a problem if you add things up in the right >>> order.) >> Thanks. I do not believe such an algorithm exists, because >> no ordering control is possible, and all other known accuracy >> improvements (like Kahn) require multiword atomicity, which we >> explicitly do not provide. >> >> Which leaves me thinking that the current disclaimer (below) >> is the best we can do. >> >> -Doug >> >>>>> "The order of accumulation within or across threads is not guaranteed. >>>>> Thus, this class may not be applicable if numerical stability is >>>>> required, especially when combining values of substantially different >>>>> orders of magnitude." >>>>> From paul.sandoz at oracle.com Mon Jan 14 15:06:26 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jan 2013 16:06:26 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F4185C.5070803@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> <50F17B81.6010603@cs.oswego.edu> <50F4185C.5070803@gmail.com> Message-ID: <8F3F582B-50BE-4E3A-A4C1-1B48CEE58A1D@oracle.com> On Jan 14, 2013, at 3:38 PM, Peter Levart wrote: > I think these classes are targeted at use cases such as gathering real-time statistics of profiling or business data, where data comes in from various sources in real-time and statistics are sampled in real-time too... > > For bulk processing, the new streams API seems more appropriate. I think the user might be able to control the order of operations applied (j.u.stream.Spliterator API indicates that the spliting of work among FJP threads could be controled and we can hope that the order of reduction of intermediary results would also be controllable by the user or at least defined). > > Can streams API developers shed some light on that? > DoubleStream (when added) will have a sum method that will defer to a reduce, so elements will be processed in order, but the grouping of elements depends on how the input is split and to what depth, and the user will have no control over that. It is similar in concept to the IntStream.sum method, but i expect for DoubleStream the collectors API will be used with a double sum collector impl that compensates for errors and supports merging (in order) of intermediate sum values. Paul. > Regards, Peter > > On 01/14/2013 07:18 AM, Howard Lovatt wrote: >> If you make a binary tree and sum it, the rounding errors aren't that bad and this algorithm is easy to parallelise. >> >> Higham, Nicholas J 1993 the accuracy of floating point summation SIAM Sci Comp 14 (4) 783-799 >> >> Also see Wikipedia for a description of Kahan summation and a general discussion of this topic. >> >> Why not commit to binary tree reductions and that will allow everyone to understand what is going on and design lambdas accordingly. >> >> -- Howard. >> >> Sent from my iPad >> >> On 13/01/2013, at 2:04 AM, Doug Lea
wrote: >> >>> On 01/11/13 21:37, Joe Darcy wrote: >>> >>>> I would prefer to cautionary note along the lines of "if you want numerical >>>> accuracy, take care to use a summation algorithm with defined worst-case behavior." >>>> >>>> (Varying magnitude is not so much of a problem if you add things up in the right >>>> order.) >>> Thanks. I do not believe such an algorithm exists, because >>> no ordering control is possible, and all other known accuracy >>> improvements (like Kahn) require multiword atomicity, which we >>> explicitly do not provide. >>> >>> Which leaves me thinking that the current disclaimer (below) >>> is the best we can do. >>> >>> -Doug >>> >>>>>> "The order of accumulation within or across threads is not guaranteed. >>>>>> Thus, this class may not be applicable if numerical stability is >>>>>> required, especially when combining values of substantially different >>>>>> orders of magnitude." >>>>>> > From aleksey.shipilev at oracle.com Mon Jan 14 15:19:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 14 Jan 2013 19:19:45 +0400 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F4185C.5070803@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> <50F17B81.6010603@cs.oswego.edu> <50F4185C.5070803@gmail.com> Message-ID: <50F42211.4070602@oracle.com> On 01/14/2013 06:38 PM, Peter Levart wrote: > I think these classes are targeted at use cases such as gathering > real-time statistics of profiling or business data, where data comes in > from various sources in real-time and statistics are sampled in > real-time too... > > For bulk processing, the new streams API seems more appropriate. I think > the user might be able to control the order of operations applied > (j.u.stream.Spliterator API indicates that the spliting of work among > FJP threads could be controled and we can hope that the order of > reduction of intermediary results would also be controllable by the user > or at least defined). > > Can streams API developers shed some light on that? I'm a bit on both camps here; and have a different perspective. *Adders are suited for the cases when the threading is already out of control, i.e. you can not guarantee any particular order in which threads are calling the public methods. *Adders are the best thing you can do at this point (I'm not sure you can do better theoretically). There are remarkably large number of scenarios where you can find these useful; basically everywhere where you clearly have add/get ratio considerably high. Streams API, on the other hand, is at the explicit control of it's internal threading, and so Collectors [1] would be beating *Adders on most scenarios, because these accumulate() computation tree leaves thread-locally, and then combine() across the leaves. In fact, that pushed our internal performance tests from using *Adders as the way to safely reduce across parallel pipeline to more concise Collectors. HTHS, -Aleksey. [1] http://hg.openjdk.java.net/lambda/lambda/jdk/file/tip/src/share/classes/java/util/stream/Collector.java From peter.levart at gmail.com Mon Jan 14 15:47:54 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 14 Jan 2013 16:47:54 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <8F3F582B-50BE-4E3A-A4C1-1B48CEE58A1D@oracle.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> <50F17B81.6010603@cs.oswego.edu> <50F4185C.5070803@gmail.com> <8F3F582B-50BE-4E3A-A4C1-1B48CEE58A1D@oracle.com> Message-ID: <50F428AA.2020301@gmail.com> On 01/14/2013 04:06 PM, Paul Sandoz wrote: > On Jan 14, 2013, at 3:38 PM, Peter Levart wrote: > >> I think these classes are targeted at use cases such as gathering real-time statistics of profiling or business data, where data comes in from various sources in real-time and statistics are sampled in real-time too... >> >> For bulk processing, the new streams API seems more appropriate. I think the user might be able to control the order of operations applied (j.u.stream.Spliterator API indicates that the spliting of work among FJP threads could be controled and we can hope that the order of reduction of intermediary results would also be controllable by the user or at least defined). >> >> Can streams API developers shed some light on that? >> > DoubleStream (when added) will have a sum method that will defer to a reduce, so elements will be processed in order, but the grouping of elements depends on how the input is split and to what depth, and the user will have no control over that. Unless user implements his own Spliterator, right? > > It is similar in concept to the IntStream.sum method, but i expect for DoubleStream the collectors API will be used with a double sum collector impl that compensates for errors and supports merging (in order) of intermediate sum values. > > Paul. > >> Regards, Peter >> >> On 01/14/2013 07:18 AM, Howard Lovatt wrote: >>> If you make a binary tree and sum it, the rounding errors aren't that bad and this algorithm is easy to parallelise. >>> >>> Higham, Nicholas J 1993 the accuracy of floating point summation SIAM Sci Comp 14 (4) 783-799 >>> >>> Also see Wikipedia for a description of Kahan summation and a general discussion of this topic. >>> >>> Why not commit to binary tree reductions and that will allow everyone to understand what is going on and design lambdas accordingly. >>> >>> -- Howard. >>> >>> Sent from my iPad >>> >>> On 13/01/2013, at 2:04 AM, Doug Lea
wrote: >>> >>>> On 01/11/13 21:37, Joe Darcy wrote: >>>> >>>>> I would prefer to cautionary note along the lines of "if you want numerical >>>>> accuracy, take care to use a summation algorithm with defined worst-case behavior." >>>>> >>>>> (Varying magnitude is not so much of a problem if you add things up in the right >>>>> order.) >>>> Thanks. I do not believe such an algorithm exists, because >>>> no ordering control is possible, and all other known accuracy >>>> improvements (like Kahn) require multiword atomicity, which we >>>> explicitly do not provide. >>>> >>>> Which leaves me thinking that the current disclaimer (below) >>>> is the best we can do. >>>> >>>> -Doug >>>> >>>>>>> "The order of accumulation within or across threads is not guaranteed. >>>>>>> Thus, this class may not be applicable if numerical stability is >>>>>>> required, especially when combining values of substantially different >>>>>>> orders of magnitude." >>>>>>> From paul.sandoz at oracle.com Mon Jan 14 16:28:30 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 14 Jan 2013 17:28:30 +0100 Subject: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder In-Reply-To: <50F428AA.2020301@gmail.com> References: <50E86CAC.8090606@oracle.com> <50EB1CEC.6060600@oracle.com> <50EB24AA.40101@cs.oswego.edu> <50F03B62.5060308@oracle.com> <50F03F52.1050504@gmail.com> <50F0448E.5060108@cs.oswego.edu> <50F04963.6030302@oracle.com> <50F0CC7F.9030305@oracle.com> <50F17B81.6010603@cs.oswego.edu> <50F4185C.5070803@gmail.com> <8F3F582B-50BE-4E3A-A4C1-1B48CEE58A1D@oracle.com> <50F428AA.2020301@gmail.com> Message-ID: <0E7F454A-3FBC-4D8E-96BF-7C9255CD3B06@oracle.com> On Jan 14, 2013, at 4:47 PM, Peter Levart wrote: > On 01/14/2013 04:06 PM, Paul Sandoz wrote: >> On Jan 14, 2013, at 3:38 PM, Peter Levart wrote: >> >>> I think these classes are targeted at use cases such as gathering real-time statistics of profiling or business data, where data comes in from various sources in real-time and statistics are sampled in real-time too... >>> >>> For bulk processing, the new streams API seems more appropriate. I think the user might be able to control the order of operations applied (j.u.stream.Spliterator API indicates that the spliting of work among FJP threads could be controled and we can hope that the order of reduction of intermediary results would also be controllable by the user or at least defined). >>> >>> Can streams API developers shed some light on that? >>> >> DoubleStream (when added) will have a sum method that will defer to a reduce, so elements will be processed in order, but the grouping of elements depends on how the input is split and to what depth, and the user will have no control over that. > Unless user implements his own Spliterator, right? > To some extent. A Spliterator can split or say "I ain't gonna split no further!" but the framework may decide not to split before the Spliterator says no. IMHO i think a good Spliterator should keep on splitting until it reaches the limits of it's data and grouping wise it is best if a balanced tree is produced. Also it is worth pointing out that type of elements supplied by the spliterator may not be the same type of elements to reduce on. FWIW i was assuming 95% of users will never see a Spliterator. Paul. From chris.hegarty at oracle.com Mon Jan 14 18:20:34 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Jan 2013 18:20:34 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F40D95.9050402@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> Message-ID: <50F44C72.60707@oracle.com> Ooooooh.... this change goes beyond my review capability!!! I thought we were just eliminating the indirection of ThreadLocal, anyway... As a basic review I don't see anything obviously wrong, and I don't have a problem with adding the fields to j.l.Thread, but I'm not in a position to review in detail the algorithm used. Alan, did mention that he may be in a better position to do a detailed review. I can also sponsor this change. -Chris. On 14/01/2013 13:52, Chris Hegarty wrote: > For what it is worth, it is on my list for today. > > -Chris. > > On 14/01/2013 13:31, Aleksey Shipilev wrote: >> I understand everyone is busy with JDK8 milestone, but maybe some >> critical people have missed this note? It would be terrific if someone >> could review this (or even sponsor it!). >> >> Thanks, >> Aleksey. >> >> On 01/11/2013 02:31 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Submitting this on behalf of Doug Lea. The webrev is here: >>> http://cr.openjdk.java.net/~shade/8005926/webrev.00/ >>> >>> Bottom-line: merge ThreadLocalRandom state into Thread, to optimize many >>> use cases around j.u.c.* code. The simple performance tests on 2x2 i5, >>> Linux x86_64, 4 threads, 5 forks, 3x3s warmup, 5x3s measurement: >>> >>> JDK8 (baseline) >>> TLR.nextInt(): 6.4 +- 0.1 ns/op >>> TLR.current().nextInt(): 16.1 +- 0.4 ns/op >>> TL.get().nextInt(): 19.1 +- 0.6 ns/op >>> >>> JDK8 (patched) >>> TLR.nextInt(): 6.5 +- 0.2 ns/op >>> TLR.current().nextInt(): 6.4 +- 0.1 ns/op >>> TL.get().nextInt(): 17.2 +- 2.0 ns/op >>> >>> First line shows the peak performance of TLR itself, everything over >>> that is the ThreadLocal overhead. One can see the patched version >>> bypasses ThreadLocal machinery completely, and the overhead is slim >>> to none. >>> >>> N.B. It gets especially interesting when there are many ThreadLocals >>> registered. Making 1M ThreadLocals and pre-touching them bloats the >>> thread-local maps, and we get: >>> >>> JDK8 (baseline), contaminators = 1M: >>> TLR.nextInt(): 6.4 +- 0.1 ns/op >>> TLR.current().nextInt(): 21.7 +- 5.3 ns/op >>> TL.get().nextInt(): 28.7 +- 1.1 ns/op >>> >>> JDK8 (patched), contaminators = 1M: >>> TLR.nextInt(): 6.6 +- 0.2 ns/op >>> TLR.current().nextInt(): 6.5 +- 0.1 ns/op >>> TL.get().nextInt(): 29.4 +- 0.5 ns/op >>> >>> Note that patched version successfully dodges this pathological case. >>> >>> Testing: >>> - Doug tested on his platforms >>> - Tested Linux x86_64 to build and run successfully >>> - JPRT builds are OK >>> - JPRT tests are OK (modulo some weird lambda/default-methods test >>> failures in jdk8/tl) >>> >>> Attribution: >>> - dl: original patch >>> - shade: testing, copyright headers, etc. >>> >>> -Aleksey. >>> >> From Alan.Bateman at oracle.com Mon Jan 14 18:53:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2013 18:53:26 +0000 Subject: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F06487.3040705@oracle.com> References: <50ED7E7C.1030803@oracle.com> <50F044BD.30503@oracle.com> <50F0627E.7010404@oracle.com> <50F06487.3040705@oracle.com> Message-ID: <50F45426.6090402@oracle.com> On 11/01/2013 19:14, Daniel Fuchs wrote: > > Although it seems cleaner to use a SchemaFactoryConfigurationError, > we could wrap the ServiceConfigurationError in > an IllegalArgumentException - which is what would have eventually > been thrown in the old code. > > If that seems like a safer strategy I could update the changes in > this sense. I went through the existing code and it appears that configuration issues (missing class listed in META-INF/services/javax.xml.validation.SchemaFactory for example) are just ignored. This causes it to continue and probably fall back to the default implementation, and IAE if the default implementation does not support the schema language. On the other hand, if the provider's constructor throws a runtime exception or error then it just gets propagated. So overall the existing implementation is inconsistent and anything we do (add the proposed SchemaFactoryConfigurationError or throw IAE with an appropriate cause) is going to be a change in behavior. As SchemaFactoryConfigurationError is much cleaner then I'm wondering if we should just "bite the bullet" and get it over with. One small thing that I noticed is that the provider's isSchemaLanguageSupported method will be invoked twice when running with assertions is enabled. This is observable, and might cause a provider to initialize itself twice so I wonder if it would be better to remove part of this assert. For the non-SL cases then if newXMLSchemaFactoryNoServiceLoader isn't static or public then the factory is ignored. I could imagine that being hard to debug so so I wonder about treating it as a configuration error. Otherwise I think these changes look good. -Alan. From joel.franck at oracle.com Mon Jan 14 19:08:32 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 14 Jan 2013 19:08:32 +0000 Subject: hg: jdk8/tl/langtools: 7193719: Support repeating annotations in javax.lang.model Message-ID: <20130114190837.C51BE47261@hg.openjdk.java.net> Changeset: 9f42a06a49c0 Author: jfranck Date: 2013-01-14 19:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f42a06a49c0 7193719: Support repeating annotations in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/Element.java From naoto.sato at oracle.com Mon Jan 14 19:17:42 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 14 Jan 2013 19:17:42 +0000 Subject: hg: jdk8/tl/jdk: 7162007: Clean up i18n related caches Message-ID: <20130114191803.3DF1247263@hg.openjdk.java.net> Changeset: 1d7a6adf499f Author: naoto Date: 2013-01-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7a6adf499f 7162007: Clean up i18n related caches Reviewed-by: okutsu, ohair ! make/java/java/FILES_java.gmk ! 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/NumberFormat.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java From martinrb at google.com Mon Jan 14 20:01:32 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Jan 2013 12:01:32 -0800 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F44C72.60707@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> Message-ID: On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty wrote: > Ooooooh.... this change goes beyond my review capability!!! We don't really need another one, since we already have Aleksey and Doug, right? We should cc: Doug on threads like this (even though he is on the list). From chris.hegarty at oracle.com Mon Jan 14 20:09:54 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Jan 2013 20:09:54 +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> Message-ID: On 14 Jan 2013, at 20:01, Martin Buchholz wrote: > On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty > wrote: >> Ooooooh.... this change goes beyond my review capability!!! > > We don't really need another one, since we already have Aleksey and Doug, right? I wasn't sure if Aleksey was volunteering to be an official reviewer or not? If so, I'll go ahead and push this ( I'm happy with my with the bits i understand ). > We should cc: Doug on threads like this (even though he is on the list). Yes, agreed. Sorry about this. -Chris From aleksey.shipilev at oracle.com Mon Jan 14 20:15:33 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 00:15:33 +0400 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> Message-ID: <50F46765.2030402@oracle.com> On 01/15/2013 12:09 AM, Chris Hegarty wrote: > > On 14 Jan 2013, at 20:01, Martin Buchholz > wrote: > >> On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty >> wrote: >>> Ooooooh.... this change goes beyond my review capability!!! >> >> We don't really need another one, since we already have Aleksey and >> Doug, right? > > I wasn't sure if Aleksey was volunteering to be an official reviewer > or not? If so, I'll go ahead and push this ( I'm happy with my with > the bits i understand ). I'm not sure I'm listed as reviewer by OpenJDK census. If that does not matter, then yes, count me as the reviewer :) -Aleksey. From martinrb at google.com Mon Jan 14 20:21:13 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Jan 2013 12:21:13 -0800 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F46765.2030402@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F46765.2030402@oracle.com> Message-ID: On Mon, Jan 14, 2013 at 12:15 PM, Aleksey Shipilev wrote: > I'm not sure I'm listed as reviewer by OpenJDK census. If that does not > matter, then yes, count me as the reviewer :) OpenJDK should give Aleksey some reviewer bits, but I don't know how that happens. From rob.mckenna at oracle.com Mon Jan 14 21:12:59 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 14 Jan 2013 21:12:59 +0000 Subject: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Message-ID: <50F474DB.3090405@oracle.com> Simple enough fix but to be honest I'm not sure any value will *always* work for the dead process waitFor(). Our testing infrastructure seems to glide past whatever we consider to be acceptable tolerances. http://cr.openjdk.java.net/~robm/8005618/webrev.01/ -Rob From jonathan.gibbons at oracle.com Mon Jan 14 21:50:59 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Jan 2013 21:50:59 +0000 Subject: hg: jdk8/tl/langtools: 8006119: update javac to follow latest spec for repeatable annotations Message-ID: <20130114215104.C7FBE47268@hg.openjdk.java.net> Changeset: df694c775e8a Author: jjg Date: 2013-01-14 13:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/df694c775e8a 8006119: update javac to follow latest spec for repeatable annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.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/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java ! test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java ! test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out ! test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java ! test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out ! test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java ! test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java ! test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out ! test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java ! test/tools/javac/diags/examples.not-yet.txt - 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/InvalidDuplicateAnnotation.java + test/tools/javac/diags/examples/RepeatableDocumentedMismatch.java + test/tools/javac/diags/examples/RepeatableInheritedMismatch.java + test/tools/javac/diags/examples/RepeatableNoValue.java + test/tools/javac/diags/examples/RepeatableNonDefault.java + test/tools/javac/diags/examples/RepeatableRetentionMismatch.java + test/tools/javac/diags/examples/RepeatableTargetMismatch.java + test/tools/javac/diags/examples/RepeatableWrongValueType.java ! test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java From Alan.Bateman at oracle.com Mon Jan 14 22:17:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jan 2013 22:17:11 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F44C72.60707@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> Message-ID: <50F483E7.6080504@oracle.com> On 14/01/2013 18:20, Chris Hegarty wrote: > Ooooooh.... this change goes beyond my review capability!!! I thought > we were just eliminating the indirection of ThreadLocal, anyway... > > As a basic review I don't see anything obviously wrong, and I don't > have a problem with adding the fields to j.l.Thread, but I'm not in a > position to review in detail the algorithm used. > > Alan, did mention that he may be in a better position to do a detailed > review. I can also sponsor this change. I looked at the changes and they look good to me. The additional fields of java.lang.Thread shouldn't be an issue. The other thing I notice is that the serialized form of the original ThreadLocalRandom included the padding fields, I guess they should have been transient in the original implementation. -Alan. From jonathan.gibbons at oracle.com Mon Jan 14 22:18:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Jan 2013 22:18:40 +0000 Subject: hg: jdk8/tl/langtools: 8006241: Test DocRootSlash.java fails Message-ID: <20130114221844.D58714726C@hg.openjdk.java.net> Changeset: d54b4a091450 Author: jjg Date: 2013-01-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d54b4a091450 8006241: Test DocRootSlash.java fails Reviewed-by: darcy ! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java From aleksey.shipilev at oracle.com Mon Jan 14 22:33:50 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 02:33:50 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F483E7.6080504@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> Message-ID: <50F487CE.6010101@oracle.com> On 01/15/2013 02:17 AM, Alan Bateman wrote: > The other thing I notice is that the serialized form of the original > ThreadLocalRandom included the padding fields, I guess they should have > been transient in the original implementation. Damn. These *are* the part of TLR serialized form :( http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom Also, the class changes probably screwed up the SUID. I think we need to get the padding back (which should not be the problem since TLR is now a singleton, and add the SUID with the previous value. -Aleksey. From heinz at javaspecialists.eu Mon Jan 14 22:36:34 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 15 Jan 2013 00:36:34 +0200 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F483E7.6080504@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> Message-ID: The padded fields are interesting, as in Java 7 they would quite possibly be optimized away or at least rearranged, no? My own tests certainly suggested this. Probably a case for @Contended? Also, do you intend on moving the padding fields over to Thread too? Other than my questions about padding, for what it's worth, I think this is a splendid suggestion :-) On 15/01/2013, Alan Bateman wrote: > On 14/01/2013 18:20, Chris Hegarty wrote: >> Ooooooh.... this change goes beyond my review capability!!! I thought >> we were just eliminating the indirection of ThreadLocal, anyway... >> >> As a basic review I don't see anything obviously wrong, and I don't >> have a problem with adding the fields to j.l.Thread, but I'm not in a >> position to review in detail the algorithm used. >> >> Alan, did mention that he may be in a better position to do a detailed >> review. I can also sponsor this change. > I looked at the changes and they look good to me. The additional fields > of java.lang.Thread shouldn't be an issue. > > The other thing I notice is that the serialized form of the original > ThreadLocalRandom included the padding fields, I guess they should have > been transient in the original implementation. > > -Alan. > -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From heinz at javaspecialists.eu Mon Jan 14 22:40:35 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 15 Jan 2013 00:40:35 +0200 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F487CE.6010101@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> Message-ID: We can probably fake the serialized form with some field descriptors and a writeObject and readObject method. Then we can keep the format exactly the same as previously. The serialized form should not stop us from optimizing this very important class. Just my 2c On 15/01/2013, Aleksey Shipilev wrote: > On 01/15/2013 02:17 AM, Alan Bateman wrote: >> The other thing I notice is that the serialized form of the original >> ThreadLocalRandom included the padding fields, I guess they should have >> been transient in the original implementation. > > Damn. These *are* the part of TLR serialized form :( > http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom > > Also, the class changes probably screwed up the SUID. I think we need to > get the padding back (which should not be the problem since TLR is now a > singleton, and add the SUID with the previous value. > > -Aleksey. > -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From aleksey.shipilev at oracle.com Mon Jan 14 22:44:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 02:44:45 +0400 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> Message-ID: <50F48A5D.6050806@oracle.com> Agreed. But I think just faking it with the plain fields is less error-prone. The memory overhead is somewhat 8x8 = 64 bytes per JVM instance. -Aleksey. On 01/15/2013 02:40 AM, Dr Heinz M. Kabutz wrote: > We can probably fake the serialized form with some field descriptors > and a writeObject and readObject method. Then we can keep the format > exactly the same as previously. The serialized form should not stop > us from optimizing this very important class. Just my 2c > > On 15/01/2013, Aleksey Shipilev wrote: >> On 01/15/2013 02:17 AM, Alan Bateman wrote: >>> The other thing I notice is that the serialized form of the original >>> ThreadLocalRandom included the padding fields, I guess they should have >>> been transient in the original implementation. >> >> Damn. These *are* the part of TLR serialized form :( >> http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom >> >> Also, the class changes probably screwed up the SUID. I think we need to >> get the padding back (which should not be the problem since TLR is now a >> singleton, and add the SUID with the previous value. >> >> -Aleksey. >> > > From chris.hegarty at oracle.com Mon Jan 14 22:47:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Jan 2013 22:47:14 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F487CE.6010101@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> Message-ID: On 14 Jan 2013, at 22:33, Aleksey Shipilev wrote: > On 01/15/2013 02:17 AM, Alan Bateman wrote: >> The other thing I notice is that the serialized form of the original >> ThreadLocalRandom included the padding fields, I guess they should have >> been transient in the original implementation. > > Damn. These *are* the part of TLR serialized form :( > http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom > > Also, the class changes probably screwed up the SUID. I think we need to > get the padding back (which should not be the problem since TLR is now a > singleton, and add the SUID with the previous value. Or serialPersistentFields? I was thinking of this anyway, so we could get rid of rnd. -Chris > > -Aleksey. From aleksey.shipilev at oracle.com Mon Jan 14 22:51:47 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 02:51:47 +0400 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> Message-ID: <50F48C03.1060508@oracle.com> On 01/15/2013 02:36 AM, Dr Heinz M. Kabutz wrote: > The padded fields are interesting, as in Java 7 they would quite > possibly be optimized away or at least rearranged, no? At my level of HotSpot knowledge I find this very unlikely. Once the class is loaded, it's layout is finalized. That pretty much means the padding is with you forever (this is a nice side-effect current implementation of @Contended is relying on). > My own tests > certainly suggested this. Probably a case for @Contended? Also, do > you intend on moving the padding fields over to Thread too? Doug insists there is no reason to pad Threads. I suspect there is the reason. This is the tie needing the empirical study. Preliminary data (in this thread) suggests we don't need to pad. At this point we can just wait for dust to settle in, make a do-over for perf experiments and decide whether to stick @Contended on Thread or not. -Aleksey. From aleksey.shipilev at oracle.com Mon Jan 14 22:53:14 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 02:53:14 +0400 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> Message-ID: <50F48C5A.4040500@oracle.com> On 01/15/2013 02:47 AM, Chris Hegarty wrote: > > On 14 Jan 2013, at 22:33, Aleksey Shipilev wrote: > >> On 01/15/2013 02:17 AM, Alan Bateman wrote: >>> The other thing I notice is that the serialized form of the original >>> ThreadLocalRandom included the padding fields, I guess they should have >>> been transient in the original implementation. >> >> Damn. These *are* the part of TLR serialized form :( >> http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom >> >> Also, the class changes probably screwed up the SUID. I think we need to >> get the padding back (which should not be the problem since TLR is now a >> singleton, and add the SUID with the previous value. > > Or serialPersistentFields? I was thinking of this anyway, so we could get rid of rnd. I'm not sure what we are saving here. Since new TLR is a singleton, we save ~64 bytes per classloader. Worth messing with advanced serialization mechanics? Probably not. I'll publish a revised webrev soon. -Aleksey. From chris.hegarty at oracle.com Mon Jan 14 22:58:31 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Jan 2013 22:58:31 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F48C5A.4040500@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> Message-ID: <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@oracle.com> On 14 Jan 2013, at 22:53, Aleksey Shipilev wrote: > On 01/15/2013 02:47 AM, Chris Hegarty wrote: >> >> On 14 Jan 2013, at 22:33, Aleksey Shipilev wrote: >> >>> On 01/15/2013 02:17 AM, Alan Bateman wrote: >>>> The other thing I notice is that the serialized form of the original >>>> ThreadLocalRandom included the padding fields, I guess they should have >>>> been transient in the original implementation. >>> >>> Damn. These *are* the part of TLR serialized form :( >>> http://docs.oracle.com/javase/7/docs/api/serialized-form.html#java.util.concurrent.ThreadLocalRandom >>> >>> Also, the class changes probably screwed up the SUID. I think we need to >>> get the padding back (which should not be the problem since TLR is now a >>> singleton, and add the SUID with the previous value. >> >> Or serialPersistentFields? I was thinking of this anyway, so we could get rid of rnd. > > I'm not sure what we are saving here. Since new TLR is a singleton, we > save ~64 bytes per classloader. Worth messing with advanced > serialization mechanics? Probably not. I'll publish a revised webrev soon. serialPersistentFields is really quite simple, and will help avoid any potential issues like this in the future. I can help implement this on top of your patch if you like. -Chris. > > -Aleksey. > > From aleksey.shipilev at oracle.com Mon Jan 14 23:04:12 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 03:04:12 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@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> Message-ID: <50F48EEC.8040308@oracle.com> On 01/15/2013 02:58 AM, Chris Hegarty wrote: > serialPersistentFields is really quite simple, and will help avoid > any potential issues like this in the future. I can help implement > this on top of your patch if you like. Oh, please go ahead. That's the learning opportunity for me (never used sPF before, ready to learn from masters). -Aleksey. From heinz at javaspecialists.eu Mon Jan 14 23:17:04 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 15 Jan 2013 01:17:04 +0200 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F48EEC.8040308@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> <50F48EEC.8040308@oracle.com> Message-ID: Yeah, that's what I meant in my earlier post. It keeps the serial format compatible with little impact on performance in this case. On 15/01/2013, Aleksey Shipilev wrote: > On 01/15/2013 02:58 AM, Chris Hegarty wrote: >> serialPersistentFields is really quite simple, and will help avoid >> any potential issues like this in the future. I can help implement >> this on top of your patch if you like. > > Oh, please go ahead. That's the learning opportunity for me (never used > sPF before, ready to learn from masters). > > -Aleksey. > -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz From dl at cs.oswego.edu Mon Jan 14 23:55:50 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 14 Jan 2013 18:55:50 -0500 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <8E0C1F8A-DF46-457C-81DB-0BC41FC5F2D5@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> Message-ID: <50F49B06.9070202@cs.oswego.edu> On 01/14/13 17:58, Chris Hegarty wrote: >> I'm not sure what we are saving here. Since new TLR is a singleton, we >> save ~64 bytes per classloader. Worth messing with advanced >> serialization mechanics? Probably not. I'll publish a revised webrev soon. > > serialPersistentFields is really quite simple, and will help avoid any potential issues like this in the future. I can help implement this on top of your patch if you like. > Thanks to Alan and Aleksey for noticing this and to Chris for offering some serialPersistentFields incantations! (The only way to serialize a TLR represents a strange abuse to begin with. You'd need to save the result of ThreadLocalRandom.current() in a field of a serialized object. Which would be a terrible idea ...) -Doug From kumar.x.srinivasan at oracle.com Tue Jan 15 00:23:10 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 15 Jan 2013 00:23:10 +0000 Subject: hg: jdk8/tl/jdk: 8005252: pack200 should support MethodParameters Message-ID: <20130115002332.5968147270@hg.openjdk.java.net> Changeset: dcb64d498d5b Author: ksrini Date: 2013-01-14 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcb64d498d5b 8005252: pack200 should support MethodParameters 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/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/ProblemList.txt ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From martinrb at google.com Tue Jan 15 01:00:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Jan 2013 17:00:30 -0800 Subject: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently In-Reply-To: <50F474DB.3090405@oracle.com> References: <50F474DB.3090405@oracle.com> Message-ID: Looks good! Mea culpa for some of those slow and flaky sleeps in this code, although they are tricky to avoid - there is no cross-process latches, for example. On Mon, Jan 14, 2013 at 1:12 PM, Rob McKenna wrote: > Simple enough fix but to be honest I'm not sure any value will *always* work > for the dead process waitFor(). Our testing infrastructure seems to glide > past whatever we consider to be acceptable tolerances. > > http://cr.openjdk.java.net/~robm/8005618/webrev.01/ > > > -Rob From david.holmes at oracle.com Tue Jan 15 01:31:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2013 11:31:38 +1000 Subject: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently In-Reply-To: <50F474DB.3090405@oracle.com> References: <50F474DB.3090405@oracle.com> Message-ID: <50F4B17A.3080502@oracle.com> On 15/01/2013 7:12 AM, Rob McKenna wrote: > Simple enough fix but to be honest I'm not sure any value will *always* > work for the dead process waitFor(). Our testing infrastructure seems to > glide past whatever we consider to be acceptable tolerances. > > http://cr.openjdk.java.net/~robm/8005618/webrev.01/ > Using the latch seems reasonable but the existing wait/sleep times do not. Why waitFor(10000) if the main thread is going to interrupt you after a sleep(1000) ??? David > -Rob From martinrb at google.com Tue Jan 15 02:11:41 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 14 Jan 2013 18:11:41 -0800 Subject: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently In-Reply-To: <50F4B17A.3080502@oracle.com> References: <50F474DB.3090405@oracle.com> <50F4B17A.3080502@oracle.com> Message-ID: On Mon, Jan 14, 2013 at 5:31 PM, David Holmes wrote: > On 15/01/2013 7:12 AM, Rob McKenna wrote: >> >> Simple enough fix but to be honest I'm not sure any value will *always* >> work for the dead process waitFor(). Our testing infrastructure seems to >> glide past whatever we consider to be acceptable tolerances. >> >> http://cr.openjdk.java.net/~robm/8005618/webrev.01/ >> > > > Using the latch seems reasonable but the existing wait/sleep times do not. > Why waitFor(10000) if the main thread is going to interrupt you after a > sleep(1000) ??? Actually, in this case it would be even safer to sleep longer, i.e. "impossibly" long, without any testing performance problem. I am tempted to clean up a bunch of those other sleeps that actually do cause performance problems, as perhaps are you. From xuelei.fan at oracle.com Tue Jan 15 02:32:53 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 15 Jan 2013 02:32:53 +0000 Subject: hg: jdk8/tl/jdk: 8006265: Add test SSLEngineDeadlock.java to ProblemList Message-ID: <20130115023314.1F84047277@hg.openjdk.java.net> Changeset: edb7e34a0531 Author: xuelei Date: 2013-01-14 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/edb7e34a0531 8006265: Add test SSLEngineDeadlock.java to ProblemList Reviewed-by: weijun ! test/ProblemList.txt From heinz at javaspecialists.eu Tue Jan 15 08:06:54 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 15 Jan 2013 10:06:54 +0200 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F49B06.9070202@cs.oswego.edu> 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> Message-ID: <50F50E1E.5040604@javaspecialists.eu> Doug Lea wrote: > On 01/14/13 17:58, Chris Hegarty wrote: > >>> I'm not sure what we are saving here. Since new TLR is a singleton, we >>> save ~64 bytes per classloader. Worth messing with advanced >>> serialization mechanics? Probably not. I'll publish a revised webrev >>> soon. >> >> serialPersistentFields is really quite simple, and will help avoid >> any potential issues like this in the future. I can help implement >> this on top of your patch if you like. >> > > Thanks to Alan and Aleksey for noticing this and to Chris for > offering some serialPersistentFields incantations! > > (The only way to serialize a TLR represents a strange abuse to > begin with. You'd need to save the result of > ThreadLocalRandom.current() in a field of a serialized object. > Which would be a terrible idea ...) Right, which means we should also add a readResolve() method to return ThreadLocalRandom.current(). All you need to do is add this to the class and the format should be compatible with Java 1.7. This means that if someone made the mistake of writing ThreadLocalRandom instances, they would now still be able to read, but would instead get the correct instance back for their thread: /** * We keep the same serial persistent format as in Java 1.7. */ 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), }; /** * Writes the ThreadLocalRandom object to the ObjectOutputStream using the * same format as in the past. */ private void writeObject(ObjectOutputStream out) throws IOException { ObjectOutputStream.PutField fields = out.putFields(); fields.put("rnd", rnd); 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(); } /** * Reads the ThreadLocalRandom object from the stream in order to keep * the format compatible, but does not use any of the read data. */ private void readObject(ObjectInputStream in) throws ClassNotFoundException, IOException { in.readFields(); // we can ignore the values, since we will replace them in the // readResolve() method anyway } /** * Once the ThreadLocalRandom object has been read from the stream, we * throw it away and instead return the correct instance for our thread. */ private Object readResolve() { return current(); } From Alan.Bateman at oracle.com Tue Jan 15 08:55:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 08:55:48 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F49B06.9070202@cs.oswego.edu> 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> Message-ID: <50F51994.7090105@oracle.com> On 14/01/2013 23:55, Doug Lea wrote: > > Thanks to Alan and Aleksey for noticing this and to Chris for > offering some serialPersistentFields incantations! > > (The only way to serialize a TLR represents a strange abuse to > begin with. You'd need to save the result of > ThreadLocalRandom.current() in a field of a serialized object. > Which would be a terrible idea ...) It does seem nonsensical. Given that the padding isn't used then the simplest thing might be to do "nothing", meaning treat this update as an API change that changes the serialized form. I don't see any compatibility issues as deserialization on an older release will just leave the padding fields with their default values (and as they are unused then it shouldn't matter). I think this would be simplest than adding serialPersistentFields and a writeObject to write these unused fields. -Alan From peter.levart at gmail.com Tue Jan 15 09:40:31 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jan 2013 10:40:31 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F51994.7090105@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> <50F51994.7090105@oracle.com> Message-ID: <50F5240F.90003@gmail.com> On 01/15/2013 09:55 AM, Alan Bateman wrote: > On 14/01/2013 23:55, Doug Lea wrote: >> >> Thanks to Alan and Aleksey for noticing this and to Chris for >> offering some serialPersistentFields incantations! >> >> (The only way to serialize a TLR represents a strange abuse to >> begin with. You'd need to save the result of >> ThreadLocalRandom.current() in a field of a serialized object. >> Which would be a terrible idea ...) > It does seem nonsensical. Given that the padding isn't used then the > simplest thing might be to do "nothing", meaning treat this update as > an API change that changes the serialized form. I don't see any > compatibility issues as deserialization on an older release will just > leave the padding fields with their default values (and as they are > unused then it shouldn't matter). I think this would be simplest than > adding serialPersistentFields and a writeObject to write these unused > fields. > > -Alan If this is an API change, then it might as well be a change in the serializability of the ThreadLocalRandom instance. Since TLR extends Random which is already Serializable, this could be done by throwing appropriate exception in writeObject(). I don't think anyone would really notice. Serializability of a java.util.Random is meant to transfer the state of the object over the wire (including current seed). This can't be done for ThreadLocalRandom since it's a singleton with thread-bound state. So serializability of TLR is dubious. Regards, Peter From aleksey.shipilev at oracle.com Tue Jan 15 09:57:32 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 13:57:32 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F5240F.90003@gmail.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> <50F51994.7090105@oracle.com> <50F5240F.90003@gmail.com> Message-ID: <50F5280C.7030400@oracle.com> On 01/15/2013 01:40 PM, Peter Levart wrote: > If this is an API change, then it might as well be a change in the > serializability of the ThreadLocalRandom instance. Since TLR extends > Random which is already Serializable, this could be done by throwing > appropriate exception in writeObject(). > > I don't think anyone would really notice. > > Serializability of a java.util.Random is meant to transfer the state of > the object over the wire (including current seed). This can't be done > for ThreadLocalRandom since it's a singleton with thread-bound state. So > serializability of TLR is dubious. That's an interesting thought indeed. However, I would say already receiving TLR from the stream and throwing the "don't want it" exception would be surprising. We are at the curse of having these fields exposed in serialized form; the only thing we can do is to minimize further leakage. Chris, do you need help preparing the patch? -Aleksey. From Alan.Bateman at oracle.com Tue Jan 15 10:01:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 10:01:04 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F5240F.90003@gmail.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> <50F51994.7090105@oracle.com> <50F5240F.90003@gmail.com> Message-ID: <50F528E0.1040409@oracle.com> On 15/01/2013 09:40, Peter Levart wrote: > If this is an API change, then it might as well be a change in the > serializability of the ThreadLocalRandom instance. Since TLR extends > Random which is already Serializable, this could be done by throwing > appropriate exception in writeObject(). > > I don't think anyone would really notice. Dubious as it might be, I'm sure it would break somebody so I think it would be safer not to do this. -Alan. From peter.levart at gmail.com Tue Jan 15 10:03:59 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jan 2013 11:03:59 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F51994.7090105@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> <50F51994.7090105@oracle.com> Message-ID: <50F5298F.1080809@gmail.com> On 01/15/2013 09:55 AM, Alan Bateman wrote: > On 14/01/2013 23:55, Doug Lea wrote: >> >> Thanks to Alan and Aleksey for noticing this and to Chris for >> offering some serialPersistentFields incantations! >> >> (The only way to serialize a TLR represents a strange abuse to >> begin with. You'd need to save the result of >> ThreadLocalRandom.current() in a field of a serialized object. >> Which would be a terrible idea ...) > It does seem nonsensical. Given that the padding isn't used then the > simplest thing might be to do "nothing", meaning treat this update as > an API change that changes the serialized form. I don't see any > compatibility issues as deserialization on an older release will just > leave the padding fields with their default values (and as they are > unused then it shouldn't matter). I think this would be simplest than > adding serialPersistentFields and a writeObject to write these unused > fields. And one more thing. With moving of fields off the TLR object, the semantics of de-serialization change. JDK7 TLR deserializes into an instance which is not thread-bound with the copy of the seed of original instance. So serializing/deserializing acts as a form of cloning the instance and detaching the copy from the thread. Proposed TLR can't keep this semantics (unless it is modeled as a private subclass of TLR for example which overrides existing logic and provides a writeReplace() method that replaces it with plain TLR instance before serializing). Regards, Peter From chris.hegarty at oracle.com Tue Jan 15 10:12:12 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Jan 2013 10:12:12 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F5280C.7030400@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> <50F51994.7090105@oracle.com> <50F5240F.90003@gmail.com> <50F5280C.7030400@oracle.com> Message-ID: <50F52B7C.6020604@oracle.com> On 01/15/2013 09:57 AM, Aleksey Shipilev wrote: > On 01/15/2013 01:40 PM, Peter Levart wrote: >> If this is an API change, then it might as well be a change in the >> serializability of the ThreadLocalRandom instance. Since TLR extends >> Random which is already Serializable, this could be done by throwing >> appropriate exception in writeObject(). >> >> I don't think anyone would really notice. >> >> Serializability of a java.util.Random is meant to transfer the state of >> the object over the wire (including current seed). This can't be done >> for ThreadLocalRandom since it's a singleton with thread-bound state. So >> serializability of TLR is dubious. > > That's an interesting thought indeed. However, I would say already > receiving TLR from the stream and throwing the "don't want it" exception > would be surprising. We are at the curse of having these fields exposed > in serialized form; the only thing we can do is to minimize further leakage. > > Chris, do you need help preparing the patch? I'm still not sure that we have agreement here. My preference, for what it's worth, is to forge ahead with Peter's suggestion, and update the TLR specification to throw in the case of writeObject. I believe this would be the best solution. Add similar text to the class description: * Note, that although ThreadLocalRandom inherits Serializable * interface from Random, it is not intended to be Serializable. * Appropriate serialization methods are implemented to throw * NotSerializableException. /** * Throws NotSerializableException, since TLR * objects are not intended to be serializable. */ private void writeObject(java.io.ObjectOutputStream out) throws NotSerializableException { throw new NotSerializableException("Not serializable."); } private void readObject(java.io.ObjectInputStream in) throws NotSerializableException { // swallow all field data. } This of course, is subject to spec change approval. -Chris. > > -Aleksey. > From aleksey.shipilev at oracle.com Tue Jan 15 10:20:35 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 14:20:35 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F52B7C.6020604@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> <50F51994.7090105@oracle.com> <50F5240F.90003@gmail.com> <50F5280C.7030400@oracle.com> <50F52B7C.6020604@oracle.com> Message-ID: <50F52D73.5080709@oracle.com> On 01/15/2013 02:12 PM, Chris Hegarty wrote: > On 01/15/2013 09:57 AM, Aleksey Shipilev wrote: >> Chris, do you need help preparing the patch? > > I'm still not sure that we have agreement here. Sorry, I should not have replied in this thread. > My preference, for what it's worth, is to forge ahead with Peter's > suggestion, and update the TLR specification to throw in the case of > writeObject. I believe this would be the best solution. > > Add similar text to the class description: > > * Note, that although ThreadLocalRandom inherits Serializable > * interface from Random, it is not intended to be Serializable. > * Appropriate serialization methods are implemented to throw > * NotSerializableException. > > /** > * Throws NotSerializableException, since TLR > * objects are not intended to be serializable. > */ > private void writeObject(java.io.ObjectOutputStream out) > throws NotSerializableException > { > throw new NotSerializableException("Not serializable."); > } > > private void readObject(java.io.ObjectInputStream in) > throws NotSerializableException > { > // swallow all field data. > } I'm technically OK with this, plus: + readResolve returning the actual TLR + SVUID fixup > This of course, is subject to spec change approval. ...but this leads me back to thinking if we should still persist the leaked serialization form (serialPersistentFields code put together by Heinz is fine) to make this functionality in JDK8 for Doug to rely on, and then back off to suggestions for collapsing serialization forms. -Aleksey. From alexey.utkin at oracle.com Tue Jan 15 10:30:36 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Tue, 15 Jan 2013 10:30:36 +0000 Subject: hg: jdk8/tl/jdk: 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Message-ID: <20130115103109.B66EE47285@hg.openjdk.java.net> Changeset: a40052a54801 Author: uta Date: 2013-01-15 14:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40052a54801 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Summary: Javadoc was changed in accordance with CCC-8005250 request. Reviewed-by: alanb, amenkov ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/javax/imageio/spi/IIORegistry.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/swing/UIManager.java From chris.hegarty at oracle.com Tue Jan 15 11:45:16 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Jan 2013 11:45:16 +0000 Subject: hg: jdk8/tl/jdk: 8005406: HTTP server implementation should use Base64 API Message-ID: <20130115114538.593DD4728A@hg.openjdk.java.net> Changeset: 4b012af44f24 Author: chegar Date: 2013-01-15 11:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b012af44f24 8005406: HTTP server implementation should use Base64 API Reviewed-by: khazra, alanb, chegar Contributed-by: Mark Sheppard ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java From Alan.Bateman at oracle.com Tue Jan 15 11:55:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 11:55:10 +0000 Subject: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently In-Reply-To: <50F4B17A.3080502@oracle.com> References: <50F474DB.3090405@oracle.com> <50F4B17A.3080502@oracle.com> Message-ID: <50F5439E.507@oracle.com> On 15/01/2013 01:31, David Holmes wrote: > On 15/01/2013 7:12 AM, Rob McKenna wrote: >> Simple enough fix but to be honest I'm not sure any value will *always* >> work for the dead process waitFor(). Our testing infrastructure seems to >> glide past whatever we consider to be acceptable tolerances. >> >> http://cr.openjdk.java.net/~robm/8005618/webrev.01/ >> > > Using the latch seems reasonable but the existing wait/sleep times do > not. Why waitFor(10000) if the main thread is going to interrupt you > after a sleep(1000) ??? It's testing that Process.waitFor will be interrupted by Thread.interrupt so it requires a thread to block in waitFor. Using sleeps is always going to be problematic as the load on test machines is unpredictable but I think Rob's proposed change does make this test a bit more robust. -Alan. From david.holmes at oracle.com Tue Jan 15 12:41:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2013 22:41:30 +1000 Subject: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently In-Reply-To: <50F5439E.507@oracle.com> References: <50F474DB.3090405@oracle.com> <50F4B17A.3080502@oracle.com> <50F5439E.507@oracle.com> Message-ID: <50F54E7A.9050805@oracle.com> On 15/01/2013 9:55 PM, Alan Bateman wrote: > On 15/01/2013 01:31, David Holmes wrote: >> On 15/01/2013 7:12 AM, Rob McKenna wrote: >>> Simple enough fix but to be honest I'm not sure any value will *always* >>> work for the dead process waitFor(). Our testing infrastructure seems to >>> glide past whatever we consider to be acceptable tolerances. >>> >>> http://cr.openjdk.java.net/~robm/8005618/webrev.01/ >>> >> >> Using the latch seems reasonable but the existing wait/sleep times do >> not. Why waitFor(10000) if the main thread is going to interrupt you >> after a sleep(1000) ??? > It's testing that Process.waitFor will be interrupted by > Thread.interrupt so it requires a thread to block in waitFor. Using > sleeps is always going to be problematic as the load on test machines is > unpredictable but I think Rob's proposed change does make this test a > bit more robust. Ah I see. I'd missed that aspect of this. Thanks for clarifying. David > -Alan. From dl at cs.oswego.edu Tue Jan 15 13:25:43 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 15 Jan 2013 08:25:43 -0500 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F50E1E.5040604@javaspecialists.eu> 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> Message-ID: <50F558D7.5040509@cs.oswego.edu> >> (The only way to serialize a TLR represents a strange abuse to >> begin with. You'd need to save the result of >> ThreadLocalRandom.current() in a field of a serialized object. >> Which would be a terrible idea ...) And so, anything sensible that we do here will have the (too nice?) effect of "fixing" the errors of anyone crazy enough to do this -- rather than deserializing into a non-thread-local ThreadLocalRandom, it will attach to the common one. Given all this, I think Heinz's suggestion below looks suitable. Chris, do you agree about the serialization incantations? -Doug On 01/15/13 03:06, Dr Heinz M. Kabutz wrote: > Right, which means we should also add a readResolve() method to return > ThreadLocalRandom.current(). All you need to do is add this to the class and > the format should be compatible with Java 1.7. This means that if someone made > the mistake of writing ThreadLocalRandom instances, they would now still be able > to read, but would instead get the correct instance back for their thread: > > /** > * We keep the same serial persistent format as in Java 1.7. > */ > 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), > }; > > /** > * Writes the ThreadLocalRandom object to the ObjectOutputStream using the > * same format as in the past. > */ > private void writeObject(ObjectOutputStream out) throws IOException { > ObjectOutputStream.PutField fields = out.putFields(); > fields.put("rnd", rnd); > 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(); > } > > /** > * Reads the ThreadLocalRandom object from the stream in order to keep > * the format compatible, but does not use any of the read data. > */ > private void readObject(ObjectInputStream in) > throws ClassNotFoundException, IOException { > in.readFields(); > // we can ignore the values, since we will replace them in the > // readResolve() method anyway > } > > /** > * Once the ThreadLocalRandom object has been read from the stream, we > * throw it away and instead return the correct instance for our thread. > */ > private Object readResolve() { > return current(); > } > From Alan.Bateman at oracle.com Tue Jan 15 13:37:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 13:37:19 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F558D7.5040509@cs.oswego.edu> 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> Message-ID: <50F55B8F.40502@oracle.com> On 15/01/2013 13:25, Doug Lea wrote: > : > > And so, anything sensible that we do here will have the > (too nice?) effect of "fixing" the errors of anyone > crazy enough to do this -- rather than deserializing into > a non-thread-local ThreadLocalRandom, it will attach to > the common one. > > Given all this, I think Heinz's suggestion below looks suitable. > Chris, do you agree about the serialization incantations? Heinz's proposal is fine but I think you also have the option of just dropping the pad fields from the serialization form (meaning no need for serialPersistentFields or writeObject). Technically it would be "API change" but one that shouldn't have any impact as the fields were never used and hence deserializing to their default value is okay. -Alan From chris.hegarty at oracle.com Tue Jan 15 13:38:45 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Jan 2013 13:38:45 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F558D7.5040509@cs.oswego.edu> 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> Message-ID: <50F55BE5.9040404@oracle.com> On 01/15/2013 01:25 PM, Doug Lea wrote: > >>> (The only way to serialize a TLR represents a strange abuse to >>> begin with. You'd need to save the result of >>> ThreadLocalRandom.current() in a field of a serialized object. >>> Which would be a terrible idea ...) > > And so, anything sensible that we do here will have the > (too nice?) effect of "fixing" the errors of anyone > crazy enough to do this -- rather than deserializing into > a non-thread-local ThreadLocalRandom, it will attach to > the common one. > > Given all this, I think Heinz's suggestion below looks suitable. > Chris, do you agree about the serialization incantations? Yes, I am starting to come to this conclusion too (Heinz's suggestion). There are a few @serialField tags to be added so we continue to generate correct javadoc. Otherwise, I think we are good. I'll follow up on this and send out a complete patch for review. If the TLR spec is ever to be updated to specify that it is not ( any more ) serializable (Peters suggestion), writeObect throw, we can do this at a later stage. -Chris. > > -Doug > > On 01/15/13 03:06, Dr Heinz M. Kabutz wrote: >> Right, which means we should also add a readResolve() method to return >> ThreadLocalRandom.current(). All you need to do is add this to the >> class and >> the format should be compatible with Java 1.7. This means that if >> someone made >> the mistake of writing ThreadLocalRandom instances, they would now >> still be able >> to read, but would instead get the correct instance back for their >> thread: >> >> /** >> * We keep the same serial persistent format as in Java 1.7. >> */ >> 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), >> }; >> >> /** >> * Writes the ThreadLocalRandom object to the ObjectOutputStream >> using the >> * same format as in the past. >> */ >> private void writeObject(ObjectOutputStream out) throws IOException { >> ObjectOutputStream.PutField fields = out.putFields(); >> fields.put("rnd", rnd); >> 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(); >> } >> >> /** >> * Reads the ThreadLocalRandom object from the stream in order to >> keep >> * the format compatible, but does not use any of the read data. >> */ >> private void readObject(ObjectInputStream in) >> throws ClassNotFoundException, IOException { >> in.readFields(); >> // we can ignore the values, since we will replace them in the >> // readResolve() method anyway >> } >> >> /** >> * Once the ThreadLocalRandom object has been read from the >> stream, we >> * throw it away and instead return the correct instance for our >> thread. >> */ >> private Object readResolve() { >> return current(); >> } >> > From chris.hegarty at oracle.com Tue Jan 15 13:49:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Jan 2013 13:49:48 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F55B8F.40502@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> Message-ID: <50F55E7C.8040809@oracle.com> On 01/15/2013 01:37 PM, Alan Bateman wrote: > On 15/01/2013 13:25, Doug Lea wrote: >> : >> >> And so, anything sensible that we do here will have the >> (too nice?) effect of "fixing" the errors of anyone >> crazy enough to do this -- rather than deserializing into >> a non-thread-local ThreadLocalRandom, it will attach to >> the common one. >> >> Given all this, I think Heinz's suggestion below looks suitable. >> Chris, do you agree about the serialization incantations? > Heinz's proposal is fine but I think you also have the option of just > dropping the pad fields from the serialization form (meaning no need for > serialPersistentFields or writeObject). Technically it would be "API > change" but one that shouldn't have any impact as the fields were never > used and hence deserializing to their default value is okay. But wouldn't there be an issue with JDK7 TLR streams being deserialized by JDK8, pad fields would be left in the Object input steam? If so, then we're down the road of having to have a readObject, etc... and possibly back to serialPersistentFields? -Chris. > > -Alan From Alan.Bateman at oracle.com Tue Jan 15 13:57:54 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 13:57:54 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F55E7C.8040809@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> Message-ID: <50F56062.5070404@oracle.com> On 15/01/2013 13:49, Chris Hegarty wrote: > > But wouldn't there be an issue with JDK7 TLR streams being > deserialized by JDK8, pad fields would be left in the Object input > steam? If so, then we're down the road of having to have a readObject, > etc... and possibly back to serialPersistentFields? Technically deleting fields is an incompatible change as the stream will not contain the fields. If someone is crazy enough to serialize with jdk8 TLR and send it to a jdk7 release then the fields will have their default value (as the values aren't in the stream). As the fields aren't used then I don't think this should make a difference. Going the other way shouldn't be an issue either as the pad fields will be ignored. -Alan. From peter.levart at gmail.com Tue Jan 15 14:11:33 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jan 2013 15:11:33 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F56062.5070404@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> Message-ID: <50F56395.2090205@gmail.com> On 01/15/2013 02:57 PM, Alan Bateman wrote: > On 15/01/2013 13:49, Chris Hegarty wrote: >> >> But wouldn't there be an issue with JDK7 TLR streams being >> deserialized by JDK8, pad fields would be left in the Object input >> steam? If so, then we're down the road of having to have a >> readObject, etc... and possibly back to serialPersistentFields? > Technically deleting fields is an incompatible change as the stream > will not contain the fields. If someone is crazy enough to serialize > with jdk8 TLR and send it to a jdk7 release then the fields will have > their default value (as the values aren't in the stream). As the > fields aren't used then I don't think this should make a difference. > Going the other way shouldn't be an issue either as the pad fields > will be ignored. > > -Alan. Should there also be a change/patch to JDK7 TLR that would "fix" the strange behaviour (by adding readResolve)? This would align the semantics no matter which direction (7/7, 7/8, 8/7, 8/8) of serialization/deserialization is used... Regards, Peter From peter.levart at gmail.com Tue Jan 15 14:33:05 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jan 2013 15:33:05 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F56062.5070404@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> Message-ID: <50F568A1.8030806@gmail.com> One more thing, not related to serialization: If a TLR reference is somehow passed from the thread that obtained it via TLR.current() to some other thread that did never call TLR.current() and this other thread calls methods on such instance (nextInt(), ...), it will start the random sequence from the zero seed, bypassing localInit() call... Is this ok? Regards, Peter From aleksey.shipilev at oracle.com Tue Jan 15 14:38:58 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 18:38:58 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F568A1.8030806@gmail.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> <50F568A1.8030806@gmail.com> Message-ID: <50F56A02.1010104@oracle.com> On 01/15/2013 06:33 PM, Peter Levart wrote: > One more thing, not related to serialization: > > If a TLR reference is somehow passed from the thread that obtained it > via TLR.current() to some other thread that did never call TLR.current() > and this other thread calls methods on such instance (nextInt(), ...), > it will start the random sequence from the zero seed, bypassing > localInit() call... > > Is this ok? I think this counts as "accidental" sharing, and Javadoc recommends to always do TLR.current().* to take the appropriate TLR; hence I think this is the adopted failure scenario. The upside for *not* fixing this is skipping the initialized checks from each of next*() methods, which are needed in corner cases only, thus saving the hot-path performance. -Aleksey. From peter.levart at gmail.com Tue Jan 15 14:50:25 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jan 2013 15:50:25 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F56A02.1010104@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> <50F568A1.8030806@gmail.com> <50F56A02.1010104@oracle.com> Message-ID: <50F56CB1.3010504@gmail.com> On 01/15/2013 03:38 PM, Aleksey Shipilev wrote: > On 01/15/2013 06:33 PM, Peter Levart wrote: >> One more thing, not related to serialization: >> >> If a TLR reference is somehow passed from the thread that obtained it >> via TLR.current() to some other thread that did never call TLR.current() >> and this other thread calls methods on such instance (nextInt(), ...), >> it will start the random sequence from the zero seed, bypassing >> localInit() call... >> >> Is this ok? > I think this counts as "accidental" sharing, and Javadoc recommends to > always do TLR.current().* to take the appropriate TLR; hence I think > this is the adopted failure scenario. The upside for *not* fixing this > is skipping the initialized checks from each of next*() methods, which > are needed in corner cases only, thus saving the hot-path performance. If javadoc recommends to always do TLR.current() then this method is also hot-path. So why not move the initialization check from current() to next(int bits)? Well, the following usage pattern can save some checks in the original case: TLR r = TLR.current(); r.next*(); .... r.next*(); .... Regards, Peter > > -Aleksey. > From Alan.Bateman at oracle.com Tue Jan 15 15:02:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 15:02:17 +0000 Subject: RFR: javax.xml.xpath: Using ServiceLoader to load JAXP XPath factories (7169894: JAXP Plugability Layer: using service loader) In-Reply-To: <50F0215D.2030600@oracle.com> References: <50F0215D.2030600@oracle.com> Message-ID: <50F56F79.1030604@oracle.com> On 11/01/2013 14:27, Daniel Fuchs wrote: > Hi, > > Here is a new webrev in the series that addresses using ServiceLoader in > JAXP for JDK 8. > > 7169894: JAXP Plugability Layer: using service loader > > This changeset addresses modification in the javax.xml.xpath > package. > > This changes are very similar to the changes proposed for > the javax.xml.validation package, except that here we didn't > need to add a new Error class. > > > It's great to get the end of these updates. I looked at the xpath changes and it mostly looks good to me. As per the validation work, it looks like the isObjectModelSupported method will be called twice when assertions are enabled (it's a minor concern). One thing that I don't get is newXPathFactoryNoServiceLoader - maybe this is question for Joe but is this means to create the XPathFactory documented anywhere, I don't see it in the javadoc. A minor style comment on this is that method declaration looks like odd. Otherwise I think this is good. -Alan. From aleksey.shipilev at oracle.com Tue Jan 15 15:06:21 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 19:06:21 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F56CB1.3010504@gmail.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> <50F568A1.8030806@gmail.com> <50F56A02.1010104@oracle.com> <50F56CB1.3010504@gmail.com> Message-ID: <50F5706D.8070401@oracle.com> On 01/15/2013 06:50 PM, Peter Levart wrote: > On 01/15/2013 03:38 PM, Aleksey Shipilev wrote: >> On 01/15/2013 06:33 PM, Peter Levart wrote: >>> One more thing, not related to serialization: >>> >>> If a TLR reference is somehow passed from the thread that obtained it >>> via TLR.current() to some other thread that did never call TLR.current() >>> and this other thread calls methods on such instance (nextInt(), ...), >>> it will start the random sequence from the zero seed, bypassing >>> localInit() call... >>> >>> Is this ok? >> I think this counts as "accidental" sharing, and Javadoc recommends to >> always do TLR.current().* to take the appropriate TLR; hence I think >> this is the adopted failure scenario. The upside for *not* fixing this >> is skipping the initialized checks from each of next*() methods, which >> are needed in corner cases only, thus saving the hot-path performance. > > If javadoc recommends to always do TLR.current() then this method is > also hot-path. So why not move the initialization check from current() > to next(int bits)? Well, the following usage pattern can save some > checks in the original case: > > TLR r = TLR.current(); > > r.next*(); .... r.next*(); .... I'm not sure I understand your comment, Peter. Your code calls TLR.current() first, and that is a good move, as per Javadoc; it should be probably mentioned that TLR should be *acquired* via current(). This does not prevent acquiring TLR once per scope, or even per thread. Before, the performance bets were off for rogue non-current() TLRs, now we should extend that to the statistical properties as well. -Aleksey. From chris.hegarty at oracle.com Tue Jan 15 16:33:33 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Jan 2013 16:33:33 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F56062.5070404@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> Message-ID: <50F584DD.6080108@oracle.com> Updated webrev: http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ * based on Aleksey initial webrev * applied serialPersistentFields, writeObject, readResolve ( as suggested by Heinz ) * did not apply readObject. It is unnecessary, defaultReadObject will read all the fields off the stream readResolve is necessary to give us "good" behavior ( as noted previously ). Once integrated, I will file a new bug to track the possible change of serialized form of TLR, and this can then remove serialPersistentFields and writeObject, if successful. -Chris. On 01/15/2013 01:57 PM, Alan Bateman wrote: > On 15/01/2013 13:49, Chris Hegarty wrote: >> >> But wouldn't there be an issue with JDK7 TLR streams being >> deserialized by JDK8, pad fields would be left in the Object input >> steam? If so, then we're down the road of having to have a readObject, >> etc... and possibly back to serialPersistentFields? > Technically deleting fields is an incompatible change as the stream will > not contain the fields. If someone is crazy enough to serialize with > jdk8 TLR and send it to a jdk7 release then the fields will have their > default value (as the values aren't in the stream). As the fields aren't > used then I don't think this should make a difference. Going the other > way shouldn't be an issue either as the pad fields will be ignored. > > -Alan. From aleksey.shipilev at oracle.com Tue Jan 15 16:39:21 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 15 Jan 2013 20:39:21 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F58639.3020901@oracle.com> On 01/15/2013 08:33 PM, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ Looks good to me; thanks for picking this up! -Aleksey. P.S. How many (Java) (concurrency) experts it takes to make a change to ThreadLocalRandom? From Lance.Andersen at oracle.com Tue Jan 15 16:48:20 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 15 Jan 2013 11:48:20 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F3D9C4.9050805@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> Message-ID: <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> Here is a revision http://cr.openjdk.java.net/~lancea/8006139/webrev.01 I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut & paste when the code was written) and ccc request As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. Best lance On Jan 14, 2013, at 5:11 AM, Alan Bateman wrote: > On 13/01/2013 23:51, Lance Andersen - Oracle wrote: >> : >> >>>> One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. >> I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. > I understand, but if you add a catch-all in the class description to cover the CCE case then this could be part of the same paragraph. > > -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 dl at cs.oswego.edu Tue Jan 15 17:28:31 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 15 Jan 2013 12:28:31 -0500 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F591BF.3090707@cs.oswego.edu> On 01/15/13 11:33, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ > Looks great; thanks!! -Doug > * based on Aleksey initial webrev > * applied serialPersistentFields, writeObject, readResolve > ( as suggested by Heinz ) > * did not apply readObject. It is unnecessary, defaultReadObject > will read all the fields off the stream > > readResolve is necessary to give us "good" behavior ( as noted previously ). > > Once integrated, I will file a new bug to track the possible change of > serialized form of TLR, and this can then remove serialPersistentFields and > writeObject, if successful. > > -Chris. > > > On 01/15/2013 01:57 PM, Alan Bateman wrote: >> On 15/01/2013 13:49, Chris Hegarty wrote: >>> >>> But wouldn't there be an issue with JDK7 TLR streams being >>> deserialized by JDK8, pad fields would be left in the Object input >>> steam? If so, then we're down the road of having to have a readObject, >>> etc... and possibly back to serialPersistentFields? >> Technically deleting fields is an incompatible change as the stream will >> not contain the fields. If someone is crazy enough to serialize with >> jdk8 TLR and send it to a jdk7 release then the fields will have their >> default value (as the values aren't in the stream). As the fields aren't >> used then I don't think this should make a difference. Going the other >> way shouldn't be an issue either as the pad fields will be ignored. >> >> -Alan. > From zhong.j.yu at gmail.com Tue Jan 15 17:31:10 2013 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 15 Jan 2013 11:31:10 -0600 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F483E7.6080504@oracle.com> References: <50EF4143.4090008@oracle.com> <50F408CF.6060207@oracle.com> <50F40D95.9050402@oracle.com> <50F44C72.60707@oracle.com> <50F483E7.6080504@oracle.com> Message-ID: >From user's point of view, there is nothing thread local about it - it is more like one global random generator, which is unseedable and unrepeatable. So why not call it a different name, like concurrent random? On Mon, Jan 14, 2013 at 4:17 PM, Alan Bateman wrote: > On 14/01/2013 18:20, Chris Hegarty wrote: >> >> Ooooooh.... this change goes beyond my review capability!!! I thought we >> were just eliminating the indirection of ThreadLocal, anyway... >> >> As a basic review I don't see anything obviously wrong, and I don't have a >> problem with adding the fields to j.l.Thread, but I'm not in a position to >> review in detail the algorithm used. >> >> Alan, did mention that he may be in a better position to do a detailed >> review. I can also sponsor this change. > > I looked at the changes and they look good to me. The additional fields of > java.lang.Thread shouldn't be an issue. > > The other thing I notice is that the serialized form of the original > ThreadLocalRandom included the padding fields, I guess they should have been > transient in the original implementation. > > -Alan. From Alan.Bateman at oracle.com Tue Jan 15 17:50:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 17:50:26 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F596E2.6080000@oracle.com> On 15/01/2013 16:33, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ > > * based on Aleksey initial webrev > * applied serialPersistentFields, writeObject, readResolve > ( as suggested by Heinz ) > * did not apply readObject. It is unnecessary, defaultReadObject > will read all the fields off the stream > > readResolve is necessary to give us "good" behavior ( as noted > previously ). > > Once integrated, I will file a new bug to track the possible change of > serialized form of TLR, and this can then remove > serialPersistentFields and writeObject, if successful. The plan and the changes looks good to me too. -Alan From chris.hegarty at oracle.com Tue Jan 15 17:59:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 15 Jan 2013 17:59:13 +0000 Subject: 8006344: Broken javadoc link in javax.lang.model.element.Element Message-ID: <50F598F1.6040106@oracle.com> Minor oversight in the changes from 7193719: "Support repeating annotations in javax.lang.model". ~/repos/jdk8/tl/adder/build/solaris-i586/impsrc/javax/lang/model/element/Element.java:199: warning - Tag @see: can't find getAnnotation() in javax.lang.model.element.Element I only noticed when building javadocs for another issue, thankfully we don't have many warnings here ;-) diff -r d54b4a091450 src/share/classes/javax/lang/model/element/Element.java --- a/src/share/classes/javax/lang/model/element/Element.java Mon Jan 14 14:17:25 2013 -0800 +++ b/src/share/classes/javax/lang/model/element/Element.java Tue Jan 15 17:55:17 2013 +0000 @@ -188,7 +188,7 @@ public interface Element { * type if present on this element, else an empty array * * @see #getAnnotationMirrors() - * @see #getAnnotation() + * @see #getAnnotation(java.lang.Class) * @see java.lang.reflect.AnnotatedElement#getAnnotations * @see EnumConstantNotPresentException * @see AnnotationTypeMismatchException -Chris. From Lance.Andersen at oracle.com Tue Jan 15 18:04:29 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 15 Jan 2013 13:04:29 -0500 Subject: 8006344: Broken javadoc link in javax.lang.model.element.Element In-Reply-To: <50F598F1.6040106@oracle.com> References: <50F598F1.6040106@oracle.com> Message-ID: +1 On Jan 15, 2013, at 12:59 PM, Chris Hegarty wrote: > Minor oversight in the changes from 7193719: "Support repeating annotations in javax.lang.model". > > ~/repos/jdk8/tl/adder/build/solaris-i586/impsrc/javax/lang/model/element/Element.java:199: warning - Tag @see: can't find getAnnotation() in javax.lang.model.element.Element > > I only noticed when building javadocs for another issue, thankfully we don't have many warnings here ;-) > > > diff -r d54b4a091450 src/share/classes/javax/lang/model/element/Element.java > --- a/src/share/classes/javax/lang/model/element/Element.java Mon Jan 14 14:17:25 2013 -0800 > +++ b/src/share/classes/javax/lang/model/element/Element.java Tue Jan 15 17:55:17 2013 +0000 > @@ -188,7 +188,7 @@ public interface Element { > * type if present on this element, else an empty array > * > * @see #getAnnotationMirrors() > - * @see #getAnnotation() > + * @see #getAnnotation(java.lang.Class) > * @see java.lang.reflect.AnnotatedElement#getAnnotations > * @see EnumConstantNotPresentException > * @see AnnotationTypeMismatchException > > -Chris. -------------- 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 rob.mckenna at oracle.com Tue Jan 15 19:55:10 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 15 Jan 2013 19:55:10 +0000 Subject: hg: jdk8/tl/jdk: 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Message-ID: <20130115195533.BCBF9472A8@hg.openjdk.java.net> Changeset: 44d6cabc9a3f Author: robm Date: 2013-01-15 19:58 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44d6cabc9a3f 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java From Alan.Bateman at oracle.com Tue Jan 15 19:58:57 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Jan 2013 19:58:57 +0000 Subject: 8006344: Broken javadoc link in javax.lang.model.element.Element In-Reply-To: <50F598F1.6040106@oracle.com> References: <50F598F1.6040106@oracle.com> Message-ID: <50F5B501.7000700@oracle.com> On 15/01/2013 17:59, Chris Hegarty wrote: > Minor oversight in the changes from 7193719: "Support repeating > annotations in javax.lang.model". > > ~/repos/jdk8/tl/adder/build/solaris-i586/impsrc/javax/lang/model/element/Element.java:199: > warning - Tag @see: can't find getAnnotation() in > javax.lang.model.element.Element > > I only noticed when building javadocs for another issue, thankfully we > don't have many warnings here ;-) > > > diff -r d54b4a091450 > src/share/classes/javax/lang/model/element/Element.java > --- a/src/share/classes/javax/lang/model/element/Element.java Mon > Jan 14 14:17:25 2013 -0800 > +++ b/src/share/classes/javax/lang/model/element/Element.java Tue > Jan 15 17:55:17 2013 +0000 > @@ -188,7 +188,7 @@ public interface Element { > * type if present on this element, else an empty array > * > * @see #getAnnotationMirrors() > - * @see #getAnnotation() > + * @see #getAnnotation(java.lang.Class) > * @see java.lang.reflect.AnnotatedElement#getAnnotations > * @see EnumConstantNotPresentException > * @see AnnotationTypeMismatchException > > -Chris. Looks good to me too. -Alan From joel.franck at oracle.com Tue Jan 15 20:05:09 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 15 Jan 2013 21:05:09 +0100 Subject: 8006344: Broken javadoc link in javax.lang.model.element.Element In-Reply-To: <50F598F1.6040106@oracle.com> References: <50F598F1.6040106@oracle.com> Message-ID: Thanks for catching this, Looks good. cheers /Joel On 15 jan 2013, at 18:59, Chris Hegarty wrote: > Minor oversight in the changes from 7193719: "Support repeating annotations in javax.lang.model". > > ~/repos/jdk8/tl/adder/build/solaris-i586/impsrc/javax/lang/model/element/Element.java:199: warning - Tag @see: can't find getAnnotation() in javax.lang.model.element.Element > > I only noticed when building javadocs for another issue, thankfully we don't have many warnings here ;-) > > > diff -r d54b4a091450 src/share/classes/javax/lang/model/element/Element.java > --- a/src/share/classes/javax/lang/model/element/Element.java Mon Jan 14 14:17:25 2013 -0800 > +++ b/src/share/classes/javax/lang/model/element/Element.java Tue Jan 15 17:55:17 2013 +0000 > @@ -188,7 +188,7 @@ public interface Element { > * type if present on this element, else an empty array > * > * @see #getAnnotationMirrors() > - * @see #getAnnotation() > + * @see #getAnnotation(java.lang.Class) > * @see java.lang.reflect.AnnotatedElement#getAnnotations > * @see EnumConstantNotPresentException > * @see AnnotationTypeMismatchException > > -Chris. From heinz at javaspecialists.eu Tue Jan 15 20:29:45 2013 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 15 Jan 2013 22:29:45 +0200 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F5BC39.1010004@javaspecialists.eu> Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ > > * based on Aleksey initial webrev > * applied serialPersistentFields, writeObject, readResolve > ( as suggested by Heinz ) > * did not apply readObject. It is unnecessary, defaultReadObject > will read all the fields off the stream > > readResolve is necessary to give us "good" behavior ( as noted > previously ). > > Once integrated, I will file a new bug to track the possible change of > serialized form of TLR, and this can then remove > serialPersistentFields and writeObject, if successful. > > -Chris. Looks good to me too. From tom.hawtin at oracle.com Tue Jan 15 20:41:22 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Tue, 15 Jan 2013 20:41:22 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F5BEF2.9030906@oracle.com> On 15/01/2013 16:33, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ Any chance of using SharedSecrets instead of UNSAFE? You know, with Unsafe being like unsafe and everything. Tom From chris.hegarty at oracle.com Tue Jan 15 20:39:40 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Jan 2013 20:39:40 +0000 Subject: hg: jdk8/tl/langtools: 8006344: Broken javadoc link in javax.lang.model.element.Element Message-ID: <20130115203945.DD1AC472AC@hg.openjdk.java.net> Changeset: f805b5e3c9d1 Author: chegar Date: 2013-01-15 20:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f805b5e3c9d1 8006344: Broken javadoc link in javax.lang.model.element.Element Reviewed-by: lancea, alanb, jfranck ! src/share/classes/javax/lang/model/element/Element.java From Ulf.Zibis at CoSoCo.de Tue Jan 15 20:45:59 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 15 Jan 2013 21:45:59 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> Message-ID: <50F5C007.2070402@CoSoCo.de> Looks great! Little nit: SQLOutputImpl.java line 579 could be dropped. -Ulf Am 15.01.2013 17:48, schrieb Lance Andersen - Oracle: > Here is a revision > > http://cr.openjdk.java.net/~lancea/8006139/webrev.01 > > I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut & paste when the code was written) and ccc request > > As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. > > > Best > lance > On Jan 14, 2013, at 5:11 AM, Alan Bateman wrote: > >> On 13/01/2013 23:51, Lance Andersen - Oracle wrote: >>> : >>> >>>>> One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. >>> I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. >> I understand, but if you add a catch-all in the class description to cover the CCE case then this could be part of the same paragraph. >> >> -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 Lance.Andersen at oracle.com Tue Jan 15 20:57:46 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 15 Jan 2013 15:57:46 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50F5C007.2070402@CoSoCo.de> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> <50F5C007.2070402@CoSoCo.de> Message-ID: <1887E1F4-8A47-4AC9-A440-77903557FC28@oracle.com> Thank you Ulf. I deleted the extra line on 579 Best Lance On Jan 15, 2013, at 3:45 PM, Ulf Zibis wrote: > Looks great! > > Little nit: > SQLOutputImpl.java line 579 could be dropped. > > -Ulf > > > Am 15.01.2013 17:48, schrieb Lance Andersen - Oracle: >> Here is a revision >> >> http://cr.openjdk.java.net/~lancea/8006139/webrev.01 >> >> I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut & paste when the code was written) and ccc request >> >> As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. >> >> >> Best >> lance >> On Jan 14, 2013, at 5:11 AM, Alan Bateman wrote: >> >>> On 13/01/2013 23:51, Lance Andersen - Oracle wrote: >>>> : >>>> >>>>>> One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the it is not a thread-safe implementation of SQLInput. >>>> I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. >>> I understand, but if you add a catch-all in the class description to cover the CCE case then this could be part of the same paragraph. >>> >>> -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 >> > -------------- 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 jonathan.gibbons at oracle.com Tue Jan 15 21:03:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Jan 2013 21:03:40 +0000 Subject: hg: jdk8/tl/langtools: 8006224: Doclint NPE for attribute with no value Message-ID: <20130115210343.8C6AC472AE@hg.openjdk.java.net> Changeset: bc1023e0e533 Author: jjg Date: 2013-01-15 13:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc1023e0e533 8006224: Doclint NPE for attribute with no value Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/AnchorTest.java + test/tools/doclint/AnchorTest.out From martinrb at google.com Tue Jan 15 21:46:49 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Jan 2013 13:46:49 -0800 Subject: zip64 compatibility problems Message-ID: Hi zip64 team! It's always a problem creating zip files using new zip spec features, since older zip implementations will fail to read those files. I see the jdk8 fix to allow the launcher to read zip64 files changeset: 5812:f1838d040cc7 user: ksrini date: 2012-09-05 11:38 -0700 7194005: (launcher) needs to be enhanced for 64-bit jar file handling Reviewed-by: darcy, sherman but that has not been backported to jdk7, which seems like a serious problem to me. More generally, most zip implementations, including in the jdk, worked just fine with >64k entries, since the entry count field was generally just treated as a hint. The change to use zip64 when there are >64k entries makes zip files *less* portable in practice for the next few years. It would have been better to default to writing non-zip64 zip files in such cases. Note that zip 3.0 does write zip64 files for >64k entries, but also provides a flag -fz- to change the default. I'd like to see a backport of 7194005 and am also aware of some other issues with our ugly friend parse_manifest.c. You changed calls to open to do this: if ((fd = open(jarfile, O_RDONLY #ifdef O_LARGEFILE | O_LARGEFILE /* large file mode on solaris */ #endif #ifdef O_BINARY | O_BINARY /* use binary mode on windows */ #endif )) == -1) But this is not done consistently - there are 2 other calls to open in the same file that didn't get the LARGEFILE treatment. Why isn't there a JLI_Open? Comments? From xueming.shen at oracle.com Wed Jan 16 00:13:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Jan 2013 16:13:01 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API Message-ID: <50F5F08D.5000008@oracle.com> Hi, The Threeten project [1] is planned to be integrated into OpenJDK8 M6 milestone. Here is the webrev http://cr.openjdk.java.net/~sherman/8003680/webrev and the latest javadoc http://cr.openjdk.java.net/~sherman/8003680/javadoc Review comments can be sent to the threeten-dev email list [2] and/or core-libs-dev email list[3]. Thanks, Sherman [1] http://openjdk.java.net/projects/threeten [2] threeten-dev @ openjdk.java.net [3] core-libs-dev @ openjdk.java.net From kumar.x.srinivasan at oracle.com Wed Jan 16 00:56:54 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 15 Jan 2013 16:56:54 -0800 Subject: Review Request : Java exe doesn't process args ending Back slash In-Reply-To: <50E6E44E.7090105@linux.vnet.ibm.com> References: <50D1F3D7.20608@linux.vnet.ibm.com> <50D1FA7E.8040609@linux.vnet.ibm.com> <50D20960.8080300@oracle.com> <50E6E44E.7090105@linux.vnet.ibm.com> Message-ID: <50F5FAD6.2090306@oracle.com> Hello Jayashree, I see the issue, I have been busy with other things, I will revisit your patch in the coming week. Kumar > On 20-12-2012 12:07 AM, Kumar Srinivasan wrote: >> Hello Jayashree, >> >> a. you are referencing a bug which has already been fixed, is there a >> new one for this ? >> >> b. with regards to the fix, I don't quite understand the issue, could >> you please >> provide a use case ? >> >> c. your regression test does not seem to be accurate it behaves the >> same with or >> without your fix, also you will need to provide a C++ test case >> in cmdtoargs.c >> as well see the bottom of that file. >> >> >> Thanks >> Kumar >> >> >> >>> >>> >>> Hi All, >>> >>> Java.exe doesn't seems to process arguments ending with back slashes >>> well , in windows only . >>> >>> I have added test scenario and changeset in the below webrev . >>> >>> http://cr.openjdk.java.net/~jviswana/7188114/webrev.01/ >>> >>> This seems to be introduced after the bug fix for 7188114 has be made >>> into jdk8 . >>> >>> Thanks and Regards, >>> Jayashree Viswanathan >>> >>> >>> >>> >> > Hi Kumar , > > a. I am referencing an old bug because , that bug fix has caused this > regression . > > b. The use case is when there are backslashes at the end args for a > java command using say -Dtest.argEndingInBackslash=a\\\\ > > JavaVM args: > version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 5 > option[ 0] = '-Dsun.java.launcher.diag=true' > option[ 1] = '-Djava.class.path=.' > option[ 2] = '-Dtest.argEndingInBackslash=a' > option[ 3] = '-Dsun.java.command=TestCmdLineParsing' > option[ 4] = '-Dsun.java.launcher=SUN_STANDARD' > 74439 micro seconds to InitializeJVM > Main class is 'TestCmdLineParsing' > App's argc is 0 > 9182 micro seconds to load main class > ----_JAVA_LAUNCHER_DEBUG---- > value of test.argEndingInBackslash = a > > > c. Sorry , I seem to have missed something , the above test case > should help you exhibit the problem . > Can you please let me know where to find or add such C++ test cases , > as In the test cases bucket I know off is jtreg or JCKs only at the > moment . > > Thanks and Regards, > Jayashree Viswanathan > > From xueming.shen at oracle.com Wed Jan 16 01:23:25 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Jan 2013 17:23:25 -0800 Subject: zip64 compatibility problems In-Reply-To: References: Message-ID: <50F6010D.5000806@oracle.com> Hi Martin, I would assume you are not asking for a similar flag for jar to disable the zip64 support (or even something at API level) to generate "old" style jar/zip file for > 64k entries, but the backport of this changeset to 7u, right? -Sherman On 1/15/13 1:46 PM, Martin Buchholz wrote: > Hi zip64 team! > > It's always a problem creating zip files using new zip spec features, > since older zip implementations will fail to read those files. > > I see the jdk8 fix to allow the launcher to read zip64 files > > changeset: 5812:f1838d040cc7 > user: ksrini > date: 2012-09-05 11:38 -0700 > 7194005: (launcher) needs to be enhanced for 64-bit jar file handling > Reviewed-by: darcy, sherman > > but that has not been backported to jdk7, which seems like a serious > problem to me. > > More generally, most zip implementations, including in the jdk, worked > just fine with >64k entries, since the entry count field was generally > just treated as a hint. The change to use zip64 when there are >64k > entries makes zip files *less* portable in practice for the next few > years. It would have been better to default to writing non-zip64 zip > files in such cases. > > Note that zip 3.0 does write zip64 files for >64k entries, but also > provides a flag -fz- to change the default. > > I'd like to see a backport of 7194005 and am also aware of some other > issues with our ugly friend parse_manifest.c. > > You changed calls to open to do this: > > if ((fd = open(jarfile, O_RDONLY > #ifdef O_LARGEFILE > | O_LARGEFILE /* large file mode on solaris */ > #endif > #ifdef O_BINARY > | O_BINARY /* use binary mode on windows */ > #endif > )) == -1) > > But this is not done consistently - there are 2 other calls to open in > the same file that didn't get the LARGEFILE treatment. Why isn't > there a JLI_Open? > > Comments? From martinrb at google.com Wed Jan 16 01:33:31 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Jan 2013 17:33:31 -0800 Subject: zip64 compatibility problems In-Reply-To: <50F6010D.5000806@oracle.com> References: <50F6010D.5000806@oracle.com> Message-ID: On Tue, Jan 15, 2013 at 5:23 PM, Xueming Shen wrote: > Hi Martin, > > I would assume you are not asking for a similar flag for jar to disable the > zip64 support (or even something at API level) to generate "old" style > jar/zip > file for > 64k entries, but the backport of this changeset to 7u, right? Actually, I think y'all should do 3 things: - backport Kumar's bug fix to jdk7 - introduce a system property to turn off the zip64 support. I am working on a patch to introduce such a system property. We will probably default to disabling zip64 by default, but you will probably find that unacceptable. But you can default the other way. - fix up some remaining largefile issues in parse_manifest I might contribute a bit of code here as well. From kumar.x.srinivasan at oracle.com Wed Jan 16 01:41:06 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 15 Jan 2013 17:41:06 -0800 Subject: zip64 compatibility problems In-Reply-To: References: Message-ID: <50F60532.80306@oracle.com> On 1/15/2013 1:46 PM, Martin Buchholz wrote: > Hi zip64 team! > > It's always a problem creating zip files using new zip spec features, > since older zip implementations will fail to read those files. > > I see the jdk8 fix to allow the launcher to read zip64 files > > changeset: 5812:f1838d040cc7 > user: ksrini > date: 2012-09-05 11:38 -0700 > 7194005: (launcher) needs to be enhanced for 64-bit jar file handling > Reviewed-by: darcy, sherman > > but that has not been backported to jdk7, which seems like a serious > problem to me. > > More generally, most zip implementations, including in the jdk, worked > just fine with >64k entries, since the entry count field was generally > just treated as a hint. The change to use zip64 when there are >64k > entries makes zip files *less* portable in practice for the next few > years. It would have been better to default to writing non-zip64 zip > files in such cases. > > Note that zip 3.0 does write zip64 files for >64k entries, but also > provides a flag -fz- to change the default. > > I'd like to see a backport of 7194005 and am also aware of some other > issues with our ugly friend parse_manifest.c. Joe and I contemplated about this, in the end we decided not to, in order to allow for some soak time in jdk8. > > You changed calls to open to do this: > > if ((fd = open(jarfile, O_RDONLY > #ifdef O_LARGEFILE > | O_LARGEFILE /* large file mode on solaris */ > #endif > #ifdef O_BINARY > | O_BINARY /* use binary mode on windows */ > #endif > )) == -1) > > But this is not done consistently - there are 2 other calls to open in > the same file that didn't get the LARGEFILE treatment. Why isn't > there a JLI_Open? Maybe if you had reviewed my code changes, you would've caught this. :) I will look into it, maybe time for a JLI_Open as you suggested. Kumar > > Comments? From martinrb at google.com Wed Jan 16 02:12:44 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Jan 2013 18:12:44 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> Message-ID: You want code? I got code. @@ -75,6 +75,18 @@ } /** + * Whether to use ZIP64 for zip files with more than 64k entries. + * When ZIP64 support in zip implementations is ubiquitous, this + * should default to true, but before then, defaulting to false is + * more portable, since most zip implementations tolerate + * incorrect total entry count fields. + */ + private static final boolean useZip64For64kEntries = + java.security.AccessController.doPrivileged( + new sun.security.action.GetBooleanAction( + "java.util.zip.useZip64For64kEntries")).booleanValue(); + + /** * Checks to make sure that this stream has not been closed. */ private void ensureOpen() throws IOException { @@ -534,8 +546,10 @@ } int count = xentries.size(); if (count >= ZIP64_MAGICCOUNT) { - count = ZIP64_MAGICCOUNT; - hasZip64 = true; + hasZip64 |= useZip64For64kEntries; + if (hasZip64) { + count = ZIP64_MAGICCOUNT; + } } if (hasZip64) { long off64 = written; On Tue, Jan 15, 2013 at 5:33 PM, Martin Buchholz wrote: > On Tue, Jan 15, 2013 at 5:23 PM, Xueming Shen wrote: >> Hi Martin, >> >> I would assume you are not asking for a similar flag for jar to disable the >> zip64 support (or even something at API level) to generate "old" style >> jar/zip >> file for > 64k entries, but the backport of this changeset to 7u, right? > > Actually, I think y'all should do 3 things: > - backport Kumar's bug fix to jdk7 > - introduce a system property to turn off the zip64 support. > I am working on a patch to introduce such a system property. > We will probably default to disabling zip64 by default, but you will > probably find that unacceptable. But you can default the other way. > - fix up some remaining largefile issues in parse_manifest > I might contribute a bit of code here as well. From xueming.shen at oracle.com Wed Jan 16 02:21:49 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Jan 2013 18:21:49 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> Message-ID: <50F60EBD.4060408@oracle.com> zip3.0 has a flag to do the similar thing may be a compelling reason to add such a system property, but make disabled default turns yourself into the dark side:-) have to explicitly turn the flag on will force the people to think if this is something they really want to do. Given it has been in the major releases for years, I don't think it's possible to disable it in openjdk. -Sherman On 1/15/13 5:33 PM, Martin Buchholz wrote: > On Tue, Jan 15, 2013 at 5:23 PM, Xueming Shen wrote: >> Hi Martin, >> >> I would assume you are not asking for a similar flag for jar to disable the >> zip64 support (or even something at API level) to generate "old" style >> jar/zip >> file for > 64k entries, but the backport of this changeset to 7u, right? > Actually, I think y'all should do 3 things: > - backport Kumar's bug fix to jdk7 > - introduce a system property to turn off the zip64 support. > I am working on a patch to introduce such a system property. > We will probably default to disabling zip64 by default, but you will > probably find that unacceptable. But you can default the other way. > - fix up some remaining largefile issues in parse_manifest > I might contribute a bit of code here as well. From xueming.shen at oracle.com Wed Jan 16 02:24:50 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Jan 2013 18:24:50 -0800 Subject: zip64 compatibility problems In-Reply-To: <50F60EBD.4060408@oracle.com> References: <50F6010D.5000806@oracle.com> <50F60EBD.4060408@oracle.com> Message-ID: <50F60F72.5070608@oracle.com> On 1/15/13 6:21 PM, Xueming Shen wrote: > > zip3.0 has a flag to do the similar thing may be a compelling reason to > add such a system property, but make disabled default turns yourself > into the dark side:-) have to explicitly turn the flag on will force the > people to think if this is something they really want to do. > > Given it has been in the major releases for years, I don't think it's > possible to disable it in openjdk. > I meant it's impossible to disable it by default..." From martinrb at google.com Wed Jan 16 03:40:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Jan 2013 19:40:30 -0800 Subject: zip64 compatibility problems In-Reply-To: <50F60F72.5070608@oracle.com> References: <50F6010D.5000806@oracle.com> <50F60EBD.4060408@oracle.com> <50F60F72.5070608@oracle.com> Message-ID: On Tue, Jan 15, 2013 at 6:24 PM, Xueming Shen wrote: > On 1/15/13 6:21 PM, Xueming Shen wrote: >> >> >> zip3.0 has a flag to do the similar thing may be a compelling reason to >> add such a system property, but make disabled default turns yourself >> into the dark side:-) have to explicitly turn the flag on will force the >> people to think if this is something they really want to do. >> >> Given it has been in the major releases for years, I don't think it's >> possible to disable it in openjdk. >> > I meant it's impossible to disable it by default..." I agree with you that it's the right decision for OpenJDK proper. You are consistent with zip 3.0 and also are obeying the zip spec 4.4.1.4 If one of the fields in the end of central directory record is too small to hold required data, the field should be set to -1 (0xFFFF or 0xFFFFFFFF) and the ZIP64 format record should be created. It's a different story for the groups of users just now adopting jdk7. The situation is a bit grim for those using jar files with >64k entries. jdk7 is not only creating jar files that are unreadable by jdk6 - they are also unreadable by the jdk7 launcher! With no visible benefit for the user! So temporarily turning off zip64 seems a better choice for us. From jviswana at linux.vnet.ibm.com Wed Jan 16 06:11:35 2013 From: jviswana at linux.vnet.ibm.com (jayashree viswanathan) Date: Wed, 16 Jan 2013 11:41:35 +0530 Subject: Review Request : Java exe doesn't process args ending Back slash In-Reply-To: <50F5FAD6.2090306@oracle.com> References: <50D1F3D7.20608@linux.vnet.ibm.com> <50D1FA7E.8040609@linux.vnet.ibm.com> <50D20960.8080300@oracle.com> <50E6E44E.7090105@linux.vnet.ibm.com> <50F5FAD6.2090306@oracle.com> Message-ID: <50F64497.3050303@linux.vnet.ibm.com> On 16-01-2013 6:26 AM, Kumar Srinivasan wrote: > Hello Jayashree, > > I see the issue, I have been busy with other things, I will revisit your > patch in the coming week. > > Kumar > >> On 20-12-2012 12:07 AM, Kumar Srinivasan wrote: >>> Hello Jayashree, >>> >>> a. you are referencing a bug which has already been fixed, is there a >>> new one for this ? >>> >>> b. with regards to the fix, I don't quite understand the issue, >>> could you please >>> provide a use case ? >>> >>> c. your regression test does not seem to be accurate it behaves the >>> same with or >>> without your fix, also you will need to provide a C++ test case >>> in cmdtoargs.c >>> as well see the bottom of that file. >>> >>> >>> Thanks >>> Kumar >>> >>> >>> >>>> >>>> >>>> Hi All, >>>> >>>> Java.exe doesn't seems to process arguments ending with back slashes >>>> well , in windows only . >>>> >>>> I have added test scenario and changeset in the below webrev . >>>> >>>> http://cr.openjdk.java.net/~jviswana/7188114/webrev.01/ >>>> >>>> This seems to be introduced after the bug fix for 7188114 has be made >>>> into jdk8 . >>>> >>>> Thanks and Regards, >>>> Jayashree Viswanathan >>>> >>>> >>>> >>>> >>> >> Hi Kumar , >> >> a. I am referencing an old bug because , that bug fix has caused this >> regression . >> >> b. The use case is when there are backslashes at the end args for a >> java command using say -Dtest.argEndingInBackslash=a\\\\ >> >> JavaVM args: >> version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 5 >> option[ 0] = '-Dsun.java.launcher.diag=true' >> option[ 1] = '-Djava.class.path=.' >> option[ 2] = '-Dtest.argEndingInBackslash=a' >> option[ 3] = '-Dsun.java.command=TestCmdLineParsing' >> option[ 4] = '-Dsun.java.launcher=SUN_STANDARD' >> 74439 micro seconds to InitializeJVM >> Main class is 'TestCmdLineParsing' >> App's argc is 0 >> 9182 micro seconds to load main class >> ----_JAVA_LAUNCHER_DEBUG---- >> value of test.argEndingInBackslash = a >> >> >> c. Sorry , I seem to have missed something , the above test case >> should help you exhibit the problem . >> Can you please let me know where to find or add such C++ test cases >> , as In the test cases bucket I know off is jtreg or JCKs only at the >> moment . >> >> Thanks and Regards, >> Jayashree Viswanathan >> >> > Thanks for the response ! Regards, Jayashree Viswanathan From joe.darcy at oracle.com Wed Jan 16 06:54:17 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 15 Jan 2013 22:54:17 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50EE88A3.7050301@redhat.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> Message-ID: <50F64E99.60100@oracle.com> Hi Florian, On 1/10/2013 1:23 AM, Florian Weimer wrote: > On 01/08/2013 10:24 PM, Joe Darcy wrote: >> As discussed over on one of the Project Lambda lists [1], we're adding >> an interface type to the platform to explicitly mark interface types as >> being functional interfaces suitable for use in lambda expressions. >> Please review the addition of this new type: >> >> http://cr.openjdk.java.net/~darcy/8005298.0/ > > Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), > similar to the @Override annotation? No; we intentionally made this annotation have runtime retention to allow it to also be queried to various tools at runtime, etc. Cheers, -Joe From peter.levart at gmail.com Wed Jan 16 07:27:13 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jan 2013 08:27:13 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F65651.9060602@gmail.com> Just a minor note: In writeObject(), the code writes constant 0L for field "rnd". If we're trying to emulate the stream of JDK7 TLR then writeObject() could do better by writing the value of Thread.currentThread().threadLocalRandomSeed field... Regards, Peter On 01/15/2013 05:33 PM, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ > > * based on Aleksey initial webrev > * applied serialPersistentFields, writeObject, readResolve > ( as suggested by Heinz ) > * did not apply readObject. It is unnecessary, defaultReadObject > will read all the fields off the stream > > readResolve is necessary to give us "good" behavior ( as noted > previously ). > > Once integrated, I will file a new bug to track the possible change of > serialized form of TLR, and this can then remove > serialPersistentFields and writeObject, if successful. > > -Chris. > > > On 01/15/2013 01:57 PM, Alan Bateman wrote: >> On 15/01/2013 13:49, Chris Hegarty wrote: >>> >>> But wouldn't there be an issue with JDK7 TLR streams being >>> deserialized by JDK8, pad fields would be left in the Object input >>> steam? If so, then we're down the road of having to have a readObject, >>> etc... and possibly back to serialPersistentFields? >> Technically deleting fields is an incompatible change as the stream will >> not contain the fields. If someone is crazy enough to serialize with >> jdk8 TLR and send it to a jdk7 release then the fields will have their >> default value (as the values aren't in the stream). As the fields aren't >> used then I don't think this should make a difference. Going the other >> way shouldn't be an issue either as the pad fields will be ignored. >> >> -Alan. From peter.levart at gmail.com Wed Jan 16 08:59:16 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jan 2013 09:59:16 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F584DD.6080108@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> Message-ID: <50F66BE4.3050305@gmail.com> Hello, I did an experiment with an alternative implementation of TLR: http://dl.dropbox.com/u/101777488/TLR/webrev.01/index.html This version is a modified proposed version. It has the following differences: - Instead of Thread.threadLocalRandomSeed field it has a Thread.threadLocalRandom reference field, pointing to an instance of TLR. - The ThreadLocalRandom is not a singleton, but an instance per thread (like JDK7's). - ThreadLocalRandom has a reference to constructing Thread, so it can check the validity of calling thread. I did some micro benchmarks and here are the results: http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt Results indicate that usage pattern: Thread.current().nextInt() is as fast as proposed variant while the nextInt() method itself is as fast as JDK7's, which is some 20% faster than proposed variant. So the alternative implementation seems to be faster and it has the following additional benefits: - Checks the calling thread and throws when called from invalid thread. - Could reinstate the padding fields (or @Contended long rnd) if needed (the tests were done without padding) It does have a memory overhead of one object per using thread. Not too much I think. Regards, Peter On 01/15/2013 05:33 PM, Chris Hegarty wrote: > Updated webrev: > http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/ > > * based on Aleksey initial webrev > * applied serialPersistentFields, writeObject, readResolve > ( as suggested by Heinz ) > * did not apply readObject. It is unnecessary, defaultReadObject > will read all the fields off the stream > > readResolve is necessary to give us "good" behavior ( as noted > previously ). > > Once integrated, I will file a new bug to track the possible change of > serialized form of TLR, and this can then remove > serialPersistentFields and writeObject, if successful. > > -Chris. > > > On 01/15/2013 01:57 PM, Alan Bateman wrote: >> On 15/01/2013 13:49, Chris Hegarty wrote: >>> >>> But wouldn't there be an issue with JDK7 TLR streams being >>> deserialized by JDK8, pad fields would be left in the Object input >>> steam? If so, then we're down the road of having to have a readObject, >>> etc... and possibly back to serialPersistentFields? >> Technically deleting fields is an incompatible change as the stream will >> not contain the fields. If someone is crazy enough to serialize with >> jdk8 TLR and send it to a jdk7 release then the fields will have their >> default value (as the values aren't in the stream). As the fields aren't >> used then I don't think this should make a difference. Going the other >> way shouldn't be an issue either as the pad fields will be ignored. >> >> -Alan. From aleksey.shipilev at oracle.com Wed Jan 16 09:13:18 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 13:13:18 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F66BE4.3050305@gmail.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> Message-ID: <50F66F2E.6060109@oracle.com> Hi Peter, This is an interesting experiment. On 01/16/2013 12:59 PM, Peter Levart wrote: > I did some micro benchmarks and here are the results: > > http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt > > Results indicate that usage pattern: Thread.current().nextInt() is as > fast as proposed variant while the nextInt() method itself is as fast as > JDK7's, which is some 20% faster than proposed variant. I find this hard to believe, since the baseline experiment I did in the conceiving note in this thread actually tells otherwise: JDK8 (baseline, 4 threads) TLR.nextInt(): 6.4 +- 0.1 ns/op TLR.current().nextInt(): 16.1 +- 0.4 ns/op TL.get().nextInt(): 19.1 +- 0.6 ns/op JDK8 (patched, 4 threads) TLR.nextInt(): 6.5 +- 0.2 ns/op TLR.current().nextInt(): 6.4 +- 0.1 ns/op TL.get().nextInt(): 17.2 +- 2.0 ns/op That is, TLR.current().nextInt() is as fast as the already-acquired TLR.nextInt() even in the baselined case, which pretty much means we hit the lower bound for possible infrastructure overheads, and we actually compute. Note that the changes in next() did not degrade the performance either. Please check your microbenchmarks. > So the > alternative implementation seems to be faster and it has the following > additional benefits: > > - Checks the calling thread and throws when called from invalid thread. This is the spec change; potentially breaks the code (instead of "just" degrading performance). I would not like to see that pushed into JDK. > - Could reinstate the padding fields (or @Contended long rnd) if needed > (the tests were done without padding) Hardly a benefit, since Thread can be padded as well, and padding there will yield better footprint. -Aleksey. From peter.levart at gmail.com Wed Jan 16 09:23:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jan 2013 10:23:57 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F66F2E.6060109@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> <50F66F2E.6060109@oracle.com> Message-ID: <50F671AD.2060204@gmail.com> Hi Aleksey, The test I used is simple: https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java I ran it on a i7-2600K (4 cores x 2 threads) PC with Linux OS and a JDK8 build from lambda repo using default JVM options (that means +UseCompressedOops enabled by default). Can you give the sources of your tests so I could try to run them on my machine? Regards, Peter On 01/16/2013 10:13 AM, Aleksey Shipilev wrote: > Hi Peter, > > This is an interesting experiment. > > On 01/16/2013 12:59 PM, Peter Levart wrote: >> I did some micro benchmarks and here are the results: >> >> http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt >> >> Results indicate that usage pattern: Thread.current().nextInt() is as >> fast as proposed variant while the nextInt() method itself is as fast as >> JDK7's, which is some 20% faster than proposed variant. > I find this hard to believe, since the baseline experiment I did in the > conceiving note in this thread actually tells otherwise: > > JDK8 (baseline, 4 threads) > TLR.nextInt(): 6.4 +- 0.1 ns/op > TLR.current().nextInt(): 16.1 +- 0.4 ns/op > TL.get().nextInt(): 19.1 +- 0.6 ns/op > > JDK8 (patched, 4 threads) > TLR.nextInt(): 6.5 +- 0.2 ns/op > TLR.current().nextInt(): 6.4 +- 0.1 ns/op > TL.get().nextInt(): 17.2 +- 2.0 ns/op > > That is, TLR.current().nextInt() is as fast as the already-acquired > TLR.nextInt() even in the baselined case, which pretty much means we hit > the lower bound for possible infrastructure overheads, and we actually > compute. Note that the changes in next() did not degrade the performance > either. Please check your microbenchmarks. > >> So the >> alternative implementation seems to be faster and it has the following >> additional benefits: >> >> - Checks the calling thread and throws when called from invalid thread. > This is the spec change; potentially breaks the code (instead of "just" > degrading performance). I would not like to see that pushed into JDK. > >> - Could reinstate the padding fields (or @Contended long rnd) if needed >> (the tests were done without padding) > Hardly a benefit, since Thread can be padded as well, and padding there > will yield better footprint. > > -Aleksey. > > From fweimer at redhat.com Wed Jan 16 09:51:05 2013 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 16 Jan 2013 10:51:05 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F64E99.60100@oracle.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> Message-ID: <50F67809.6040306@redhat.com> On 01/16/2013 07:54 AM, Joe Darcy wrote: > Hi Florian, > > On 1/10/2013 1:23 AM, Florian Weimer wrote: >> On 01/08/2013 10:24 PM, Joe Darcy wrote: >>> As discussed over on one of the Project Lambda lists [1], we're adding >>> an interface type to the platform to explicitly mark interface types as >>> being functional interfaces suitable for use in lambda expressions. >>> Please review the addition of this new type: >>> >>> http://cr.openjdk.java.net/~darcy/8005298.0/ >> >> Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), >> similar to the @Override annotation? > > No; we intentionally made this annotation have runtime retention to > allow it to also be queried to various tools at runtime, etc. This is really a bit odd. Doesn't this risk that code will rely on the annotation, instead of inferring the functional interface status based on the interface contents? I could not find this part in the lambda-libs-spec-experts discussion. Have you got a more specific pointer? -- Florian Weimer / Red Hat Product Security Team From chris.hegarty at oracle.com Wed Jan 16 10:15:50 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Jan 2013 10:15:50 +0000 Subject: hg: jdk8/tl/jdk: 8005926: Merge ThreadLocalRandom state into java.lang.Thread Message-ID: <20130116101618.3DE0A472D5@hg.openjdk.java.net> Changeset: 9d8ef6174cfd Author: dl Date: 2013-01-16 10:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d8ef6174cfd 8005926: Merge ThreadLocalRandom state into java.lang.Thread Reviewed-by: shade, chegar ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java From forax at univ-mlv.fr Wed Jan 16 10:21:54 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 Jan 2013 11:21:54 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F67809.6040306@redhat.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> Message-ID: <50F67F42.2040102@univ-mlv.fr> On 01/16/2013 10:51 AM, Florian Weimer wrote: > On 01/16/2013 07:54 AM, Joe Darcy wrote: >> Hi Florian, >> >> On 1/10/2013 1:23 AM, Florian Weimer wrote: >>> On 01/08/2013 10:24 PM, Joe Darcy wrote: >>>> As discussed over on one of the Project Lambda lists [1], we're adding >>>> an interface type to the platform to explicitly mark interface >>>> types as >>>> being functional interfaces suitable for use in lambda expressions. >>>> Please review the addition of this new type: >>>> >>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>> >>> Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), >>> similar to the @Override annotation? >> >> No; we intentionally made this annotation have runtime retention to >> allow it to also be queried to various tools at runtime, etc. > > This is really a bit odd. Doesn't this risk that code will rely on > the annotation, instead of inferring the functional interface status > based on the interface contents? Yes, it's a serious issue IMO. because the annotation is verified at compile time and the linking is done at runtime in Java so the annotation can be present and valid when compiled but at runtime the interface is not a functional interface anymore because by example a super interface was recompiled without compiling the annotated interface. I agree that a good way to mitigate this is to make the annotation not present in the bytecode and only available to javac and all annotation processors. If a runtime tool want this information, it should use the reflection API that provides the VM point of view of the world, not the compiler(s) one. > > I could not find this part in the lambda-libs-spec-experts discussion. > Have you got a more specific pointer? > As far as I now, this part was not discussed. For reference, the whole thread starts here: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-December/000877.html R?mi From aleksey.shipilev at oracle.com Wed Jan 16 10:37:50 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 16 Jan 2013 14:37:50 +0400 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F671AD.2060204@gmail.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> <50F66F2E.6060109@oracle.com> <50F671AD.2060204@gmail.com> Message-ID: <50F682FE.7050704@oracle.com> On 01/16/2013 01:23 PM, Peter Levart wrote: > The test I used is simple: > https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java OK, you can't get serious with that test. The failures visible at the surface are: - dead-code elimination for parts of nextInt(): you should consume the results! - thread start/stops are not synchronized; there are significant chances threads are running solo for considerable amount of time. This should be much easier to write once our microbenchmark harness goes into OpenJDK; in the mean time, you will need to invest considerably more time into making this right. -Aleksey. From dl at cs.oswego.edu Wed Jan 16 11:48:50 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 16 Jan 2013 06:48:50 -0500 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F66BE4.3050305@gmail.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> Message-ID: <50F693A2.8030000@cs.oswego.edu> On 01/16/13 03:59, Peter Levart wrote: > - Instead of Thread.threadLocalRandomSeed field it has a > Thread.threadLocalRandom reference field, pointing to an instance of TLR. > - The ThreadLocalRandom is not a singleton, but an instance per thread (like > JDK7's). Yes, this is the "Plan B" I mentioned in mail last week. I had explored this. Both on performance and resource grounds, it is a little worse. Not hugely worse, but if we are going to improve TLR, then might as well take the best option. (Another reason to prefer current solution also serves as a reply to Tom: Yes we don't like using Unsafe just to bypass package-protection access control. But at least it is just accessing simple scalars, not references.) -Doug From Alan.Bateman at oracle.com Wed Jan 16 12:08:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2013 12:08:01 +0000 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F5F08D.5000008@oracle.com> References: <50F5F08D.5000008@oracle.com> Message-ID: <50F69821.6040300@oracle.com> On 16/01/2013 00:13, Xueming Shen wrote: > Hi, > > The Threeten project [1] is planned to be integrated into OpenJDK8 M6 > milestone. > > Here is the webrev > http://cr.openjdk.java.net/~sherman/8003680/webrev > > and the latest javadoc > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Review comments can be sent to the threeten-dev email list [2] and/or > core-libs-dev email list[3]. This is not a review of the API or implementation. Rather just a few random comments as I look through the webrev. It looks to me that the zone rules compiler ends up in rt.jar, is that expected and is it actually used at runtime? On initial read I thought it was build-time only but I might be wrong. As per off-list discussion, it needs to run on the boot JDK to work in cross-compilation environments and so the dependency on java.time is an issue. I see Formatter has been updated to support conversions of TemporalAccessor. Is the assert(width == -1) on L4067 right or was it copied from another print method? (Brian Burkhalter and I were chatting recently about an assert into another print method). Also on Formatter then I think it would be good to put the tests in test/java/util/Formatter as someone touching the Formatter code might not know there are additional tests hiding down in the odd location test/java/time/test/java/util. As you are adding a jdk_test target to test/Makefile then you will should also add the target to jprt.properties (btoh top-level repo and jdk/make). This is only interesting for Oracle build+test system of course. Just on the tests, is the plan to push the TCK tests to the jdk as proposed in the webrev? -Alan. From chris.hegarty at oracle.com Wed Jan 16 12:11:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Jan 2013 12:11:13 +0000 Subject: hg: jdk8/tl/jdk: 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Message-ID: <20130116121134.C9446472DD@hg.openjdk.java.net> Changeset: a546d8897e0d Author: dl Date: 2013-01-16 12:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a546d8897e0d 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Reviewed-by: dl, chegar, darcy, goetz Contributed-by: dl at cs.oswego.edu, chris.hegarty at oracle.com ! 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 From Alan.Bateman at oracle.com Wed Jan 16 12:20:08 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2013 12:20:08 +0000 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> <50F60EBD.4060408@oracle.com> <50F60F72.5070608@oracle.com> Message-ID: <50F69AF8.3080508@oracle.com> On 16/01/2013 03:40, Martin Buchholz wrote: > : > > It's a different story for the groups of users just now adopting jdk7. > The situation is a bit grim for those using jar files with>64k entries. > jdk7 is not only creating jar files that are unreadable by jdk6 - they > are also unreadable by the jdk7 launcher! With no visible benefit for > the user! > Just to be clear, do you mean just executable JAR files (java -jar)? I assume that library JAR files on the classpath or elsewhere with >64k are not an issue. -Alan From peter.levart at gmail.com Wed Jan 16 13:48:45 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jan 2013 14:48:45 +0100 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F693A2.8030000@cs.oswego.edu> 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> Message-ID: <50F6AFBD.1030202@gmail.com> On 01/16/2013 12:48 PM, Doug Lea wrote: > On 01/16/13 03:59, Peter Levart wrote: > >> - Instead of Thread.threadLocalRandomSeed field it has a >> Thread.threadLocalRandom reference field, pointing to an instance of >> TLR. >> - The ThreadLocalRandom is not a singleton, but an instance per >> thread (like >> JDK7's). > > Yes, this is the "Plan B" I mentioned in mail last week. > I had explored this. Both on performance and resource grounds, > it is a little worse. Not hugely worse, but if we are going > to improve TLR, then might as well take the best option. > > (Another reason to prefer current solution also serves as > a reply to Tom: Yes we don't like using Unsafe just to > bypass package-protection access control. But at least it > is just accessing simple scalars, not references.) Don't forget it is also writing them... :-( Regards, Peter > > -Doug > From Ulf.Zibis at CoSoCo.de Wed Jan 16 14:31:45 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 16 Jan 2013 15:31:45 +0100 Subject: Can't report bug In-Reply-To: <50F2CD18.5060500@oracle.com> References: <50F2A808.4070809@CoSoCo.de> <50F2CD18.5060500@oracle.com> Message-ID: <50F6B9D1.8070307@CoSoCo.de> Hi Roger, and what's about my older bug reports? Do they have a Bug ID yet? I did not receive any message. Your report has been assigned an internal review ID of 2361929, which is NOT visible on the Sun Developer Network (SDN). The new one is: Your report has been assigned an internal review ID of 2426775. -Ulf Am 13.01.2013 16:04, schrieb Roger Lewis: > Hello Ulf, > > We are looking into it. > > -Roger > > > On 1/13/13 4:26 AM, Ulf Zibis wrote: >> Hi, >> >> what's about http://bugreport.sun.com/bugreport/ ? >> I get "Server not available" >> Is this temporary, or is it disabled because of new infrastructure? >> >> Thanks, >> >> -Ulf >> > > From sean.mullan at oracle.com Wed Jan 16 14:58:18 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 16 Jan 2013 14:58:18 +0000 Subject: hg: jdk8/tl/jdk: 8005389: Backout fix for JDK-6500133 Message-ID: <20130116145924.3ACC0472E6@hg.openjdk.java.net> Changeset: c7d54f93d3e5 Author: juh Date: 2013-01-16 09:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7d54f93d3e5 8005389: Backout fix for JDK-6500133 Reviewed-by: mullan ! src/share/classes/sun/security/x509/URIName.java ! test/sun/security/x509/URIName/Parse.java From chris.hegarty at oracle.com Wed Jan 16 15:01:56 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 16 Jan 2013 15:01:56 +0000 Subject: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread In-Reply-To: <50F693A2.8030000@cs.oswego.edu> 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> Message-ID: <50F6C0E4.2090401@oracle.com> 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. -Chris. On 16/01/2013 11:48, Doug Lea wrote: > On 01/16/13 03:59, Peter Levart wrote: > >> - Instead of Thread.threadLocalRandomSeed field it has a >> Thread.threadLocalRandom reference field, pointing to an instance of TLR. >> - The ThreadLocalRandom is not a singleton, but an instance per thread >> (like >> JDK7's). > > Yes, this is the "Plan B" I mentioned in mail last week. > I had explored this. Both on performance and resource grounds, > it is a little worse. Not hugely worse, but if we are going > to improve TLR, then might as well take the best option. > > (Another reason to prefer current solution also serves as > a reply to Tom: Yes we don't like using Unsafe just to > bypass package-protection access control. But at least it > is just accessing simple scalars, not references.) > > -Doug > From kumar.x.srinivasan at oracle.com Wed Jan 16 15:35:37 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 16 Jan 2013 07:35:37 -0800 Subject: zip64 compatibility problems In-Reply-To: <50F69AF8.3080508@oracle.com> References: <50F6010D.5000806@oracle.com> <50F60EBD.4060408@oracle.com> <50F60F72.5070608@oracle.com> <50F69AF8.3080508@oracle.com> Message-ID: <50F6C8C9.9040505@oracle.com> On 1/16/2013 4:20 AM, Alan Bateman wrote: > On 16/01/2013 03:40, Martin Buchholz wrote: >> : >> >> It's a different story for the groups of users just now adopting jdk7. >> The situation is a bit grim for those using jar files with>64k entries. >> jdk7 is not only creating jar files that are unreadable by jdk6 - they >> are also unreadable by the jdk7 launcher! With no visible benefit for >> the user! >> > Just to be clear, do you mean just executable JAR files (java -jar)? I > assume that library JAR files on the classpath or elsewhere with >64k > are not an issue. Only -jar would be affected since the launcher needs to read the manifest to extract the main-class name, so the changeset which Martin refers to, fixes the parse_manifest.c. Therefore using the construct java -cp foo.jar Main .... would/should work correctly via the classloader. Kumar > > -Alan From brian.goetz at oracle.com Wed Jan 16 16:08:12 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Jan 2013 08:08:12 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F67809.6040306@redhat.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> Message-ID: There is a benefit for languages *other* than Java, that can use this as a means to determine whether the interface is suitable for passing to the SAM conversion machinery. The JDK support for lambda conversion is available to other languages as well. On Jan 16, 2013, at 1:51 AM, Florian Weimer wrote: > On 01/16/2013 07:54 AM, Joe Darcy wrote: >> Hi Florian, >> >> On 1/10/2013 1:23 AM, Florian Weimer wrote: >>> On 01/08/2013 10:24 PM, Joe Darcy wrote: >>>> As discussed over on one of the Project Lambda lists [1], we're adding >>>> an interface type to the platform to explicitly mark interface types as >>>> being functional interfaces suitable for use in lambda expressions. >>>> Please review the addition of this new type: >>>> >>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>> >>> Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), >>> similar to the @Override annotation? >> >> No; we intentionally made this annotation have runtime retention to >> allow it to also be queried to various tools at runtime, etc. > > This is really a bit odd. Doesn't this risk that code will rely on the annotation, instead of inferring the functional interface status based on the interface contents? > > I could not find this part in the lambda-libs-spec-experts discussion. Have you got a more specific pointer? > > -- > Florian Weimer / Red Hat Product Security Team From brian.goetz at oracle.com Wed Jan 16 16:09:35 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Jan 2013 08:09:35 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F67F42.2040102@univ-mlv.fr> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F67F42.2040102@univ-mlv.fr> Message-ID: <91A384DE-4929-4884-929B-F048EAC29AEC@oracle.com> The point is not to provide an ironclad guarantee that SAM conversion will never fail. It is to capture the original author's design intent and provide a small amount of compile-time tooling to help enforce that. Like @Override. On Jan 16, 2013, at 2:21 AM, Remi Forax wrote: > On 01/16/2013 10:51 AM, Florian Weimer wrote: >> On 01/16/2013 07:54 AM, Joe Darcy wrote: >>> Hi Florian, >>> >>> On 1/10/2013 1:23 AM, Florian Weimer wrote: >>>> On 01/08/2013 10:24 PM, Joe Darcy wrote: >>>>> As discussed over on one of the Project Lambda lists [1], we're adding >>>>> an interface type to the platform to explicitly mark interface types as >>>>> being functional interfaces suitable for use in lambda expressions. >>>>> Please review the addition of this new type: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>>> >>>> Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), >>>> similar to the @Override annotation? >>> >>> No; we intentionally made this annotation have runtime retention to >>> allow it to also be queried to various tools at runtime, etc. >> >> This is really a bit odd. Doesn't this risk that code will rely on the annotation, instead of inferring the functional interface status based on the interface contents? > > Yes, it's a serious issue IMO. > because the annotation is verified at compile time and the linking is done at runtime in Java so the annotation can be present and valid when compiled but at runtime the interface is not a functional interface anymore because by example a super interface was recompiled without compiling the annotated interface. > > I agree that a good way to mitigate this is to make the annotation not present in the bytecode and only available to javac and all annotation processors. > If a runtime tool want this information, it should use the reflection API that provides the VM point of view of the world, not the compiler(s) one. > >> >> I could not find this part in the lambda-libs-spec-experts discussion. Have you got a more specific pointer? >> > > As far as I now, this part was not discussed. > For reference, the whole thread starts here: > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-December/000877.html > > R?mi > From brian.goetz at oracle.com Wed Jan 16 16:27:42 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Jan 2013 08:27:42 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F6D276.2060108@redhat.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> Message-ID: <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> Yes it would. The primary purpose of this annotation is to *capture design intent*. It is not required. The compiler will help you enforce the design intent if you provide it. The compiler will not synthesize this annotation, since that would be guessing at the design intent. It is possible to create classfiles that subvert the design intent. The point about other languages was simply to point out that the universe of tools that might usefully use this design intent is bigger than sometimes assumed. On Jan 16, 2013, at 8:16 AM, Florian Weimer wrote: > On 01/16/2013 05:08 PM, Brian Goetz wrote: >> There is a benefit for languages *other* than Java, that can use this as a means to determine whether the interface is suitable for passing to the SAM conversion machinery. > > But this would miss non-annotated classes, wouldn't it? > > (If javac is supposed to synthesize this annotation on interfaces which are of SAM type, but not yet annotated as such, then this should be mentioned in the documentation.) > > -- > Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Wed Jan 16 16:32:42 2013 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 16 Jan 2013 17:32:42 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> Message-ID: <50F6D62A.3080401@redhat.com> On 01/16/2013 05:27 PM, Brian Goetz wrote: > The primary purpose of this annotation is to *capture design intent*. It is not required. The compiler will help you enforce the design intent if you provide it. The compiler will not synthesize this annotation, since that would be guessing at the design intent. It is possible to create classfiles that subvert the design intent. > > The point about other languages was simply to point out that the universe of tools that might usefully use this design intent is bigger than sometimes assumed. I don't think run-time behavior should depend on optional annotations documenting design intent (like @Override). Supporting the discovery of functional interfaces is a good idea. But a method like Class#isFunctionalInterface() would sever this purpose better than an entirely optional annotation. -- Florian Weimer / Red Hat Product Security Team From brian.goetz at oracle.com Wed Jan 16 16:35:48 2013 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Jan 2013 08:35:48 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F6D62A.3080401@redhat.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> <50F6D62A.3080401@redhat.com> Message-ID: <5C3DEE96-826A-43E7-A899-6DF3360038E3@oracle.com> Runtime behavior of Java will NOT depend on optional annotations. Where did you get that idea? The reflection aspect is separate and also desirable. On Jan 16, 2013, at 8:32 AM, Florian Weimer wrote: > On 01/16/2013 05:27 PM, Brian Goetz wrote: > >> The primary purpose of this annotation is to *capture design intent*. It is not required. The compiler will help you enforce the design intent if you provide it. The compiler will not synthesize this annotation, since that would be guessing at the design intent. It is possible to create classfiles that subvert the design intent. >> >> The point about other languages was simply to point out that the universe of tools that might usefully use this design intent is bigger than sometimes assumed. > > I don't think run-time behavior should depend on optional annotations documenting design intent (like @Override). > > Supporting the discovery of functional interfaces is a good idea. But a method like Class#isFunctionalInterface() would sever this purpose better than an entirely optional annotation. > > -- > Florian Weimer / Red Hat Product Security Team From joe.darcy at oracle.com Wed Jan 16 16:58:09 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Jan 2013 08:58:09 -0800 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F6D62A.3080401@redhat.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> <50F6D62A.3080401@redhat.com> Message-ID: <50F6DC21.1090202@oracle.com> On 1/16/2013 8:32 AM, Florian Weimer wrote: > On 01/16/2013 05:27 PM, Brian Goetz wrote: > >> The primary purpose of this annotation is to *capture design >> intent*. It is not required. The compiler will help you enforce the >> design intent if you provide it. The compiler will not synthesize >> this annotation, since that would be guessing at the design intent. >> It is possible to create classfiles that subvert the design intent. >> >> The point about other languages was simply to point out that the >> universe of tools that might usefully use this design intent is >> bigger than sometimes assumed. > > I don't think run-time behavior should depend on optional annotations > documenting design intent (like @Override). > > Supporting the discovery of functional interfaces is a good idea. But > a method like Class#isFunctionalInterface() would sever this purpose > better than an entirely optional annotation. > A method like Class#isFunctionalInterface is planned too for later in JDK 8. -Joe From maurizio.cimadamore at oracle.com Wed Jan 16 17:02:04 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 16 Jan 2013 17:02:04 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130116170224.B6AB5472ED@hg.openjdk.java.net> Changeset: f785dcac17b7 Author: mcimadamore Date: 2013-01-16 16:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f785dcac17b7 8005854: Add support for array constructor references Summary: Support constructor references of the kind int[]::new Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/lambda/MethodReference59.java + test/tools/javac/lambda/MethodReference60.java + test/tools/javac/lambda/MethodReference60.out Changeset: 7aa2025bbb7b Author: mcimadamore Date: 2013-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7aa2025bbb7b 8005299: Add FunctionalInterface checking to javac Summary: Javac should check that types annotated with @FunctionalInterface are indeed functional interfaces Reviewed-by: jjg ! 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/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadFunctionalIntfAnno.java ! test/tools/javac/lambda/BadConv03.out ! test/tools/javac/lambda/BadLambdaPos.out ! test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/FunctionalInterfaceAnno.java + test/tools/javac/lambda/FunctionalInterfaceAnno.out ! test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaConv09.out ! test/tools/javac/lambda/LambdaExpr10.out ! test/tools/javac/lambda/MethodReference04.out ! test/tools/javac/lambda/TargetType17.out ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM3.out ! test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out ! test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out From fweimer at redhat.com Wed Jan 16 16:16:54 2013 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 16 Jan 2013 17:16:54 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> Message-ID: <50F6D276.2060108@redhat.com> On 01/16/2013 05:08 PM, Brian Goetz wrote: > There is a benefit for languages *other* than Java, that can use this as a means to determine whether the interface is suitable for passing to the SAM conversion machinery. But this would miss non-annotated classes, wouldn't it? (If javac is supposed to synthesize this annotation on interfaces which are of SAM type, but not yet annotated as such, then this should be mentioned in the documentation.) -- Florian Weimer / Red Hat Product Security Team From maurizio.cimadamore at oracle.com Wed Jan 16 17:41:11 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 16 Jan 2013 17:41:11 +0000 Subject: hg: jdk8/tl/langtools: 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Message-ID: <20130116174116.E1FA4472FA@hg.openjdk.java.net> Changeset: 1afdf1f1472b Author: mcimadamore Date: 2013-01-16 17:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1afdf1f1472b 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Summary: Wrong implementation of ResolveError.access in AmbiguityError Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/comp/Resolve.java From jonathan.gibbons at oracle.com Wed Jan 16 18:30:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Jan 2013 18:30:26 +0000 Subject: hg: jdk8/tl/langtools: 8006236: doclint: structural issue hidden Message-ID: <20130116183032.359CA472FD@hg.openjdk.java.net> Changeset: 6b6311a8c9cc Author: jjg Date: 2013-01-16 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b6311a8c9cc 8006236: doclint: structural issue hidden Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/EndTagsTest.java + test/tools/doclint/EndTagsTest.out From bharadwaj.yadavalli at oracle.com Wed Jan 16 18:35:47 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 16 Jan 2013 13:35:47 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call Message-ID: <50F6F303.3000504@oracle.com> Please review the change at http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ Default interface methods are new in Java 8. VM creates overpass methods in the vtable slots of classes to invoke a default method using invokespecial. Consequently, invocation of default interface methods (i.e., overpass methods in the VM) via invokespecial is legal and should not be flagged as illegal. In short, this change allows invocation of default methods of Java 8 using invokespecial. I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new failures. Thanks, Bharadwaj From sean.mullan at oracle.com Wed Jan 16 18:37:08 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 16 Jan 2013 18:37:08 +0000 Subject: hg: jdk8/tl/jdk: 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Message-ID: <20130116183729.875AE472FE@hg.openjdk.java.net> Changeset: f7f77bdf248b Author: juh Date: 2013-01-16 13:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7f77bdf248b 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Reviewed-by: mullan, weijun ! test/sun/security/x509/X509CRLImpl/Verify.java ! test/sun/security/x509/X509CertImpl/Verify.java From xueming.shen at oracle.com Wed Jan 16 18:46:13 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 16 Jan 2013 10:46:13 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F69821.6040300@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F69821.6040300@oracle.com> Message-ID: <50F6F575.6060303@oracle.com> On 01/16/2013 04:08 AM, Alan Bateman wrote: > On 16/01/2013 00:13, Xueming Shen wrote: >> Hi, >> >> The Threeten project [1] is planned to be integrated into OpenJDK8 M6 milestone. >> >> Here is the webrev >> http://cr.openjdk.java.net/~sherman/8003680/webrev >> >> and the latest javadoc >> http://cr.openjdk.java.net/~sherman/8003680/javadoc >> >> Review comments can be sent to the threeten-dev email list [2] and/or >> core-libs-dev email list[3]. > This is not a review of the API or implementation. Rather just a few random comments as I look through the webrev. > > It looks to me that the zone rules compiler ends up in rt.jar, is that expected and is it actually used at runtime? On initial read I thought it was build-time only but I might be wrong. As per off-list discussion, it needs to run on the boot JDK to work in cross-compilation environments and so the dependency on java.time is an issue. Yes, looking into rewriting or moving some pieces around to satisfy the cross-compilation env. No, those should not be in rt.jar, at least for now. > > I see Formatter has been updated to support conversions of TemporalAccessor. Is the assert(width == -1) on L4067 right or was it copied from another print method? (Brian Burkhalter and I were chatting recently about an assert into another print method). It's copy/pasted from print(StringBuffer, Calendar...) > Also on Formatter then I think it would be good to put the tests in test/java/util/Formatter as someone touching the Formatter code might not know there are additional tests hiding down in the odd location test/java/time/test/java/util. > Yes, understood. The concern is that, at least for now, it is more likely we are going to change the java/time and we forget there is another test case at java/util/Formatter:-) Maybe it is more convenient to keep it here for a little while until the threeten is stable enough. The "location" is odd, mainly to satisfy the TestNG requirement (for tests with their own package). The test is written to use TestNG. > As you are adding a jdk_test target to test/Makefile then you will should also add the target to jprt.properties (btoh top-level repo and jdk/make). This is only interesting for Oracle build+test system of course. Sure, will added. > > Just on the tests, is the plan to push the TCK tests to the jdk as proposed in the webrev? Those tck tests also serve as unit tests. They are so named for the convenience that TCK guys can just pick them up and drop into their suite easily. -Sherman From kurchi.subhra.hazra at oracle.com Wed Jan 16 19:50:27 2013 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 16 Jan 2013 11:50:27 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F5F08D.5000008@oracle.com> References: <50F5F08D.5000008@oracle.com> Message-ID: <50F70483.9090202@oracle.com> Hi Sherman, As I was telling you, I had a very minor comment - the javadoc for the enums DayOfWeek and Month shows the days/months in alphabetical order. I am not sure if it is somehow possible to bypass that and show them in the order of their occurrence instead. Thanks, - Kurchi On 15.01.2013 16:13, Xueming Shen wrote: > Hi, > > The Threeten project [1] is planned to be integrated into OpenJDK8 M6 > milestone. > > Here is the webrev > http://cr.openjdk.java.net/~sherman/8003680/webrev > > and the latest javadoc > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Review comments can be sent to the threeten-dev email list [2] and/or > core-libs-dev email list[3]. > > Thanks, > Sherman > > [1] http://openjdk.java.net/projects/threeten > [2] threeten-dev @ openjdk.java.net > [3] core-libs-dev @ openjdk.java.net > > -- -Kurchi From martinrb at google.com Wed Jan 16 20:24:14 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Jan 2013 12:24:14 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> Message-ID: On Tue, Jan 15, 2013 at 5:33 PM, Martin Buchholz wrote: > Actually, I think y'all should do 3 things: > - backport Kumar's bug fix to jdk7 > - introduce a system property to turn off the zip64 support. > I am working on a patch to introduce such a system property. > We will probably default to disabling zip64 by default, but you will > probably find that unacceptable. But you can default the other way. > - fix up some remaining largefile issues in parse_manifest > I might contribute a bit of code here as well. As I said, I'm willing to do more work on this mini-project myself, but we need rough consensus on the direction we should go. From lana.steuck at oracle.com Wed Jan 16 21:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:01 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130116211804.8921F4730F@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From lana.steuck at oracle.com Wed Jan 16 21:18:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:06 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20130116211821.E15BF47311@hg.openjdk.java.net> Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags Changeset: 06827097cdd3 Author: lana Date: 2013-01-16 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/06827097cdd3 Merge From lana.steuck at oracle.com Wed Jan 16 21:18:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:09 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130116211825.1256547312@hg.openjdk.java.net> Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags Changeset: 8d0baee36c71 Author: lana Date: 2013-01-10 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8d0baee36c71 Merge Changeset: 63b20bde7cd6 Author: lana Date: 2013-01-16 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/63b20bde7cd6 Merge From lana.steuck at oracle.com Wed Jan 16 21:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:01 +0000 Subject: hg: jdk8/tl: 4 new changesets Message-ID: <20130116211801.EC7084730E@hg.openjdk.java.net> Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags Changeset: 93b9664f97ee Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/93b9664f97ee Merge Changeset: cecfba251e4a Author: lana Date: 2013-01-16 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cecfba251e4a Merge From lana.steuck at oracle.com Wed Jan 16 21:18:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:03 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130116211813.6617747310@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From lana.steuck at oracle.com Wed Jan 16 21:18:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:27 +0000 Subject: hg: jdk8/tl/hotspot: 39 new changesets Message-ID: <20130116211948.11B1547313@hg.openjdk.java.net> Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck 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/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.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/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle 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/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.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: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags From lana.steuck at oracle.com Wed Jan 16 21:18:29 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:29 +0000 Subject: hg: jdk8/tl/jdk: 6 new changesets Message-ID: <20130116211951.9531347314@hg.openjdk.java.net> Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags Changeset: d54922883f4c Author: alexsch Date: 2013-01-09 16:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d54922883f4c 8005019: JTable passes row index instead of length when inserts selection interval Reviewed-by: serb, denis ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/8005019/bug8005019.java Changeset: b2c425d7e5be Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2c425d7e5be Merge Changeset: 733885f57e14 Author: lana Date: 2013-01-10 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/733885f57e14 Merge Changeset: 9fed48caac80 Author: lana Date: 2013-01-16 12:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fed48caac80 Merge From joe.darcy at oracle.com Wed Jan 16 21:22:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 16 Jan 2013 21:22:28 +0000 Subject: hg: jdk8/tl/langtools: 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Message-ID: <20130116212231.47D6C47315@hg.openjdk.java.net> Changeset: 8b749558767b Author: darcy Date: 2013-01-16 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b749558767b 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java From peter.levart at gmail.com Wed Jan 16 22:25:32 2013 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 16 Jan 2013 23:25:32 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F6DC21.1090202@oracle.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> <50F6D62A.3080401@redhat.com> <50F6DC21.1090202@oracle.com> Message-ID: <50F728DC.1000506@gmail.com> On 01/16/2013 05:58 PM, Joe Darcy wrote: > On 1/16/2013 8:32 AM, Florian Weimer wrote: >> On 01/16/2013 05:27 PM, Brian Goetz wrote: >> >>> The primary purpose of this annotation is to *capture design >>> intent*. It is not required. The compiler will help you enforce >>> the design intent if you provide it. The compiler will not >>> synthesize this annotation, since that would be guessing at the >>> design intent. It is possible to create classfiles that subvert the >>> design intent. >>> >>> The point about other languages was simply to point out that the >>> universe of tools that might usefully use this design intent is >>> bigger than sometimes assumed. >> >> I don't think run-time behavior should depend on optional annotations >> documenting design intent (like @Override). >> >> Supporting the discovery of functional interfaces is a good idea. But >> a method like Class#isFunctionalInterface() would sever this purpose >> better than an entirely optional annotation. >> > > A method like Class#isFunctionalInterface is planned too for later in > JDK 8. I can imagine that a method like that would be useful if also accompanied with a method like: Class#getFunctionalInterfaceMethod() Regards, Peter > > -Joe From bharadwaj.yadavalli at oracle.com Thu Jan 17 00:47:14 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 16 Jan 2013 19:47:14 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F712A5.9030707@oracle.com> References: <50F6F303.3000504@oracle.com> <50F712A5.9030707@oracle.com> Message-ID: <50F74A12.4060206@oracle.com> On 1/16/2013 3:50 PM, Dean Long wrote: > Don't you need to change the split verifier as well? > Looks like the a corresponding change is already in http://hg.openjdk.java.net/jdk8/tl/hotspot/diff/4735d2c84362/src/share/vm/classfile/verifier.cpp. It bypasses verification of an overpass method (determined by the method type being ConstMethod::OVERPASS). It would be consistent to use the same set of verification tests in the old and new verifiers. But, I do not see a JVM_* query that would give me the method type to use in verification of methods in check_code.c. Does anyone know of a way to get this info via JVM_* query? For now, it appears to me that checking access flags as I did in the webrev would be sufficient in the old verifier code. Bharadwaj From vladimir.kozlov at oracle.com Thu Jan 17 04:27:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Jan 2013 20:27:35 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F120CD.6020207@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> Message-ID: <50F77DB7.50806@oracle.com> On 1/12/13 12:37 AM, Ulf Zibis wrote: > Am 11.01.2013 23:53, schrieb Christian Thalinger: >> But you guys noticed that sentence in the initial review request, right? >> >> "Move encoding loop into separate method for which VM will use >> intrinsic on x86." >> >> Just wanted to make sure ;-) > > Good question Christian! > > This is, how it shows up to me: > 1) The bug synopsis is unspecific about intrinsc, so ... > 2) the mentioned 1st sentence could be one of many solutions. > 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is > not available. I opened it, should show up in few days. > 4) What specific operation should be done by the intrinsic, i.e. is > there a fixed API for that method ??? When C2 (server JIT compiler in JVM) compiles encode methods it will replace new method encodeArray() (matched by signature) with hand optimized assembler code which uses latest processor instructions. I will send Hotspot changes soon. So it is nothing to do with interpreter or bytecode sequence. > 5) Can an intrinsic write back more than 1 value (see my hack via int[] > p) ? > 6) Vladimir's webrev shows an integer as return type for that method, > I've added a variant with boolean return type, and the code from my last > approach could be transformed to a method with Object return type. Here is latest webrev, I added caching arrayOffset() call results: http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev.01 I tested it with java nio regression/verification tests. I am done with java part and will not accept any more changes except if someone find a bug in it. > > ... so waiting for Vladimir's feedback :-[ > (especially on performance/hsdis results) Performance on x86 tested with next code (whole test will be in Hotspot changes) : ba = CharBuffer.wrap(a); bb = ByteBuffer.wrap(b); long start = System.currentTimeMillis(); for (int i = 0; i < 1000000; i++) { ba.clear(); bb.clear(); enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); } long end = System.currentTimeMillis(); 1 - current java code 2 - new encodeArray() with loop but without intrinsic (JIT compiled code) 3 - using assembler intrinsic for encodeArray() on cpu without SSE4.2 4 - using assembler intrinsic on cpu with SSE4.2 5 - using assembler intrinsic on cpu with AVX2 size: 1 time: 40 34 28 28 28 size: 7 time: 47 40 33 33 34 size: 8 time: 51 41 33 28 29 size: 16 time: 58 45 37 29 29 size: 32 time: 72 56 44 30 29 size: 64 time: 103 71 62 32 31 size: 128 time: 160 105 89 36 33 size: 256 time: 284 178 141 42 37 size: 512 time: 514 317 246 61 50 size: 1024 time: 987 599 458 89 68 size: 2048 time: 1930 1150 853 145 114 size: 4096 time: 3820 2283 1645 264 207 Thanks, Vladimir > > (Can someone push the bug to the public?) > > -Ulf From jonathan.gibbons at oracle.com Thu Jan 17 04:41:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 17 Jan 2013 04:41:40 +0000 Subject: hg: jdk8/tl/langtools: 8006228: Doclint doesn't detect {@code nested inline} Message-ID: <20130117044145.5514147330@hg.openjdk.java.net> Changeset: 916143318f10 Author: jjg Date: 2013-01-16 20:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/916143318f10 8006228: Doclint doesn't detect {@code nested inline} Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/LiteralTest.java + test/tools/doclint/LiteralTest.out From forax at univ-mlv.fr Thu Jan 17 06:58:15 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Jan 2013 07:58:15 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F728DC.1000506@gmail.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> <50F6D62A.3080401@redhat.com> <50F6DC21.1090202@oracle.com> <50F728DC.1000506@gmail.com> Message-ID: <50F7A107.1000008@univ-mlv.fr> On 01/16/2013 11:25 PM, Peter Levart wrote: > > On 01/16/2013 05:58 PM, Joe Darcy wrote: >> On 1/16/2013 8:32 AM, Florian Weimer wrote: >>> On 01/16/2013 05:27 PM, Brian Goetz wrote: >>> >>>> The primary purpose of this annotation is to *capture design >>>> intent*. It is not required. The compiler will help you enforce >>>> the design intent if you provide it. The compiler will not >>>> synthesize this annotation, since that would be guessing at the >>>> design intent. It is possible to create classfiles that subvert >>>> the design intent. >>>> >>>> The point about other languages was simply to point out that the >>>> universe of tools that might usefully use this design intent is >>>> bigger than sometimes assumed. >>> >>> I don't think run-time behavior should depend on optional >>> annotations documenting design intent (like @Override). >>> >>> Supporting the discovery of functional interfaces is a good idea. >>> But a method like Class#isFunctionalInterface() would sever this >>> purpose better than an entirely optional annotation. >>> >> >> A method like Class#isFunctionalInterface is planned too for later in >> JDK 8. > I can imagine that a method like that would be useful if also > accompanied with a method like: > > Class#getFunctionalInterfaceMethod() this method may not exist. > > Regards, Peter > >> >> -Joe > R?mi From forax at univ-mlv.fr Thu Jan 17 07:00:24 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Jan 2013 08:00:24 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <91A384DE-4929-4884-929B-F048EAC29AEC@oracle.com> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F67F42.2040102@univ-mlv.fr> <91A384DE-4929-4884-929B-F048EAC29AEC@oracle.com> Message-ID: <50F7A188.4010606@univ-mlv.fr> On 01/16/2013 05:09 PM, Brian Goetz wrote: > The point is not to provide an ironclad guarantee that SAM conversion will never fail. It is to capture the original author's design intent and provide a small amount of compile-time tooling to help enforce that. Like @Override. so we agree, like @Override, the retention of this annotation should be SOURCE. R?mi > > > On Jan 16, 2013, at 2:21 AM, Remi Forax wrote: > >> On 01/16/2013 10:51 AM, Florian Weimer wrote: >>> On 01/16/2013 07:54 AM, Joe Darcy wrote: >>>> Hi Florian, >>>> >>>> On 1/10/2013 1:23 AM, Florian Weimer wrote: >>>>> On 01/08/2013 10:24 PM, Joe Darcy wrote: >>>>>> As discussed over on one of the Project Lambda lists [1], we're adding >>>>>> an interface type to the platform to explicitly mark interface types as >>>>>> being functional interfaces suitable for use in lambda expressions. >>>>>> Please review the addition of this new type: >>>>>> >>>>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>>>> Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), >>>>> similar to the @Override annotation? >>>> No; we intentionally made this annotation have runtime retention to >>>> allow it to also be queried to various tools at runtime, etc. >>> This is really a bit odd. Doesn't this risk that code will rely on the annotation, instead of inferring the functional interface status based on the interface contents? >> Yes, it's a serious issue IMO. >> because the annotation is verified at compile time and the linking is done at runtime in Java so the annotation can be present and valid when compiled but at runtime the interface is not a functional interface anymore because by example a super interface was recompiled without compiling the annotated interface. >> >> I agree that a good way to mitigate this is to make the annotation not present in the bytecode and only available to javac and all annotation processors. >> If a runtime tool want this information, it should use the reflection API that provides the VM point of view of the world, not the compiler(s) one. >> >>> I could not find this part in the lambda-libs-spec-experts discussion. Have you got a more specific pointer? >>> >> As far as I now, this part was not discussed. >> For reference, the whole thread starts here: >> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-December/000877.html >> >> R?mi >> From peter.levart at gmail.com Thu Jan 17 08:07:10 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 17 Jan 2013 09:07:10 +0100 Subject: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries In-Reply-To: <50F7A107.1000008@univ-mlv.fr> References: <50EC8E7B.807@oracle.com> <50EE88A3.7050301@redhat.com> <50F64E99.60100@oracle.com> <50F67809.6040306@redhat.com> <50F6D276.2060108@redhat.com> <61107897-EA40-4F06-937C-95A279C60EEB@oracle.com> <50F6D62A.3080401@redhat.com> <50F6DC21.1090202@oracle.com> <50F728DC.1000506@gmail.com> <50F7A107.1000008@univ-mlv.fr> Message-ID: <50F7B12E.4010405@gmail.com> On 01/17/2013 07:58 AM, Remi Forax wrote: > On 01/16/2013 11:25 PM, Peter Levart wrote: >> >> On 01/16/2013 05:58 PM, Joe Darcy wrote: >>> On 1/16/2013 8:32 AM, Florian Weimer wrote: >>>> On 01/16/2013 05:27 PM, Brian Goetz wrote: >>>> >>>>> The primary purpose of this annotation is to *capture design >>>>> intent*. It is not required. The compiler will help you enforce >>>>> the design intent if you provide it. The compiler will not >>>>> synthesize this annotation, since that would be guessing at the >>>>> design intent. It is possible to create classfiles that subvert >>>>> the design intent. >>>>> >>>>> The point about other languages was simply to point out that the >>>>> universe of tools that might usefully use this design intent is >>>>> bigger than sometimes assumed. >>>> >>>> I don't think run-time behavior should depend on optional >>>> annotations documenting design intent (like @Override). >>>> >>>> Supporting the discovery of functional interfaces is a good idea. >>>> But a method like Class#isFunctionalInterface() would sever this >>>> purpose better than an entirely optional annotation. >>>> >>> >>> A method like Class#isFunctionalInterface is planned too for later >>> in JDK 8. >> I can imagine that a method like that would be useful if also >> accompanied with a method like: >> >> Class#getFunctionalInterfaceMethod() > > this method may not exist. Even if isFunctionalInterface() returns true? How? There might be more than one (if they can be implemented by a single method), but there might exist an algorithm to choose the most appropriate. Regards, Peter > >> >> Regards, Peter >> >>> >>> -Joe >> > > R?mi > From weijun.wang at oracle.com Thu Jan 17 09:12:22 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2013 17:12:22 +0800 Subject: No newline at the end of Base64.getMimeEncoder() Message-ID: <50F7C076.20501@oracle.com> I noticed that the encoding output of Base64.getMimeEncoder() never ends with a newline char. There is no right or wrong on this but it will be nice to write the current behavior into the spec. Thanks Max From weijun.wang at oracle.com Thu Jan 17 09:37:51 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2013 17:37:51 +0800 Subject: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API In-Reply-To: <20130113221518.BD0B247237@hg.openjdk.java.net> References: <20130113221518.BD0B247237@hg.openjdk.java.net> Message-ID: <50F7C66F.5010004@oracle.com> NTLM auth still uses it. Codes in src/windows and src/solaris. -Max On 01/14/2013 06:14 AM, chris.hegarty at oracle.com wrote: > Changeset: 7db04ae3378f > Author: chegar > Date: 2013-01-13 22:09 +0000 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f > > 8006153: HTTP protocol handler authenication should use Base64 API > Reviewed-by: chegar, alanb > Contributed-by: Mark Sheppard > > ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java > ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java > From chris.hegarty at oracle.com Thu Jan 17 09:45:54 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Jan 2013 09:45:54 +0000 Subject: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API In-Reply-To: <50F7C66F.5010004@oracle.com> References: <20130113221518.BD0B247237@hg.openjdk.java.net> <50F7C66F.5010004@oracle.com> Message-ID: <50F7C852.90608@oracle.com> On 01/17/2013 09:37 AM, Weijun Wang wrote: > NTLM auth still uses it. Codes in src/windows and src/solaris. Thank you Max. Yes, Mark just noticed these yesterday. He is preparing a patch and will send it for review shortly. -Chris. > > -Max > > On 01/14/2013 06:14 AM, chris.hegarty at oracle.com wrote: >> Changeset: 7db04ae3378f >> Author: chegar >> Date: 2013-01-13 22:09 +0000 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f >> >> 8006153: HTTP protocol handler authenication should use Base64 API >> Reviewed-by: chegar, alanb >> Contributed-by: Mark Sheppard >> >> ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java >> ! >> src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java >> From weijun.wang at oracle.com Thu Jan 17 10:52:06 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 17 Jan 2013 18:52:06 +0800 Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) In-Reply-To: <50F7C076.20501@oracle.com> References: <50F7C076.20501@oracle.com> Message-ID: <50F7D7D6.3080105@oracle.com> This time on the decoder side: Base64.getMimeDecoder().decode("AA==\n") throws an exception because the string ends with a newline. I would prefer it be acceptable. Thanks Max On 01/17/2013 05:12 PM, Weijun Wang wrote: > I noticed that the encoding output of Base64.getMimeEncoder() never ends > with a newline char. There is no right or wrong on this but it will be > nice to write the current behavior into the spec. > > Thanks > Max From mark.sheppard at oracle.com Thu Jan 17 15:02:55 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 17 Jan 2013 07:02:55 -0800 (PST) Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) Message-ID: <0d1a18f2-fde9-45de-9af9-e4566b8a7338@default> Hi Max, The fact that the padding characters == and = appear before the newline, leads to RFC2045 section 6.8 (pg 25) and how the implementation interprets the processing for the pad character in the encoding. As per RFC2045 base64 encoding the occurrence of = indicates end of data. That is to say, == or = is only used in the final unit of encoding at the very end of the encoded data. This raises a couple of questions: So is it an error if there are data after these explicit "end of data" markers, when they occur? should a special case be made for line separators? What about ignoring any data after == or = ? The javadoc for Base64 Mime Encoder/Decoder alludes to the line separator and characters outside the base64 alphabet being ignored during decoding. This in itself can be ambiguously interpreted to mean anywhere in the stream, including after an end of data indicator, unless specific attention and interpretation is give to RFC2045. Consider the fact that Base64.getMimeDecoder().decode("AA==B") also throws an exception this suggests that the decoder is interpreting data after the end of data padding indication as an error. Thus, a newline after = or == is reasonable interpreted as an error, suggesting that the exception is reasonable. It can be noted that Base64.getMimeDecoder().decode("AAAA\n") doesn't throw an exception. regards Mark ----- Original Message ----- From: weijun.wang at oracle.com To: core-libs-dev at openjdk.java.net Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) This time on the decoder side: Base64.getMimeDecoder().decode("AA==\n") throws an exception because the string ends with a newline. I would prefer it be acceptable. Thanks Max On 01/17/2013 05:12 PM, Weijun Wang wrote: > I noticed that the encoding output of Base64.getMimeEncoder() never ends > with a newline char. There is no right or wrong on this but it will be > nice to write the current behavior into the spec. > > Thanks > Max From joel.franck at oracle.com Thu Jan 17 16:23:54 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 17 Jan 2013 17:23:54 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations Message-ID: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> Hi, Here is a webrev for core reflection support for type annotations: http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/ This code is based on the tl/jdk repository, but in order to run the tests you need a javac with type annotations support and also a recent copy of the VM that includes this change set: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282 (This also means this code can't be pushed until all supporting pieces are in place.) Type annotations are still a bit of a moving target so there will be follow up work on this. There is no caching of annotations in this version and I am not sure how we want to do the space/time trade of for type annotations. cheers /Joel From xueming.shen at oracle.com Thu Jan 17 17:03:46 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 17 Jan 2013 09:03:46 -0800 Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) In-Reply-To: <0d1a18f2-fde9-45de-9af9-e4566b8a7338@default> References: <0d1a18f2-fde9-45de-9af9-e4566b8a7338@default> Message-ID: <50F82EF2.5090401@oracle.com> Hi, Yes, padding \n (and any non-base64 character) after base64 padding character '=' probably should be ignored, instead of exception in mime mode. The behavior/ implementation is not consistent now for this case. Will file a cr and address this, probably after M6. Thanks! -Sherman On 1/17/13 7:02 AM, Mark Sheppard wrote: > Hi Max, > > The fact that the padding characters == and = appear before the > newline, leads to RFC2045 section 6.8 (pg 25) and how the > implementation interprets the processing for the pad character in the encoding. > > As per RFC2045 base64 encoding the occurrence of = indicates end of data. > That is to say, == or = is only used in the final unit of encoding > at the very end of the encoded data. > This raises a couple of questions: > So is it an error if there are data after these explicit "end of data" markers, when they occur? > should a special case be made for line separators? > What about ignoring any data after == or = ? > > The javadoc for Base64 Mime Encoder/Decoder alludes to the line separator and characters > outside the base64 alphabet being ignored during decoding. This in itself can be ambiguously > interpreted to mean anywhere in the stream, including after an end of data indicator, > unless specific attention and interpretation is give to RFC2045. > > Consider the fact that > > Base64.getMimeDecoder().decode("AA==B") also throws an exception > > this suggests that the decoder is interpreting data after the > end of data padding indication as an error. > > Thus, a newline after = or == is reasonable interpreted as an error, suggesting > that the exception is reasonable. > > It can be noted that Base64.getMimeDecoder().decode("AAAA\n") > doesn't throw an exception. > > regards > Mark > > > ----- Original Message ----- > From: weijun.wang at oracle.com > To: core-libs-dev at openjdk.java.net > Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, Ireland, Portugal > Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) > > This time on the decoder side: > > Base64.getMimeDecoder().decode("AA==\n") > > throws an exception because the string ends with a newline. I would > prefer it be acceptable. > > Thanks > Max > > On 01/17/2013 05:12 PM, Weijun Wang wrote: >> I noticed that the encoding output of Base64.getMimeEncoder() never ends >> with a newline char. There is no right or wrong on this but it will be >> nice to write the current behavior into the spec. >> >> Thanks >> Max From xueming.shen at oracle.com Thu Jan 17 17:13:21 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 17 Jan 2013 09:13:21 -0800 Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) In-Reply-To: <50F82EF2.5090401@oracle.com> References: <0d1a18f2-fde9-45de-9af9-e4566b8a7338@default> <50F82EF2.5090401@oracle.com> Message-ID: <50F83131.2050807@oracle.com> JDK-8006530 (including the request of explicitly documenting the no \n at end behavior) -Sherman On 1/17/13 9:03 AM, Xueming Shen wrote: > Hi, > > Yes, padding \n (and any non-base64 character) after base64 padding > character > '=' probably should be ignored, instead of exception in mime mode. The > behavior/ > implementation is not consistent now for this case. Will file a cr and > address this, > probably after M6. > > Thanks! > -Sherman > > On 1/17/13 7:02 AM, Mark Sheppard wrote: >> Hi Max, >> >> The fact that the padding characters == and = appear before the >> newline, leads to RFC2045 section 6.8 (pg 25) and how the >> implementation interprets the processing for the pad character in the >> encoding. >> >> As per RFC2045 base64 encoding the occurrence of = indicates end of >> data. >> That is to say, == or = is only used in the final unit of encoding >> at the very end of the encoded data. >> This raises a couple of questions: >> So is it an error if there are data after these explicit "end of >> data" markers, when they occur? >> should a special case be made for line separators? >> What about ignoring any data after == or = ? >> >> The javadoc for Base64 Mime Encoder/Decoder alludes to the line >> separator and characters >> outside the base64 alphabet being ignored during decoding. This in >> itself can be ambiguously >> interpreted to mean anywhere in the stream, including after an end of >> data indicator, >> unless specific attention and interpretation is give to RFC2045. >> >> Consider the fact that >> >> Base64.getMimeDecoder().decode("AA==B") also throws an exception >> this suggests that the decoder is interpreting data after the >> end of data padding indication as an error. >> >> Thus, a newline after = or == is reasonable interpreted as an error, >> suggesting >> that the exception is reasonable. >> >> It can be noted that Base64.getMimeDecoder().decode("AAAA\n") >> doesn't throw an exception. >> >> regards >> Mark >> >> >> ----- Original Message ----- >> From: weijun.wang at oracle.com >> To: core-libs-dev at openjdk.java.net >> Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, >> Ireland, Portugal >> Subject: And Decoder (was Re: No newline at the end of >> Base64.getMimeEncoder()) >> >> This time on the decoder side: >> >> Base64.getMimeDecoder().decode("AA==\n") >> >> throws an exception because the string ends with a newline. I would >> prefer it be acceptable. >> >> Thanks >> Max >> >> On 01/17/2013 05:12 PM, Weijun Wang wrote: >>> I noticed that the encoding output of Base64.getMimeEncoder() never >>> ends >>> with a newline char. There is no right or wrong on this but it will be >>> nice to write the current behavior into the spec. >>> >>> Thanks >>> Max > From brian.burkhalter at oracle.com Thu Jan 17 17:36:24 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 17 Jan 2013 09:36:24 -0800 Subject: RFR: 8006090 - Formatter asserts with -esa Message-ID: The assert occurs in private Appendable print(StringBuilder sb, Calendar t, char c, Locale l) due to assert(width == -1); not being satisfied. The proposed fix is to remove this assert statement which appears to be vestigial. Regression and compatibility testing did not reveal any failures due to removing this statement. --- old/src/share/classes/java/util/Formatter.java 2013-01-16 12:22:55.000000000 -0800 +++ new/src/share/classes/java/util/Formatter.java 2013-01-16 12:22:55.000000000 -0800 @@ -3827,7 +3827,6 @@ Locale l) throws IOException { - assert(width == -1); if (sb == null) sb = new StringBuilder(); switch ? { Thanks, Brian From karen.kinnear at oracle.com Thu Jan 17 17:44:14 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 17 Jan 2013 12:44:14 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F303.3000504@oracle.com> References: <50F6F303.3000504@oracle.com> Message-ID: <90888A43-ED70-4FC6-8484-39BC2E016FF7@oracle.com> Change looks good give I don't know any way for the java library to get the internal method type information. Can you please fix the spelling of "implementation" in the comment? thanks, Karen p.s. And I think you are ensuring !abstract by doing an exact match of flags. On Jan 16, 2013, at 1:35 PM, Bharadwaj Yadavalli wrote: > Please review the change at http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ > > Default interface methods are new in Java 8. VM creates overpass methods in the vtable slots of classes to invoke a default method using invokespecial. > > Consequently, invocation of default interface methods (i.e., overpass methods in the VM) via invokespecial is legal and should not be flagged as illegal. > > In short, this change allows invocation of default methods of Java 8 using invokespecial. > > I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new failures. > > Thanks, > > Bharadwaj > From joe.darcy at oracle.com Thu Jan 17 17:48:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Jan 2013 09:48:30 -0800 Subject: RFR: 8006090 - Formatter asserts with -esa In-Reply-To: References: Message-ID: <50F8396E.7070700@oracle.com> Look fine Brian. Thanks, -Joe On 1/17/2013 9:36 AM, Brian Burkhalter wrote: > The assert occurs in > > private Appendable print(StringBuilder sb, Calendar t, char c, > Locale l) > > due to > > assert(width == -1); > > not being satisfied. The proposed fix is to remove this assert statement which appears to be vestigial. Regression and compatibility testing did not reveal any failures due to removing this statement. > > --- old/src/share/classes/java/util/Formatter.java 2013-01-16 12:22:55.000000000 -0800 > +++ new/src/share/classes/java/util/Formatter.java 2013-01-16 12:22:55.000000000 -0800 > @@ -3827,7 +3827,6 @@ > Locale l) > throws IOException > { > - assert(width == -1); > if (sb == null) > sb = new StringBuilder(); > switch ? { > > Thanks, > > Brian From Alan.Bateman at oracle.com Thu Jan 17 18:00:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jan 2013 18:00:46 +0000 Subject: RFR: 8006090 - Formatter asserts with -esa In-Reply-To: References: Message-ID: <50F83C4E.9020705@oracle.com> This looks fine to me. Sherman - I suspect the same assert in the print method added by JSR-310 has the same issue. -Alan. On 17/01/2013 17:36, Brian Burkhalter wrote: > The assert occurs in > > private Appendable print(StringBuilder sb, Calendar t, char c, > Locale l) > > due to > > assert(width == -1); > > not being satisfied. The proposed fix is to remove this assert statement which appears to be vestigial. Regression and compatibility testing did not reveal any failures due to removing this statement. > > --- old/src/share/classes/java/util/Formatter.java 2013-01-16 12:22:55.000000000 -0800 > +++ new/src/share/classes/java/util/Formatter.java 2013-01-16 12:22:55.000000000 -0800 > @@ -3827,7 +3827,6 @@ > Locale l) > throws IOException > { > - assert(width == -1); > if (sb == null) > sb = new StringBuilder(); > switch ? { > > Thanks, > > Brian From xueming.shen at oracle.com Thu Jan 17 18:10:03 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 17 Jan 2013 10:10:03 -0800 Subject: RFR: 8006090 - Formatter asserts with -esa In-Reply-To: <50F83C4E.9020705@oracle.com> References: <50F83C4E.9020705@oracle.com> Message-ID: <50F83E7B.5040804@oracle.com> On 1/17/13 10:00 AM, Alan Bateman wrote: > > This looks fine to me. > > Sherman - I suspect the same assert in the print method added by > JSR-310 has the same issue. Yes. That will be removed as well. > > -Alan. > > On 17/01/2013 17:36, Brian Burkhalter wrote: >> The assert occurs in >> >> private Appendable print(StringBuilder sb, Calendar t, char c, >> Locale l) >> >> due to >> >> assert(width == -1); >> >> not being satisfied. The proposed fix is to remove this assert >> statement which appears to be vestigial. Regression and compatibility >> testing did not reveal any failures due to removing this statement. >> >> --- old/src/share/classes/java/util/Formatter.java 2013-01-16 >> 12:22:55.000000000 -0800 >> +++ new/src/share/classes/java/util/Formatter.java 2013-01-16 >> 12:22:55.000000000 -0800 >> @@ -3827,7 +3827,6 @@ >> Locale l) >> throws IOException >> { >> - assert(width == -1); >> if (sb == null) >> sb = new StringBuilder(); >> switch ? { >> >> Thanks, >> >> Brian > From maurizio.cimadamore at oracle.com Thu Jan 17 18:15:49 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 17 Jan 2013 18:15:49 +0000 Subject: hg: jdk8/tl/langtools: 8005852: Treatment of '_' as identifier Message-ID: <20130117181554.2FFD747375@hg.openjdk.java.net> Changeset: 2d2b2be57c78 Author: mcimadamore Date: 2013-01-17 18:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d2b2be57c78 8005852: Treatment of '_' as identifier Summary: warn when '_' is found in an identifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/lambda/LambdaParserTest.java From jim.gish at oracle.com Thu Jan 17 20:18:53 2013 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 17 Jan 2013 12:18:53 -0800 (PST) Subject: RFR: 8006534 CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Message-ID: <50F85CAD.6070006@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bug8006534-getUnusedRandomPort-retry-more/ TestLibrary.getUnusedPort() attempts to retry getting an ephemeral port 10 times, which is the current number of ports in the reserved port range. Debugging code added a few weeks back has revealed that intermittent failures in tests using this method are caused when the underlying socket code first returns the first number in the reserved port range. Subsequent retries result in incrementing the port number by one until reaching the max reserved port number, which just happens to correspond to the 10th attempt, and the code then quits trying. The proposed fix (one of many possible alternatives, of course) simply retries for twice the number of ports in the range. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From kumar.x.srinivasan at oracle.com Thu Jan 17 20:44:13 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 17 Jan 2013 12:44:13 -0800 Subject: Review Request : Java exe doesn't process args ending Back slash In-Reply-To: <50F64497.3050303@linux.vnet.ibm.com> References: <50D1F3D7.20608@linux.vnet.ibm.com> <50D1FA7E.8040609@linux.vnet.ibm.com> <50D20960.8080300@oracle.com> <50E6E44E.7090105@linux.vnet.ibm.com> <50F5FAD6.2090306@oracle.com> <50F64497.3050303@linux.vnet.ibm.com> Message-ID: <50F8629D.5020801@oracle.com> Hi Jayashree, I have assigned a JBS issue to this: JDK-8006536, for your reference. I have attached a modified patch to that issue. There are other issues as well that needs to be resolved with \ parsing. We will address this once we are done with our JDK8 Milestone feature commitments. Thanks Kumar > On 16-01-2013 6:26 AM, Kumar Srinivasan wrote: >> Hello Jayashree, >> >> I see the issue, I have been busy with other things, I will revisit your >> patch in the coming week. >> >> Kumar >> >>> On 20-12-2012 12:07 AM, Kumar Srinivasan wrote: >>>> Hello Jayashree, >>>> >>>> a. you are referencing a bug which has already been fixed, is there a >>>> new one for this ? >>>> >>>> b. with regards to the fix, I don't quite understand the issue, >>>> could you please >>>> provide a use case ? >>>> >>>> c. your regression test does not seem to be accurate it behaves the >>>> same with or >>>> without your fix, also you will need to provide a C++ test case >>>> in cmdtoargs.c >>>> as well see the bottom of that file. >>>> >>>> >>>> Thanks >>>> Kumar >>>> >>>> >>>> >>>>> >>>>> >>>>> Hi All, >>>>> >>>>> Java.exe doesn't seems to process arguments ending with back slashes >>>>> well , in windows only . >>>>> >>>>> I have added test scenario and changeset in the below webrev . >>>>> >>>>> http://cr.openjdk.java.net/~jviswana/7188114/webrev.01/ >>>>> >>>>> This seems to be introduced after the bug fix for 7188114 has be made >>>>> into jdk8 . >>>>> >>>>> Thanks and Regards, >>>>> Jayashree Viswanathan >>>>> >>>>> >>>>> >>>>> >>>> >>> Hi Kumar , >>> >>> a. I am referencing an old bug because , that bug fix has caused >>> this regression . >>> >>> b. The use case is when there are backslashes at the end args for a >>> java command using say -Dtest.argEndingInBackslash=a\\\\ >>> >>> JavaVM args: >>> version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 5 >>> option[ 0] = '-Dsun.java.launcher.diag=true' >>> option[ 1] = '-Djava.class.path=.' >>> option[ 2] = '-Dtest.argEndingInBackslash=a' >>> option[ 3] = '-Dsun.java.command=TestCmdLineParsing' >>> option[ 4] = '-Dsun.java.launcher=SUN_STANDARD' >>> 74439 micro seconds to InitializeJVM >>> Main class is 'TestCmdLineParsing' >>> App's argc is 0 >>> 9182 micro seconds to load main class >>> ----_JAVA_LAUNCHER_DEBUG---- >>> value of test.argEndingInBackslash = a >>> >>> >>> c. Sorry , I seem to have missed something , the above test case >>> should help you exhibit the problem . >>> Can you please let me know where to find or add such C++ test cases >>> , as In the test cases bucket I know off is jtreg or JCKs only at >>> the moment . >>> >>> Thanks and Regards, >>> Jayashree Viswanathan >>> >>> >> > Thanks for the response ! > > Regards, > Jayashree Viswanathan > From xueming.shen at oracle.com Thu Jan 17 20:45:04 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 17 Jan 2013 20:45:04 +0000 Subject: hg: jdk8/tl/jdk: 8006090: Formatter asserts with -esa Message-ID: <20130117204528.C49394737E@hg.openjdk.java.net> Changeset: 787c7c1c210f Author: sherman Date: 2013-01-17 12:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/787c7c1c210f 8006090: Formatter asserts with -esa Summary: removed the offending assert Reviewed-by: alanb, darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java ! test/ProblemList.txt From mike.duigou at oracle.com Thu Jan 17 21:28:04 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 17 Jan 2013 13:28:04 -0800 Subject: RFR: 8006534 CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times In-Reply-To: <50F85CAD.6070006@oracle.com> References: <50F85CAD.6070006@oracle.com> Message-ID: <75CCE655-81B8-44EE-A2E6-3A1363505A4F@oracle.com> Seems entirely reasonable. On Jan 17 2013, at 12:18 , Jim Gish wrote: > Please review http://cr.openjdk.java.net/~jgish/Bug8006534-getUnusedRandomPort-retry-more/ > > TestLibrary.getUnusedPort() attempts to retry getting an ephemeral port 10 times, which is the current number of ports in the reserved port range. Debugging code added a few weeks back has revealed that intermittent failures in tests using this method are caused when the underlying socket code first returns the first number in the reserved port range. Subsequent retries result in incrementing the port number by one until reaching the max reserved port number, which just happens to correspond to the 10th attempt, and the code then quits trying. > > The proposed fix (one of many possible alternatives, of course) simply retries for twice the number of ports in the range. > > Thanks, > Jim > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > From eric.mccorkle at oracle.com Thu Jan 17 21:54:43 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 17 Jan 2013 16:54:43 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F059AF.1000706@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> Message-ID: <50F87323.9040505@oracle.com> After (lengthy) examination, it seems that properly addressing the synthesized parameters issue will require more changes to javac. In light of this, I think that the synthesized parameter logic should go in a follow-up enhancement. I have created JDK-8006345 to track this issue: http://bugs.sun.com/view_bug.do?bug_id=8006345 Therefore, I've rolled back the changes I was making which would have synthesized parameters in the reflection API itself, and updated the webrev. Please examine for any additional concerns. On 01/11/13 13:27, Joe Darcy wrote: > Hi Eric, > > Taking another look at the code, some extra logic / checking is needed > in cases where the number of source parameters (non-synthetic and > non-synthesized) disagrees with the number of actual parameters at a > class file level. > > For example, if the single source parameter of an inner class > constructor is annotated, the annotation should be associated with the > *second* parameter since the first class file parameter is a synthesized > constructor added by the compiler. I think generally annotations should > not be associated with synthesized or synthetic parameters. > > -Joe > > On 1/11/2013 9:03 AM, Eric McCorkle wrote: >> Update should be visible now. >> >> On 01/11/13 11:54, Vitaly Davidovich wrote: >>> Yes that's exactly what I'm looking for as well. >>> >>> Sent from my phone >>> >>> On Jan 11, 2013 11:25 AM, "Peter Levart" >> > wrote: >>> >>> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >>> >>> The webrev has been updated again. >>> >>> The multiple writes to parameters have been removed, and the >>> tests have >>> been expanded to look at inner classes, and to test modifiers. >>> >>> Please look over it again. >>> >>> >>> Hello Eric, >>> >>> You still have 2 reads of volatile even in fast path. I would do it >>> this way: >>> >>> >>> private Parameter[] privateGetParameters() { >>> Parameter[] tmp = parameters; // one and only read >>> if (tmp != null) >>> return tmp; >>> >>> // Otherwise, go to the JVM to get them >>> tmp = getParameters0(); >>> >>> // If we get back nothing, then synthesize parameters >>> if (tmp == null) { >>> final int num = getParameterCount(); >>> tmp = new Parameter[num]; >>> for (int i = 0; i < num; i++) >>> // TODO: is there a way to synthetically derive the >>> // modifiers? Probably not in the general case, since >>> // we'd have no way of knowing about them, but there >>> // may be specific cases. >>> tmp[i] = new Parameter("arg" + i, 0, this, i); >>> // This avoids possible races from seeing a >>> // half-initialized parameters cache. >>> } >>> >>> parameters = tmp; >>> >>> return tmp; >>> } >>> >>> >>> Regards, Peter >>> >>> >>> Test-wise, I've got a clean run on JPRT (there were some >>> failures in >>> lambda stuff, but I've been seeing that for some time now). >>> >>> On 01/10/13 21:47, Eric McCorkle wrote: >>> >>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>> >>> Hi Eric, >>> >>> Parameter.equals() doesn't need null check - instanceof >>> covers that already. >>> >>> Removed. >>> >>> Maybe this has been mentioned already, but personally >>> I'm not a fan of >>> null checks such as "if (null == x)" - I prefer the >>> null >>> on the right >>> hand side, but that's just stylistic. >>> >>> Changed. >>> >>> Perhaps I'm looking at a stale webrev but >>> Executable.__privateGetParameters() reads and writes >>> from/to the volatile >>> field more than once. I think Peter already mentioned >>> that it should >>> use one read into a local and one write to publish the >>> final version to >>> the field (it can return the temp as well). >>> >>> You weren't. From a pure correctness standpoint, there is >>> nothing wrong >>> with what is there. getParameters0 is a constant >>> function, and >>> parameters is writable only if null. Hence, we only every >>> see one >>> nontrivial write to it. >>> >>> But you are right, it should probably be reduced to a >>> single >>> write, for >>> performance reasons (to avoid unnecessary memory barriers). >>> Therefore, >>> I changed it. >>> >>> However, I won't be able to refresh the webrev until >>> tomorrow. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>> >> >>> >> >> wrote: >>> >>> The webrev has been refreshed with the solution I >>> describe below >>> implemented. Please make additional comments. >>> >>> On 01/10/13 17:29, Eric McCorkle wrote: >>> > Good catch there. I made the field volatile, >>> and >>> I also did the same >>> > with the cache fields in Parameter. >>> > >>> > It is possible with what exists that you could >>> wind up with multiple >>> > copies of identical parameter objects in >>> existence. It goes something >>> > like this >>> > >>> > thread A sees Executable.parameters is null, >>> goes >>> into the VM to >>> get them >>> > thread B sees Executable.parameters is null, >>> goes >>> into the VM to >>> get them >>> > thread A stores to Executable.parameters >>> > thread B stores to Executable.parameters >>> > >>> > Since Parameters is immutable (except for its >>> caches, which will >>> always >>> > end up containing the same things), this >>> *should* >>> have no visible >>> > effects, unless someone does == instead of >>> .equals. >>> > >>> > This can be avoided by doing a CAS, which is >>> more >>> expensive >>> execution-wise. >>> > >>> > My vote is to *not* do a CAS, and accept that >>> (in >>> extremely rare >>> cases, >>> > even as far as concurrency-related anomalies >>> go), >>> you may end up with >>> > duplicates, and document that very well. >>> > >>> > Thoughts? >>> > >>> > On 01/10/13 16:10, Peter Levart wrote: >>> >> Hello Eric, >>> >> >>> >> I have another one. Although not very likely, >>> the reference to >>> the same >>> >> Method/Constructor can be shared among multiple >>> threads. The >>> publication >>> >> of a parameters array should therefore be >>> performed via a >>> volatile write >>> >> / volatile read, otherwise it can happen that >>> some thread sees >>> >> half-initialized array content. The >>> 'parameters' >>> field in Executable >>> >> should be declared as volatile and there should >>> be a single read >>> from it >>> >> and a single write to it in the >>> privateGetParameters() method >>> (you need >>> >> a local variable to hold intermediate >>> states)... >>> >> >>> >> Regards, Peter >>> >> >>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>> >>> Thanks to all for initial reviews; however, it >>> appears that the >>> version >>> >>> you saw was somewhat stale. I've applied your >>> comments (and some >>> >>> changes that I'd made since the version that >>> was posted). >>> >>> >>> >>> Please take a second look. >>> >>> >>> >>> Thanks, >>> >>> Eric >>> >>> >>> >>> >>> >>> On 01/10/13 04:19, Peter Levart wrote: >>> >>>> Hello Eric, >>> >>>> >>> >>>> You must have missed my comment from the >>> previous webrev: >>> >>>> >>> >>>> 292 private Parameter[] >>> privateGetParameters() { >>> >>>> 293 if (null != parameters) >>> >>>> 294 return parameters.get(); >>> >>>> >>> >>>> If/when the 'parameters' SoftReference is >>> cleared, the method >>> will be >>> >>>> returning null forever after... >>> >>>> >>> >>>> You should also retrieve the referent and >>> check for it's >>> presence before >>> >>>> returning it: >>> >>>> >>> >>>> Parameter[] res; >>> >>>> if (parameters != null && (res = >>> parameters.get()) != null) >>> >>>> return res; >>> >>>> ... >>> >>>> ... >>> >>>> >>> >>>> Regards, Peter >>> >>>> >>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>> >>>>> Hello, >>> >>>>> >>> >>>>> Please review the core reflection API >>> implementation of parameter >>> >>>>> reflection. This is the final component of >>> method parameter >>> reflection. >>> >>>>> This was posted for review before, then >>> delayed until the >>> check-in for >>> >>>>> JDK-8004728 (hotspot support for parameter >>> reflection), which >>> occurred >>> >>>>> yesterday. >>> >>>>> >>> >>>>> Note: The check-in of JDK-8004728 was into >>> hsx/hotspot-rt, *not* >>> >>>>> jdk8/tl; therefore, it may be a while before >>> the changeset >>> makes its way >>> >>>>> into jdk8/tl. >>> >>>>> >>> >>>>> Also note: since the check-in of JDK-8004727 >>> (javac support for >>> >>>>> parameter reflection), there has been a >>> failure in the tests for >>> >>>>> Pack200. This is being addressed in a fix >>> contributed by >>> Kumar, which I >>> >>>>> believe has also been posted for review. >>> >>>>> >>> >>>>> The open webrev is here: >>> >>>>> >>> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >>> >>> >>>>> >>> >>>>> The feature request is here: >>> >>>>> >>> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >>> >>> >>>>> >>> >>>>> The latest version of the spec can be >>> found here: >>> >>>>> >>> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >>> >>> >>>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Eric >>> >> >>> >>> > From kurchi.subhra.hazra at oracle.com Thu Jan 17 22:44:57 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 17 Jan 2013 22:44:57 +0000 Subject: hg: jdk8/tl/jdk: 7171415: java.net.URI.equals/hashCode not consistent for some URIs Message-ID: <20130117224517.A557F4738B@hg.openjdk.java.net> Changeset: e8414d69692c Author: khazra Date: 2013-01-17 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8414d69692c 7171415: java.net.URI.equals/hashCode not consistent for some URIs Summary: Rewrite URI.hashCode() to consider encoded characters, also reviewed by vitalyd at gmail.com, schlosna at gmail.com Reviewed-by: chegar ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java From fredrik.ohrstrom at oracle.com Thu Jan 17 23:19:22 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 17 Jan 2013 23:19:22 +0000 Subject: hg: jdk8/tl/langtools: 8004658: Add internal smart javac wrapper to solve JEP 139 Message-ID: <20130117231925.B122947393@hg.openjdk.java.net> Changeset: 22e417cdddee Author: ohrstrom Date: 2013-01-18 00:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/22e417cdddee 8004658: Add internal smart javac wrapper to solve JEP 139 Reviewed-by: jjg ! make/build.properties ! make/build.xml + src/share/classes/com/sun/tools/sjavac/BuildState.java + src/share/classes/com/sun/tools/sjavac/CleanProperties.java + src/share/classes/com/sun/tools/sjavac/CompileChunk.java + src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java + src/share/classes/com/sun/tools/sjavac/CompileProperties.java + src/share/classes/com/sun/tools/sjavac/CopyFile.java + src/share/classes/com/sun/tools/sjavac/JavacState.java + src/share/classes/com/sun/tools/sjavac/Log.java + src/share/classes/com/sun/tools/sjavac/Main.java + src/share/classes/com/sun/tools/sjavac/Module.java + src/share/classes/com/sun/tools/sjavac/Package.java + src/share/classes/com/sun/tools/sjavac/ProblemException.java + src/share/classes/com/sun/tools/sjavac/Source.java + src/share/classes/com/sun/tools/sjavac/Transformer.java + src/share/classes/com/sun/tools/sjavac/Util.java + src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java + src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java + src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java + src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java + src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + src/share/classes/com/sun/tools/sjavac/server/JavacServer.java + src/share/classes/com/sun/tools/sjavac/server/PortFile.java + src/share/classes/com/sun/tools/sjavac/server/SysInfo.java + test/tools/sjavac/SJavac.java From stuart.marks at oracle.com Thu Jan 17 23:43:10 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 17 Jan 2013 23:43:10 +0000 Subject: hg: jdk8/tl/jdk: 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Message-ID: <20130117234322.E862C47395@hg.openjdk.java.net> Changeset: 79fed1733d4a Author: jgish Date: 2013-01-17 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79fed1733d4a 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Summary: Increase number of retries to twice the number of ports in the reserved range Reviewed-by: mduigou ! test/java/rmi/testlibrary/TestLibrary.java From naoto.sato at oracle.com Thu Jan 17 23:53:22 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 17 Jan 2013 15:53:22 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F5F08D.5000008@oracle.com> References: <50F5F08D.5000008@oracle.com> Message-ID: <50F88EF2.5060507@oracle.com> Hi Sherman, Here are my comments on the 310 changes: - java/util/Formatter.java Line 4125: To do a locale neutral case mapping, use Locale.ROOT instead of Locale.US. Line 4161-4169: Remove this as it is commented out. Also "import sun.util.locale.provider.TimeZoneNameUtility" is not needed either. Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is this correct? Should it be Locale.ROOT? - java/time/DayOfWeek.java Line 298-300: Maybe just me, but I thought the convention for "throws" was to consolidate conditions into a single "throws" line for the same exception. - java/time/ZoneOffset.java Line 214: @SuppressWarnings("fallthrough")? - java/time/calendar/ChronoDateImpl.java: In the example in the class description, "%n" should be "\n" for the new lines in the printf()s. - java/time/calendar/HijrahDeviationReader.java Line 224: Is it OK to catch all Exception here, and pretends as if nothing happened? - java/time/calendar/JapaneseChrono.java Line 166-172: How come it includes "Keio"? Isn't the era before "Meiji" "Seireki"? - java/time/calendar/MinguoDate.java Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on this field. - java/time/calendar/ThaiBuddhistDate.java Same as above MinguoDate.java - java/time/format/DateTimeBuilder.java There are several "TODO"s in here. Line 357: It is commented that return value is for ZoneOffset/ZoneId. But since it is public, could this be safe? Can arbitrary app modify it maliciously? - java/time/format/DateTimeFormatSymbols.java Line 131: It should use the default locale for formatting, i.e, Locale.getDefault(Locale.Category.FORMAT) - java/time/format/DateTimeFormatter.java Line 411: DateTimeException needs to be described, as it is thrown in this method. Line 486: The DateTimeException needs to be on @throws clause. - java/time/format/DateTimeFormatterBuilder Line 174: The type for "padNextChar" should be "int" to accommodate supplementary characters. Not only this particular instance, it looks like there are bunch of places that use ++/-- for character iteration. Are they OK? Line 236: "sensitive" -> "insensitive" Line 276: "strict" -> "lenient" Line 1440: use Locale.getDefault(Locale.Category.FORMAT) - java/time/format/DateTimeFormatters.java Line 271, 294, 317, 340: Locale.getDefault() -> Locale.getDefault(Locale.Category), "default locale" -> "default FORMAT locale" - java/time/format/DateTimeParseContext.java Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as an argument? Remember the Turkish 'i' case? - java/time/overview.html Should the contents here be moved to package.html? Should we continue to use "Threeten" name? - java/time/temporal/Chrono.java Line 102: "minguoDate" -> "thaiDate" Line 212: The comment is kind of cryptic. Looks like not "removing" but "registering" - java/time/zone/TzdbZoneRulesProvider.java Line 171: Is it OK to catch all exceptions here and ignore? - sun/tools/tzdb/* Should the compile be moved under "make" directory, instead of "src"? Naoto On 1/15/13 4:13 PM, Xueming Shen wrote: > Hi, > > The Threeten project [1] is planned to be integrated into OpenJDK8 M6 > milestone. > > Here is the webrev > http://cr.openjdk.java.net/~sherman/8003680/webrev > > and the latest javadoc > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Review comments can be sent to the threeten-dev email list [2] and/or > core-libs-dev email list[3]. > > Thanks, > Sherman > > [1] http://openjdk.java.net/projects/threeten > [2] threeten-dev @ openjdk.java.net > [3] core-libs-dev @ openjdk.java.net > > From naoto.sato at oracle.com Thu Jan 17 23:55:46 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 17 Jan 2013 15:55:46 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F5F08D.5000008@oracle.com> References: <50F5F08D.5000008@oracle.com> Message-ID: <50F88F82.40507@oracle.com> Hi Sherman, Here are my comments on the 310 changes: - java/util/Formatter.java Line 4125: To do a locale neutral case mapping, use Locale.ROOT instead of Locale.US. Line 4161-4169: Remove this as it is commented out. Also "import sun.util.locale.provider.TimeZoneNameUtility" is not needed either. Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is this correct? Should it be Locale.ROOT? - java/time/DayOfWeek.java Line 298-300: Maybe just me, but I thought the convention for "throws" was to consolidate conditions into a single "throws" line for the same exception. - java/time/ZoneOffset.java Line 214: @SuppressWarnings("fallthrough")? - java/time/calendar/ChronoDateImpl.java: In the example in the class description, "%n" should be "\n" for the new lines in the printf()s. - java/time/calendar/HijrahDeviationReader.java Line 224: Is it OK to catch all Exception here, and pretends as if nothing happened? - java/time/calendar/JapaneseChrono.java Line 166-172: How come it includes "Keio"? Isn't the era before "Meiji" "Seireki"? - java/time/calendar/MinguoDate.java Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on this field. - java/time/calendar/ThaiBuddhistDate.java Same as above MinguoDate.java - java/time/format/DateTimeBuilder.java There are several "TODO"s in here. Line 357: It is commented that return value is for ZoneOffset/ZoneId. But since it is public, could this be safe? Can arbitrary app modify it maliciously? - java/time/format/DateTimeFormatSymbols.java Line 131: It should use the default locale for formatting, i.e, Locale.getDefault(Locale.Category.FORMAT) - java/time/format/DateTimeFormatter.java Line 411: DateTimeException needs to be described, as it is thrown in this method. Line 486: The DateTimeException needs to be on @throws clause. - java/time/format/DateTimeFormatterBuilder Line 174: The type for "padNextChar" should be "int" to accommodate supplementary characters. Not only this particular instance, it looks like there are bunch of places that use ++/-- for character iteration. Are they OK? Line 236: "sensitive" -> "insensitive" Line 276: "strict" -> "lenient" Line 1440: use Locale.getDefault(Locale.Category.FORMAT) - java/time/format/DateTimeFormatters.java Line 271, 294, 317, 340: Locale.getDefault() -> Locale.getDefault(Locale.Category), "default locale" -> "default FORMAT locale" - java/time/format/DateTimeParseContext.java Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as an argument? Remember the Turkish 'i' case? - java/time/overview.html Should the contents here be moved to package.html? Should we continue to use "Threeten" name? - java/time/temporal/Chrono.java Line 102: "minguoDate" -> "thaiDate" Line 212: The comment is kind of cryptic. Looks like not "removing" but "registering" - java/time/zone/TzdbZoneRulesProvider.java Line 171: Is it OK to catch all exceptions here and ignore? - sun/tools/tzdb/* Should the compile be moved under "make" directory, instead of "src"? Naoto On 1/15/13 4:13 PM, Xueming Shen wrote: > Hi, > > The Threeten project [1] is planned to be integrated into OpenJDK8 M6 > milestone. > > Here is the webrev > http://cr.openjdk.java.net/~sherman/8003680/webrev > > and the latest javadoc > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Review comments can be sent to the threeten-dev email list [2] and/or > core-libs-dev email list[3]. > > Thanks, > Sherman > > [1] http://openjdk.java.net/projects/threeten > [2] threeten-dev @ openjdk.java.net > [3] core-libs-dev @ openjdk.java.net > > From weijun.wang at oracle.com Fri Jan 18 00:22:19 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Jan 2013 08:22:19 +0800 Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder()) In-Reply-To: <50F82EF2.5090401@oracle.com> References: <0d1a18f2-fde9-45de-9af9-e4566b8a7338@default> <50F82EF2.5090401@oracle.com> Message-ID: <50F895BB.1060804@oracle.com> Thanks. Most files end with a new line and having to trim() it before decoding would drive me crazy. Also, the old BASE64Decoder ignores it, so it would be nice to be compatible. -Max On 01/18/2013 01:03 AM, Xueming Shen wrote: > Hi, > > Yes, padding \n (and any non-base64 character) after base64 padding > character > '=' probably should be ignored, instead of exception in mime mode. The > behavior/ > implementation is not consistent now for this case. Will file a cr and > address this, > probably after M6. > > Thanks! > -Sherman > > On 1/17/13 7:02 AM, Mark Sheppard wrote: >> Hi Max, >> >> The fact that the padding characters == and = appear before the >> newline, leads to RFC2045 section 6.8 (pg 25) and how the >> implementation interprets the processing for the pad character in the >> encoding. >> >> As per RFC2045 base64 encoding the occurrence of = indicates end of data. >> That is to say, == or = is only used in the final unit of encoding >> at the very end of the encoded data. >> This raises a couple of questions: >> So is it an error if there are data after these explicit "end of data" >> markers, when they occur? >> should a special case be made for line separators? >> What about ignoring any data after == or = ? >> >> The javadoc for Base64 Mime Encoder/Decoder alludes to the line >> separator and characters >> outside the base64 alphabet being ignored during decoding. This in >> itself can be ambiguously >> interpreted to mean anywhere in the stream, including after an end of >> data indicator, >> unless specific attention and interpretation is give to RFC2045. >> >> Consider the fact that >> >> Base64.getMimeDecoder().decode("AA==B") also throws an exception >> this suggests that the decoder is interpreting data after the >> end of data padding indication as an error. >> >> Thus, a newline after = or == is reasonable interpreted as an error, >> suggesting >> that the exception is reasonable. >> >> It can be noted that Base64.getMimeDecoder().decode("AAAA\n") >> doesn't throw an exception. >> >> regards >> Mark >> >> >> ----- Original Message ----- >> From: weijun.wang at oracle.com >> To: core-libs-dev at openjdk.java.net >> Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, >> Ireland, Portugal >> Subject: And Decoder (was Re: No newline at the end of >> Base64.getMimeEncoder()) >> >> This time on the decoder side: >> >> Base64.getMimeDecoder().decode("AA==\n") >> >> throws an exception because the string ends with a newline. I would >> prefer it be acceptable. >> >> Thanks >> Max >> >> On 01/17/2013 05:12 PM, Weijun Wang wrote: >>> I noticed that the encoding output of Base64.getMimeEncoder() never ends >>> with a newline char. There is no right or wrong on this but it will be >>> nice to write the current behavior into the spec. >>> >>> Thanks >>> Max > From weijun.wang at oracle.com Fri Jan 18 02:07:47 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Jan 2013 10:07:47 +0800 Subject: --enable-sjavac not enabled in tl repo yet? Message-ID: <50F8AE73.8000809@oracle.com> Just tried on a latest jdk8/tl clone and Building Java(TM) for target 'all' in configuration '/space/repos/jdk8/tl/build/linux-x86_64-sjavac' ## Starting langtools Compiling 2 files for BUILD_TOOLS Compiling 26 properties into resource bundles Compiling 720 files for BUILD_BOOTSTRAP_LANGTOOLS Creating langtools/dist/bootstrap/lib/javac.jar Updating langtools/dist/lib/src.zip Creating langtools/dist/bootstrap/lib/javah.jar Creating langtools/dist/bootstrap/lib/javap.jar Compiling BUILD_FULL_JAVAC Creating langtools/dist/bootstrap/lib/javadoc.jar The makefile listed source /space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java was not calculated by the smart javac wrapper! make[1]: *** [/space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/classes/javac_state] Error 255 make[1]: *** Waiting for unfinished jobs.... make: *** [langtools-only] Error 2 Thanks Max From xueming.shen at oracle.com Fri Jan 18 04:55:42 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 17 Jan 2013 20:55:42 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F88F82.40507@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F88F82.40507@oracle.com> Message-ID: <50F8D5CE.6060508@oracle.com> Thanks Naoto! We will see how many we can update tomorrow. Regarding the Locale.ROOT vs Locale.US, it appears we are now using Locale.US in j.u.Formatter for l==null case in existing. (Formatter is earlier than the the 1.6 ROOT). So I may keep the US for now for the consistency. It may be a good small Locale.US cleanup project later. -Sherman On 01/17/2013 03:55 PM, Naoto Sato wrote: > Hi Sherman, > > Here are my comments on the 310 changes: > > > - java/util/Formatter.java > > Line 4125: To do a locale neutral case mapping, use Locale.ROOT instead of Locale.US. > > Line 4161-4169: Remove this as it is commented out. Also "import sun.util.locale.provider.TimeZoneNameUtility" is not needed either. > > Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is this correct? Should it be Locale.ROOT? > > > - java/time/DayOfWeek.java > > Line 298-300: Maybe just me, but I thought the convention for "throws" was to consolidate conditions into a single "throws" line for the same exception. > > > - java/time/ZoneOffset.java > > Line 214: @SuppressWarnings("fallthrough")? > > > - java/time/calendar/ChronoDateImpl.java: > > In the example in the class description, "%n" should be "\n" for the new lines in the printf()s. > > > - java/time/calendar/HijrahDeviationReader.java > > Line 224: Is it OK to catch all Exception here, and pretends as if nothing happened? > > > - java/time/calendar/JapaneseChrono.java > > Line 166-172: How come it includes "Keio"? Isn't the era before "Meiji" "Seireki"? > > > - java/time/calendar/MinguoDate.java > > Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on this field. > > - java/time/calendar/ThaiBuddhistDate.java > > Same as above MinguoDate.java > > - java/time/format/DateTimeBuilder.java > > There are several "TODO"s in here. > > Line 357: It is commented that return value is for ZoneOffset/ZoneId. But since it is public, could this be safe? Can arbitrary app modify it maliciously? > > > - java/time/format/DateTimeFormatSymbols.java > > Line 131: It should use the default locale for formatting, i.e, Locale.getDefault(Locale.Category.FORMAT) > > > - java/time/format/DateTimeFormatter.java > > Line 411: DateTimeException needs to be described, as it is thrown in this method. > > Line 486: The DateTimeException needs to be on @throws clause. > > > - java/time/format/DateTimeFormatterBuilder > > Line 174: The type for "padNextChar" should be "int" to accommodate supplementary characters. Not only this particular instance, it looks like there are bunch of places that use ++/-- for character iteration. Are they OK? > > Line 236: "sensitive" -> "insensitive" > > Line 276: "strict" -> "lenient" > > Line 1440: use Locale.getDefault(Locale.Category.FORMAT) > > > - java/time/format/DateTimeFormatters.java > > Line 271, 294, 317, 340: Locale.getDefault() -> Locale.getDefault(Locale.Category), "default locale" -> "default FORMAT locale" > > > - java/time/format/DateTimeParseContext.java > > Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as an argument? Remember the Turkish 'i' case? > > > - java/time/overview.html > > Should the contents here be moved to package.html? Should we continue to use "Threeten" name? > > > - java/time/temporal/Chrono.java > > Line 102: "minguoDate" -> "thaiDate" > > Line 212: The comment is kind of cryptic. Looks like not "removing" but "registering" > > > - java/time/zone/TzdbZoneRulesProvider.java > > Line 171: Is it OK to catch all exceptions here and ignore? > > > - sun/tools/tzdb/* > > Should the compile be moved under "make" directory, instead of "src"? > > > Naoto > > On 1/15/13 4:13 PM, Xueming Shen wrote: >> Hi, >> >> The Threeten project [1] is planned to be integrated into OpenJDK8 M6 >> milestone. >> >> Here is the webrev >> http://cr.openjdk.java.net/~sherman/8003680/webrev >> >> and the latest javadoc >> http://cr.openjdk.java.net/~sherman/8003680/javadoc >> >> Review comments can be sent to the threeten-dev email list [2] and/or >> core-libs-dev email list[3]. >> >> Thanks, >> Sherman >> >> [1] http://openjdk.java.net/projects/threeten >> [2] threeten-dev @ openjdk.java.net >> [3] core-libs-dev @ openjdk.java.net >> >> > From fredrik.ohrstrom at oracle.com Fri Jan 18 06:58:39 2013 From: fredrik.ohrstrom at oracle.com (=?iso-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 18 Jan 2013 07:58:39 +0100 Subject: --enable-sjavac not enabled in tl repo yet? In-Reply-To: <50F8AE73.8000809@oracle.com> References: <50F8AE73.8000809@oracle.com> Message-ID: <88BFD301-5CC2-4878-8185-44C55F7639BF@oracle.com> 18 jan 2013 kl. 03:07 skrev Weijun Wang: > Just tried on a latest jdk8/tl clone and > The makefile listed source /space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java was not calculated by the smart javac Ok, as the old saying goes, this works for me.... :-) So could you please tar up your build directory and email it to me? As for the error message, since the build system has to handle building with javac as well as with sjavac, the logic for finding which java files to compile, is implemented both in make and in java (sjavac). Sjavac has the option: --compare-found-sources file_with_list_of_files which is used to make sjavac compare its own calculated list of source files with the list supplied by make. If they differ, you will get the error message > was not calculated by the smart javac So why do we need to calculate the files to be compiled? Is it not just compiling the required source roots? For example like this? sjavac src/share/classes src/posix/classes src/linux/classes -d bin Lets say, that we have an opportunity to organize the source in this way. At the moment for example, when build the OpenJDK the snmp classes have to be excluded, thus the compile command looks more like: sjavac -x sun.management.snmp.* src/share/classes -d bin (In make the same calculation is handled by find and grep and sed et al.) The full filtering rules for compiling the main jdk looks like this: sjavac -x com.sun.pept.* -x com.sun.tools.example.trace.* -x com.sun.tools.example.debug.bdi.* -x com.sun.tools.example.debug.event.* -x com.sun.tools.example.debug.gui.* -x sun.dc.* -x com.sun.jmx.snmp.* -x sun.management.snmp.* -x com.sun.script.* -x com.oracle.security.* -x sun.java2d.cmm.kcms.* -xf *SolarisAclFileAttributeView.java -xf *SolarisFileStore.java -xf *SolarisFileSystem.java -xf *SolarisFileSystemProvider.java -xf *SolarisNativeDispatcher.java -xf *SolarisUserDefinedFileAttributeView.java -xf *SolarisWatchService.java -xf *SolarisAclFileAttributeView.java -xf *SolarisLoginModule.java -xf *SolarisSystem.java -xf *sun/nio/ch/DevPollArrayWrapper.java -xf *sun/nio/ch/DevPollSelectorImpl.java -xf *sun/nio/ch/DevPollSelectorProvider.java -xf *sun/nio/ch/EventPortSelectorImpl.java -xf *sun/nio/ch/EventPortSelectorProvider.java -xf *sun/nio/ch/EventPortWrapper.java -xf *sun/nio/ch/SolarisAsynchronousChannelProvider.java -xf *sun/nio/ch/SolarisEventPort.java -xf *sun/tools/attach/SolarisAttachProvider.java -xf *sun/tools/attach/SolarisVirtualMachine.java -xf *WrapperGenerator.java -xf *NTLoginModule.java -xf *NTSystem.java -xf *sun/nio/ch/BsdAsynchronousChannelProvider.java -xf *sun/nio/ch/KQueue.java -xf *sun/nio/ch/KQueuePort.java -xf *sun/nio/fs/BsdFileStore.java -xf *sun/nio/fs/BsdFileSystem.java -xf *sun/nio/fs/BsdFileSystemProvider.java -xf *sun/nio/fs/BsdNativeDispatcher.java -xf *sun/nio/fs/MacOSXFileSystemProvider.java -xf *sun/nio/fs/MacOSXFileSystem.java -xf *sun/nio/fs/MacOSXNativeDispatcher.java -xf *sun/tools/attach/BsdAttachProvider.java -xf *sun/tools/attach/BsdVirtualMachine.java -xf *sun/text/resources/BreakIteratorRules.java -xf *sun/text/resources/BreakIteratorRules_th.java -xf *sun/awt/AWTCharset.java -xf *sun/awt/X11/ScreenFormat.java -xf *sun/awt/X11/XArc.java -xf *sun/awt/X11/XChar2b.java -xf *sun/awt/X11/XCharStruct.java -xf *sun/awt/X11/XClassHint.java -xf *sun/awt/X11/XComposeStatus.java -xf *sun/awt/X11/XExtCodes.java -xf *sun/awt/X11/XFontProp.java -xf *sun/awt/X11/XFontSetExtents.java -xf *sun/awt/X11/XFontStruct.java -xf *sun/awt/X11/XGCValues.java -xf *sun/awt/X11/XHostAddress.java -xf *sun/awt/X11/XIMCallback.java -xf *sun/awt/X11/XIMHotKeyTrigger.java -xf *sun/awt/X11/XIMHotKeyTriggers.java -xf *sun/awt/X11/XIMPreeditCaretCallbackStruct.java -xf *sun/awt/X11/XIMPreeditDrawCallbackStruct.java -xf *sun/awt/X11/XIMPreeditStateNotifyCallbackStruct.java -xf *sun/awt/X11/XIMStatusDrawCallbackStruct.java -xf *sun/awt/X11/XIMStringConversionCallbackStruct.java -xf *sun/awt/X11/XIMStringConversionText.java -xf *sun/awt/X11/XIMStyles.java -xf *sun/awt/X11/XIMText.java -xf *sun/awt/X11/XIMValuesList.java -xf *sun/awt/X11/XImage.java -xf *sun/awt/X11/XKeyboardControl.java -xf *sun/awt/X11/XKeyboardState.java -xf *sun/awt/X11/XOMCharSetList.java -xf *sun/awt/X11/XOMFontInfo.java -xf *sun/awt/X11/XOMOrientation.java -xf *sun/awt/X11/XPoint.java -xf *sun/awt/X11/XRectangle.java -xf *sun/awt/X11/XSegment.java -xf *sun/awt/X11/XStandardColormap.java -xf *sun/awt/X11/XTextItem.java -xf *sun/awt/X11/XTextItem16.java -xf *sun/awt/X11/XTextProperty.java -xf *sun/awt/X11/XTimeCoord.java -xf *sun/awt/X11/XWindowChanges.java -xf *sun/awt/X11/XdbeSwapInfo.java -xf *sun/awt/X11/XmbTextItem.java -xf *sun/awt/X11/XwcTextItem.java -xf *sun/util/locale/AsciiUtil.java -xf *sun/nio/fs/PollingWatchService.java -xf *-linux-arm.java -xf *-linux-ppc.java -xf *javax/swing/plaf/nimbus/InternalFrameTitlePanePainter.java -xf *javax/swing/plaf/nimbus/OptionPaneMessageAreaPainter.java -xf *javax/swing/plaf/nimbus/ScrollBarPainter.java -xf *javax/swing/plaf/nimbus/SliderPainter.java -xf *javax/swing/plaf/nimbus/SpinnerPainter.java -xf *javax/swing/plaf/nimbus/SplitPanePainter.java -xf *javax/swing/plaf/nimbus/TabbedPanePainter.java -src "/home/fohrstro/jdk8/jdk/src/share/classes:/home/fohrstro/jdk8/jdk/src/solaris/classes:/home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/gensrc:/home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/gensrc_no_srczip" -bootclasspath /home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/classes -source 8 -target 8 -encoding ascii -XDignore.symbol.file=true -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally -h /home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/gensrc_headers -d /home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/classes From joe.darcy at oracle.com Fri Jan 18 07:07:08 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Jan 2013 23:07:08 -0800 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F2EF3B.8070008@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F0F128.5060000@oracle.com> <50F1AD23.3010604@oracle.com> <50F2EF3B.8070008@oracle.com> Message-ID: <50F8F49C.6050509@oracle.com> On 1/13/2013 9:30 AM, Eric McCorkle wrote: > On 01/12/13 13:36, Joe Darcy wrote: >> Hi Eric, >> >> On 1/11/2013 9:14 PM, Eric McCorkle wrote: >>> I got halfway through implementing a change that would synthesize >>> Parameter's for the static links (this for the inner classes), when it >>> occurred to me: is there really a case for allowing reflection on those >>> parameters. >>> >>> Put another way, >>> >>> public class Foo { >>> public class Bar { >>> int baz(int qux) { } >>> } >>> } >>> >>> Should baz.getParameters() return just qux, or should it expose >>> Foo.this? On second thought, I can't think of a good reason why you >>> *want* to reflect on Foo.this. >> You need to reflect on that parameter so you can call the constructor >> properly using reflection :-) >> > Alright, I will make the logic changes and post for review. > >>> Also, the logic is much simpler. You just have to figure out how deep >>> you are in inner classes, store that information somewhere, and offset >>> by that much every time a Parameter calls back to its Executable to get >>> information. The logic for synthesizing the this parameters is much >>> more complex. >>> >>> Thoughts? >> We may need some more help from javac to mark parameters as synthesized >> or synthetic, which can be done as follow-up work. For inner classes >> that are members of types, the outer this parameters are required to be >> a certain way by the platform specification to make linkage work. >> *However*, local and anonymous classes only have to obey a compiler's >> contract with itself and are not specified. In particular, not all such >> inner classes constructors even have an outer this parameter. For >> example, with javac the constructor of an anonymous class in a static >> initializer will *not* have an other this parameter. >> > Is there any compelling reason that javac should generate information > about the link parameters? They don't have a name, and have standard > modifiers (presumably final and synthesized). It seems to me they ought > to be synthesized by the reflection API. Not all class files come from Java compilers of course and since core reflection implicitly acts on a class file level model rather than a source-level model, generally it is preferable (and in keeping with past practice) for core reflection to not try to get too clever in inferring missing information. -Joe From weijun.wang at oracle.com Fri Jan 18 08:45:45 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 18 Jan 2013 16:45:45 +0800 Subject: --enable-sjavac not enabled in tl repo yet? In-Reply-To: <88BFD301-5CC2-4878-8185-44C55F7639BF@oracle.com> References: <50F8AE73.8000809@oracle.com> <88BFD301-5CC2-4878-8185-44C55F7639BF@oracle.com> Message-ID: <50F90BB9.3060600@oracle.com> On 01/18/2013 02:58 PM, Fredrik ?hrstr?m wrote: > 18 jan 2013 kl. 03:07 skrev Weijun Wang: > >> Just tried on a latest jdk8/tl clone and >> The makefile listed source /space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java was not calculated by the smart javac > > > Ok, as the old saying goes, this works for me.... :-) So could you please tar up your build directory and email it to me? I just find something interesting. /space on my machine is a symlink to /home/more/space. If I cd to /home/more/space/repos/jdk8/tl/build/linux-x86_64-sjavac and configure/make there, everything is fine. Do you still need the tar? It's already 28MB when the failure happens. Thanks Max > > As for the error message, since the build system has to handle building with javac as well as with sjavac, the logic for finding which java > files to compile, is implemented both in make and in java (sjavac). Sjavac has the option: > --compare-found-sources file_with_list_of_files > which is used to make sjavac compare its own calculated list of source files with the list supplied by make. > If they differ, you will get the error message >> was not calculated by the smart javac > > > So why do we need to calculate the files to be compiled? Is it not just > compiling the required source roots? For example like this? > > sjavac src/share/classes src/posix/classes src/linux/classes -d bin > > Lets say, that we have an opportunity to organize the source in this way. > At the moment for example, when build the OpenJDK the snmp classes have to be excluded, > thus the compile command looks more like: > sjavac -x sun.management.snmp.* src/share/classes -d bin > > (In make the same calculation is handled by find and grep and sed et al.) > > The full filtering rules for compiling the main jdk looks like this: > > sjavac -x com.sun.pept.* -x com.sun.tools.example.trace.* -x com.sun.tools.example.debug.bdi.* -x com.sun.tools.example.debug.event.* -x com.sun.tools.example.debug.gui.* -x sun.dc.* -x com.sun.jmx.snmp.* -x sun.management.snmp.* -x com.sun.script.* -x com.oracle.security.* -x sun.java2d.cmm.kcms.* -xf *SolarisAclFileAttributeView.java -xf *SolarisFileStore.java -xf *SolarisFileSystem.java -xf *SolarisFileSystemProvider.java -xf *SolarisNativeDispatcher.java -xf *SolarisUserDefinedFileAttributeView.java -xf *SolarisWatchService.java -xf *SolarisAclFileAttributeView.java -xf *SolarisLoginModule.java -xf *SolarisSystem.java -xf *sun/nio/ch/DevPollArrayWrapper.java -xf *sun/nio/ch/DevPollSelectorImpl.java -xf *sun/nio/ch/DevPollSelectorProvider.java -xf *sun/nio/ch/EventPortSelectorImpl.java -xf *sun/nio/ch/EventPortSelectorProvider.java -xf *sun/nio/ch/EventPortWrapper.java -xf *sun/nio/ch/SolarisAsynchronousChannelProvider.java -xf *sun/nio/ch/SolarisEventPort.java -xf *su! n/tools/at tach/SolarisAttachProvider.java -xf *sun/tools/attach/SolarisVirtualMachine.java -xf *WrapperGenerator.java -xf *NTLoginModule.java -xf *NTSystem.java -xf *sun/nio/ch/BsdAsynchronousChannelProvider.java -xf *sun/nio/ch/KQueue.java -xf *sun/nio/ch/KQueuePort.java -xf *sun/nio/fs/BsdFileStore.java -xf *sun/nio/fs/BsdFileSystem.java -xf *sun/nio/fs/BsdFileSystemProvider.java -xf *sun/nio/fs/BsdNativeDispatcher.java -xf *sun/nio/fs/MacOSXFileSystemProvider.java -xf *sun/nio/fs/MacOSXFileSystem.java -xf *sun/nio/fs/MacOSXNativeDispatcher.java -xf *sun/tools/attach/BsdAttachProvider.java -xf *sun/tools/attach/BsdVirtualMachine.java -xf *sun/text/resources/BreakIteratorRules.java -xf *sun/text/resources/BreakIteratorRules_th.java -xf *sun/awt/AWTCharset.java -xf *sun/awt/X11/ScreenFormat.java -xf *sun/awt/X11/XArc.java -xf *sun/awt/X11/XChar2b.java -xf *sun/awt/X11/XCharStruct.java -xf *sun/awt/X11/XClassHint.java -xf *sun/awt/X11/XComposeStatus.java -xf *sun/awt/X11/XExtCodes.java! -xf *sun/ awt/X11/XFontProp.java -xf *sun/awt/X11/XFontSetExtents.java -xf *sun/awt/X11/XFontStruct.java -xf *sun/awt/X11/XGCValues.java -xf *sun/awt/X11/XHostAddress.java -xf *sun/awt/X11/XIMCallback.java -xf *sun/awt/X11/XIMHotKeyTrigger.java -xf *sun/awt/X11/XIMHotKeyTriggers.java -xf *sun/awt/X11/XIMPreeditCaretCallbackStruct.java -xf *sun/awt/X11/XIMPreeditDrawCallbackStruct.java -xf *sun/awt/X11/XIMPreeditStateNotifyCallbackStruct.java -xf *sun/awt/X11/XIMStatusDrawCallbackStruct.java -xf *sun/awt/X11/XIMStringConversionCallbackStruct.java -xf *sun/awt/X11/XIMStringConversionText.java -xf *sun/awt/X11/XIMStyles.java -xf *sun/awt/X11/XIMText.java -xf *sun/awt/X11/XIMValuesList.java -xf *sun/awt/X11/XImage.java -xf *sun/awt/X11/XKeyboardControl.java -xf *sun/awt/X11/XKeyboardState.java -xf *sun/awt/X11/XOMCharSetList.java -xf *sun/awt/X11/XOMFontInfo.java -xf *sun/awt/X11/XOMOrientation.java -xf *sun/awt/X11/XPoint.java -xf *sun/awt/X11/XRectangle.java -xf *sun/awt/X11/XSegment.ja! va -xf *su n/awt/X11/XStandardColormap.java -xf *sun/awt/X11/XTextItem.java -xf *sun/awt/X11/XTextItem16.java -xf *sun/awt/X11/XTextProperty.java -xf *sun/awt/X11/XTimeCoord.java -xf *sun/awt/X11/XWindowChanges.java -xf *sun/awt/X11/XdbeSwapInfo.java -xf *sun/awt/X11/XmbTextItem.java -xf *sun/awt/X11/XwcTextItem.java -xf *sun/util/locale/AsciiUtil.java -xf *sun/nio/fs/PollingWatchService.java -xf *-linux-arm.java -xf *-linux-ppc.java -xf *javax/swing/plaf/nimbus/InternalFrameTitlePanePainter.java -xf *javax/swing/plaf/nimbus/OptionPaneMessageAreaPainter.java -xf *javax/swing/plaf/nimbus/ScrollBarPainter.java -xf *javax/swing/plaf/nimbus/SliderPainter.java -xf *javax/swing/plaf/nimbus/SpinnerPainter.java -xf *javax/swing/plaf/nimbus/SplitPanePainter.java -xf *javax/swing/plaf/nimbus/TabbedPanePainter.java -src "/home/fohrstro/jdk8/jdk/src/share/classes:/home/fohrstro/jdk8/jdk/src/solaris/classes:/home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/gensrc:/home/fohrstro/jdk8! /build/lin ux-x86_64-normal-server-release/jdk/gensrc_no_srczip" > -bootclasspath /home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/classes > -source 8 -target 8 -encoding ascii -XDignore.symbol.file=true -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > -h /home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/gensrc_headers > -d /home/fohrstro/jdk8/build/linux-x86_64-normal-server-release/jdk/classes > From bharadwaj.yadavalli at oracle.com Fri Jan 18 14:37:17 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 18 Jan 2013 09:37:17 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F6F303.3000504@oracle.com> References: <50F6F303.3000504@oracle.com> Message-ID: <50F95E1D.7050202@oracle.com> Thanks to Remi, Dean and Karen for looking at the code changes. Upon further contemplation, it seems to me that my initial proposed change (http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/) *might* incorrectly trust bytecode in methods that were *not* VM generated and flag it as legal. So, I have implemented, IMHO, a more robust/correct way to handle verification of methods generated by the VM in the old verifier. This change is consistent with the way verification done on such methods in the (new) split verifier (which I think is appropriate). The new changes are in hotspot and jdk trees. Please review the 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/ I ran JCK tests (vm, lang completed; api running), runThese and vm.quicklist with no regressions. Thanks, Bharadwaj On 1/16/2013 1:35 PM, Bharadwaj Yadavalli wrote: > Please review the change at > http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ > > Default interface methods are new in Java 8. VM creates overpass > methods in the vtable slots of classes to invoke a default method > using invokespecial. > > Consequently, invocation of default interface methods (i.e., overpass > methods in the VM) via invokespecial is legal and should not be > flagged as illegal. > > In short, this change allows invocation of default methods of Java 8 > using invokespecial. > > I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new > failures. > > Thanks, > > Bharadwaj > From karen.kinnear at oracle.com Fri Jan 18 15:15:54 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 18 Jan 2013 10:15:54 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <50F95E1D.7050202@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> Message-ID: <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> Bharadwaj, Makes me glad Remi brought up his concerns :-) 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. That also might be still useful if we were to add additional vm generated methods in future which are not specifically normal vs overpass. thanks, Karen On Jan 18, 2013, at 9:37 AM, Bharadwaj Yadavalli wrote: > Thanks to Remi, Dean and Karen for looking at the code changes. > > Upon further contemplation, it seems to me that my initial proposed change (http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/) *might* incorrectly trust bytecode in methods that were *not* VM generated and flag it as legal. > > So, I have implemented, IMHO, a more robust/correct way to handle verification of methods generated by the VM in the old verifier. This change is consistent with the way verification done on such methods in the (new) split verifier (which I think is appropriate). > > The new changes are in hotspot and jdk trees. > > Please review the 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/ > > I ran JCK tests (vm, lang completed; api running), runThese and vm.quicklist with no regressions. > > Thanks, > > Bharadwaj > > On 1/16/2013 1:35 PM, Bharadwaj Yadavalli wrote: >> Please review the change at http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/ >> >> Default interface methods are new in Java 8. VM creates overpass methods in the vtable slots of classes to invoke a default method using invokespecial. >> >> Consequently, invocation of default interface methods (i.e., overpass methods in the VM) via invokespecial is legal and should not be flagged as illegal. >> >> In short, this change allows invocation of default methods of Java 8 using invokespecial. >> >> I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new failures. >> >> Thanks, >> >> Bharadwaj >> From alexey.utkin at oracle.com Fri Jan 18 15:30:59 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 18 Jan 2013 19:30:59 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly Message-ID: <50F96AB3.4000207@oracle.com> Hi Everyone, Please review the fix. Bug description: https://jbs.oracle.com/bugs/browse/JDK-6519127 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.02/ 1] The registry branch was removed from the code as obsolete. It was actual only for Windows 95 M3 Beta. This approach is obsolete and is not supported by MS for decades. [http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx] For compatibility reasons the Registry path "HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" is filling ones and is not supported in actual state. Even more, in case of execute-as-service, impersonation, and "RunAs" call, User Registry hive could be unloaded or be outsider. That fix should resolve the bunch of corner-case problems with impersonation and migration. 2] KF_FLAG_CREATE and CSIDL_FLAG_CREATE need to be use is case, than Java application is applied as Administrative Tool for Users management. Potentially the Java call could be the first profile request. For the case the real folder need to be created in time. 3] __try/__except trick for potentially absent DLL entry is known and successfully used in AWT. That simplifies code and checks function signatures on link time. 4] Function [GetJavaProperties] was changed for better "initialization-finished" condition checking in low-risky raise condition. 5] The pre-requirements for JDK build includes section "Windows i586: Microsoft Visual Studio 2010 Compilers" about installed Windows SDK v 7.0a or later. That includes actual headers for Shell Lib version 6.0.6000 with [SHGetKnownFolderPath] entry. http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.htmll#msvc32 Regards, -uta From Alan.Bateman at oracle.com Fri Jan 18 15:41:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Jan 2013 15:41:25 +0000 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50F96AB3.4000207@oracle.com> References: <50F96AB3.4000207@oracle.com> Message-ID: <50F96D25.8000308@oracle.com> On 18/01/2013 15:30, Alexey Utkin wrote: > Hi Everyone, > Please review the fix. > > Bug description: > https://jbs.oracle.com/bugs/browse/JDK-6519127 > > Here is the suggested fix: > > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.02/ Sean Chou also sent a proposed for this one a few months ago. Clearly we need to update this code but there is a concern that changing it will break somebody (as there has often been ambiguity as to where the user's home directory is). Can you summarize the difference in the approach and also explain what the potential compatibility issues/differences are? -Alan From maurizio.cimadamore at oracle.com Fri Jan 18 15:58:03 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 18 Jan 2013 15:58:03 +0000 Subject: hg: jdk8/tl/langtools: 8006561: Langtools test failure: missing diags/examples Message-ID: <20130118155811.3B471473BF@hg.openjdk.java.net> Changeset: 3d84ae209919 Author: mcimadamore Date: 2013-01-18 15:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d84ae209919 8006561: Langtools test failure: missing diags/examples Summary: forgot to hg add tests Reviewed-by: jjg + test/tools/javac/diags/examples/UnderscoreAsIdentifier.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.out From oehrstroem at gmail.com Fri Jan 18 09:20:04 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 18 Jan 2013 10:20:04 +0100 Subject: --enable-sjavac not enabled in tl repo yet? In-Reply-To: <50F90BB9.3060600@oracle.com> References: <50F8AE73.8000809@oracle.com> <88BFD301-5CC2-4878-8185-44C55F7639BF@oracle.com> <50F90BB9.3060600@oracle.com> Message-ID: 2013/1/18 Weijun Wang : > I just find something interesting. /space on my machine is a symlink to > /home/more/space. If I cd to > /home/more/space/repos/jdk8/tl/build/linux-x86_64-sjavac and configure/make > there, everything is fine. Ah, then sjavac is probably doing canonical or absolute on the paths, thus the makefile list will look different even though they point to the same files. That should be easy to fix! Thanks for the bug report! > > Do you still need the tar? It's already 28MB when the failure happens. No. //Fredrik From alexey.utkin at oracle.com Fri Jan 18 16:40:29 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 18 Jan 2013 20:40:29 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50F96D25.8000308@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> Message-ID: <50F97AFD.20800@oracle.com> On 18.01.2013 19:41, Alan Bateman wrote: > On 18/01/2013 15:30, Alexey Utkin wrote: >> Hi Everyone, >> Please review the fix. >> >> Bug description: >> https://jbs.oracle.com/bugs/browse/JDK-6519127 >> >> Here is the suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.02/ > Sean Chou also sent a proposed for this one a few months ago. Clearly > we need to update this code but there is a concern that changing it > will break somebody (as there has often been ambiguity as to where the > user's home directory is). Can you summarize the difference in the > approach and also explain what the potential compatibility > issues/differences are? > > -Alan The main difference is that after the fix Java becomes the program that could be certified by MS as Vista comparable. Java would support the dynamic user profiles and follow the changes in Windows OS policy (profiles migration). Java would able to support long home directories (Windows API migrates from limited-length paths, that were the FAT FS limitation, to unlimited-length paths). The only compatibility issues could happen on the systems that uses Registry-based redirection by the way that was reserved for Java property define switch -Duser.home=XXXX. I would like repeat it again: after the fix Java becomes Vista comparable program, that catch up changes from Windows OS management tools. For the special cases we have compatibility solution: Java define for "user.home" property. From MS point of view the User's home directory could not be used directly for data storage. The specialized [Document], [Downloand], and etc. sub-folders need to be used. Often configs are stored in [.XXXX] sub-folders. That does not make MS happy, but that is common practice for cross-platform tools. On that field Java plays together with SSH, cygwin, Firefox, Netbeans and all other well-known products. The behavior could not be easily change (MS would happy to move configs into [AppData\Local] sub-folder, but it is not a Java problem). Regards, -uta From chris.hegarty at oracle.com Fri Jan 18 17:36:01 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 18 Jan 2013 17:36:01 +0000 Subject: hg: jdk8/tl/jdk: 8005120: Compiler warnings in socket transport native code Message-ID: <20130118173649.6DD71473CC@hg.openjdk.java.net> Changeset: f88e963960ae Author: jzavgren Date: 2013-01-18 17:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f88e963960ae 8005120: Compiler warnings in socket transport native code Reviewed-by: chegar, dsamersoff ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.c From bharadwaj.yadavalli at oracle.com Fri Jan 18 17:45:34 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 18 Jan 2013 12:45:34 -0500 Subject: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call In-Reply-To: <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> References: <50F6F303.3000504@oracle.com> <50F95E1D.7050202@oracle.com> <9A41FC71-08B0-4F93-98B7-E3FDF4B392D1@oracle.com> Message-ID: <50F98A3E.3090705@oracle.com> 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 From vladimir.kozlov at oracle.com Fri Jan 18 18:26:05 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Jan 2013 10:26:05 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F77DB7.50806@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> Message-ID: <50F993BD.5020607@oracle.com> Here are Hotspot changes with new jtreg test: http://cr.openjdk.java.net/~kvn/6896617/webrev New ideal node EncodeArray was added for the intrinsic. It is main change since it touches all places in C2. Also fixed Assembler::vptest(xmm, adr) encoding (currently it is not used). Tested with jdk regression nio test, compiler jtreg tests, ctw. Thanks, Vladimir On 1/16/13 8:27 PM, Vladimir Kozlov wrote: > On 1/12/13 12:37 AM, Ulf Zibis wrote: >> Am 11.01.2013 23:53, schrieb Christian Thalinger: >>> But you guys noticed that sentence in the initial review request, right? >>> >>> "Move encoding loop into separate method for which VM will use >>> intrinsic on x86." >>> >>> Just wanted to make sure ;-) >> >> Good question Christian! >> >> This is, how it shows up to me: >> 1) The bug synopsis is unspecific about intrinsc, so ... >> 2) the mentioned 1st sentence could be one of many solutions. >> 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is >> not available. > > I opened it, should show up in few days. > >> 4) What specific operation should be done by the intrinsic, i.e. is >> there a fixed API for that method ??? > > When C2 (server JIT compiler in JVM) compiles encode methods it will > replace new method encodeArray() (matched by signature) with hand > optimized assembler code which uses latest processor instructions. I > will send Hotspot changes soon. So it is nothing to do with interpreter > or bytecode sequence. > >> 5) Can an intrinsic write back more than 1 value (see my hack via int[] >> p) ? >> 6) Vladimir's webrev shows an integer as return type for that method, >> I've added a variant with boolean return type, and the code from my last >> approach could be transformed to a method with Object return type. > > Here is latest webrev, I added caching arrayOffset() call results: > > http://cr.openjdk.java.net/~kvn/6896617_jdk/webrev.01 > > I tested it with java nio regression/verification tests. I am done with > java part and will not accept any more changes except if someone find a > bug in it. > >> >> ... so waiting for Vladimir's feedback :-[ >> (especially on performance/hsdis results) > > Performance on x86 tested with next code (whole test will be in Hotspot > changes) : > > ba = CharBuffer.wrap(a); > bb = ByteBuffer.wrap(b); > long start = System.currentTimeMillis(); > for (int i = 0; i < 1000000; i++) { > ba.clear(); bb.clear(); > enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); > } > long end = System.currentTimeMillis(); > > 1 - current java code > 2 - new encodeArray() with loop but without intrinsic (JIT compiled code) > 3 - using assembler intrinsic for encodeArray() on cpu without SSE4.2 > 4 - using assembler intrinsic on cpu with SSE4.2 > 5 - using assembler intrinsic on cpu with AVX2 > > size: 1 time: 40 34 28 28 28 > size: 7 time: 47 40 33 33 34 > size: 8 time: 51 41 33 28 29 > size: 16 time: 58 45 37 29 29 > size: 32 time: 72 56 44 30 29 > size: 64 time: 103 71 62 32 31 > size: 128 time: 160 105 89 36 33 > size: 256 time: 284 178 141 42 37 > size: 512 time: 514 317 246 61 50 > size: 1024 time: 987 599 458 89 68 > size: 2048 time: 1930 1150 853 145 114 > size: 4096 time: 3820 2283 1645 264 207 > > > Thanks, > Vladimir > >> >> (Can someone push the bug to the public?) >> >> -Ulf From Roger.Riggs at oracle.com Fri Jan 18 18:36:01 2013 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 18 Jan 2013 13:36:01 -0500 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F88F82.40507@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F88F82.40507@oracle.com> Message-ID: <50F99611.2050805@oracle.com> Hi Naoto, Thank you for the review, comments inline. Some issues are still to be addressed. On 1/17/2013 6:55 PM, Naoto Sato wrote: > Hi Sherman, > > Here are my comments on the 310 changes: > > > - java/util/Formatter.java > > Line 4125: To do a locale neutral case mapping, use Locale.ROOT > instead of Locale.US. > > Line 4161-4169: Remove this as it is commented out. Also "import > sun.util.locale.provider.TimeZoneNameUtility" is not needed either. > > Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is > this correct? Should it be Locale.ROOT? > > > - java/time/DayOfWeek.java > > Line 298-300: Maybe just me, but I thought the convention for "throws" > was to consolidate conditions into a single "throws" line for the same > exception. This style is used by JSR 310 and will need to be reconciled with the JDK before release. > > > - java/time/ZoneOffset.java > > Line 214: @SuppressWarnings("fallthrough")? intentional; fixed with @SuppressWarnings > > > - java/time/calendar/ChronoDateImpl.java: > > In the example in the class description, "%n" should be "\n" for the > new lines in the printf()s. According to java.util.Format %n is the platform specific line separator. "\n" would, I expect, work just as well. > > > - java/time/calendar/HijrahDeviationReader.java > > Line 224: Is it OK to catch all Exception here, and pretends as if > nothing happened? That check is an optimization of the library path. Even if it fails, the file will be checked with the unoptimized library path. What is the convention for reporting configuration errors? It might be applicable in this case. > > > - java/time/calendar/JapaneseChrono.java > > Line 166-172: How come it includes "Keio"? Isn't the era before > "Meiji" "Seireki"? Those resources are unused and should be removed. The Era names are provided by the JapaneseEra class. > > > - java/time/calendar/MinguoDate.java > > Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on > this field. \ The @serial and readObject in JapaneseDate is out of date, the serialized form for all of ChronoLocalDates use writeReplace to put an instance of "Ser" in the stream. > > - java/time/calendar/ThaiBuddhistDate.java > > Same as above MinguoDate.java Same as MinguoDate > > - java/time/format/DateTimeBuilder.java > > There are several "TODO"s in here. DateTimeBuilder is in the process of being redesigned and will be updated for M7. > > Line 357: It is commented that return value is for ZoneOffset/ZoneId. > But since it is public, could this be safe? Can arbitrary app modify > it maliciously? DateTimeBuilder is a working context for resolving individual fields during parsing. Its instances are short lived and not shared. > > > - java/time/format/DateTimeFormatSymbols.java > > Line 131: It should use the default locale for formatting, i.e, > Locale.getDefault(Locale.Category.FORMAT) > > > - java/time/format/DateTimeFormatter.java > > Line 411: DateTimeException needs to be described, as it is thrown in > this method. added > > Line 486: The DateTimeException needs to be on @throws clause. added > > > - java/time/format/DateTimeFormatterBuilder > > Line 174: The type for "padNextChar" should be "int" to accommodate > supplementary characters. Not only this particular instance, it looks > like there are bunch of places that use ++/-- for character iteration. > Are they OK? > > Line 236: "sensitive" -> "insensitive" > > Line 276: "strict" -> "lenient" > > Line 1440: use Locale.getDefault(Locale.Category.FORMAT) > > > - java/time/format/DateTimeFormatters.java > > Line 271, 294, 317, 340: Locale.getDefault() -> > Locale.getDefault(Locale.Category), "default locale" -> "default > FORMAT locale" > > > - java/time/format/DateTimeParseContext.java > > Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as > an argument? Remember the Turkish 'i' case? > > > - java/time/overview.html > > Should the contents here be moved to package.html? Should we continue > to use "Threeten" name? The overview.html is present only for the JSR 310 Public Review as an overview of the API and will not be present in the JDK. Most of its contents have been integrated into java.time package javadoc. > > > - java/time/temporal/Chrono.java > > Line 102: "minguoDate" -> "thaiDate" fixed > > Line 212: The comment is kind of cryptic. Looks like not "removing" > but "registering" Corrected. > > > - java/time/zone/TzdbZoneRulesProvider.java > > Line 171: Is it OK to catch all exceptions here and ignore? Similar to the treatment in HijrahDeviationReader; the library path optimization may fail but the file checks are done later. > > > - sun/tools/tzdb/* > > Should the compile be moved under "make" directory, instead of "src"? > > > Naoto > > On 1/15/13 4:13 PM, Xueming Shen wrote: >> Hi, >> >> The Threeten project [1] is planned to be integrated into OpenJDK8 M6 >> milestone. >> >> Here is the webrev >> http://cr.openjdk.java.net/~sherman/8003680/webrev >> >> and the latest javadoc >> http://cr.openjdk.java.net/~sherman/8003680/javadoc >> >> Review comments can be sent to the threeten-dev email list [2] and/or >> core-libs-dev email list[3]. >> >> Thanks, >> Sherman >> >> [1] http://openjdk.java.net/projects/threeten >> [2] threeten-dev @ openjdk.java.net >> [3] core-libs-dev @ openjdk.java.net >> >> > From alan.bateman at oracle.com Fri Jan 18 18:50:49 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 18 Jan 2013 18:50:49 +0000 Subject: hg: jdk8/tl/jdk: 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Message-ID: <20130118185127.5897A473D5@hg.openjdk.java.net> Changeset: 06da87777d0e Author: alanb Date: 2013-01-18 18:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06da87777d0e 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java From iris.clark at oracle.com Fri Jan 18 19:30:46 2013 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Jan 2013 11:30:46 -0800 (PST) Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50F96AB3.4000207@oracle.com> References: <50F96AB3.4000207@oracle.com> Message-ID: <75ecd41a-eb88-4354-b939-c6007587ec8a@default> Publically accessible URL for this bug description (since this is going to a public mailing list): http://bugs.sun.com/view_bug.do?bug_id=6519127 -----Original Message----- From: Alexey Utkin Sent: Friday, January 18, 2013 7:31 AM To: core-libs-dev; Alan Bateman Subject: Review request: JDK-6519127 Vista: user.home property not set correctly Hi Everyone, Please review the fix. Bug description: https://jbs.oracle.com/bugs/browse/JDK-6519127 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.02/ 1] The registry branch was removed from the code as obsolete. It was actual only for Windows 95 M3 Beta. This approach is obsolete and is not supported by MS for decades. [http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx] For compatibility reasons the Registry path "HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" is filling ones and is not supported in actual state. Even more, in case of execute-as-service, impersonation, and "RunAs" call, User Registry hive could be unloaded or be outsider. That fix should resolve the bunch of corner-case problems with impersonation and migration. 2] KF_FLAG_CREATE and CSIDL_FLAG_CREATE need to be use is case, than Java application is applied as Administrative Tool for Users management. Potentially the Java call could be the first profile request. For the case the real folder need to be created in time. 3] __try/__except trick for potentially absent DLL entry is known and successfully used in AWT. That simplifies code and checks function signatures on link time. 4] Function [GetJavaProperties] was changed for better "initialization-finished" condition checking in low-risky raise condition. 5] The pre-requirements for JDK build includes section "Windows i586: Microsoft Visual Studio 2010 Compilers" about installed Windows SDK v 7.0a or later. That includes actual headers for Shell Lib version 6.0.6000 with [SHGetKnownFolderPath] entry. http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.htmll#msvc32 Regards, -uta From darryl.mocek at oracle.com Fri Jan 18 23:11:29 2013 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 18 Jan 2013 15:11:29 -0800 Subject: RFR: 8006534 CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times In-Reply-To: <50F85CAD.6070006@oracle.com> References: <50F85CAD.6070006@oracle.com> Message-ID: <50F9D6A1.2000707@oracle.com> Hi Jim, I think this change looks fine. I think it works for our purposes for now and is a quick and painless change. The problem as I understand it is that when getUnusedRandomPort is called and the port returned is FIXED_PORT_MIN (which is rejected), then the code tries again and returns FIXED_PORT_MIN + 1, then +2, etc. Since FIXED_PORT_MAX - FIXED_PORT_MIN >= numTries, it fails. The fix increases the number of tries. This means when FIXED_PORT_MAX - FIXED_PORT_MIN increases above the current numTries, then we'll need to increase the number of tries again. This probably won't happen for a while as we're trying to decrease the use of fixed ports, not increase them. However, there are a bunch of tests which currently use fixed ports which aren't using TestLibrary, but should be because we can probably convert most or all of them to use a random port. Those we cannot convert should have their fixed ports reserved in TestLibrary. After some thought, I think we can improve "getting an unused random port by providing a custom SocketImplFactory which will not use ServerSocket (as we open the ServerSocket, get the port number, close the ServerSocket, return the port number...btw, it is unlikely but possible that this port will be grabbed by some other process between the time the ServerSocket is closed and the time the socket is opened by the caller of getUnusedRandomPort, but this may happen with a custom SocketImplFactory anyway) and which only look for ports whicha re not used and which are within a range we want (read outside the FIXED_PORT_* range (and other ranges like < 1024)). I think using a SocketImplFactory will improve the performance and reliability of the tests. Darryl On 01/17/2013 12:18 PM, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/Bug8006534-getUnusedRandomPort-retry-more/ > > > > TestLibrary.getUnusedPort() attempts to retry getting an ephemeral > port 10 times, which is the current number of ports in the reserved > port range. Debugging code added a few weeks back has revealed that > intermittent failures in tests using this method are caused when the > underlying socket code first returns the first number in the reserved > port range. Subsequent retries result in incrementing the port number > by one until reaching the max reserved port number, which just happens > to correspond to the 10th attempt, and the code then quits trying. > > The proposed fix (one of many possible alternatives, of course) simply > retries for twice the number of ports in the range. > > Thanks, > Jim > From xueming.shen at oracle.com Sat Jan 19 00:03:26 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 18 Jan 2013 16:03:26 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F5F08D.5000008@oracle.com> References: <50F5F08D.5000008@oracle.com> Message-ID: <50F9E2CE.9090500@oracle.com> Hi, The webrev and Javadoc have been updated based on the feedback we received so far. The main stopper is the timezone data compiler had dependency on new threeten classes (and these classes themselves depend on new JDK8 features). The compiler has been re-written to remove the dependency and now work as a "normal" build tool at make/tool. Build-infra team please help take a look if all our makefile changes are OK for the new/ old build system. http://cr.openjdk.java.net/~sherman/8003680/webrev http://cr.openjdk.java.net/~sherman/8003680/javadoc Thanks, Sherman On 01/15/2013 04:13 PM, Xueming Shen wrote: > Hi, > > The Threeten project [1] is planned to be integrated into OpenJDK8 M6 milestone. > > Here is the webrev > http://cr.openjdk.java.net/~sherman/8003680/webrev > > and the latest javadoc > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Review comments can be sent to the threeten-dev email list [2] and/or > core-libs-dev email list[3]. > > Thanks, > Sherman > > [1] http://openjdk.java.net/projects/threeten > [2] threeten-dev @ openjdk.java.net > [3] core-libs-dev @ openjdk.java.net > > From chris.hegarty at oracle.com Sat Jan 19 08:40:34 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 19 Jan 2013 08:40:34 +0000 Subject: hg: jdk8/tl/jdk: 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Message-ID: <20130119084055.AA3A0473F2@hg.openjdk.java.net> Changeset: 33d0175ea8d9 Author: msheppar Date: 2013-01-19 08:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33d0175ea8d9 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Reviewed-by: chegar, alanb ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java From Alan.Bateman at oracle.com Sat Jan 19 14:43:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 19 Jan 2013 14:43:01 +0000 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> Message-ID: <50FAB0F5.9000607@oracle.com> On 15/01/2013 16:48, Lance Andersen - Oracle wrote: > Here is a revision > > http://cr.openjdk.java.net/~lancea/8006139/webrev.01 > > I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut& paste when the code was written) and ccc request > > As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. > It would be good to get the ClassCastException specified when you get time. I looked at the latest webrev and it seems okay to me. SQLInputImpl.getNextAttribute would be bit better if it only incremented idx after retrieving an attribute but that is existing code. Minor intent issue in SQLOutputImpl. writeNClob. -Alan. From Lance.Andersen at oracle.com Sat Jan 19 15:08:29 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 19 Jan 2013 10:08:29 -0500 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: <50FAB0F5.9000607@oracle.com> References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> <50FAB0F5.9000607@oracle.com> Message-ID: On Jan 19, 2013, at 9:43 AM, Alan Bateman wrote: > On 15/01/2013 16:48, Lance Andersen - Oracle wrote: >> Here is a revision >> >> http://cr.openjdk.java.net/~lancea/8006139/webrev.01 >> >> I still have to enter the JBS entry for the javadoc clarifications (and I also found another javadoc issue that was due to incorrect cut& paste when the code was written) and ccc request >> >> As i mentioned in an earlier thread, these classes are hardly ever, if at all used and would only be used when UDTs are used and the majority of databases do not support this. >> > It would be good to get the ClassCastException specified when you get time. Yes will do once the ccc is approved on my list > > I looked at the latest webrev and it seems okay to me. SQLInputImpl.getNextAttribute would be bit better if it only incremented idx after retrieving an attribute but that is existing code. Minor intent issue in SQLOutputImpl. writeNClob. > fixed the spacing. going to leave idx alone for now as but will look at this for the future Best Lance > -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 lance.andersen at oracle.com Sat Jan 19 15:12:19 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Sat, 19 Jan 2013 15:12:19 +0000 Subject: hg: jdk8/tl/jdk: 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Message-ID: <20130119151254.BFB80473F3@hg.openjdk.java.net> Changeset: 78514544980d Author: lancea Date: 2013-01-19 10:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78514544980d 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Reviewed-by: naoto, ulfzibis, alanb ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java From lance.andersen at oracle.com Sat Jan 19 15:53:33 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Sat, 19 Jan 2013 15:53:33 +0000 Subject: hg: jdk8/tl/jdk: 8005080: JDBC 4.2 Core changes Message-ID: <20130119155356.2F255473F4@hg.openjdk.java.net> Changeset: d3da0d29d7cd Author: lancea Date: 2013-01-19 10:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd 8005080: JDBC 4.2 Core changes Reviewed-by: naoto ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverManager.java + src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLTimeoutException.java + src/share/classes/java/sql/SQLType.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Types.java ! src/share/classes/java/sql/package.html ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java From peter.levart at gmail.com Sat Jan 19 17:11:48 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 19 Jan 2013 18:11:48 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations In-Reply-To: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> References: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> Message-ID: Hi Joel, I see, there is a dilema how to cache type annotations. To satisfy single-annotation-returning methods and repeating annotation logic, a HashMap would be a logical choice, but it has much bigger footprint than simple arrays of annotations... I experimented with an idea of using a special purpose immutable Map implementation: https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/UniqueIndex.java and: https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/AnnotationMap.java This is just a preview. I still have to create some tests to see how it compares to HashMap. Being an immutable wrapper for a single array of annotations it has a nice feature that a reference to it can be passed to other threads via a data race with no danger of data inconsistency, which simplifies caching mechanisms and helps scalability. Might even be a space-saving replacement for existing HashMaps of annotations. Depending on performance, of course. What do you think? Is it worth pursuing this further? Regards, Peter On Jan 17, 2013 5:24 PM, "Joel Borggr?n-Franck" wrote: > Hi, > > Here is a webrev for core reflection support for type annotations: > > http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/ > > This code is based on the tl/jdk repository, but in order to run the tests > you need a javac with type annotations support and also a recent copy of > the VM that includes this change set: > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282(This also means this code can't be pushed until all supporting pieces are > in place.) > > Type annotations are still a bit of a moving target so there will be > follow up work on this. There is no caching of annotations in this version > and I am not sure how we want to do the space/time trade of for type > annotations. > > cheers > /Joel From stevenschlansker at gmail.com Sun Jan 20 00:54:03 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Sat, 19 Jan 2013 16:54:03 -0800 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <50EEB930.1090005@oracle.com> References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> <50EEB930.1090005@oracle.com> Message-ID: <430A2634-5B37-4979-8B87-C6F360CB297C@gmail.com> Thank you for the feedback! On Jan 10, 2013, at 4:50 AM, Aleksey Shipilev wrote: > On 01/09/2013 09:51 PM, Steven Schlansker wrote: >> Hello again, >> >> I sent this email a week ago and have received no replies. Is there >> any step I have missed necessary to contribute to the JDK libraries? > > I think the crucial part is OCA, as per: > http://openjdk.java.net/contribute/ I have now taken care of this :-) The OCA is under the company name "Ness Computing" and was emailed yesterday. > >> I am very interested in making your lives easier, so please let me >> know if I am in the wrong place or are otherwise misguided. > > You are at the correct place. > > On the first glance, the change looks good for the start. A few comments > though: > a) Do you need the masks before or-ing with most/leastSigBits? So, they seem to exist to satisfy a few Apache Harmony test cases: http://svn.apache.org/viewvc/harmony/enhanced/java/branches/java6/classlib/modules/luni/src/test/api/common/org/apache/harmony/luni/tests/java/util/UUIDTest.java?revision=929252 For example, uuid = UUID.fromString("123456789-0-0-0-0"); Assert.assertEquals(0x2345678900000000L, uuid.getMostSignificantBits()); Assert.assertEquals(0x0L, uuid.getLeastSignificantBits()); Without the masking, the values can smear together. It would be possible to avoid converting extra characters, but I believe that the mask is probably cheaper than an if to check for the presence of extra characters. Were I writing the code from scratch I would throw an IllegalArgumentException on such a UUID but I assume that is not acceptable for compatibility reasons. > b) Is there a more standard (and still performant) way to do the hex > conversion? Look around JDK source, I think there should be something > else needing the same kind of conversion. I didn't see any candidates. I thought of at least the following places to look: Long, String, Formatter, BitSet, and did some general browsing around java.lang and java.util with no luck. The Long methods are in java.lang and so could not be used without making them public. I assume that having private helper methods for my class is preferable to introducing new public methods. It's entirely possible I missed something, but I'm not seeing it. > c) I'd go for making utility methods a bit more generic. For one, I > would rather make decodeHex(String str, int start, int end), and > encodeHex(char[] dest, int offset, int value). I can do this if you feel strongly, but I believe that this compromises the readability of the code. For example, right now you can see: long mostSigBits = decode(str, dashPos, 0); mostSigBits <<= 16; mostSigBits |= decode(str, dashPos, 1); ? whereas to make it use a "more general" helper it would have to look like this: long mostSigBits = decode(str, dashPos[0]+1, dashPos[1]); mostSigBits <<= 16; mostSigBits |= decode(str, dashPos[1], dashPos[2]+1); This is an increase from one "magic value" per invocation to three. It's not a huge difference either way, but I'm not sure that your suggestion is better? I suppose I could make it non-private helper method available to others, although I am not sure if this is considered a good practice in the JDK code. Let me know if you think I should do this. > > Microbenchmark glitches: > a) % is the integer division, and at the scale of the operations you > are measuring, it could incur significant costs; the usual practice is > having power-of-2 size, and then (i % size) -> (i & (size - 1)). I fixed this, but it made no meaningful change to the numbers. > b) Not sure if you want to stick with random UUIDs for comparisons. > While the law of large numbers is on your side, 1000 random UUIDs might > be not random enough. I don't believe that this has any bearing on the result. I've run the trials many, many times and the number rarely changes by even 1% from the values that I posted beforehand. If you think this is an actual problem, I can come up with an alternate methodology. I don't think it's a problem. Thanks again for the review. Please let me know if you agree or believe I am mistaken in my analysis above. From chris.hegarty at oracle.com Sun Jan 20 09:39:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 20 Jan 2013 09:39:14 +0000 Subject: hg: jdk8/tl/jdk: 8006560: java/net/ipv6tests/B6521014.java fails intermittently Message-ID: <20130120093937.554AE47407@hg.openjdk.java.net> Changeset: bb2ed83676d2 Author: chegar Date: 2013-01-20 09:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2ed83676d2 8006560: java/net/ipv6tests/B6521014.java fails intermittently Reviewed-by: khazra, wetmore ! test/java/net/ipv6tests/B6521014.java From masayoshi.okutsu at oracle.com Mon Jan 21 03:06:51 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 21 Jan 2013 03:06:51 +0000 Subject: hg: jdk8/tl/jdk: 4745761: (cal) RFE: Support builder for constructing Calendar Message-ID: <20130121030714.D5F3D47410@hg.openjdk.java.net> Changeset: 6ca6b6f07653 Author: okutsu Date: 2013-01-21 12:04 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ca6b6f07653 4745761: (cal) RFE: Support builder for constructing Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java + test/java/util/Calendar/Builder/BuilderTest.java ! test/java/util/Calendar/CalendarTypeTest.java From masayoshi.okutsu at oracle.com Mon Jan 21 06:44:38 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 21 Jan 2013 06:44:38 +0000 Subject: hg: jdk8/tl/jdk: 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI; ... Message-ID: <20130121064458.EBD9847413@hg.openjdk.java.net> Changeset: 3c1a440a1e12 Author: okutsu Date: 2013-01-21 15:41 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a440a1e12 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI 8006509: Add more calendar symbol names from CLDR Reviewed-by: peytoia ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! src/share/classes/java/util/spi/CalendarNameProvider.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/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.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/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.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/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.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/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/util/Calendar/CldrFormatNamesTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From weijun.wang at oracle.com Mon Jan 21 07:06:19 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 21 Jan 2013 07:06:19 +0000 Subject: hg: jdk8/tl/jdk: 8006092: SecurityPermission: printIdentity doesn't exist Message-ID: <20130121070641.C5D8A47414@hg.openjdk.java.net> Changeset: bb940b2107bd Author: juh Date: 2013-01-21 15:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb940b2107bd 8006092: SecurityPermission: printIdentity doesn't exist Reviewed-by: weijun ! test/sun/security/tools/policytool/UpdatePermissions.html From aleksey.shipilev at oracle.com Mon Jan 21 11:00:57 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 21 Jan 2013 15:00:57 +0400 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <430A2634-5B37-4979-8B87-C6F360CB297C@gmail.com> References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> <50EEB930.1090005@oracle.com> <430A2634-5B37-4979-8B87-C6F360CB297C@gmail.com> Message-ID: <50FD1FE9.3000704@oracle.com> On 01/20/2013 04:54 AM, Steven Schlansker wrote: >> a) Do you need the masks before or-ing with most/leastSigBits? > > So, they seem to exist to satisfy a few Apache Harmony test cases: > http://svn.apache.org/viewvc/harmony/enhanced/java/branches/java6/classlib/modules/luni/src/test/api/common/org/apache/harmony/luni/tests/java/util/UUIDTest.java?revision=929252 I'm sure some due dilignence will be required to actually do this... but can we add the similar-looking test to OpenJDK? > For example, > uuid = UUID.fromString("123456789-0-0-0-0"); > Assert.assertEquals(0x2345678900000000L, uuid.getMostSignificantBits()); > Assert.assertEquals(0x0L, uuid.getLeastSignificantBits()); > Without the masking, the values can smear together. It would be > possible to avoid converting extra characters, but I believe that the > mask is probably cheaper than an if to check for the presence of > extra characters. Yeah, OK, masking is better. Any specific reason some masks are integer, not long? > Were I writing the code from scratch I would throw an > IllegalArgumentException on such a UUID but I assume that is not > acceptable for compatibility reasons. It is a gray area when exceptional behavior are considered. The changes potentially breaking compatibility are better to be submitted as another CR, not to drag the precious changes along. >> c) I'd go for making utility methods a bit more generic. For one, I >> would rather make decodeHex(String str, int start, int end), and >> encodeHex(char[] dest, int offset, int value). > > It's not a huge difference either way, but I'm not sure that your suggestion is better? My inclination was to match usual ($something, offset, count) or ($something, start, end) signatures you will see across the JDK. But in this concrete example this seems to be a tie. Your code is as fine. > I suppose I could make it non-private helper method available to > others, although I am not sure if this is considered a good practice > in the JDK code. Let me know if you think I should do this. I think you should consider doing that, although it is not strictly speaking required, especially given this pretty limited change. Anyway, we have the sun.misc.* namespace for these helpers. You would be surprised to see how many usages these helpers will bear once you have them, and let some time to pass. -Aleksey. From aleksey.shipilev at oracle.com Mon Jan 21 11:12:46 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 21 Jan 2013 15:12:46 +0400 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <430A2634-5B37-4979-8B87-C6F360CB297C@gmail.com> References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> <50EEB930.1090005@oracle.com> <430A2634-5B37-4979-8B87-C6F360CB297C@gmail.com> Message-ID: <50FD22AE.9090005@oracle.com> On 01/20/2013 04:54 AM, Steven Schlansker wrote: > On Jan 10, 2013, at 4:50 AM, Aleksey Shipilev wrote: > >> On 01/09/2013 09:51 PM, Steven Schlansker wrote: >>> I sent this email a week ago and have received no replies. Is there >>> any step I have missed necessary to contribute to the JDK libraries? >> >> I think the crucial part is OCA, as per: >> http://openjdk.java.net/contribute/ > > I have now taken care of this :-) > The OCA is under the company name "Ness Computing" and was emailed yesterday. Ok, now as this is being taken care of, you need to follow these steps: a) prepare the code, and create the webrev [1] for the change. b) upload the webrev somewhere, submit the link to webrev for formal review on this list, clearly stating the subject, and the CR. I had submitted CR for this change (8006627), it will be eventually available in public [2]. So, for reviews, you should use this subject line: "RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string" c) Work with sponsors to commit this. Thanks, -Aleksey. [1] "ksh make/scripts/webrev.ksh -f", maybe with "-N" if you have not committed, and your changes are against the working copy. [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006627 From chris.hegarty at oracle.com Mon Jan 21 13:51:26 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 21 Jan 2013 13:51:26 +0000 Subject: hg: jdk8/tl/jdk: 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Message-ID: <20130121135207.0FE2947420@hg.openjdk.java.net> Changeset: f21a3c273fb2 Author: dl Date: 2013-01-21 13:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f21a3c273fb2 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Reviewed-by: chegar, darcy, goetz ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java + src/share/classes/java/util/concurrent/atomic/DoubleAdder.java + src/share/classes/java/util/concurrent/atomic/LongAccumulator.java + src/share/classes/java/util/concurrent/atomic/LongAdder.java + src/share/classes/java/util/concurrent/atomic/Striped64.java + test/java/util/concurrent/atomic/DoubleAdderDemo.java + test/java/util/concurrent/atomic/LongAdderDemo.java From Alan.Bateman at oracle.com Mon Jan 21 16:01:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2013 16:01:37 +0000 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50F97AFD.20800@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> Message-ID: <50FD6661.6040304@oracle.com> On 18/01/2013 16:40, Alexey Utkin wrote: > The main difference is that after the fix Java becomes the program > that could be certified by MS as Vista comparable. > Java would support the dynamic user profiles and follow the changes > in Windows OS policy (profiles migration). > Java would able to support long home directories (Windows API migrates > from limited-length paths, that were the FAT FS limitation, to > unlimited-length paths). > The only compatibility issues could happen on the systems that uses > Registry-based redirection by the way that was reserved for Java > property define switch -Duser.home=XXXX. > > I would like repeat it again: after the fix Java becomes Vista > comparable program, that catch up changes from Windows OS management > tools. > For the special cases we have compatibility solution: Java define for > "user.home" property. > > From MS point of view the User's home directory could not be used > directly for data storage. The specialized [Document], [Downloand], > and etc. sub-folders need to be used. > Often configs are stored in [.XXXX] sub-folders. That does not make MS > happy, but that is common practice for cross-platform tools. On that > field Java plays together with SSH, cygwin, > Firefox, Netbeans and all other well-known products. The behavior > could not be easily change (MS would happy to move configs into > [AppData\Local] sub-folder, but it is not a Java problem). > > Regards, > -uta It's good to get rid of the registry code, I just wonder if using the shell API will have impact on startup performance. I also wonder about corner-case configurations. One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE and I'm not sure if that is right because we don't want the JDK creating the user's directory if it doesn't exist. I think it's okay to leave out the comment at L529 as it might be confusing when there isn't any registry code. Otherwise I think the change is okay, definitely something for a major release rather than an update release. -Alan. From jonathan.gibbons at oracle.com Mon Jan 21 18:01:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 21 Jan 2013 18:01:30 +0000 Subject: hg: jdk8/tl/langtools: 8006263: Supplementary test cases needed for doclint Message-ID: <20130121180135.C92B34742C@hg.openjdk.java.net> Changeset: 4a3cfc970c6f Author: jjg Date: 2013-01-21 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a3cfc970c6f 8006263: Supplementary test cases needed for doclint Reviewed-by: mcimadamore Contributed-by: peter.jensen at oracle.com ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Entity.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java + test/tools/doclint/CoverageExtras.java ! test/tools/doclint/DocLintTester.java + test/tools/doclint/html/EntitiesTest.java + test/tools/doclint/html/EntitiesTest.out + test/tools/doclint/tool/HelpTest.java + test/tools/doclint/tool/HelpTest.out + test/tools/doclint/tool/MaxDiagsTest.java + test/tools/doclint/tool/MaxDiagsTest.out + test/tools/doclint/tool/PathsTest.java + test/tools/doclint/tool/RunTest.java + test/tools/doclint/tool/StatsTest.java + test/tools/doclint/tool/StatsTest.out From jonathan.gibbons at oracle.com Mon Jan 21 18:07:48 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 21 Jan 2013 18:07:48 +0000 Subject: hg: jdk8/tl/langtools: 8006251: doclint: incorrect position for diagnostic for illegal text in tags Message-ID: <20130121180751.01A7D4742D@hg.openjdk.java.net> Changeset: 967052c425a1 Author: jjg Date: 2013-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/967052c425a1 8006251: doclint: incorrect position for diagnostic for illegal text in tags Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/html/BlockTagsTest.java + test/tools/doclint/html/InlineTagsTest.java + test/tools/doclint/html/ListTagsTest.java + test/tools/doclint/html/OtherTagsTest.java + test/tools/doclint/html/OtherTagsTest.out + test/tools/doclint/html/TableTagsTest.java + test/tools/doclint/html/TagNotAllowed.java + test/tools/doclint/html/TagNotAllowed.out + test/tools/doclint/html/TextNotAllowed.java + test/tools/doclint/html/TextNotAllowed.out ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/TextNotAllowed.out From lance.andersen at oracle.com Mon Jan 21 19:09:16 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 21 Jan 2013 19:09:16 +0000 Subject: hg: jdk8/tl/jdk: 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Message-ID: <20130121190938.951684742F@hg.openjdk.java.net> Changeset: de30e46250c5 Author: lancea Date: 2013-01-21 14:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de30e46250c5 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Reviewed-by: alanb ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java From lana.steuck at oracle.com Mon Jan 21 19:22:20 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:20 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130121192237.0070A47433@hg.openjdk.java.net> Changeset: 56c97aff46bb Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56c97aff46bb Added tag jdk8-b73 for changeset 8d0baee36c71 ! .hgtags Changeset: b450959b42ff Author: lana Date: 2013-01-20 23:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b450959b42ff Merge Changeset: 1985e35e97b2 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1985e35e97b2 Merge From lana.steuck at oracle.com Mon Jan 21 19:22:13 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:13 +0000 Subject: hg: jdk8/tl: 28 new changesets Message-ID: <20130121192216.AFCED47431@hg.openjdk.java.net> Changeset: 4090847a5444 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4090847a5444 Added tag jdk8-b73 for changeset 93b9664f97ee ! .hgtags Changeset: 77f062a41850 Author: erikj Date: 2012-12-27 20:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/77f062a41850 8001942: build-infra: General permission problems on Windows/cygwin Summary: Added sanity check for file permissions in configure Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: d2c1f80118de Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d2c1f80118de 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/NativeCompilation.gmk Changeset: d5f3a6f60d51 Author: erikj Date: 2012-12-27 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d5f3a6f60d51 8005548: build-infra: Fix docs target on windows Summary: Fix path sep variable Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk Changeset: ef6adbf511cc Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ef6adbf511cc 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! NewMakefile.gmk ! common/autoconf/Makefile.in ! common/autoconf/generated-configure.sh + common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile Changeset: 2d9bb72b4e34 Author: erikj Date: 2012-12-30 12:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2d9bb72b4e34 8004490: build-infra: mac: hotspot is always built in product, regardless of --with-debug-level setting Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: abc8078e070b Author: erikj Date: 2013-01-01 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/abc8078e070b 8001895: build-infra: Make JDK_BUILD_NUMBER and MILESTONE customizable Summary: Added configure params Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/version.numbers Changeset: 14d7ebe42c8d Author: erikj Date: 2013-01-02 11:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/14d7ebe42c8d 8005347: build-infra: Verify 'gnumake source' at the top level works ok Reviewed-by: tbell, ohair, dholmes ! common/autoconf/basics.m4 - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in = common/autoconf/version-numbers < common/autoconf/version.numbers Changeset: 348a881c6da0 Author: erikj Date: 2013-01-02 15:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/348a881c6da0 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: befbad2e4d87 Author: erikj Date: 2013-01-03 20:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/befbad2e4d87 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/Jprt.gmk ! common/src/fixpath.c Changeset: 39194e004ade Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/39194e004ade 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! common/autoconf/compare.sh.in ! common/bin/compare.sh Changeset: 9263657c2756 Author: erikj Date: 2013-01-04 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9263657c2756 8005692: build-infra: Target "all" should do the right thing Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: c874a8a27933 Author: erikj Date: 2013-01-04 17:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c874a8a27933 8005597: build-infra: bridgeBuild broken for pure openjdk build Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: 7b9c42f14281 Author: erikj Date: 2013-01-04 17:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7b9c42f14281 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! common/bin/compare.sh ! common/makefiles/JavaCompilation.gmk Changeset: 2597feac57c0 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2597feac57c0 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: 5cf7750c8c43 Author: ohair Date: 2013-01-04 21:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5cf7750c8c43 8004229: build-infra: Umbrella for switch of default "make" to new makefiles Reviewed-by: erikj, tbell ! Makefile ! make/jprt.properties Changeset: 7a3c6ffdf1fb Author: tbell Date: 2013-01-07 14:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7a3c6ffdf1fb 8005442: autogen.sh sets DATE_WHEN_GENERATED to empty string on Solaris version 11 or later Reviewed-by: ohair ! common/autoconf/autogen.sh Changeset: 64a9ebad39fe Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/64a9ebad39fe Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: b284980b7d9a Author: tbell Date: 2013-01-08 16:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b284980b7d9a 8005794: in new infra, how do we change java -version? Summary: Added configure parameter --with-user-release-suffix Reviewed-by: ohair, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: db3984e4eb97 Author: erikj Date: 2013-01-10 12:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/db3984e4eb97 8005858: build-infra: Add missed comparison of sec-windows-bin.zip and friends to compare.sh Reviewed-by: tbell, ohair ! common/bin/compare.sh Changeset: 6f8f7a5449f6 Author: erikj Date: 2013-01-11 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6f8f7a5449f6 8005850: build-infra: Make --enable-openjdk-only really disable custom Reviewed-by: ohair, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: b66c81dfa291 Author: ohair Date: 2013-01-14 16:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b66c81dfa291 8005284: build-infra: nonstandard copyright headers under common/autoconf/build-aux Reviewed-by: katleman ! common/autoconf/build-aux/autoconf-config.guess ! common/autoconf/build-aux/config.sub ! common/autoconf/build-aux/pkg.m4 Changeset: 3540aa40c868 Author: erikj Date: 2013-01-14 13:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3540aa40c868 8006074: build-infra: Configure fails to find SetEnv.Cmd in microsoft sdk Reviewed-by: tbell, ohair ! common/autoconf/basics_windows.m4 ! common/autoconf/generated-configure.sh Changeset: 6e822b534678 Author: erikj Date: 2013-01-14 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6e822b534678 8006100: build-infra: Bundle up the correct images in jprt Reviewed-by: tbell ! NewMakefile.gmk ! common/makefiles/Jprt.gmk Changeset: 52cce3326649 Author: erikj Date: 2013-01-15 09:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/52cce3326649 Merge Changeset: fe1c94aca5a8 Author: katleman Date: 2013-01-15 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fe1c94aca5a8 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: dc84b505b408 Author: katleman Date: 2013-01-16 22:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dc84b505b408 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 2e12a508d7ae Author: lana Date: 2013-01-20 23:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2e12a508d7ae Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/makefiles/javadoc/Javadoc.gmk From lana.steuck at oracle.com Mon Jan 21 19:22:13 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:13 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b73 for changeset 191afde59e7b Message-ID: <20130121192216.0181147430@hg.openjdk.java.net> Changeset: 2132845cf5f7 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2132845cf5f7 Added tag jdk8-b73 for changeset 191afde59e7b ! .hgtags From lana.steuck at oracle.com Mon Jan 21 19:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:19 +0000 Subject: hg: jdk8/tl/hotspot: 2 new changesets Message-ID: <20130121192230.9073F47432@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a3e54283c54 Merge ! .hgtags From lana.steuck at oracle.com Mon Jan 21 19:22:16 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:16 +0000 Subject: hg: jdk8/tl/jaxp: 6 new changesets Message-ID: <20130121192241.8359D47435@hg.openjdk.java.net> Changeset: cf0917c0d771 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cf0917c0d771 Added tag jdk8-b73 for changeset 84946404d1e1 ! .hgtags Changeset: 278a2f60c55b Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/278a2f60c55b 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxp.gmk Changeset: 2e4d87e6662e Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2e4d87e6662e Merge Changeset: a317d3e1bbac Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a317d3e1bbac Merge Changeset: 2087e24a4357 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2087e24a4357 Merge Changeset: 4e049aa2495f Author: lana Date: 2013-01-20 23:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4e049aa2495f Merge From lana.steuck at oracle.com Mon Jan 21 19:22:24 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:24 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20130121192241.2371647434@hg.openjdk.java.net> Changeset: 68f508979ffe Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/68f508979ffe Added tag jdk8-b73 for changeset c606f644a5d9 ! .hgtags Changeset: 51f3117e2b75 Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/51f3117e2b75 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxws.gmk Changeset: dd7473082690 Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dd7473082690 Merge Changeset: b8fd32e44c26 Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b8fd32e44c26 Merge Changeset: 12db3c5a3393 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/12db3c5a3393 Merge From lana.steuck at oracle.com Mon Jan 21 19:22:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:51 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20130121192706.4089847436@hg.openjdk.java.net> Changeset: 965e89e2abd3 Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/965e89e2abd3 Added tag jdk8-b73 for changeset 733885f57e14 ! .hgtags Changeset: e91caf05f441 Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e91caf05f441 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: 368fa50469da Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368fa50469da 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! makefiles/BuildJdk.gmk Changeset: 461b069100fa Author: erikj Date: 2013-01-02 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/461b069100fa 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + makefiles/SignJars.gmk Changeset: 3841da683703 Author: erikj Date: 2013-01-03 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3841da683703 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! make/common/shared/Defs-windows.gmk ! makefiles/BuildJdk.gmk ! makefiles/Bundles.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: a8d25b689563 Author: erikj Date: 2013-01-04 16:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8d25b689563 8005694: build-infra: Cleanup of misc changes in build-infra Reviewed-by: tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 3824d8469dcf Author: erikj Date: 2013-01-04 17:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3824d8469dcf 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: d98e73b7bc78 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d98e73b7bc78 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 244e481f538b Author: katleman Date: 2013-01-08 13:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/244e481f538b Merge ! makefiles/CreateJars.gmk Changeset: 1868bde529b8 Author: ohrstrom Date: 2013-01-09 13:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1868bde529b8 8005096: Move a few source files in swing/beaninfo and in a demo. Reviewed-by: ohair, erikj, malenkov ! make/javax/swing/beaninfo/SwingBeans.gmk - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java + make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java + make/tools/swing-beans/sun/swing/BeanInfoUtils.java ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcSwing.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java Changeset: 2cc29d0b9eaf Author: erikj Date: 2013-01-09 16:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cc29d0b9eaf 8005903: build-infra: bad symlink: j2sdk-bundle/jdk1.8.0.jdk/Contents/MacOS/libjli.dylib Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: f92ab6dbbff8 Author: erikj Date: 2013-01-10 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f92ab6dbbff8 8005856: build-infra: Remove special handling of base module classes header generation Reviewed-by: alanb, tbell, ohair Contributed-by: fredrik.ohrstrom at oracle.com ! makefiles/CompileJavaClasses.gmk ! src/share/classes/java/io/FileSystem.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java Changeset: 4d80ab394efa Author: erikj Date: 2013-01-15 16:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d80ab394efa 8006296: build-infra: Unsigned sunmscapi.jar is missing manifest. Reviewed-by: alanb, tbell ! makefiles/CreateJars.gmk Changeset: 6d1a3d43851d Author: katleman Date: 2013-01-15 10:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1a3d43851d Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 3eef1e0540c4 Author: erikj Date: 2013-01-16 16:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3eef1e0540c4 8006385: build-infra: linux and solaris *-debuginfo-*.zip file created from the new makefile has extra HUDSON direcotry in jre/lib/i386/server Reviewed-by: tbell ! makefiles/Import.gmk Changeset: 54bbeb149525 Author: katleman Date: 2013-01-16 22:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54bbeb149525 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! src/share/classes/java/lang/Integer.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 8b1857409159 Author: lana Date: 2013-01-20 23:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b1857409159 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 7f4e3da76ec1 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f4e3da76ec1 Merge From maurizio.cimadamore at oracle.com Mon Jan 21 20:21:51 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 21 Jan 2013 20:21:51 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130121202204.8A33747438@hg.openjdk.java.net> Changeset: 7873d37f5b37 Author: mcimadamore Date: 2013-01-21 20:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7873d37f5b37 8005244: Implement overload resolution as per latest spec EDR Summary: Add support for stuck expressions and provisional applicability Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.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/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/generics/diamond/T6939780.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg10.java ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference25.out ! test/tools/javac/lambda/MethodReference26.java - test/tools/javac/lambda/MethodReference26.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType06.java - test/tools/javac/lambda/TargetType06.out ! test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType11.java - test/tools/javac/lambda/TargetType11.out ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType45.java - test/tools/javac/lambda/TargetType45.out ! 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/VoidCompatibility.java - test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java Changeset: c7c41a044e7c Author: mcimadamore Date: 2013-01-21 20:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7c41a044e7c 8006566: Remove transient lambda-related guards from JavacParser Summary: Remove transitional internal flag for allowing intersection types in cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: b12ffdfa1341 Author: mcimadamore Date: 2013-01-21 20:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b12ffdfa1341 8005851: Remove support for synchronized interface methods Summary: Synchronized default methods are no longer supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: cf84b07a82db Author: mcimadamore Date: 2013-01-21 20:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf84b07a82db 8005166: Add support for static interface methods Summary: Support public static interface methods Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! 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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/static/Static01.java + test/tools/javac/defaultMethods/static/Static02.java + test/tools/javac/defaultMethods/static/Static02.out + test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java + test/tools/javac/defaultMethods/static/import/StaticImport1.java + test/tools/javac/defaultMethods/static/import/StaticImport2.java + test/tools/javac/defaultMethods/static/import/StaticImport2.out + test/tools/javac/defaultMethods/static/import/StaticImport3.java + test/tools/javac/defaultMethods/static/import/StaticImport3.out + test/tools/javac/defaultMethods/static/import/pkg/A.java + test/tools/javac/defaultMethods/static/import/pkg/B.java + test/tools/javac/defaultMethods/static/import/pkg/C.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java + test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java From Ulf.Zibis at CoSoCo.de Mon Jan 21 21:46:47 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 21 Jan 2013 22:46:47 +0100 Subject: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl In-Reply-To: References: <79D15CF5-D706-493A-B5A9-204D72EBC114@oracle.com> <50F2B8AC.6080807@oracle.com> <50F31442.8090302@oracle.com> <50F32653.9070106@CoSoCo.de> <50F3D9C4.9050805@oracle.com> <717063B4-2108-4FFB-AA01-D29519AAC989@oracle.com> <50FAB0F5.9000607@oracle.com> Message-ID: <50FDB747.3010305@CoSoCo.de> Am 19.01.2013 16:08, schrieb Lance Andersen - Oracle: >> I looked at the latest webrev and it seems okay to me. SQLInputImpl.getNextAttribute would be bit better if it only incremented idx after retrieving an attribute but that is existing code. Minor intent issue in SQLOutputImpl. writeNClob. >> > fixed the spacing. going to leave idx alone for now as but will look at this for the future ... and starting idx by 0 instead -1 would not be so exotic, see: internal review ID of 2426775 -Ulf From vladimir.kozlov at oracle.com Mon Jan 21 22:02:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Jan 2013 14:02:14 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <50FDBAE6.6040504@oracle.com> Thank you, Roland Vladimir On 1/21/13 8:49 AM, Roland Westrelin wrote: >> Here are Hotspot changes with new jtreg test: >> >> http://cr.openjdk.java.net/~kvn/6896617/webrev > > It looks good to me. > > Roland. > From xueming.shen at oracle.com Mon Jan 21 22:11:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 21 Jan 2013 14:11:36 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F9E2CE.9090500@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> Message-ID: <50FDBD18.4060608@oracle.com> Hi, Webrev has been updated with the latest build-infra changes in TL. The jprt.properties change in control repo is also included. This is probably the final bits we are going to push for M6. http://cr.openjdk.java.net/~sherman/8003680/webrev http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl http://cr.openjdk.java.net/~sherman/8003680/javadoc I'm yet to run the jprt build. Build with new buld-infra (config/make) and old make have been verified locally. Thanks, Sherman On 1/18/13 4:03 PM, Xueming Shen wrote: > Hi, > > The webrev and Javadoc have been updated based on the feedback > we received so far. > > The main stopper is the timezone data compiler had dependency on > new threeten classes (and these classes themselves depend on new > JDK8 features). The compiler has been re-written to remove the dependency > and now work as a "normal" build tool at make/tool. Build-infra team > please help take a look if all our makefile changes are OK for the new/ > old build system. > > http://cr.openjdk.java.net/~sherman/8003680/webrev > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Thanks, > Sherman > > On 01/15/2013 04:13 PM, Xueming Shen wrote: >> Hi, >> >> The Threeten project [1] is planned to be integrated into OpenJDK8 M6 >> milestone. >> >> Here is the webrev >> http://cr.openjdk.java.net/~sherman/8003680/webrev >> >> and the latest javadoc >> http://cr.openjdk.java.net/~sherman/8003680/javadoc >> >> Review comments can be sent to the threeten-dev email list [2] and/or >> core-libs-dev email list[3]. >> >> Thanks, >> Sherman >> >> [1] http://openjdk.java.net/projects/threeten >> [2] threeten-dev @ openjdk.java.net >> [3] core-libs-dev @ openjdk.java.net >> >> > From mandy.chung at oracle.com Mon Jan 21 22:15:32 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Jan 2013 14:15:32 -0800 Subject: RFR: 8005646: TEST_BUG: RMI UnregisterGroup test leaves process running In-Reply-To: <50ECB0D2.9050202@oracle.com> References: <50ECB0D2.9050202@oracle.com> Message-ID: <50FDBE04.6080108@oracle.com> Stuart, I think you still need a reviewer for this fix. This change looks okay to me. The details in the bug report are useful and you must have lots of fun to diagnose this :) - definitely not easy. Mandy On 1/8/2013 3:50 PM, Stuart Marks wrote: > Hi all, > > Please review this fix: > > http://cr.openjdk.java.net/~smarks/reviews/8005646/webrev.0/ > > for this bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005646 > > Many gory details are in that bug report. TL;DR the old test jumped > through several hoops attempting to deactivate all the activated > objects, but this sometimes failed. The revised test uses a better > deactivation technique. This improves the reliability of the test, and > it makes unnecessary a bunch of infrastructure that supported the old > deactivation technique. > > I've also removed the RMI stubs from the checked-in sources, since > they have been generated at runtime since Java 5. > > Thanks, > > s'marks From Ulf.Zibis at CoSoCo.de Mon Jan 21 23:30:38 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 22 Jan 2013 00:30:38 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F77DB7.50806@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> Message-ID: <50FDCF9E.5040600@CoSoCo.de> Am 17.01.2013 05:27, schrieb Vladimir Kozlov: > On 1/12/13 12:37 AM, Ulf Zibis wrote: >> 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is >> not available. > > I opened it, should show up in few days. Thanks! > >> 4) What specific operation should be done by the intrinsic, i.e. is >> there a fixed API for that method ??? > > When C2 (server JIT compiler in JVM) compiles encode methods it will replace new method > encodeArray() (matched by signature) with hand optimized assembler code which uses latest > processor instructions. I will send Hotspot changes soon. So it is nothing to do with interpreter > or bytecode sequence. > >> 5) Can an intrinsic write back more than 1 value (see my hack via int[] >> p) ? >> 6) Vladimir's webrev shows an integer as return type for that method, >> I've added a variant with boolean return type, and the code from my last >> approach could be transformed to a method with Object return type. I wanted to say, there would maybe different results for the surrounding code depending on the API we choose for the intrinsic method call. If the surrounding code is *as short as possible*, there is a better chance, it will be JIT-compiled too after fewer invocations of encodeArrayLoop(). I guess, the fastest would be: // while inlinig, JIT will erase the surrounding int[] p private static CoderResult copyISOs(CoderResult cr, char[] sa, byte[] da, final int[] p, int sl) { for (int sp = p[0], dp = p[1]; sp < sl; sp++) { char c = sa[sp]; // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, would be fastest if ((byte)(c >> 8) != 0) // temporary replacement, fast byte-length operation on x86 return null; da[dp++] = (byte)c; } return cr; } // No more needs try...finally block private CoderResult encodeArrayLoop( CharBuffer src, ByteBuffer dst) { char[] sa = src.array(); int soff = src.arrayOffset(); int sp = soff + src.position(); int sr = src.remaining(); byte[] da = dst.array(); int doff = dst.arrayOffset(); int dp = doff + dst.position(); int dr = dst.remaining(); CoderResult cr; if (dr < sr) { sr = dr; cr = CoderResult.OVERFLOW; } else cr = CoderResult.UNDERFLOW; int sl = sp + sr; final int[] p = { sp, dp }; cr = copyISOs(cr, sa, da, p, sl); src.position(p[0] - soff); dst.position(p[1] - doff); return result(cr, sa, p[0], sl); } // if adapted, maybe could also be reused in encodeBufferLoop() private static CoderResult result(CoderResult cr, byte[] sa, int sp, int sl) { return cr != null ? cr : sgp.parse(sa[sp], sa, sp, sl) < 0 ? sgp.error(); : sgp.unmappableResult(); } >> >> ... so waiting for Vladimir's feedback :-[ >> (especially on performance/hsdis results) > > Performance on x86 tested with next code (whole test will be in Hotspot changes) : > > ba = CharBuffer.wrap(a); > bb = ByteBuffer.wrap(b); > long start = System.currentTimeMillis(); > for (int i = 0; i < 1000000; i++) { > ba.clear(); bb.clear(); > enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); > } > long end = System.currentTimeMillis(); 1.) Wouldn't System.nanoTime() give more accurate results? 2.) I want to point out that it is not real world scenario, encoding the same data 1.000.000 times. If same data is used, it is likely, that the data itself becomes cached in the inner CPU cache so should have very fast access times, which would be not the case on real world data. 3.) It would also be interesting to see the results for less than 1.000.000 iterations in considering, the surrounding code would be JIT-compiled or not. Also performance on C1 should be tested. I also worry about the naming of method encodeArray(...). I think, it should reflect the fact, that it only encodes ISO-8859-1 charset characters. Please add a comment on the fact, that method encodeArray(...) is intended to be intrinsified. -Ulf From joel.franck at oracle.com Tue Jan 22 08:40:29 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 22 Jan 2013 09:40:29 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations In-Reply-To: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> References: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> Message-ID: <50FE507D.70009@oracle.com> Hi, New webrev: http://cr.openjdk.java.net/~jfranck/8004698/webrev.01/ - More comments in the code, more javadoc comments, hopefully better flow for enhanced readability. - I have also reduced permissions on some methods and made most of the classes immutable. cheers /Joel On 01/17/2013 05:23 PM, Joel Borggr?n-Franck wrote: > Hi, > > Here is a webrev for core reflection support for type annotations: > > http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/ > > This code is based on the tl/jdk repository, but in order to run the tests you need a javac with type annotations support and also a recent copy of the VM that includes this change set: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282 (This also means this code can't be pushed until all supporting pieces are in place.) > > Type annotations are still a bit of a moving target so there will be follow up work on this. There is no caching of annotations in this version and I am not sure how we want to do the space/time trade of for type annotations. > > cheers > /Joel > From alexey.utkin at oracle.com Tue Jan 22 09:48:13 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 22 Jan 2013 13:48:13 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FD6661.6040304@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> Message-ID: <50FE605D.6080400@oracle.com> On 21.01.2013 20:01, Alan Bateman wrote: > On 18/01/2013 16:40, Alexey Utkin wrote: >> The main difference is that after the fix Java becomes the program >> that could be certified by MS as Vista comparable. >> Java would support the dynamic user profiles and follow the changes >> in Windows OS policy (profiles migration). >> Java would able to support long home directories (Windows API >> migrates from limited-length paths, that were the FAT FS limitation, >> to unlimited-length paths). >> The only compatibility issues could happen on the systems that uses >> Registry-based redirection by the way that was reserved for Java >> property define switch -Duser.home=XXXX. >> >> I would like repeat it again: after the fix Java becomes Vista >> comparable program, that catch up changes from Windows OS management >> tools. >> For the special cases we have compatibility solution: Java define for >> "user.home" property. >> >> From MS point of view the User's home directory could not be used >> directly for data storage. The specialized [Document], [Downloand], >> and etc. sub-folders need to be used. >> Often configs are stored in [.XXXX] sub-folders. That does not make >> MS happy, but that is common practice for cross-platform tools. On >> that field Java plays together with SSH, cygwin, >> Firefox, Netbeans and all other well-known products. The behavior >> could not be easily change (MS would happy to move configs into >> [AppData\Local] sub-folder, but it is not a Java problem). >> >> Regards, >> -uta > It's good to get rid of the registry code, I just wonder if using the > shell API will have impact on startup performance. I also wonder about > corner-case configurations. The Shell32.dll is a part of Windows kernel. It is always in memory. The DLL code segments are shared between process instances until load address conflicts (that is not the case for Java) . The initialization of Shell32.dll data segment postponed till the first use. So, the reduction in the performance would be minimal. That is about the corner cases. Java definitely changes code flow in fix. But it is the bug subject. Suggested solution makes Java compatible with the rest of Win32 applications. In accordance with Chen's article (he is an expert!) http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx the registry entries got the values ones. That is a problem for any dynamic system. An upgrade is a kind of dynamic conversion that could make a problem. > One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE > and I'm not sure if that is right because we don't want the JDK > creating the user's directory if it doesn't exist. That is a corner case. In the latest versions of OS, MS is trying to follow "lazy" strategy in everything. Nothing is been instantiating before the first use. But Java needs the home folder. So, we have the right to request the creation. That is OS solution to accept or decline the request. > > I think it's okay to leave out the comment at L529 as it might be > confusing when there isn't any registry code. > Agree. Comment at L529 will be removed. > Otherwise I think the change is okay, definitely something for a major > release rather than an update release. Thanks, Alan! -uta From anthony.petrov at oracle.com Tue Jan 22 11:14:40 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Jan 2013 15:14:40 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FE605D.6080400@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> Message-ID: <50FE74A0.7000208@oracle.com> On 1/22/2013 13:48, Alexey Utkin wrote: >> One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE >> and I'm not sure if that is right because we don't want the JDK >> creating the user's directory if it doesn't exist. > That is a corner case. In the latest versions of OS, MS is trying to > follow "lazy" strategy in everything. Nothing is been instantiating > before the first use. But Java needs the home folder. > So, we have the right to request the creation. That is OS solution to > accept or decline the request. I agree with Alan. Java shouldn't forcibly create the user directory if it doesn't exist yet. I suggest to pass 0 (zero) as the dwFlags argument to ::SHGetKnownFolderPath(). The same applies to a call to the ::SHGetFolderPathW(). getHomeFromShell32() may return NULL, so let it do so if no user directory exists. -- best regards, Anthony From alexey.utkin at oracle.com Tue Jan 22 11:52:00 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 22 Jan 2013 15:52:00 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FE74A0.7000208@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> Message-ID: <50FE7D60.4050405@oracle.com> Ok. Alan and Anthony, would you like to be faster and follow optimistic strategy, that is described here: http://blogs.msdn.com/b/oldnewthing/archive/2011/01/05/10111777.aspx That do you thing about |CSIDL_FLAG_DONT_VERIFY/||KF_FLAG_DONT_VERIFY flags for the |fix? Regards, -uta On 22.01.2013 15:14, Anthony Petrov wrote: > On 1/22/2013 13:48, Alexey Utkin wrote: >>> One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE >>> and I'm not sure if that is right because we don't want the JDK >>> creating the user's directory if it doesn't exist. >> That is a corner case. In the latest versions of OS, MS is trying to >> follow "lazy" strategy in everything. Nothing is been instantiating >> before the first use. But Java needs the home folder. >> So, we have the right to request the creation. That is OS solution to >> accept or decline the request. > > I agree with Alan. Java shouldn't forcibly create the user directory > if it doesn't exist yet. I suggest to pass 0 (zero) as the dwFlags > argument to ::SHGetKnownFolderPath(). The same applies to a call to > the ::SHGetFolderPathW(). getHomeFromShell32() may return NULL, so let > it do so if no user directory exists. > > -- > best regards, > Anthony > > From anthony.petrov at oracle.com Tue Jan 22 12:13:33 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Jan 2013 16:13:33 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FE7D60.4050405@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> Message-ID: <50FE826D.9060904@oracle.com> Well, I think this might be a good idea in order to preserve the performance of the former implementation. I'd suggest to introduce a boolean system property that, when specified, would omit these flags though, so that if someone happens to rely on this behavior, they could get it back by specifying the system property. And I actually doubt we would ever have to advertise this system property in real life, but it's good to feel safe anyway. At least that is what we would do in Client code. However, I'll leave it up to Alan to decide if this is a good solution for Core-libs. -- best regards, Anthony On 1/22/2013 15:52, Alexey Utkin wrote: > > Ok. Alan and Anthony, > would you like to be faster and follow optimistic strategy, that is > described here: > http://blogs.msdn.com/b/oldnewthing/archive/2011/01/05/10111777.aspx > > That do you thing about |CSIDL_FLAG_DONT_VERIFY/||KF_FLAG_DONT_VERIFY > flags for the |fix? > > Regards, > -uta > > On 22.01.2013 15:14, Anthony Petrov wrote: >> On 1/22/2013 13:48, Alexey Utkin wrote: >>>> One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE >>>> and I'm not sure if that is right because we don't want the JDK >>>> creating the user's directory if it doesn't exist. >>> That is a corner case. In the latest versions of OS, MS is trying to >>> follow "lazy" strategy in everything. Nothing is been instantiating >>> before the first use. But Java needs the home folder. >>> So, we have the right to request the creation. That is OS solution to >>> accept or decline the request. >> >> I agree with Alan. Java shouldn't forcibly create the user directory >> if it doesn't exist yet. I suggest to pass 0 (zero) as the dwFlags >> argument to ::SHGetKnownFolderPath(). The same applies to a call to >> the ::SHGetFolderPathW(). getHomeFromShell32() may return NULL, so let >> it do so if no user directory exists. >> >> -- >> best regards, >> Anthony >> >> > From alexey.utkin at oracle.com Tue Jan 22 12:28:33 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 22 Jan 2013 16:28:33 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FE826D.9060904@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> Message-ID: <50FE85F1.2080107@oracle.com> To be clear, there are three options for a shell call: 1. Force folder creation if not exists (KF_FLAG_CREATE) 2. Return existent folder if any (0) 3. Return folder name without verification (KF_FLAG_DONT_VERIFY) Current implementation is close to the last option (without verification). That is our choice for the fix? (My choice was #1) Regards, -uta On 22.01.2013 16:13, Anthony Petrov wrote: > Well, I think this might be a good idea in order to preserve the > performance of the former implementation. I'd suggest to introduce a > boolean system property that, when specified, would omit these flags > though, so that if someone happens to rely on this behavior, they > could get it back by specifying the system property. And I actually > doubt we would ever have to advertise this system property in real > life, but it's good to feel safe anyway. At least that is what we > would do in Client code. > > However, I'll leave it up to Alan to decide if this is a good solution > for Core-libs. > > -- > best regards, > Anthony > > On 1/22/2013 15:52, Alexey Utkin wrote: >> >> Ok. Alan and Anthony, >> would you like to be faster and follow optimistic strategy, that is >> described here: >> http://blogs.msdn.com/b/oldnewthing/archive/2011/01/05/10111777.aspx >> >> That do you thing about >> |CSIDL_FLAG_DONT_VERIFY/||KF_FLAG_DONT_VERIFY flags for the |fix? >> >> Regards, >> -uta >> >> On 22.01.2013 15:14, Anthony Petrov wrote: >>> On 1/22/2013 13:48, Alexey Utkin wrote: >>>>> One thing on SHGetKnownFolderPath is that you specify >>>>> KF_FLAG_CREATE and I'm not sure if that is right because we don't >>>>> want the JDK creating the user's directory if it doesn't exist. >>>> That is a corner case. In the latest versions of OS, MS is trying >>>> to follow "lazy" strategy in everything. Nothing is been >>>> instantiating before the first use. But Java needs the home folder. >>>> So, we have the right to request the creation. That is OS solution >>>> to accept or decline the request. >>> >>> I agree with Alan. Java shouldn't forcibly create the user directory >>> if it doesn't exist yet. I suggest to pass 0 (zero) as the dwFlags >>> argument to ::SHGetKnownFolderPath(). The same applies to a call to >>> the ::SHGetFolderPathW(). getHomeFromShell32() may return NULL, so >>> let it do so if no user directory exists. >>> >>> -- >>> best regards, >>> Anthony >>> >>> >> > > From joel.franck at oracle.com Tue Jan 22 12:47:45 2013 From: joel.franck at oracle.com (=?UTF-8?B?Sm9lbCBCb3JnZ3LDqW4tRnJhbmNr?=) Date: Tue, 22 Jan 2013 13:47:45 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations In-Reply-To: References: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> Message-ID: <50FE8A71.7080204@oracle.com> Hi Peter, Thanks for your comments, see inline, On 01/19/2013 06:11 PM, Peter Levart wrote: > I see, there is a dilema how to cache type annotations. To satisfy > single-annotation-returning methods and repeating annotation logic, a > HashMap would be a logical choice, but it has much bigger footprint than > simple arrays of annotations... > I don't prioritize footprint for classes that have runtime visible type annotations. Those classes should be very few, and as a user you are making an explicit choice of adding metadata when you use runtime visible (type) annotations. So here is my list of priorities (and by un-annotated I mean without runtime visible annotations): - Unannotated classes/fields/methods should have as small as possible extra footprint, this is most important. - Classes/fields/methods without type annotations should have negligible footprint over classes/fields/methods with only regular annotations. > I experimented with an idea of using a special purpose immutable Map > implementation: > > https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/UniqueIndex.java > > and: > > https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/AnnotationMap.java > > This is just a preview. I still have to create some tests to see how it > compares to HashMap. Being an immutable wrapper for a single array of > annotations it has a nice feature that a reference to it can be passed to > other threads via a data race with no danger of data inconsistency, which > simplifies caching mechanisms and helps scalability. > Might even be a space-saving replacement for existing HashMaps of > annotations. Depending on performance, of course. > What do you think? Is it worth pursuing this further? > I'd be very hesitant to introduce a new hashmap like type. Especially since IMHO footprint when we actually have annotations isn't as critical as when we are annotation free. My initial approach is probably to dust of your patches for an annotations cache on Class and adopt it for type annotations, and use on Field/Method/Constructor/(TypeVar). Thank you again for your work on this! cheers /Joel > Regards, Peter > > On Jan 17, 2013 5:24 PM, "Joel Borggr?n-Franck" > wrote: > > Hi, > > Here is a webrev for core reflection support for type annotations: > > http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/ > > This code is based on the tl/jdk repository, but in order to run the > tests you need a javac with type annotations support and also a recent > copy of the VM that includes this change set: > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282 > (This also means this code can't be pushed until all supporting pieces > are in place.) > > Type annotations are still a bit of a moving target so there will be > follow up work on this. There is no caching of annotations in this > version and I am not sure how we want to do the space/time trade of for > type annotations. > > cheers > /Joel > From Alan.Bateman at oracle.com Tue Jan 22 12:52:56 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2013 12:52:56 +0000 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FE85F1.2080107@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> Message-ID: <50FE8BA8.7070003@oracle.com> On 22/01/2013 12:28, Alexey Utkin wrote: > To be clear, there are three options for a shell call: > 1. Force folder creation if not exists (KF_FLAG_CREATE) > 2. Return existent folder if any (0) > 3. Return folder name without verification (KF_FLAG_DONT_VERIFY) > > Current implementation is close to the last option (without > verification). > That is our choice for the fix? (My choice was #1) > > Regards, > -uta The JDK doesn't strictly require the user's home directory to exist and it's possible in some environments for the home directory to become inaccessible during the lifetime of the VM. The main thing (I think) is that exceptions and messages are clear if there is an error accessing something in the home directory. So I think #3 is the right answer. As you point out, this is essentially long standing behavior. My concern with #2 is that it might hurt startup significantly when the home directory is remote. My concern with #1 is that I don't think the JDK should be the one to create the home directory (although in practice it would be very rare). -Alan. From alexey.utkin at oracle.com Tue Jan 22 15:30:15 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 22 Jan 2013 19:30:15 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FE8BA8.7070003@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> Message-ID: <50FEB087.8080801@oracle.com> On 22.01.2013 16:52, Alan Bateman wrote: > On 22/01/2013 12:28, Alexey Utkin wrote: >> To be clear, there are three options for a shell call: >> 1. Force folder creation if not exists (KF_FLAG_CREATE) >> 2. Return existent folder if any (0) >> 3. Return folder name without verification (KF_FLAG_DONT_VERIFY) >> >> Current implementation is close to the last option (without >> verification). >> That is our choice for the fix? (My choice was #1) >> >> Regards, >> -uta > The JDK doesn't strictly require the user's home directory to exist > and it's possible in some environments for the home directory to > become inaccessible during the lifetime of the VM. The main thing (I > think) is that exceptions and messages are clear if there is an error > accessing something in the home directory. > > So I think #3 is the right answer. As you point out, this is > essentially long standing behavior. My concern with #2 is that it > might hurt startup significantly when the home directory is remote. My > concern with #1 is that I don't think the JDK should be the one to > create the home directory (although in practice it would be very rare). Sounds reasonable. Let's follow that way. The #3 option is chosen. Suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.03/ Regards, -uta From anthony.petrov at oracle.com Tue Jan 22 15:45:00 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Jan 2013 19:45:00 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FEB087.8080801@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> <50FEB087.8080801@oracle.com> Message-ID: <50FEB3FC.7080809@oracle.com> Hi Alexey, The fix looks good from code logic perspective. I'm only concerned with whether we should use the __try/__except magic, or would it rather make sense to define: #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6) and guard the call to SHGetKnownFolderPath() with this check? This seems to be lighter than using the exception handling machinery from performance perspective, and IMO it would make the code cleaner/easier to read. -- best regards, Anthony On 1/22/2013 19:30, Alexey Utkin wrote: > On 22.01.2013 16:52, Alan Bateman wrote: >> On 22/01/2013 12:28, Alexey Utkin wrote: >>> To be clear, there are three options for a shell call: >>> 1. Force folder creation if not exists (KF_FLAG_CREATE) >>> 2. Return existent folder if any (0) >>> 3. Return folder name without verification (KF_FLAG_DONT_VERIFY) >>> >>> Current implementation is close to the last option (without >>> verification). >>> That is our choice for the fix? (My choice was #1) >>> >>> Regards, >>> -uta >> The JDK doesn't strictly require the user's home directory to exist >> and it's possible in some environments for the home directory to >> become inaccessible during the lifetime of the VM. The main thing (I >> think) is that exceptions and messages are clear if there is an error >> accessing something in the home directory. >> >> So I think #3 is the right answer. As you point out, this is >> essentially long standing behavior. My concern with #2 is that it >> might hurt startup significantly when the home directory is remote. My >> concern with #1 is that I don't think the JDK should be the one to >> create the home directory (although in practice it would be very rare). > Sounds reasonable. > Let's follow that way. The #3 option is chosen. > Suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.03/ > > Regards, > -uta From Alan.Bateman at oracle.com Tue Jan 22 15:58:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2013 15:58:34 +0000 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FEB3FC.7080809@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> <50FEB087.8080801@oracle.com> <50FEB3FC.7080809@oracle.com> Message-ID: <50FEB72A.3060103@oracle.com> On 22/01/2013 15:45, Anthony Petrov wrote: > Hi Alexey, > > The fix looks good from code logic perspective. > > I'm only concerned with whether we should use the __try/__except > magic, or would it rather make sense to define: > > #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6) > > and guard the call to SHGetKnownFolderPath() with this check? This > seems to be lighter than using the exception handling machinery from > performance perspective, and IMO it would make the code cleaner/easier > to read. I guess this comes down to whether Windows XP will still be important when jdk8 ships. I think the current webrev is okay, assuming that CSIDL_FLAG_DONT_VERIFY is a valid flag for SHGetFolderPathW. Alexey - I assume you'll test on several different editions of Windows before you push this. -Alan. From alexey.utkin at oracle.com Tue Jan 22 15:59:40 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 22 Jan 2013 19:59:40 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FEB3FC.7080809@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> <50FEB087.8080801@oracle.com> <50FEB3FC.7080809@oracle.com> Message-ID: <50FEB76C.5080907@oracle.com> Hi Anthony, The MS back porting process is not trivial. [SHGetKnownFolderPath] could be introduced is service pack for earlier OS. In my opinion that is better to use the function based on fact of present (here the question is more about Shell32.dll version, not OS version but they are in relation). Alan, that do you think about it? Regards, -uta On 22.01.2013 19:45, Anthony Petrov wrote: > Hi Alexey, > > The fix looks good from code logic perspective. > > I'm only concerned with whether we should use the __try/__except > magic, or would it rather make sense to define: > > #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6) > > and guard the call to SHGetKnownFolderPath() with this check? This > seems to be lighter than using the exception handling machinery from > performance perspective, and IMO it would make the code cleaner/easier > to read. > > -- > best regards, > Anthony > > On 1/22/2013 19:30, Alexey Utkin wrote: >> On 22.01.2013 16:52, Alan Bateman wrote: >>> On 22/01/2013 12:28, Alexey Utkin wrote: >>>> To be clear, there are three options for a shell call: >>>> 1. Force folder creation if not exists (KF_FLAG_CREATE) >>>> 2. Return existent folder if any (0) >>>> 3. Return folder name without verification (KF_FLAG_DONT_VERIFY) >>>> >>>> Current implementation is close to the last option (without >>>> verification). >>>> That is our choice for the fix? (My choice was #1) >>>> >>>> Regards, >>>> -uta >>> The JDK doesn't strictly require the user's home directory to exist >>> and it's possible in some environments for the home directory to >>> become inaccessible during the lifetime of the VM. The main thing (I >>> think) is that exceptions and messages are clear if there is an >>> error accessing something in the home directory. >>> >>> So I think #3 is the right answer. As you point out, this is >>> essentially long standing behavior. My concern with #2 is that it >>> might hurt startup significantly when the home directory is remote. >>> My concern with #1 is that I don't think the JDK should be the one >>> to create the home directory (although in practice it would be very >>> rare). >> Sounds reasonable. >> Let's follow that way. The #3 option is chosen. >> Suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.03/ >> >> Regards, >> -uta > > From alexey.utkin at oracle.com Tue Jan 22 16:14:05 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 22 Jan 2013 20:14:05 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FEB72A.3060103@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> <50FEB087.8080801@oracle.com> <50FEB3FC.7080809@oracle.com> <50FEB72A.3060103@oracle.com> Message-ID: <50FEBACD.4000300@oracle.com> On 22.01.2013 19:58, Alan Bateman wrote: > On 22/01/2013 15:45, Anthony Petrov wrote: >> Hi Alexey, >> >> The fix looks good from code logic perspective. >> >> I'm only concerned with whether we should use the __try/__except >> magic, or would it rather make sense to define: >> >> #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6) >> >> and guard the call to SHGetKnownFolderPath() with this check? This >> seems to be lighter than using the exception handling machinery from >> performance perspective, and IMO it would make the code >> cleaner/easier to read. > I guess this comes down to whether Windows XP will still be important > when jdk8 ships. I think the current webrev is okay, assuming that > CSIDL_FLAG_DONT_VERIFY is a valid flag for SHGetFolderPathW. > > Alexey - I assume you'll test on several different editions of Windows > before you push this. > Yes, I test it on Vista, XP and Win 2000. Can I push it to JDK8 after? > -Alan. From anthony.petrov at oracle.com Tue Jan 22 16:26:23 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 22 Jan 2013 20:26:23 +0400 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FEB76C.5080907@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> <50FEB087.8080801@oracle.com> <50FEB3FC.7080809@oracle.com> <50FEB76C.5080907@oracle.com> Message-ID: <50FEBDAF.9090903@oracle.com> Thanks for the clarification. If Alan is OK with that, then I'm fine with the current fix as well. -- best regards, Anthony On 1/22/2013 19:59, Alexey Utkin wrote: > Hi Anthony, > > The MS back porting process is not trivial. > [SHGetKnownFolderPath] could be introduced is service pack for earlier OS. > In my opinion that is better to use the function based on fact of > present (here the question is more about > Shell32.dll version, not OS version but they are in relation). > > Alan, that do you think about it? > > Regards, > -uta > > > On 22.01.2013 19:45, Anthony Petrov wrote: >> Hi Alexey, >> >> The fix looks good from code logic perspective. >> >> I'm only concerned with whether we should use the __try/__except >> magic, or would it rather make sense to define: >> >> #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6) >> >> and guard the call to SHGetKnownFolderPath() with this check? This >> seems to be lighter than using the exception handling machinery from >> performance perspective, and IMO it would make the code cleaner/easier >> to read. >> >> -- >> best regards, >> Anthony >> >> On 1/22/2013 19:30, Alexey Utkin wrote: >>> On 22.01.2013 16:52, Alan Bateman wrote: >>>> On 22/01/2013 12:28, Alexey Utkin wrote: >>>>> To be clear, there are three options for a shell call: >>>>> 1. Force folder creation if not exists (KF_FLAG_CREATE) >>>>> 2. Return existent folder if any (0) >>>>> 3. Return folder name without verification (KF_FLAG_DONT_VERIFY) >>>>> >>>>> Current implementation is close to the last option (without >>>>> verification). >>>>> That is our choice for the fix? (My choice was #1) >>>>> >>>>> Regards, >>>>> -uta >>>> The JDK doesn't strictly require the user's home directory to exist >>>> and it's possible in some environments for the home directory to >>>> become inaccessible during the lifetime of the VM. The main thing (I >>>> think) is that exceptions and messages are clear if there is an >>>> error accessing something in the home directory. >>>> >>>> So I think #3 is the right answer. As you point out, this is >>>> essentially long standing behavior. My concern with #2 is that it >>>> might hurt startup significantly when the home directory is remote. >>>> My concern with #1 is that I don't think the JDK should be the one >>>> to create the home directory (although in practice it would be very >>>> rare). >>> Sounds reasonable. >>> Let's follow that way. The #3 option is chosen. >>> Suggested fix: >>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6519127/webrev.03/ >>> >>> Regards, >>> -uta >> >> > From maurizio.cimadamore at oracle.com Tue Jan 22 16:29:26 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 22 Jan 2013 16:29:26 +0000 Subject: hg: jdk8/tl/langtools: 8006673: TargetType52 fails because of bad golden file Message-ID: <20130122162931.87DFD47461@hg.openjdk.java.net> Changeset: be443002e970 Author: mcimadamore Date: 2013-01-22 16:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be443002e970 8006673: TargetType52 fails because of bad golden file Summary: Fix golden file in negative test Reviewed-by: jjg ! test/tools/javac/lambda/TargetType52.out From maurizio.cimadamore at oracle.com Tue Jan 22 16:40:15 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 22 Jan 2013 16:40:15 +0000 Subject: hg: jdk8/tl/langtools: 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Message-ID: <20130122164020.3A9D347463@hg.openjdk.java.net> Changeset: b61e5f801f7c Author: mcimadamore Date: 2013-01-22 16:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b61e5f801f7c 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Summary: Lambda desugaring generates spurious references to 'this' in static contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaExpr21.java From peter.levart at gmail.com Tue Jan 22 17:01:04 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Jan 2013 18:01:04 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations In-Reply-To: <50FE8A71.7080204@oracle.com> References: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> <50FE8A71.7080204@oracle.com> Message-ID: <50FEC5D0.4070307@gmail.com> On 01/22/2013 01:47 PM, Joel Borggr?n-Franck wrote: > Hi Peter, > > Thanks for your comments, see inline, > > On 01/19/2013 06:11 PM, Peter Levart wrote: > >> I see, there is a dilema how to cache type annotations. To satisfy >> single-annotation-returning methods and repeating annotation logic, a >> HashMap would be a logical choice, but it has much bigger footprint than >> simple arrays of annotations... >> > > I don't prioritize footprint for classes that have runtime visible > type annotations. Those classes should be very few, and as a user you > are making an explicit choice of adding metadata when you use runtime > visible (type) annotations. > > So here is my list of priorities (and by un-annotated I mean without > runtime visible annotations): > > - Unannotated classes/fields/methods should have as small as possible > extra footprint, this is most important. Hello Joel, I imagine there will be additional places where references to Map, Annotation> will be added to hold cached annotations. To satisfy your priority #1 I would consistently make sure that when there are no annotations to put into the map, a singleton Collections.emptyMap() reference is put in place. This is currently not so for regular annotations (should be corrected). I know of runtime tools that "scan" classes for particular annotations, just to find out that majority of them are without annotations. If empty instances of HashMap(16) pop-up as a result of such scan, lots of memory is wasted. > > - Classes/fields/methods without type annotations should have > negligible footprint over classes/fields/methods with only regular > annotations. You meant "Classes/fields/methods *with* type annotations should have negligible footprint over classes/fields/methods with only regular annotations", right? Regards, Peter > >> I experimented with an idea of using a special purpose immutable Map >> implementation: >> >> https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/UniqueIndex.java >> >> >> and: >> >> https://github.com/plevart/jdk8-tl/blob/anno-map/jdk/src/share/classes/sun/reflect/annotation/AnnotationMap.java >> >> >> This is just a preview. I still have to create some tests to see how it >> compares to HashMap. Being an immutable wrapper for a single array of >> annotations it has a nice feature that a reference to it can be >> passed to >> other threads via a data race with no danger of data inconsistency, >> which >> simplifies caching mechanisms and helps scalability. >> Might even be a space-saving replacement for existing HashMaps of >> annotations. Depending on performance, of course. >> What do you think? Is it worth pursuing this further? >> > > I'd be very hesitant to introduce a new hashmap like type. Especially > since IMHO footprint when we actually have annotations isn't as > critical as when we are annotation free. > > My initial approach is probably to dust of your patches for an > annotations cache on Class and adopt it for type annotations, and use > on Field/Method/Constructor/(TypeVar). > > Thank you again for your work on this! > > cheers > /Joel > >> Regards, Peter >> >> On Jan 17, 2013 5:24 PM, "Joel Borggr?n-Franck" > > wrote: >> >> Hi, >> >> Here is a webrev for core reflection support for type annotations: >> >> http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/ >> >> This code is based on the tl/jdk repository, but in order to run the >> tests you need a javac with type annotations support and also a >> recent >> copy of the VM that includes this change set: >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282 >> (This also means this code can't be pushed until all supporting >> pieces >> are in place.) >> >> Type annotations are still a bit of a moving target so there will be >> follow up work on this. There is no caching of annotations in this >> version and I am not sure how we want to do the space/time trade >> of for >> type annotations. >> >> cheers >> /Joel >> From joel.franck at oracle.com Tue Jan 22 17:08:46 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 22 Jan 2013 18:08:46 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations In-Reply-To: <50FEC5D0.4070307@gmail.com> References: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> <50FE8A71.7080204@oracle.com> <50FEC5D0.4070307@gmail.com> Message-ID: <52AF7D73-A144-4079-9EEF-9766E839E922@oracle.com> Hi, On Jan 22, 2013, at 6:01 PM, Peter Levart wrote: > On 01/22/2013 01:47 PM, Joel Borggr?n-Franck wrote: >> Hi Peter, >> >> Thanks for your comments, see inline, >> >> On 01/19/2013 06:11 PM, Peter Levart wrote: >> >>> I see, there is a dilema how to cache type annotations. To satisfy >>> single-annotation-returning methods and repeating annotation logic, a >>> HashMap would be a logical choice, but it has much bigger footprint than >>> simple arrays of annotations... >>> >> >> I don't prioritize footprint for classes that have runtime visible type annotations. Those classes should be very few, and as a user you are making an explicit choice of adding metadata when you use runtime visible (type) annotations. >> >> So here is my list of priorities (and by un-annotated I mean without runtime visible annotations): >> >> - Unannotated classes/fields/methods should have as small as possible extra footprint, this is most important. > > Hello Joel, > > I imagine there will be additional places where references to Map, Annotation> will be added to hold cached annotations. To satisfy your priority #1 I would consistently make sure that when there are no annotations to put into the map, a singleton Collections.emptyMap() reference is put in place. This is currently not so for regular annotations (should be corrected). I know of runtime tools that "scan" classes for particular annotations, just to find out that majority of them are without annotations. If empty instances of HashMap(16) pop-up as a result of such scan, lots of memory is wasted. > Good suggestion. >> >> - Classes/fields/methods without type annotations should have negligible footprint over classes/fields/methods with only regular annotations. > > You meant "Classes/fields/methods *with* type annotations should have negligible footprint over classes/fields/methods with only regular annotations", right? > No :) As I suspect class/filed/methods with runtime visible regular annotations will be 100x (or 1000x??) more common than with runtime visible type annotations the most common scenario will be 1) No annotations 2) Only regular annotations So there should be very little overhead from having no type annotations. IE in the order of an extra pointer that is null. cheers /Joel From Alan.Bateman at oracle.com Tue Jan 22 17:18:15 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2013 17:18:15 +0000 Subject: Review request: JDK-6519127 Vista: user.home property not set correctly In-Reply-To: <50FEBACD.4000300@oracle.com> References: <50F96AB3.4000207@oracle.com> <50F96D25.8000308@oracle.com> <50F97AFD.20800@oracle.com> <50FD6661.6040304@oracle.com> <50FE605D.6080400@oracle.com> <50FE74A0.7000208@oracle.com> <50FE7D60.4050405@oracle.com> <50FE826D.9060904@oracle.com> <50FE85F1.2080107@oracle.com> <50FE8BA8.7070003@oracle.com> <50FEB087.8080801@oracle.com> <50FEB3FC.7080809@oracle.com> <50FEB72A.3060103@oracle.com> <50FEBACD.4000300@oracle.com> Message-ID: <50FEC9D7.9010805@oracle.com> On 22/01/2013 16:14, Alexey Utkin wrote: > On 22.01.2013 19:58, Alan Bateman wrote: >> On 22/01/2013 15:45, Anthony Petrov wrote: >>> Hi Alexey, >>> >>> The fix looks good from code logic perspective. >>> >>> I'm only concerned with whether we should use the __try/__except >>> magic, or would it rather make sense to define: >>> >>> #define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) >= 6) >>> >>> and guard the call to SHGetKnownFolderPath() with this check? This >>> seems to be lighter than using the exception handling machinery from >>> performance perspective, and IMO it would make the code >>> cleaner/easier to read. >> I guess this comes down to whether Windows XP will still be important >> when jdk8 ships. I think the current webrev is okay, assuming that >> CSIDL_FLAG_DONT_VERIFY is a valid flag for SHGetFolderPathW. >> >> Alexey - I assume you'll test on several different editions of >> Windows before you push this. >> > Yes, I test it on Vista, XP and Win 2000. > Can I push it to JDK8 after? If you've tested it on all these versions of Windows then I think what you have is fine. -Alan From peter.levart at gmail.com Tue Jan 22 17:27:56 2013 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 Jan 2013 18:27:56 +0100 Subject: Request for review: 8004698: Implement Core Reflection for Type Annotations In-Reply-To: <52AF7D73-A144-4079-9EEF-9766E839E922@oracle.com> References: <44120FFD-DAF6-4222-B184-AF5BA475D08E@oracle.com> <50FE8A71.7080204@oracle.com> <50FEC5D0.4070307@gmail.com> <52AF7D73-A144-4079-9EEF-9766E839E922@oracle.com> Message-ID: <50FECC1C.4020703@gmail.com> On 01/22/2013 06:08 PM, Joel Borggr?n-Franck wrote: > Hi, > > On Jan 22, 2013, at 6:01 PM, Peter Levart wrote: > >> On 01/22/2013 01:47 PM, Joel Borggr?n-Franck wrote: >>> Hi Peter, >>> >>> Thanks for your comments, see inline, >>> >>> On 01/19/2013 06:11 PM, Peter Levart wrote: >>> >>>> I see, there is a dilema how to cache type annotations. To satisfy >>>> single-annotation-returning methods and repeating annotation logic, a >>>> HashMap would be a logical choice, but it has much bigger footprint than >>>> simple arrays of annotations... >>>> >>> I don't prioritize footprint for classes that have runtime visible type annotations. Those classes should be very few, and as a user you are making an explicit choice of adding metadata when you use runtime visible (type) annotations. >>> >>> So here is my list of priorities (and by un-annotated I mean without runtime visible annotations): >>> >>> - Unannotated classes/fields/methods should have as small as possible extra footprint, this is most important. >> Hello Joel, >> >> I imagine there will be additional places where references to Map, Annotation> will be added to hold cached annotations. To satisfy your priority #1 I would consistently make sure that when there are no annotations to put into the map, a singleton Collections.emptyMap() reference is put in place. This is currently not so for regular annotations (should be corrected). I know of runtime tools that "scan" classes for particular annotations, just to find out that majority of them are without annotations. If empty instances of HashMap(16) pop-up as a result of such scan, lots of memory is wasted. >> > Good suggestion. > >>> - Classes/fields/methods without type annotations should have negligible footprint over classes/fields/methods with only regular annotations. >> You meant "Classes/fields/methods *with* type annotations should have negligible footprint over classes/fields/methods with only regular annotations", right? >> > No :) > > As I suspect class/filed/methods with runtime visible regular annotations will be 100x (or 1000x??) more common than with runtime visible type annotations the most common scenario will be > > 1) No annotations > 2) Only regular annotations > > So there should be very little overhead from having no type annotations. IE in the order of an extra pointer that is null. Ah, I understand that sentence now ;-). ... extra pointer that is null (not cached yet) or Collections.emptyMap() (cached but empty).... Regards, Peter > > cheers > /Joel From eric.mccorkle at oracle.com Tue Jan 22 18:54:53 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 22 Jan 2013 13:54:53 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50F87323.9040505@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F87323.9040505@oracle.com> Message-ID: <50FEE07D.9040902@oracle.com> Are there any additional comments? I'd like to get this pushed today. On 01/17/13 16:54, Eric McCorkle wrote: > After (lengthy) examination, it seems that properly addressing the > synthesized parameters issue will require more changes to javac. In > light of this, I think that the synthesized parameter logic should go in > a follow-up enhancement. I have created JDK-8006345 to track this issue: > > http://bugs.sun.com/view_bug.do?bug_id=8006345 > > Therefore, I've rolled back the changes I was making which would have > synthesized parameters in the reflection API itself, and updated the > webrev. Please examine for any additional concerns. > > > On 01/11/13 13:27, Joe Darcy wrote: >> Hi Eric, >> >> Taking another look at the code, some extra logic / checking is needed >> in cases where the number of source parameters (non-synthetic and >> non-synthesized) disagrees with the number of actual parameters at a >> class file level. >> >> For example, if the single source parameter of an inner class >> constructor is annotated, the annotation should be associated with the >> *second* parameter since the first class file parameter is a synthesized >> constructor added by the compiler. I think generally annotations should >> not be associated with synthesized or synthetic parameters. >> >> -Joe >> >> On 1/11/2013 9:03 AM, Eric McCorkle wrote: >>> Update should be visible now. >>> >>> On 01/11/13 11:54, Vitaly Davidovich wrote: >>>> Yes that's exactly what I'm looking for as well. >>>> >>>> Sent from my phone >>>> >>>> On Jan 11, 2013 11:25 AM, "Peter Levart" >>> > wrote: >>>> >>>> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >>>> >>>> The webrev has been updated again. >>>> >>>> The multiple writes to parameters have been removed, and the >>>> tests have >>>> been expanded to look at inner classes, and to test modifiers. >>>> >>>> Please look over it again. >>>> >>>> >>>> Hello Eric, >>>> >>>> You still have 2 reads of volatile even in fast path. I would do it >>>> this way: >>>> >>>> >>>> private Parameter[] privateGetParameters() { >>>> Parameter[] tmp = parameters; // one and only read >>>> if (tmp != null) >>>> return tmp; >>>> >>>> // Otherwise, go to the JVM to get them >>>> tmp = getParameters0(); >>>> >>>> // If we get back nothing, then synthesize parameters >>>> if (tmp == null) { >>>> final int num = getParameterCount(); >>>> tmp = new Parameter[num]; >>>> for (int i = 0; i < num; i++) >>>> // TODO: is there a way to synthetically derive the >>>> // modifiers? Probably not in the general case, since >>>> // we'd have no way of knowing about them, but there >>>> // may be specific cases. >>>> tmp[i] = new Parameter("arg" + i, 0, this, i); >>>> // This avoids possible races from seeing a >>>> // half-initialized parameters cache. >>>> } >>>> >>>> parameters = tmp; >>>> >>>> return tmp; >>>> } >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> Test-wise, I've got a clean run on JPRT (there were some >>>> failures in >>>> lambda stuff, but I've been seeing that for some time now). >>>> >>>> On 01/10/13 21:47, Eric McCorkle wrote: >>>> >>>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>>> >>>> Hi Eric, >>>> >>>> Parameter.equals() doesn't need null check - instanceof >>>> covers that already. >>>> >>>> Removed. >>>> >>>> Maybe this has been mentioned already, but personally >>>> I'm not a fan of >>>> null checks such as "if (null == x)" - I prefer the >>>> null >>>> on the right >>>> hand side, but that's just stylistic. >>>> >>>> Changed. >>>> >>>> Perhaps I'm looking at a stale webrev but >>>> Executable.__privateGetParameters() reads and writes >>>> from/to the volatile >>>> field more than once. I think Peter already mentioned >>>> that it should >>>> use one read into a local and one write to publish the >>>> final version to >>>> the field (it can return the temp as well). >>>> >>>> You weren't. From a pure correctness standpoint, there is >>>> nothing wrong >>>> with what is there. getParameters0 is a constant >>>> function, and >>>> parameters is writable only if null. Hence, we only every >>>> see one >>>> nontrivial write to it. >>>> >>>> But you are right, it should probably be reduced to a >>>> single >>>> write, for >>>> performance reasons (to avoid unnecessary memory barriers). >>>> Therefore, >>>> I changed it. >>>> >>>> However, I won't be able to refresh the webrev until >>>> tomorrow. >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>>> >>> >>>> >>> >> wrote: >>>> >>>> The webrev has been refreshed with the solution I >>>> describe below >>>> implemented. Please make additional comments. >>>> >>>> On 01/10/13 17:29, Eric McCorkle wrote: >>>> > Good catch there. I made the field volatile, >>>> and >>>> I also did the same >>>> > with the cache fields in Parameter. >>>> > >>>> > It is possible with what exists that you could >>>> wind up with multiple >>>> > copies of identical parameter objects in >>>> existence. It goes something >>>> > like this >>>> > >>>> > thread A sees Executable.parameters is null, >>>> goes >>>> into the VM to >>>> get them >>>> > thread B sees Executable.parameters is null, >>>> goes >>>> into the VM to >>>> get them >>>> > thread A stores to Executable.parameters >>>> > thread B stores to Executable.parameters >>>> > >>>> > Since Parameters is immutable (except for its >>>> caches, which will >>>> always >>>> > end up containing the same things), this >>>> *should* >>>> have no visible >>>> > effects, unless someone does == instead of >>>> .equals. >>>> > >>>> > This can be avoided by doing a CAS, which is >>>> more >>>> expensive >>>> execution-wise. >>>> > >>>> > My vote is to *not* do a CAS, and accept that >>>> (in >>>> extremely rare >>>> cases, >>>> > even as far as concurrency-related anomalies >>>> go), >>>> you may end up with >>>> > duplicates, and document that very well. >>>> > >>>> > Thoughts? >>>> > >>>> > On 01/10/13 16:10, Peter Levart wrote: >>>> >> Hello Eric, >>>> >> >>>> >> I have another one. Although not very likely, >>>> the reference to >>>> the same >>>> >> Method/Constructor can be shared among multiple >>>> threads. The >>>> publication >>>> >> of a parameters array should therefore be >>>> performed via a >>>> volatile write >>>> >> / volatile read, otherwise it can happen that >>>> some thread sees >>>> >> half-initialized array content. The >>>> 'parameters' >>>> field in Executable >>>> >> should be declared as volatile and there should >>>> be a single read >>>> from it >>>> >> and a single write to it in the >>>> privateGetParameters() method >>>> (you need >>>> >> a local variable to hold intermediate >>>> states)... >>>> >> >>>> >> Regards, Peter >>>> >> >>>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>>> >>> Thanks to all for initial reviews; however, it >>>> appears that the >>>> version >>>> >>> you saw was somewhat stale. I've applied your >>>> comments (and some >>>> >>> changes that I'd made since the version that >>>> was posted). >>>> >>> >>>> >>> Please take a second look. >>>> >>> >>>> >>> Thanks, >>>> >>> Eric >>>> >>> >>>> >>> >>>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>> >>>> Hello Eric, >>>> >>>> >>>> >>>> You must have missed my comment from the >>>> previous webrev: >>>> >>>> >>>> >>>> 292 private Parameter[] >>>> privateGetParameters() { >>>> >>>> 293 if (null != parameters) >>>> >>>> 294 return parameters.get(); >>>> >>>> >>>> >>>> If/when the 'parameters' SoftReference is >>>> cleared, the method >>>> will be >>>> >>>> returning null forever after... >>>> >>>> >>>> >>>> You should also retrieve the referent and >>>> check for it's >>>> presence before >>>> >>>> returning it: >>>> >>>> >>>> >>>> Parameter[] res; >>>> >>>> if (parameters != null && (res = >>>> parameters.get()) != null) >>>> >>>> return res; >>>> >>>> ... >>>> >>>> ... >>>> >>>> >>>> >>>> Regards, Peter >>>> >>>> >>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>> >>>>> Hello, >>>> >>>>> >>>> >>>>> Please review the core reflection API >>>> implementation of parameter >>>> >>>>> reflection. This is the final component of >>>> method parameter >>>> reflection. >>>> >>>>> This was posted for review before, then >>>> delayed until the >>>> check-in for >>>> >>>>> JDK-8004728 (hotspot support for parameter >>>> reflection), which >>>> occurred >>>> >>>>> yesterday. >>>> >>>>> >>>> >>>>> Note: The check-in of JDK-8004728 was into >>>> hsx/hotspot-rt, *not* >>>> >>>>> jdk8/tl; therefore, it may be a while before >>>> the changeset >>>> makes its way >>>> >>>>> into jdk8/tl. >>>> >>>>> >>>> >>>>> Also note: since the check-in of JDK-8004727 >>>> (javac support for >>>> >>>>> parameter reflection), there has been a >>>> failure in the tests for >>>> >>>>> Pack200. This is being addressed in a fix >>>> contributed by >>>> Kumar, which I >>>> >>>>> believe has also been posted for review. >>>> >>>>> >>>> >>>>> The open webrev is here: >>>> >>>>> >>>> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >>>> >>>> >>>>> >>>> >>>>> The feature request is here: >>>> >>>>> >>>> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >>>> >>>> >>>>> >>>> >>>>> The latest version of the spec can be >>>> found here: >>>> >>>>> >>>> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> Thanks, >>>> >>>>> Eric >>>> >> >>>> >>>> >> From xueming.shen at oracle.com Tue Jan 22 19:09:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 22 Jan 2013 11:09:36 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F9E2CE.9090500@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> Message-ID: <50FEE3F0.40906@oracle.com> Hi, Webrev has been updated to address the build issue in the new build infra. M (1) added the java.time packages into common/makefiles.javadoc/CORE_PKGS.gmk to be included into ct.sym http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/ (2) not sure which one should be used for lib/tzdb.jar. It appears the tzdb.jar will not be picked for "images" if use $(JDK_OUTPUTDIR)/lib and it does not get copied for "overlay-image", if use $(IMAGES_OUTPUTDIR)/lib. Guess something need to be tweak in Images.gmk. But I'm running out of time, so now I copy the tzdb into both to make both happy for M6. http://cr.openjdk.java.net/~sherman/8003680/webrev/makefiles/GendataTZDB.gmk.html Thanks, -Sherman On 01/18/2013 04:03 PM, Xueming Shen wrote: > Hi, > > The webrev and Javadoc have been updated based on the feedback > we received so far. > > The main stopper is the timezone data compiler had dependency on > new threeten classes (and these classes themselves depend on new > JDK8 features). The compiler has been re-written to remove the dependency > and now work as a "normal" build tool at make/tool. Build-infra team > please help take a look if all our makefile changes are OK for the new/ > old build system. > > http://cr.openjdk.java.net/~sherman/8003680/webrev > http://cr.openjdk.java.net/~sherman/8003680/javadoc > > Thanks, > Sherman > > On 01/15/2013 04:13 PM, Xueming Shen wrote: >> Hi, >> >> The Threeten project [1] is planned to be integrated into OpenJDK8 M6 milestone. >> >> Here is the webrev >> http://cr.openjdk.java.net/~sherman/8003680/webrev >> >> and the latest javadoc >> http://cr.openjdk.java.net/~sherman/8003680/javadoc >> >> Review comments can be sent to the threeten-dev email list [2] and/or >> core-libs-dev email list[3]. >> >> Thanks, >> Sherman >> >> [1] http://openjdk.java.net/projects/threeten >> [2] threeten-dev @ openjdk.java.net >> [3] core-libs-dev @ openjdk.java.net >> >> > From jim.gish at oracle.com Tue Jan 22 19:40:26 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 22 Jan 2013 14:40:26 -0500 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent In-Reply-To: <50EEE585.6000800@oracle.com> References: <50EDF350.7050302@oracle.com> <50EEE585.6000800@oracle.com> Message-ID: <50FEEB2A.5030509@oracle.com> I've made the changes as suggested by Mike, and this has now been approved by CCC. Could someone please give it one more look and push it for me, please? Thanks, Jim http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ On 01/10/2013 11:00 AM, Jim Gish wrote: > Stephen, > Currently here's (a sampling) of how the other methods work. > Although most check indices first, not all do... (The original bug was > about this very inconsistency, however one answer given to it was that > in general we don't say anything about order of exceptions). However, > given that most of the methods do index checking first, I think I > agree with Mike on this one. > > Jim > > getChars(int srcBegin, int srcEnd, char[]dst, int dstBegin) > - will check for srcBegin, srcEnd first and throw > StringIndexOutOfBoundsException > - then System.arraycopy checks for null and throws NPE > > replace(int start, int end, String str) > - same as above (checking start and end first) > > insert(int index, char[] str, int offset, int len) > - same as above (checking index and offset first) > > insert(int offset, char[] str) > - same (checking offset first) > > String(char value[], int offset, int count) > - same > String(int[] codePoints, int offset, int count) > - same > String(byte ascii[], int hibyte, int offset, int count) > - same > String(byte bytes[], int offset, int length, String charsetName) > - same > > * String(byte bytes[], int offset, int length, Charset charset) > - checks charset == null first! > - then checks offset and length > - and then checks bytes==null > > String.getChars(char dst[], int dstBegin) > - checks for dst==null first > - then for bad and throw ArrayIndexOutOfBoundsException > > > On 01/10/2013 06:47 AM, Stephen Colebourne wrote: >> I would encourage null checking to be done first, rather than >> sometimes getting StringIndexOutOfBoundsException for a null input. >> Reasoning about the JDK methods is much easier that way around. >> >> Stephen >> >> >> On 9 January 2013 23:09, Mike Duigou wrote: >>> AbstractStringBuilder probably needs the "Unless otherwise noted," >>> blanket statement as well (Same as StringBuffer/StringBuilder) >>> >>> You might want to move the Objects.requireNonNull(dst); in >>> String.getBytes() to after the existing checks so as not to >>> unnecessarily change the exception thrown for bad inputs. An >>> exception will still be thrown but some bad code may anticipate >>> StringIndexOutOfBoundsException rather than NPE. This is a very >>> minor matter though. >>> >>> Otherwise, it looks good. >>> >>> Mike >>> >>> On Jan 9 2013, at 14:46 , Jim Gish wrote: >>> >>>> Please review the following: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ >>>> >>>> >>>> Here's a specdiff: >>>> http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ >>>> >>>> >>>> >>>> Summary: This change replaces java/lang/*String*.java javadoc, >>>> method-specific @throws NullPointerException clauses with blanket >>>> null-handling statements like that currently in String.java >>>> >>>> That was motivated by a discussion awhile back, strongly favoring a >>>> blanket statement over individual @throws clauses. >>>> >>>> For String, the following blanket statement is already in place: >>>> >>>> *

Unless otherwise noted, passing a null argument to a >>>> constructor >>>> * or method in this class will cause a {@link NullPointerException} >>>> to be >>>> * thrown. >>>> >>>> >>>> However, despite the blanket statement, the following methods also >>>> have @throws clauses: >>>> >>>> public boolean contains(java.lang.CharSequence s) >>>> >>>> Throws: >>>> |java.lang.NullPointerException|- if|s|is|null| >>>> --------------------------------------------------------------- >>>> >>>> public staticString >>>> >>>> format(String >>>> >>>> format, >>>> java.lang.Object... args) >>>> >>>> >>>> Throws: >>>> |java.lang.NullPointerException|- If the|format|is|null >>>> |----------------------------------------------------------------------- >>>> >>>> || >>>> >>>> public staticString >>>> >>>> format(java.util.Locale l, >>>> String >>>> >>>> format, >>>> java.lang.Object... args) >>>> >>>> Throws: >>>> |java.lang.NullPointerException|- If the|format|is|null >>>> |-------------------------------------------------------------------------- >>>> >>>> All of the above are properly specified with the blanket statement >>>> or other parts of their spec (such as format w.r.t. null Locale) >>>> and the @throws can safely be removed. >>>> >>>> Because the blanket statement is already in effect for String.java, >>>> I wrote tests for all methods/constructors to ensure compliance. >>>> Running them revealed the following: >>>> >>>> public void getBytes(int srcBegin, int srcEnd, byte dst[], int >>>> dstBegin) >>>> - I would expect an NPE to be thrown if dst == null. However, this >>>> isn't always the case. If dst isn't accessed because of the values >>>> of the other parameters (as in getBytes(1,2,(byte[]null,1), then no >>>> NPE is thrown. >>>> - This brings up the question as to the correctness of the blanket >>>> statement w.r.t. this method. I think this method (and others like >>>> it) should use Objects.requireNonNull(dst). (The correspoding >>>> method public void getChars(int srcBegin, int srcEnd, char dst[], >>>> int dstBegin), does always throw NPE for dst==null) >>>> >>>> All other methods/constructors in StringBuffer and StringBuilder >>>> either correctly state null-handling behavior that differs from the >>>> blanket statement or are correct w.r.t. the blanket statement. >>>> >>>> This has been reviewed by the JCK team. It will require CCC >>>> approval (because of the new blanket statement, and the fact that >>>> some of the existing methods were previously silent on null >>>> handling, but all already conform to the blanket statement). >>>> >>>> Thanks, >>>> Jim Gish >>>> >>>> >>>> -- >>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>>> Oracle Java Platform Group | Core Libraries Team >>>> 35 Network Drive >>>> Burlington, MA 01803 >>>> jim.gish at oracle.com >>>> >>>> -- >>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>>> Oracle Java Platform Group | Core Libraries Team >>>> 35 Network Drive >>>> Burlington, MA 01803 >>>> jim.gish at oracle.com >>>> > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From Alan.Bateman at oracle.com Tue Jan 22 19:52:35 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2013 19:52:35 +0000 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50FEE3F0.40906@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> <50FEE3F0.40906@oracle.com> Message-ID: <50FEEE03.4080701@oracle.com> On 22/01/2013 19:09, Xueming Shen wrote: > Hi, > > Webrev has been updated to address the build issue in the > new build infra. M > > (1) added the java.time packages into > common/makefiles.javadoc/CORE_PKGS.gmk > to be included into ct.sym > > http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/ > > (2) not sure which one should be used for lib/tzdb.jar. It > appears > the tzdb.jar will not be picked for "images" if use > $(JDK_OUTPUTDIR)/lib and > it does not get copied for "overlay-image", if use > $(IMAGES_OUTPUTDIR)/lib. > Guess something need to be tweak in Images.gmk. But I'm running out of > time, > so now I copy the tzdb into both to make both happy for M6. > > http://cr.openjdk.java.net/~sherman/8003680/webrev/makefiles/GendataTZDB.gmk.html > cc'ing build-dev as I think you need Erik or Kelly to comment on this. I'm not an expert on the new build but I think you just need to add something like this to CreateJars.gmk: $(IMAGES_OUTPUTDIR)/lib/tzdb.jar: $(JDK_OUTPUTDIR)/lib/tzdb.jar $(install-file) JARS += $(IMAGES_OUTPUTDIR)/lib/tzdb.jar and remove the copying that you are doing in GendataTZDB.gmk. I looked at the changes to the top-level repo and the changes look fine to me. -Alan. From jim.gish at oracle.com Tue Jan 22 19:54:30 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 22 Jan 2013 14:54:30 -0500 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent In-Reply-To: <50FEEB2A.5030509@oracle.com> References: <50EDF350.7050302@oracle.com> <50EEE585.6000800@oracle.com> <50FEEB2A.5030509@oracle.com> Message-ID: <50FEEE76.9090304@oracle.com> change set/patch attached for pushing. Thanks, Jim On 01/22/2013 02:40 PM, Jim Gish wrote: > I've made the changes as suggested by Mike, and this has now been > approved by CCC. Could someone please give it one more look and push > it for me, please? > > Thanks, > Jim > > http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ > > > On 01/10/2013 11:00 AM, Jim Gish wrote: >> Stephen, >> Currently here's (a sampling) of how the other methods work. >> Although most check indices first, not all do... (The original bug >> was about this very inconsistency, however one answer given to it was >> that in general we don't say anything about order of exceptions). >> However, given that most of the methods do index checking first, I >> think I agree with Mike on this one. >> >> Jim >> >> getChars(int srcBegin, int srcEnd, char[]dst, int dstBegin) >> - will check for srcBegin, srcEnd first and throw >> StringIndexOutOfBoundsException >> - then System.arraycopy checks for null and throws NPE >> >> replace(int start, int end, String str) >> - same as above (checking start and end first) >> >> insert(int index, char[] str, int offset, int len) >> - same as above (checking index and offset first) >> >> insert(int offset, char[] str) >> - same (checking offset first) >> >> String(char value[], int offset, int count) >> - same >> String(int[] codePoints, int offset, int count) >> - same >> String(byte ascii[], int hibyte, int offset, int count) >> - same >> String(byte bytes[], int offset, int length, String charsetName) >> - same >> >> * String(byte bytes[], int offset, int length, Charset charset) >> - checks charset == null first! >> - then checks offset and length >> - and then checks bytes==null >> >> String.getChars(char dst[], int dstBegin) >> - checks for dst==null first >> - then for bad and throw ArrayIndexOutOfBoundsException >> >> >> On 01/10/2013 06:47 AM, Stephen Colebourne wrote: >>> I would encourage null checking to be done first, rather than >>> sometimes getting StringIndexOutOfBoundsException for a null input. >>> Reasoning about the JDK methods is much easier that way around. >>> >>> Stephen >>> >>> >>> On 9 January 2013 23:09, Mike Duigou wrote: >>>> AbstractStringBuilder probably needs the "Unless otherwise noted," >>>> blanket statement as well (Same as StringBuffer/StringBuilder) >>>> >>>> You might want to move the Objects.requireNonNull(dst); in >>>> String.getBytes() to after the existing checks so as not to >>>> unnecessarily change the exception thrown for bad inputs. An >>>> exception will still be thrown but some bad code may anticipate >>>> StringIndexOutOfBoundsException rather than NPE. This is a very >>>> minor matter though. >>>> >>>> Otherwise, it looks good. >>>> >>>> Mike >>>> >>>> On Jan 9 2013, at 14:46 , Jim Gish wrote: >>>> >>>>> Please review the following: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ >>>>> >>>>> Here's a specdiff: >>>>> http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ >>>>> >>>>> >>>>> >>>>> Summary: This change replaces java/lang/*String*.java javadoc, >>>>> method-specific @throws NullPointerException clauses with blanket >>>>> null-handling statements like that currently in String.java >>>>> >>>>> That was motivated by a discussion awhile back, strongly favoring >>>>> a blanket statement over individual @throws clauses. >>>>> >>>>> For String, the following blanket statement is already in place: >>>>> >>>>> *

Unless otherwise noted, passing a null argument to >>>>> a constructor >>>>> * or method in this class will cause a {@link >>>>> NullPointerException} to be >>>>> * thrown. >>>>> >>>>> >>>>> However, despite the blanket statement, the following methods also >>>>> have @throws clauses: >>>>> >>>>> public boolean contains(java.lang.CharSequence s) >>>>> >>>>> Throws: >>>>> |java.lang.NullPointerException|- if|s|is|null| >>>>> --------------------------------------------------------------- >>>>> >>>>> public staticString >>>>> >>>>> format(String >>>>> >>>>> format, >>>>> java.lang.Object... args) >>>>> >>>>> >>>>> Throws: >>>>> |java.lang.NullPointerException|- If the|format|is|null >>>>> |----------------------------------------------------------------------- >>>>> >>>>> || >>>>> >>>>> public staticString >>>>> >>>>> format(java.util.Locale l, >>>>> String >>>>> >>>>> format, >>>>> java.lang.Object... args) >>>>> >>>>> Throws: >>>>> |java.lang.NullPointerException|- If the|format|is|null >>>>> |-------------------------------------------------------------------------- >>>>> >>>>> All of the above are properly specified with the blanket statement >>>>> or other parts of their spec (such as format w.r.t. null Locale) >>>>> and the @throws can safely be removed. >>>>> >>>>> Because the blanket statement is already in effect for >>>>> String.java, I wrote tests for all methods/constructors to ensure >>>>> compliance. Running them revealed the following: >>>>> >>>>> public void getBytes(int srcBegin, int srcEnd, byte dst[], int >>>>> dstBegin) >>>>> - I would expect an NPE to be thrown if dst == null. However, this >>>>> isn't always the case. If dst isn't accessed because of the >>>>> values of the other parameters (as in getBytes(1,2,(byte[]null,1), >>>>> then no NPE is thrown. >>>>> - This brings up the question as to the correctness of the blanket >>>>> statement w.r.t. this method. I think this method (and others >>>>> like it) should use Objects.requireNonNull(dst). (The >>>>> correspoding method public void getChars(int srcBegin, int srcEnd, >>>>> char dst[], int dstBegin), does always throw NPE for dst==null) >>>>> >>>>> All other methods/constructors in StringBuffer and StringBuilder >>>>> either correctly state null-handling behavior that differs from >>>>> the blanket statement or are correct w.r.t. the blanket statement. >>>>> >>>>> This has been reviewed by the JCK team. It will require CCC >>>>> approval (because of the new blanket statement, and the fact that >>>>> some of the existing methods were previously silent on null >>>>> handling, but all already conform to the blanket statement). >>>>> >>>>> Thanks, >>>>> Jim Gish >>>>> >>>>> >>>>> -- >>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>>>> Oracle Java Platform Group | Core Libraries Team >>>>> 35 Network Drive >>>>> Burlington, MA 01803 >>>>> jim.gish at oracle.com >>>>> >>>>> -- >>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>>>> Oracle Java Platform Group | Core Libraries Team >>>>> 35 Network Drive >>>>> Burlington, MA 01803 >>>>> jim.gish at oracle.com >>>>> >> > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From vladimir.kozlov at oracle.com Tue Jan 22 20:20:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Jan 2013 12:20:42 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FDCF9E.5040600@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> Message-ID: <50FEF49A.6090409@oracle.com> Thank you, Ulf I will rename method to encodeISOArray and add comment that it could be replaced by intrinsic by JVM. The same arrays were use intentionally in test to get performance of code without effect of CPU's cache/memory subsystem. The method encodeArrayLoop() is also compiled because it is invoked > 10000 times. And I don't see an effect on performance of its code change so I will leave it as it is. Thanks, Vladimir On 1/21/13 3:30 PM, Ulf Zibis wrote: > Am 17.01.2013 05:27, schrieb Vladimir Kozlov: >> On 1/12/13 12:37 AM, Ulf Zibis wrote: >>> 3) bugs.sun.com/bugdatabase/view_bug.do?bug_id=6896617 ==> This bug is >>> not available. >> >> I opened it, should show up in few days. > > Thanks! > >> >>> 4) What specific operation should be done by the intrinsic, i.e. is >>> there a fixed API for that method ??? >> >> When C2 (server JIT compiler in JVM) compiles encode methods it will >> replace new method encodeArray() (matched by signature) with hand >> optimized assembler code which uses latest processor instructions. I >> will send Hotspot changes soon. So it is nothing to do with >> interpreter or bytecode sequence. >> >>> 5) Can an intrinsic write back more than 1 value (see my hack via int[] >>> p) ? >>> 6) Vladimir's webrev shows an integer as return type for that method, >>> I've added a variant with boolean return type, and the code from my last >>> approach could be transformed to a method with Object return type. > > I wanted to say, there would maybe different results for the surrounding > code depending on the API we choose for the intrinsic method call. If > the surrounding code is *as short as possible*, there is a better > chance, it will be JIT-compiled too after fewer invocations of > encodeArrayLoop(). I guess, the fastest would be: > > // while inlinig, JIT will erase the surrounding int[] p > private static CoderResult copyISOs(CoderResult cr, > char[] sa, byte[] da, final int[] p, int sl) { > for (int sp = p[0], dp = p[1]; sp < sl; sp++) { > char c = sa[sp]; > // if (c & '\uFF00' != 0) // needs bug 6935994 to be fixed, > would be fastest > if ((byte)(c >> 8) != 0) // temporary replacement, fast > byte-length operation on x86 > return null; > da[dp++] = (byte)c; > } > return cr; > } > > // No more needs try...finally block > private CoderResult encodeArrayLoop( > CharBuffer src, ByteBuffer dst) { > char[] sa = src.array(); > int soff = src.arrayOffset(); > int sp = soff + src.position(); > int sr = src.remaining(); > byte[] da = dst.array(); > int doff = dst.arrayOffset(); > int dp = doff + dst.position(); > int dr = dst.remaining(); > CoderResult cr; > if (dr < sr) { > sr = dr; > cr = CoderResult.OVERFLOW; > } else > cr = CoderResult.UNDERFLOW; > int sl = sp + sr; > final int[] p = { sp, dp }; > cr = copyISOs(cr, sa, da, p, sl); > src.position(p[0] - soff); > dst.position(p[1] - doff); > return result(cr, sa, p[0], sl); > > } > > // if adapted, maybe could also be reused in encodeBufferLoop() > private static CoderResult result(CoderResult cr, byte[] sa, int sp, int > sl) { > return cr != null ? cr : > sgp.parse(sa[sp], sa, sp, sl) < 0 > ? sgp.error(); > : sgp.unmappableResult(); > } > > >>> >>> ... so waiting for Vladimir's feedback :-[ >>> (especially on performance/hsdis results) >> >> Performance on x86 tested with next code (whole test will be in >> Hotspot changes) : >> >> ba = CharBuffer.wrap(a); >> bb = ByteBuffer.wrap(b); >> long start = System.currentTimeMillis(); >> for (int i = 0; i < 1000000; i++) { >> ba.clear(); bb.clear(); >> enc_res = enc_res && enc.encode(ba, bb, true).isUnderflow(); >> } >> long end = System.currentTimeMillis(); > > 1.) Wouldn't System.nanoTime() give more accurate results? > 2.) I want to point out that it is not real world scenario, encoding the > same data 1.000.000 times. If same data is used, it is likely, that the > data itself becomes cached in the inner CPU cache so should have very > fast access times, which would be not the case on real world data. > 3.) It would also be interesting to see the results for less than > 1.000.000 iterations in considering, the surrounding code would be > JIT-compiled or not. Also performance on C1 should be tested. > > I also worry about the naming of method encodeArray(...). I think, it > should reflect the fact, that it only encodes ISO-8859-1 charset characters. > > Please add a comment on the fact, that method encodeArray(...) is > intended to be intrinsified. > > -Ulf > > From mike.duigou at oracle.com Tue Jan 22 21:15:49 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 22 Jan 2013 13:15:49 -0800 Subject: RFR : 8006594/8006595 : Define jdk_core test set Message-ID: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> 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/ http://cr.openjdk.java.net/~mduigou/8006595/0/webrev/ The overall goal is to provide a target to the top level OpenJDK for a core set of tests. ie. make test TEST=jdk_core The "core" test set is the set of JDK tests which should be run to smoketest prior to posting a webrev or committing any OpenJDK change or for nightly regression testing. These patches are the first of a planned series of patches to incrementally improve test execution and the selection of tests. I would like to commit these changes to jdk8/build repo so will need a committer from that project to push the changes for me once reviewed. Mike From mike.duigou at oracle.com Tue Jan 22 21:27:08 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 22 Jan 2013 13:27:08 -0800 Subject: RFR: 8006709 : Add minimal support of MacOSX platform for JDK NetBeans Projects Message-ID: <1C444A52-9B11-41BB-8B73-990097AC914C@oracle.com> Hello all; This is a patch that has been lingering around in the lambda/lambda repo for a long time. It adds minimal support for the MacOSX platform to the JDK NetBeans projects. It could also be used as the basis for similar support for the langtools NetBeans projects. The patch also adjust the source level of the project to 1.8 and removes some long obsolete cruft. http://cr.openjdk.java.net/~mduigou/8006709/0/webrev/ Mike From david.holmes at oracle.com Tue Jan 22 22:19:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 08:19:48 +1000 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50FEEE03.4080701@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> <50FEE3F0.40906@oracle.com> <50FEEE03.4080701@oracle.com> Message-ID: <50FF1084.1070404@oracle.com> On 23/01/2013 5:52 AM, Alan Bateman wrote: > On 22/01/2013 19:09, Xueming Shen wrote: >> Hi, >> >> Webrev has been updated to address the build issue in the >> new build infra. M >> >> (1) added the java.time packages into >> common/makefiles.javadoc/CORE_PKGS.gmk >> to be included into ct.sym >> >> http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/ >> >> (2) not sure which one should be used for lib/tzdb.jar. It >> appears >> the tzdb.jar will not be picked for "images" if use >> $(JDK_OUTPUTDIR)/lib and >> it does not get copied for "overlay-image", if use >> $(IMAGES_OUTPUTDIR)/lib. >> Guess something need to be tweak in Images.gmk. But I'm running out of >> time, >> so now I copy the tzdb into both to make both happy for M6. >> >> http://cr.openjdk.java.net/~sherman/8003680/webrev/makefiles/GendataTZDB.gmk.html >> > cc'ing build-dev as I think you need Erik or Kelly to comment on this. > > I'm not an expert on the new build but I think you just need to add > something like this to CreateJars.gmk: > > $(IMAGES_OUTPUTDIR)/lib/tzdb.jar: $(JDK_OUTPUTDIR)/lib/tzdb.jar > $(install-file) > > JARS += $(IMAGES_OUTPUTDIR)/lib/tzdb.jar > > and remove the copying that you are doing in GendataTZDB.gmk. I'd also like Erik's input on this. All of the jar building was modified so that jars go into images/lib not jdk/lib. So it should not be necessary (or desirable) to build into jdk/lib and then copy over. That said all other jar creation is handled via CreateJars.gmk so perhaps this does need a special case. But again I'd like the build-infra experts to comment on it. This isn't a blocker. I just want to make sure we have a good resolution to the issue. I also verified the new build approach with cross-compilation - everything good! Thanks, David > I looked at the changes to the top-level repo and the changes look fine > to me. > > -Alan. From Alan.Bateman at oracle.com Tue Jan 22 22:58:19 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Jan 2013 22:58:19 +0000 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50FF1084.1070404@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> <50FEE3F0.40906@oracle.com> <50FEEE03.4080701@oracle.com> <50FF1084.1070404@oracle.com> Message-ID: <50FF198B.8060009@oracle.com> On 22/01/2013 22:19, David Holmes wrote: > All of the jar building was modified so that jars go into images/lib > not jdk/lib. So it should not be necessary (or desirable) to build > into jdk/lib and then copy over. Sherman can confirm, but I believe the TzdbZoneRulesProvider requires it in the lib directory so it would need to in jdk/lib when running/testing without in a non-images build. -Alan. From xueming.shen at oracle.com Tue Jan 22 23:08:07 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 22 Jan 2013 15:08:07 -0800 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50FF198B.8060009@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> <50FEE3F0.40906@oracle.com> <50FEEE03.4080701@oracle.com> <50FF1084.1070404@oracle.com> <50FF198B.8060009@oracle.com> Message-ID: <50FF1BD7.7090707@oracle.com> On 01/22/2013 02:58 PM, Alan Bateman wrote: > On 22/01/2013 22:19, David Holmes wrote: >> All of the jar building was modified so that jars go into images/lib not jdk/lib. So it should not be necessary (or desirable) to build into jdk/lib and then copy over. > Sherman can confirm, but I believe the TzdbZoneRulesProvider requires it in the lib directory so it would need to in jdk/lib when running/testing without in a non-images build. > > -Alan. tzdb.jar is special that it is a data file in jar format. It's not a jar for classes. It needs to be generated in jdk/lib (non-images build) for developing and testing. -Sherman From vincent.x.ryan at oracle.com Tue Jan 22 23:41:13 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 22 Jan 2013 23:41:13 +0000 Subject: hg: jdk8/tl/jdk: 6263419: No way to clean the memory for a java.security.Key Message-ID: <20130122234135.62D744748F@hg.openjdk.java.net> Changeset: 8ee6d45348ba Author: vinnie Date: 2013-01-22 23:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ee6d45348ba 6263419: No way to clean the memory for a java.security.Key Reviewed-by: mullan ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java ! src/share/classes/javax/security/auth/Destroyable.java + test/javax/security/auth/Destroyable/KeyDestructionTest.java From Ulf.Zibis at CoSoCo.de Tue Jan 22 23:57:38 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 23 Jan 2013 00:57:38 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FEF49A.6090409@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> Message-ID: <50FF2772.7080807@CoSoCo.de> Am 22.01.2013 21:20, schrieb Vladimir Kozlov: > Thank you, Ulf > > I will rename method to encodeISOArray and add comment that it could be replaced by intrinsic by JVM. Thanks, that's much better. Thinking about, I would more like encodeArrayToISO or just encodeToISO_8859_1. > The same arrays were use intentionally in test to get performance of code without effect of CPU's > cache/memory subsystem. I worry about, if the overhead of recalculating sp and dp + comparing ret != len + complicated calculation of len will come to effect on short strings, at least on C1 and interpreter. So why not choose the best code for all these cases? > The method encodeArrayLoop() is also compiled because it is invoked > 10000 times. That is what I assumed. But I see 2 corner cases: - Programs with sparse use of ISO-8859-1 encoding will not profit of it, if the compile threshold becomes not reached. Also think about C1. - I worry, that on small strings the performance of the the intrinsic surrounding code would come to some account, even if JIT-compiled, but specially on C1 and interpreter. So would it hurt, to include those cases while tuning? -Ulf From david.holmes at oracle.com Wed Jan 23 00:14:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 10:14:25 +1000 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50FF1BD7.7090707@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> <50FEE3F0.40906@oracle.com> <50FEEE03.4080701@oracle.com> <50FF1084.1070404@oracle.com> <50FF198B.8060009@oracle.com> <50FF1BD7.7090707@oracle.com> Message-ID: <50FF2B61.2010101@oracle.com> On 23/01/2013 9:08 AM, Xueming Shen wrote: > On 01/22/2013 02:58 PM, Alan Bateman wrote: >> On 22/01/2013 22:19, David Holmes wrote: >>> All of the jar building was modified so that jars go into images/lib >>> not jdk/lib. So it should not be necessary (or desirable) to build >>> into jdk/lib and then copy over. >> Sherman can confirm, but I believe the TzdbZoneRulesProvider requires >> it in the lib directory so it would need to in jdk/lib when >> running/testing without in a non-images build. >> >> -Alan. > > tzdb.jar is special that it is a data file in jar format. It's not a jar > for classes. > It needs to be generated in jdk/lib (non-images build) for developing and > testing. Okay - sounds reasonable then. Thanks, David > -Sherman From vitalyd at gmail.com Wed Jan 23 00:14:54 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 22 Jan 2013 19:14:54 -0500 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FF2772.7080807@CoSoCo.de> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> Message-ID: Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. Maybe this is heresy though :). Sent from my phone On Jan 22, 2013 6:58 PM, "Ulf Zibis" wrote: > Am 22.01.2013 21:20, schrieb Vladimir Kozlov: > >> Thank you, Ulf >> >> I will rename method to encodeISOArray and add comment that it could be >> replaced by intrinsic by JVM. >> > > Thanks, that's much better. Thinking about, I would more like > encodeArrayToISO or just encodeToISO_8859_1. > > The same arrays were use intentionally in test to get performance of code >> without effect of CPU's cache/memory subsystem. >> > > I worry about, if the overhead of recalculating sp and dp + comparing ret > != len + complicated calculation of len will come to effect on short > strings, at least on C1 and interpreter. So why not choose the best code > for all these cases? > > The method encodeArrayLoop() is also compiled because it is invoked > >> 10000 times. >> > > That is what I assumed. > But I see 2 corner cases: > - Programs with sparse use of ISO-8859-1 encoding will not profit of it, > if the compile threshold becomes not reached. Also think about C1. > - I worry, that on small strings the performance of the the intrinsic > surrounding code would come to some account, even if JIT-compiled, but > specially on C1 and interpreter. > So would it hurt, to include those cases while tuning? > > -Ulf > > From david.holmes at oracle.com Wed Jan 23 01:03:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 11:03:04 +1000 Subject: RFR: (JDK-8006667) Merge issue: Profile attribute need to be examined before custom attributes Message-ID: <50FF36C8.4040807@oracle.com> Slightly unusual situation here. :) We're in the process of staging the Profiles changes ready for integration to the mainline repos via the jdk8/build forest. That will happen in a few weeks after a test cycle. All those changes have already gone out for review etc. Alan just discovered that when I merged the Profiles changes to the LauncherHelper with the recent FXHelper changes, they ended up in the wrong order - Profiles needs to be checked first. So this change addresses that swap: http://cr.openjdk.java.net/~dholmes/8006667/webrev/ Naturally Alan will be the official reviewer for this but there needs to be an email chain too. Thanks, David From david.holmes at oracle.com Wed Jan 23 01:15:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 11:15:57 +1000 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> Message-ID: <50FF39CD.6020709@oracle.com> On 23/01/2013 10:14 AM, Vitaly Davidovich wrote: > Personally, optimizing for interpreter (or even C1) doesn't seem worth it. > If something's truly hot and best perf is desired then use C2 or tiered. > If the method isn't hot enough to trigger the C2 threshold, then why > bother? You're already behind the 8 ball in terms of performance. Maybe > this is heresy though :). Not all platforms/products have C2. David > Sent from my phone > On Jan 22, 2013 6:58 PM, "Ulf Zibis" wrote: > >> Am 22.01.2013 21:20, schrieb Vladimir Kozlov: >> >>> Thank you, Ulf >>> >>> I will rename method to encodeISOArray and add comment that it could be >>> replaced by intrinsic by JVM. >>> >> >> Thanks, that's much better. Thinking about, I would more like >> encodeArrayToISO or just encodeToISO_8859_1. >> >> The same arrays were use intentionally in test to get performance of code >>> without effect of CPU's cache/memory subsystem. >>> >> >> I worry about, if the overhead of recalculating sp and dp + comparing ret >> != len + complicated calculation of len will come to effect on short >> strings, at least on C1 and interpreter. So why not choose the best code >> for all these cases? >> >> The method encodeArrayLoop() is also compiled because it is invoked> >>> 10000 times. >>> >> >> That is what I assumed. >> But I see 2 corner cases: >> - Programs with sparse use of ISO-8859-1 encoding will not profit of it, >> if the compile threshold becomes not reached. Also think about C1. >> - I worry, that on small strings the performance of the the intrinsic >> surrounding code would come to some account, even if JIT-compiled, but >> specially on C1 and interpreter. >> So would it hurt, to include those cases while tuning? >> >> -Ulf >> >> From joe.darcy at oracle.com Wed Jan 23 01:21:45 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 22 Jan 2013 17:21:45 -0800 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50FEE07D.9040902@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F87323.9040505@oracle.com> <50FEE07D.9040902@oracle.com> Message-ID: <50FF3B29.6050507@oracle.com> Hello Eric, In Executable, 283 // TODO: This may eventually need to be guarded by security 284 // mechanisms similar to those in Field, Method, etc. If not done so already, please file a bug to note this item for follow-up work. Extra space: 316 317 parameters = tmp; 318 319 } Parameter.java 41 * @author Eric McCorkle We generally don't use author tags in new code under /src. For consistency with existing code (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f9c19741285), please add an "@jls 13.1 The Form of a Binary" tag to the isSynthethic method. The @since tags on getAnnotation, getAnnotations, getDeclaredAnnotation, etc. are redundant with the @since on the Parameter type itself and should be removed. Executable.c Please verify the "Copyright (c) 1994, 2010" range on this file is correct and that an copyright end range of "2013" is applied as appropriate. Otherwise looks fine. Thanks, -Joe On 1/22/2013 10:54 AM, Eric McCorkle wrote: > Are there any additional comments? I'd like to get this pushed today. > > On 01/17/13 16:54, Eric McCorkle wrote: >> After (lengthy) examination, it seems that properly addressing the >> synthesized parameters issue will require more changes to javac. In >> light of this, I think that the synthesized parameter logic should go in >> a follow-up enhancement. I have created JDK-8006345 to track this issue: >> >> http://bugs.sun.com/view_bug.do?bug_id=8006345 >> >> Therefore, I've rolled back the changes I was making which would have >> synthesized parameters in the reflection API itself, and updated the >> webrev. Please examine for any additional concerns. >> >> >> On 01/11/13 13:27, Joe Darcy wrote: >>> Hi Eric, >>> >>> Taking another look at the code, some extra logic / checking is needed >>> in cases where the number of source parameters (non-synthetic and >>> non-synthesized) disagrees with the number of actual parameters at a >>> class file level. >>> >>> For example, if the single source parameter of an inner class >>> constructor is annotated, the annotation should be associated with the >>> *second* parameter since the first class file parameter is a synthesized >>> constructor added by the compiler. I think generally annotations should >>> not be associated with synthesized or synthetic parameters. >>> >>> -Joe >>> >>> On 1/11/2013 9:03 AM, Eric McCorkle wrote: >>>> Update should be visible now. >>>> >>>> On 01/11/13 11:54, Vitaly Davidovich wrote: >>>>> Yes that's exactly what I'm looking for as well. >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 11, 2013 11:25 AM, "Peter Levart" >>>> > wrote: >>>>> >>>>> On 01/11/2013 04:54 PM, Eric McCorkle wrote: >>>>> >>>>> The webrev has been updated again. >>>>> >>>>> The multiple writes to parameters have been removed, and the >>>>> tests have >>>>> been expanded to look at inner classes, and to test modifiers. >>>>> >>>>> Please look over it again. >>>>> >>>>> >>>>> Hello Eric, >>>>> >>>>> You still have 2 reads of volatile even in fast path. I would do it >>>>> this way: >>>>> >>>>> >>>>> private Parameter[] privateGetParameters() { >>>>> Parameter[] tmp = parameters; // one and only read >>>>> if (tmp != null) >>>>> return tmp; >>>>> >>>>> // Otherwise, go to the JVM to get them >>>>> tmp = getParameters0(); >>>>> >>>>> // If we get back nothing, then synthesize parameters >>>>> if (tmp == null) { >>>>> final int num = getParameterCount(); >>>>> tmp = new Parameter[num]; >>>>> for (int i = 0; i < num; i++) >>>>> // TODO: is there a way to synthetically derive the >>>>> // modifiers? Probably not in the general case, since >>>>> // we'd have no way of knowing about them, but there >>>>> // may be specific cases. >>>>> tmp[i] = new Parameter("arg" + i, 0, this, i); >>>>> // This avoids possible races from seeing a >>>>> // half-initialized parameters cache. >>>>> } >>>>> >>>>> parameters = tmp; >>>>> >>>>> return tmp; >>>>> } >>>>> >>>>> >>>>> Regards, Peter >>>>> >>>>> >>>>> Test-wise, I've got a clean run on JPRT (there were some >>>>> failures in >>>>> lambda stuff, but I've been seeing that for some time now). >>>>> >>>>> On 01/10/13 21:47, Eric McCorkle wrote: >>>>> >>>>> On 01/10/13 19:50, Vitaly Davidovich wrote: >>>>> >>>>> Hi Eric, >>>>> >>>>> Parameter.equals() doesn't need null check - instanceof >>>>> covers that already. >>>>> >>>>> Removed. >>>>> >>>>> Maybe this has been mentioned already, but personally >>>>> I'm not a fan of >>>>> null checks such as "if (null == x)" - I prefer the >>>>> null >>>>> on the right >>>>> hand side, but that's just stylistic. >>>>> >>>>> Changed. >>>>> >>>>> Perhaps I'm looking at a stale webrev but >>>>> Executable.__privateGetParameters() reads and writes >>>>> from/to the volatile >>>>> field more than once. I think Peter already mentioned >>>>> that it should >>>>> use one read into a local and one write to publish the >>>>> final version to >>>>> the field (it can return the temp as well). >>>>> >>>>> You weren't. From a pure correctness standpoint, there is >>>>> nothing wrong >>>>> with what is there. getParameters0 is a constant >>>>> function, and >>>>> parameters is writable only if null. Hence, we only every >>>>> see one >>>>> nontrivial write to it. >>>>> >>>>> But you are right, it should probably be reduced to a >>>>> single >>>>> write, for >>>>> performance reasons (to avoid unnecessary memory barriers). >>>>> Therefore, >>>>> I changed it. >>>>> >>>>> However, I won't be able to refresh the webrev until >>>>> tomorrow. >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 10, 2013 6:05 PM, "Eric McCorkle" >>>>> >>>> >>>>> >>>> >> wrote: >>>>> >>>>> The webrev has been refreshed with the solution I >>>>> describe below >>>>> implemented. Please make additional comments. >>>>> >>>>> On 01/10/13 17:29, Eric McCorkle wrote: >>>>> > Good catch there. I made the field volatile, >>>>> and >>>>> I also did the same >>>>> > with the cache fields in Parameter. >>>>> > >>>>> > It is possible with what exists that you could >>>>> wind up with multiple >>>>> > copies of identical parameter objects in >>>>> existence. It goes something >>>>> > like this >>>>> > >>>>> > thread A sees Executable.parameters is null, >>>>> goes >>>>> into the VM to >>>>> get them >>>>> > thread B sees Executable.parameters is null, >>>>> goes >>>>> into the VM to >>>>> get them >>>>> > thread A stores to Executable.parameters >>>>> > thread B stores to Executable.parameters >>>>> > >>>>> > Since Parameters is immutable (except for its >>>>> caches, which will >>>>> always >>>>> > end up containing the same things), this >>>>> *should* >>>>> have no visible >>>>> > effects, unless someone does == instead of >>>>> .equals. >>>>> > >>>>> > This can be avoided by doing a CAS, which is >>>>> more >>>>> expensive >>>>> execution-wise. >>>>> > >>>>> > My vote is to *not* do a CAS, and accept that >>>>> (in >>>>> extremely rare >>>>> cases, >>>>> > even as far as concurrency-related anomalies >>>>> go), >>>>> you may end up with >>>>> > duplicates, and document that very well. >>>>> > >>>>> > Thoughts? >>>>> > >>>>> > On 01/10/13 16:10, Peter Levart wrote: >>>>> >> Hello Eric, >>>>> >> >>>>> >> I have another one. Although not very likely, >>>>> the reference to >>>>> the same >>>>> >> Method/Constructor can be shared among multiple >>>>> threads. The >>>>> publication >>>>> >> of a parameters array should therefore be >>>>> performed via a >>>>> volatile write >>>>> >> / volatile read, otherwise it can happen that >>>>> some thread sees >>>>> >> half-initialized array content. The >>>>> 'parameters' >>>>> field in Executable >>>>> >> should be declared as volatile and there should >>>>> be a single read >>>>> from it >>>>> >> and a single write to it in the >>>>> privateGetParameters() method >>>>> (you need >>>>> >> a local variable to hold intermediate >>>>> states)... >>>>> >> >>>>> >> Regards, Peter >>>>> >> >>>>> >> On 01/10/2013 09:42 PM, Eric McCorkle wrote: >>>>> >>> Thanks to all for initial reviews; however, it >>>>> appears that the >>>>> version >>>>> >>> you saw was somewhat stale. I've applied your >>>>> comments (and some >>>>> >>> changes that I'd made since the version that >>>>> was posted). >>>>> >>> >>>>> >>> Please take a second look. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> Eric >>>>> >>> >>>>> >>> >>>>> >>> On 01/10/13 04:19, Peter Levart wrote: >>>>> >>>> Hello Eric, >>>>> >>>> >>>>> >>>> You must have missed my comment from the >>>>> previous webrev: >>>>> >>>> >>>>> >>>> 292 private Parameter[] >>>>> privateGetParameters() { >>>>> >>>> 293 if (null != parameters) >>>>> >>>> 294 return parameters.get(); >>>>> >>>> >>>>> >>>> If/when the 'parameters' SoftReference is >>>>> cleared, the method >>>>> will be >>>>> >>>> returning null forever after... >>>>> >>>> >>>>> >>>> You should also retrieve the referent and >>>>> check for it's >>>>> presence before >>>>> >>>> returning it: >>>>> >>>> >>>>> >>>> Parameter[] res; >>>>> >>>> if (parameters != null && (res = >>>>> parameters.get()) != null) >>>>> >>>> return res; >>>>> >>>> ... >>>>> >>>> ... >>>>> >>>> >>>>> >>>> Regards, Peter >>>>> >>>> >>>>> >>>> On 01/09/2013 10:55 PM, Eric McCorkle wrote: >>>>> >>>>> Hello, >>>>> >>>>> >>>>> >>>>> Please review the core reflection API >>>>> implementation of parameter >>>>> >>>>> reflection. This is the final component of >>>>> method parameter >>>>> reflection. >>>>> >>>>> This was posted for review before, then >>>>> delayed until the >>>>> check-in for >>>>> >>>>> JDK-8004728 (hotspot support for parameter >>>>> reflection), which >>>>> occurred >>>>> >>>>> yesterday. >>>>> >>>>> >>>>> >>>>> Note: The check-in of JDK-8004728 was into >>>>> hsx/hotspot-rt, *not* >>>>> >>>>> jdk8/tl; therefore, it may be a while before >>>>> the changeset >>>>> makes its way >>>>> >>>>> into jdk8/tl. >>>>> >>>>> >>>>> >>>>> Also note: since the check-in of JDK-8004727 >>>>> (javac support for >>>>> >>>>> parameter reflection), there has been a >>>>> failure in the tests for >>>>> >>>>> Pack200. This is being addressed in a fix >>>>> contributed by >>>>> Kumar, which I >>>>> >>>>> believe has also been posted for review. >>>>> >>>>> >>>>> >>>>> The open webrev is here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~__coleenp/JDK-8004729 >>>>> >>>>> >>>>> >>>>> >>>>> The feature request is here: >>>>> >>>>> >>>>> http://bugs.sun.com/view_bug.__do?bug_id=8004729 >>>>> >>>>> >>>>> >>>>> >>>>> The latest version of the spec can be >>>>> found here: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~__abuckley/8misc.pdf >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Eric >>>>> >> >>>>> >>>>> From stuart.marks at oracle.com Wed Jan 23 02:33:32 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 23 Jan 2013 02:33:32 +0000 Subject: hg: jdk8/tl/jdk: 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Message-ID: <20130123023343.64B0D47496@hg.openjdk.java.net> Changeset: c18f28312c49 Author: smarks Date: 2013-01-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Reviewed-by: mchung ! test/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.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.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy From stuart.marks at oracle.com Wed Jan 23 02:39:18 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 22 Jan 2013 18:39:18 -0800 Subject: RFR: 8005646: TEST_BUG: RMI UnregisterGroup test leaves process running In-Reply-To: <50FDBE04.6080108@oracle.com> References: <50ECB0D2.9050202@oracle.com> <50FDBE04.6080108@oracle.com> Message-ID: <50FF4D56.6070106@oracle.com> Hi Mandy, Yes, I still did need a reviewer for this, thanks. Yeah, it was a pain to debug, but once I figured out the solution it really was fun. "Oh, I don't need this piece anymore, or this piece, or this piece. Delete, delete, delete." Negative code FTW! Pushed: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49 s'marks On 1/21/13 2:15 PM, Mandy Chung wrote: > Stuart, > > I think you still need a reviewer for this fix. This change looks okay to me. > The details in the bug report are useful and you must have lots of fun to > diagnose this :) - definitely not easy. > > Mandy > > On 1/8/2013 3:50 PM, Stuart Marks wrote: >> Hi all, >> >> Please review this fix: >> >> http://cr.openjdk.java.net/~smarks/reviews/8005646/webrev.0/ >> >> for this bug: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005646 >> >> Many gory details are in that bug report. TL;DR the old test jumped through >> several hoops attempting to deactivate all the activated objects, but this >> sometimes failed. The revised test uses a better deactivation technique. This >> improves the reliability of the test, and it makes unnecessary a bunch of >> infrastructure that supported the old deactivation technique. >> >> I've also removed the RMI stubs from the checked-in sources, since they have >> been generated at runtime since Java 5. >> >> Thanks, >> >> s'marks From jonathan.gibbons at oracle.com Wed Jan 23 02:43:47 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 02:43:47 +0000 Subject: hg: jdk8/tl/langtools: 8006723: sjavac test fails to compile on clean build Message-ID: <20130123024349.A433C47497@hg.openjdk.java.net> Changeset: 8943b4213f59 Author: jjg Date: 2013-01-22 18:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8943b4213f59 8006723: sjavac test fails to compile on clean build Reviewed-by: ksrini ! test/tools/sjavac/SJavac.java + test/tools/sjavac/SJavacWrapper.java From jonathan.gibbons at oracle.com Wed Jan 23 03:07:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 03:07:23 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130123030731.0EB3747498@hg.openjdk.java.net> Changeset: f5b70712e0d5 Author: jjg Date: 2013-01-22 19:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f5b70712e0d5 8006728: temporarily workaround jtreg problems for doclint tests in othervm Reviewed-by: jjh + test/tools/doclint/html/AAA.java + test/tools/doclint/tidy/AAA.java + test/tools/doclint/tool/AAA.java Changeset: 385828dd5604 Author: jjg Date: 2013-01-22 19:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/385828dd5604 Merge From eric.mccorkle at oracle.com Wed Jan 23 03:49:58 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Tue, 22 Jan 2013 22:49:58 -0500 Subject: Review request JDK-8004729: Parameter Reflection API In-Reply-To: <50FF3B29.6050507@oracle.com> References: <50EDE75B.4000308@oracle.com> <50EE878C.2040707@gmail.com> <50EF27A8.1060505@oracle.com> <50EF2E56.7070007@gmail.com> <50EF40E2.1060305@oracle.com> <50EF4908.7050002@oracle.com> <50EF7D3A.8080106@oracle.com> <50F035AB.6090400@oracle.com> <50F03CE8.2010805@gmail.com> <50F045E6.40709@oracle.com> <50F059AF.1000706@oracle.com> <50F87323.9040505@oracle.com> <50FEE07D.9040902@oracle.com> <50FF3B29.6050507@oracle.com> Message-ID: <50FF5DE6.3020904@oracle.com> On 01/22/13 20:21, Joe Darcy wrote: > Hello Eric, > > In Executable, > > 283 // TODO: This may eventually need to be guarded by security > 284 // mechanisms similar to those in Field, Method, etc. > > If not done so already, please file a bug to note this item for > follow-up work. I will do so. There was no mention of this sort of thing in the spec at the time I created Parameter.java, and I noticed its presence elsewhere. Also, I know there is a security analysis going on concerning possible vulnerabilities, but as far as I'm aware, it has not delivered a report yet. > > Extra space: > > 316 > 317 parameters = tmp; > 318 > 319 } > Fixed. > Parameter.java > > 41 * @author Eric McCorkle > > We generally don't use author tags in new code under /src. > Removed > For consistency with existing code > (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f9c19741285), please add an > "@jls 13.1 The Form of a Binary" tag to the isSynthethic method. > Done. > The @since tags on getAnnotation, getAnnotations, getDeclaredAnnotation, > etc. are redundant with the @since on the Parameter type itself and > should be removed. > Done > Executable.c > > Please verify the "Copyright (c) 1994, 2010" range on this file is > correct and that an copyright end range of "2013" is applied as > appropriate. > The copyright range was not correct. I'd copy-pasted it and forgotten to change it. It's fixed now. > Otherwise looks fine. > > Thanks, > > -Joe > Thanks for the review, Joe. Can anyone volunteer to push this for me? I am not a committer. Eric From xueming.shen at oracle.com Wed Jan 23 04:54:43 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 04:54:43 +0000 Subject: hg: jdk8/tl/jdk: 8003680: JSR 310 Date/Time API Message-ID: <20130123045504.5A781474A3@hg.openjdk.java.net> Changeset: 919afffa70b0 Author: sherman Date: 2013-01-22 20:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919afffa70b0 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/time/Makefile ! make/jprt.properties ! make/sun/Makefile + make/sun/tzdb/Makefile ! make/tools/Makefile + make/tools/src/build/tools/tzdb/ChronoField.java + make/tools/src/build/tools/tzdb/DateTimeException.java + make/tools/src/build/tools/tzdb/LocalDate.java + make/tools/src/build/tools/tzdb/LocalDateTime.java + make/tools/src/build/tools/tzdb/LocalTime.java + make/tools/src/build/tools/tzdb/TimeDefinition.java + make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java + make/tools/src/build/tools/tzdb/Utils.java + make/tools/src/build/tools/tzdb/ZoneOffset.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java + make/tools/src/build/tools/tzdb/ZoneRules.java + make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java + make/tools/tzdb/Makefile ! makefiles/CreateJars.gmk + makefiles/GendataTZDB.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk + src/share/classes/java/time/Clock.java + src/share/classes/java/time/DateTimeException.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/Period.java + src/share/classes/java/time/PeriodParser.java + src/share/classes/java/time/Ser.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/format/DateTimeBuilder.java + src/share/classes/java/time/format/DateTimeFormatStyleProvider.java + src/share/classes/java/time/format/DateTimeFormatSymbols.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/DateTimeParseException.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/SignStyle.java + src/share/classes/java/time/format/TextStyle.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/Adjusters.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/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/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/ValueRange.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/Ser.java + src/share/classes/java/time/zone/TzdbZoneRulesProvider.java + src/share/classes/java/time/zone/ZoneOffsetTransition.java + src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java + src/share/classes/java/time/zone/ZoneRules.java + src/share/classes/java/time/zone/ZoneRulesException.java + src/share/classes/java/time/zone/ZoneRulesProvider.java + src/share/classes/java/time/zone/package-info.java ! src/share/classes/java/util/Formatter.java ! test/Makefile + test/java/time/META-INF/services/java.time.temporal.Chrono + test/java/time/TEST.properties + test/java/time/tck/java/time/AbstractDateTimeTest.java + test/java/time/tck/java/time/AbstractTCKTest.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/TCKZoneId.java + test/java/time/tck/java/time/TCKZoneOffset.java + test/java/time/tck/java/time/TCKZonedDateTime.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/format/TCKDateTimeFormatSymbols.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/temporal/TCKDateTimeAdjusters.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/AbstractTest.java + test/java/time/test/java/time/MockSimplePeriod.java + test/java/time/test/java/time/TestClock_Fixed.java + test/java/time/test/java/time/TestClock_Offset.java + test/java/time/test/java/time/TestClock_System.java + test/java/time/test/java/time/TestClock_Tick.java + test/java/time/test/java/time/TestDuration.java + test/java/time/test/java/time/TestInstant.java + test/java/time/test/java/time/TestLocalDate.java + test/java/time/test/java/time/TestLocalDateTime.java + test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestPeriod.java + test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/TestZoneOffset.java + test/java/time/test/java/time/TestZonedDateTime.java + test/java/time/test/java/time/format/AbstractTestPrinterParser.java + test/java/time/test/java/time/format/MockIOExceptionAppendable.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/TestDateTimeFormatSymbols.java + test/java/time/test/java/time/format/TestDateTimeFormatter.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/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/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/TestDateTimeAdjusters.java + test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java + test/java/time/test/java/time/temporal/TestDateTimeValueRange.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/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 From xueming.shen at oracle.com Wed Jan 23 04:57:27 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 04:57:27 +0000 Subject: hg: jdk8/tl: 8003680: JSR 310 Date/Time API Message-ID: <20130123045727.7D1AD474A4@hg.openjdk.java.net> Changeset: 8209c91b751d Author: sherman Date: 2013-01-22 21:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8209c91b751d 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! common/makefiles/javadoc/CORE_PKGS.gmk ! make/jprt.properties ! test/Makefile From erik.joelsson at oracle.com Wed Jan 23 09:43:41 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2013 10:43:41 +0100 Subject: Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50FF2B61.2010101@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F9E2CE.9090500@oracle.com> <50FEE3F0.40906@oracle.com> <50FEEE03.4080701@oracle.com> <50FF1084.1070404@oracle.com> <50FF198B.8060009@oracle.com> <50FF1BD7.7090707@oracle.com> <50FF2B61.2010101@oracle.com> Message-ID: <50FFB0CD.3050109@oracle.com> On 2013-01-23 01:14, David Holmes wrote: > On 23/01/2013 9:08 AM, Xueming Shen wrote: >> On 01/22/2013 02:58 PM, Alan Bateman wrote: >>> On 22/01/2013 22:19, David Holmes wrote: >>>> All of the jar building was modified so that jars go into images/lib >>>> not jdk/lib. So it should not be necessary (or desirable) to build >>>> into jdk/lib and then copy over. >>> Sherman can confirm, but I believe the TzdbZoneRulesProvider requires >>> it in the lib directory so it would need to in jdk/lib when >>> running/testing without in a non-images build. >>> >>> -Alan. >> >> tzdb.jar is special that it is a data file in jar format. It's not a jar >> for classes. >> It needs to be generated in jdk/lib (non-images build) for developing >> and >> testing. > > Okay - sounds reasonable then. > David is indeed correct with how we would like to have it. But I can understand the exception explained by Alan, so I think this is ok and the correct way of doing it. /Erik From vincent.x.ryan at oracle.com Wed Jan 23 09:50:00 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 09:50:00 +0000 Subject: hg: jdk8/tl/jdk: 8006741: javadoc cleanup for 6263419 Message-ID: <20130123095040.D74E1474C5@hg.openjdk.java.net> Changeset: 71691b9d45ab Author: vinnie Date: 2013-01-23 09:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71691b9d45ab 8006741: javadoc cleanup for 6263419 Reviewed-by: alanb ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java From weijun.wang at oracle.com Wed Jan 23 10:30:41 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 23 Jan 2013 18:30:41 +0800 Subject: OPENJDK env var not playing well with new build Message-ID: <50FFBBD1.2070507@oracle.com> I thought building an OpenJDK or Oracle JDK can be fully controlled by using the --enable-openjdk-only configure option, but it seems the OPENJDK env variable still plays a part. If the variable is set to true and --enable-openjdk-only is not provided, the new build process gets confused and fails. I understand this is my fault and I should not have that variable around. However, it will be nice if the build can deny all external variables like it did with all those ALT_*** variables. Are there any other variables I should be aware of? Thanks Max From erik.joelsson at oracle.com Wed Jan 23 10:58:03 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2013 11:58:03 +0100 Subject: OPENJDK env var not playing well with new build In-Reply-To: <50FFBBD1.2070507@oracle.com> References: <50FFBBD1.2070507@oracle.com> Message-ID: <50FFC23B.2060905@oracle.com> On 2013-01-23 11:30, Weijun Wang wrote: > I thought building an OpenJDK or Oracle JDK can be fully controlled by > using the --enable-openjdk-only configure option, but it seems the > OPENJDK env variable still plays a part. If the variable is set to > true and --enable-openjdk-only is not provided, the new build process > gets confused and fails. > > I understand this is my fault and I should not have that variable > around. However, it will be nice if the build can deny all external > variables like it did with all those ALT_*** variables. Are there any > other variables I should be aware of? > This is bad, I agree. We initially kept the same variable for controlling if the build was OpenJDK only or not as the old build, because it made it easier during the conversion. The problem with this variable is that it is either set or not, which makes it harder to override in makefiles. The proper solution would be to replace this in the new build with something like OPENJDK_ONLY=true/false and completely ignore the old OPENJDK. I can't remember any other variables right now, but it's quite possible there are more. /Erik From alexey.utkin at oracle.com Wed Jan 23 11:10:35 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Wed, 23 Jan 2013 11:10:35 +0000 Subject: hg: jdk8/tl/jdk: 6519127: user.home property not set correctly Message-ID: <20130123111048.B7CBD474C6@hg.openjdk.java.net> Changeset: 01b36b400145 Author: uta Date: 2013-01-23 15:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b36b400145 6519127: user.home property not set correctly Summary: Registry-based approach was changed to SHGetKnownFolderPath/SHGetFolderPathW Reviewed-by: alanb, anthony ! src/windows/native/java/lang/java_props_md.c From david.holmes at oracle.com Wed Jan 23 11:54:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2013 21:54:32 +1000 Subject: OPENJDK env var not playing well with new build In-Reply-To: <50FFC23B.2060905@oracle.com> References: <50FFBBD1.2070507@oracle.com> <50FFC23B.2060905@oracle.com> Message-ID: <50FFCF78.4060307@oracle.com> On 23/01/2013 8:58 PM, Erik Joelsson wrote: > On 2013-01-23 11:30, Weijun Wang wrote: >> I thought building an OpenJDK or Oracle JDK can be fully controlled by >> using the --enable-openjdk-only configure option, but it seems the >> OPENJDK env variable still plays a part. If the variable is set to >> true and --enable-openjdk-only is not provided, the new build process >> gets confused and fails. Can you point us at a log? I'd like to see exactly where the confusion arises. >> I understand this is my fault and I should not have that variable >> around. However, it will be nice if the build can deny all external >> variables like it did with all those ALT_*** variables. Are there any >> other variables I should be aware of? >> > This is bad, I agree. We initially kept the same variable for > controlling if the build was OpenJDK only or not as the old build, > because it made it easier during the conversion. The problem with this > variable is that it is either set or not, which makes it harder to > override in makefiles. The proper solution would be to replace this in > the new build with something like OPENJDK_ONLY=true/false and completely > ignore the old OPENJDK. Not sure why the set/unset situation is a problem. If OPENJDK is set then it must be set to true else the sanity checks fail. But we should locate anywhere that the make files still examine the environment for such variables - not that I thought there were such places. The environment variables should only be used to influence how configure runs, and the variables it sets should then be used by the make files. David ----- > I can't remember any other variables right now, but it's quite possible > there are more. > > /Erik From erik.joelsson at oracle.com Wed Jan 23 12:12:11 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2013 13:12:11 +0100 Subject: OPENJDK env var not playing well with new build In-Reply-To: <50FFCF78.4060307@oracle.com> References: <50FFBBD1.2070507@oracle.com> <50FFC23B.2060905@oracle.com> <50FFCF78.4060307@oracle.com> Message-ID: <50FFD39B.5050105@oracle.com> On 2013-01-23 12:54, David Holmes wrote: > On 23/01/2013 8:58 PM, Erik Joelsson wrote: >> On 2013-01-23 11:30, Weijun Wang wrote: >>> I thought building an OpenJDK or Oracle JDK can be fully controlled by >>> using the --enable-openjdk-only configure option, but it seems the >>> OPENJDK env variable still plays a part. If the variable is set to >>> true and --enable-openjdk-only is not provided, the new build process >>> gets confused and fails. > > Can you point us at a log? I'd like to see exactly where the confusion > arises. > >>> I understand this is my fault and I should not have that variable >>> around. However, it will be nice if the build can deny all external >>> variables like it did with all those ALT_*** variables. Are there any >>> other variables I should be aware of? >>> >> This is bad, I agree. We initially kept the same variable for >> controlling if the build was OpenJDK only or not as the old build, >> because it made it easier during the conversion. The problem with this >> variable is that it is either set or not, which makes it harder to >> override in makefiles. The proper solution would be to replace this in >> the new build with something like OPENJDK_ONLY=true/false and completely >> ignore the old OPENJDK. > > Not sure why the set/unset situation is a problem. If OPENJDK is set > then it must be set to true else the sanity checks fail. > > But we should locate anywhere that the make files still examine the > environment for such variables - not that I thought there were such > places. The environment variables should only be used to influence how > configure runs, and the variables it sets should then be used by the > make files. > The problem I can imagine is this: Configure creates a configuration without --enable-openjdk-only, which results in a spec.gmk with no OPENJDK=true in it. OPENJDK=true is then set in the environment, which will trigger all ifdef OPENJDK in the makefiles. This would end up being a hybrid between fully open and a closed build since configure has already done things differently at configure time, but the makefiles will try to behave as if it was an open build. I don't know where this fails, but I'm not surprised that it does, and even if it didn't fail, the resulting bits would be bad. If instead spec.gmk would have a line like OPENJDK_ONLY=false, this would always override any environment variable. /Erik From weijun.wang at oracle.com Wed Jan 23 12:23:09 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 23 Jan 2013 20:23:09 +0800 Subject: OPENJDK env var not playing well with new build In-Reply-To: <50FFCF78.4060307@oracle.com> References: <50FFBBD1.2070507@oracle.com> <50FFC23B.2060905@oracle.com> <50FFCF78.4060307@oracle.com> Message-ID: <50FFD62D.8040907@oracle.com> On 01/23/2013 07:54 PM, David Holmes wrote: > On 23/01/2013 8:58 PM, Erik Joelsson wrote: >> On 2013-01-23 11:30, Weijun Wang wrote: >>> I thought building an OpenJDK or Oracle JDK can be fully controlled by >>> using the --enable-openjdk-only configure option, but it seems the >>> OPENJDK env variable still plays a part. If the variable is set to >>> true and --enable-openjdk-only is not provided, the new build process >>> gets confused and fails. > > Can you point us at a log? I'd like to see exactly where the confusion > arises. I don't have a log now. The problem is at libfreetype.so. Something like /libfreetype.so is needed to build .../libfreetype.so. -Max > >>> I understand this is my fault and I should not have that variable >>> around. However, it will be nice if the build can deny all external >>> variables like it did with all those ALT_*** variables. Are there any >>> other variables I should be aware of? >>> >> This is bad, I agree. We initially kept the same variable for >> controlling if the build was OpenJDK only or not as the old build, >> because it made it easier during the conversion. The problem with this >> variable is that it is either set or not, which makes it harder to >> override in makefiles. The proper solution would be to replace this in >> the new build with something like OPENJDK_ONLY=true/false and completely >> ignore the old OPENJDK. > > Not sure why the set/unset situation is a problem. If OPENJDK is set > then it must be set to true else the sanity checks fail. > > But we should locate anywhere that the make files still examine the > environment for such variables - not that I thought there were such > places. The environment variables should only be used to influence how > configure runs, and the variables it sets should then be used by the > make files. > > David > ----- > >> I can't remember any other variables right now, but it's quite possible >> there are more. >> >> /Erik From erik.joelsson at oracle.com Wed Jan 23 13:00:34 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Jan 2013 14:00:34 +0100 Subject: OPENJDK env var not playing well with new build In-Reply-To: <50FFD62D.8040907@oracle.com> References: <50FFBBD1.2070507@oracle.com> <50FFC23B.2060905@oracle.com> <50FFCF78.4060307@oracle.com> <50FFD62D.8040907@oracle.com> Message-ID: <50FFDEF2.50201@oracle.com> On 2013-01-23 13:23, Weijun Wang wrote: > > > On 01/23/2013 07:54 PM, David Holmes wrote: >> On 23/01/2013 8:58 PM, Erik Joelsson wrote: >>> On 2013-01-23 11:30, Weijun Wang wrote: >>>> I thought building an OpenJDK or Oracle JDK can be fully controlled by >>>> using the --enable-openjdk-only configure option, but it seems the >>>> OPENJDK env variable still plays a part. If the variable is set to >>>> true and --enable-openjdk-only is not provided, the new build process >>>> gets confused and fails. >> >> Can you point us at a log? I'd like to see exactly where the confusion >> arises. > > I don't have a log now. The problem is at libfreetype.so. Something > like /libfreetype.so is needed to build .../libfreetype.so. > Yes, I see how this would fail. In a closed build, configure doesn't setup freetype as it's not needed. Thanks. /Erik From Alan.Bateman at oracle.com Wed Jan 23 14:35:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 14:35:07 +0000 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> Message-ID: <50FFF51B.1030809@oracle.com> 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? 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. 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. 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. -Alan. From chris.hegarty at oracle.com Wed Jan 23 14:47:31 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Jan 2013 14:47:31 +0000 Subject: hg: jdk8/tl/jdk: 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Message-ID: <20130123144822.C9D6A474CB@hg.openjdk.java.net> Changeset: bf2a14ebb6e9 Author: chegar Date: 2013-01-23 14:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf2a14ebb6e9 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java From Alan.Bateman at oracle.com Wed Jan 23 14:54:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 14:54:25 +0000 Subject: 8006764: FunctionalInterface missing from rt.jar (old build) Message-ID: <50FFF9A1.5010404@oracle.com> The j.l.FunctionalInterface annotation was added recently but it's not showing up in rt.jar when using the old build (NEWBUILD=false). Unfortunately we have to keep the old build on life support until the new build is bedded down and downstream projects have transitioned. So I need a reviewer to update FILES_java.gmk to add the class name (in the old build then the core area required keeping a list of individual classes). Thanks, -Alan diff --git a/make/java/java/FILES_java.gmk b/make/java/java/FILES_java.gmk --- a/make/java/java/FILES_java.gmk +++ b/make/java/java/FILES_java.gmk @@ -137,6 +137,7 @@ java/lang/Appendable.java \ java/lang/Comparable.java \ java/lang/Readable.java \ + java/lang/FunctionalInterface.java \ java/lang/Override.java \ java/lang/SafeVarargs.java \ java/lang/SuppressWarnings.java \ From Lance.Andersen at oracle.com Wed Jan 23 14:56:07 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 23 Jan 2013 09:56:07 -0500 Subject: 8006764: FunctionalInterface missing from rt.jar (old build) In-Reply-To: <50FFF9A1.5010404@oracle.com> References: <50FFF9A1.5010404@oracle.com> Message-ID: <716AB809-3739-4F71-B166-3C729A50D8A2@oracle.com> +1 On Jan 23, 2013, at 9:54 AM, Alan Bateman wrote: > > The j.l.FunctionalInterface annotation was added recently but it's not showing up in rt.jar when using the old build (NEWBUILD=false). Unfortunately we have to keep the old build on life support until the new build is bedded down and downstream projects have transitioned. > > So I need a reviewer to update FILES_java.gmk to add the class name (in the old build then the core area required keeping a list of individual classes). > > Thanks, > > -Alan > > > diff --git a/make/java/java/FILES_java.gmk b/make/java/java/FILES_java.gmk > --- a/make/java/java/FILES_java.gmk > +++ b/make/java/java/FILES_java.gmk > @@ -137,6 +137,7 @@ > java/lang/Appendable.java \ > java/lang/Comparable.java \ > java/lang/Readable.java \ > + java/lang/FunctionalInterface.java \ > java/lang/Override.java \ > java/lang/SafeVarargs.java \ > java/lang/SuppressWarnings.java \ -------------- 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 forax at univ-mlv.fr Wed Jan 23 14:59:05 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 23 Jan 2013 15:59:05 +0100 Subject: 8006764: FunctionalInterface missing from rt.jar (old build) In-Reply-To: <716AB809-3739-4F71-B166-3C729A50D8A2@oracle.com> References: <50FFF9A1.5010404@oracle.com> <716AB809-3739-4F71-B166-3C729A50D8A2@oracle.com> Message-ID: <50FFFAB9.2050709@univ-mlv.fr> On 01/23/2013 03:56 PM, Lance Andersen - Oracle wrote: > +1 +1 too R?mi > On Jan 23, 2013, at 9:54 AM, Alan Bateman wrote: > >> The j.l.FunctionalInterface annotation was added recently but it's not showing up in rt.jar when using the old build (NEWBUILD=false). Unfortunately we have to keep the old build on life support until the new build is bedded down and downstream projects have transitioned. >> >> So I need a reviewer to update FILES_java.gmk to add the class name (in the old build then the core area required keeping a list of individual classes). >> >> Thanks, >> >> -Alan >> >> >> diff --git a/make/java/java/FILES_java.gmk b/make/java/java/FILES_java.gmk >> --- a/make/java/java/FILES_java.gmk >> +++ b/make/java/java/FILES_java.gmk >> @@ -137,6 +137,7 @@ >> java/lang/Appendable.java \ >> java/lang/Comparable.java \ >> java/lang/Readable.java \ >> + java/lang/FunctionalInterface.java \ >> java/lang/Override.java \ >> java/lang/SafeVarargs.java \ >> java/lang/SuppressWarnings.java \ > > > 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 maurizio.cimadamore at oracle.com Wed Jan 23 15:08:44 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 23 Jan 2013 15:08:44 +0000 Subject: hg: jdk8/tl/langtools: 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Message-ID: <20130123150849.81DF2474CD@hg.openjdk.java.net> Changeset: 97bd5e7151bc Author: mcimadamore Date: 2013-01-23 15:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97bd5e7151bc 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Summary: Missing boxing cause spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8006692/T8006692.java From chris.hegarty at oracle.com Wed Jan 23 15:12:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 23 Jan 2013 15:12:38 +0000 Subject: 8006764: FunctionalInterface missing from rt.jar (old build) In-Reply-To: <716AB809-3739-4F71-B166-3C729A50D8A2@oracle.com> References: <50FFF9A1.5010404@oracle.com> <716AB809-3739-4F71-B166-3C729A50D8A2@oracle.com> Message-ID: <50FFFDE6.9070903@oracle.com> Looks fine to me too. -Chris. On 23/01/2013 14:56, Lance Andersen - Oracle wrote: > +1 > On Jan 23, 2013, at 9:54 AM, Alan Bateman wrote: > >> >> The j.l.FunctionalInterface annotation was added recently but it's not showing up in rt.jar when using the old build (NEWBUILD=false). Unfortunately we have to keep the old build on life support until the new build is bedded down and downstream projects have transitioned. >> >> So I need a reviewer to update FILES_java.gmk to add the class name (in the old build then the core area required keeping a list of individual classes). >> >> Thanks, >> >> -Alan >> >> >> diff --git a/make/java/java/FILES_java.gmk b/make/java/java/FILES_java.gmk >> --- a/make/java/java/FILES_java.gmk >> +++ b/make/java/java/FILES_java.gmk >> @@ -137,6 +137,7 @@ >> java/lang/Appendable.java \ >> java/lang/Comparable.java \ >> java/lang/Readable.java \ >> + java/lang/FunctionalInterface.java \ >> java/lang/Override.java \ >> java/lang/SafeVarargs.java \ >> java/lang/SuppressWarnings.java \ > > > > > 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 Jan 23 15:14:46 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 Jan 2013 15:14:46 +0000 Subject: hg: jdk8/tl/jdk: 8006764: FunctionalInterface missing from rt.jar (old build) Message-ID: <20130123151511.AFF7C474CE@hg.openjdk.java.net> Changeset: 53064bbaeec5 Author: alanb Date: 2013-01-23 15:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53064bbaeec5 8006764: FunctionalInterface missing from rt.jar (old build) Reviewed-by: lancea, forax ! make/java/java/FILES_java.gmk From eric.mccorkle at oracle.com Wed Jan 23 15:16:25 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 23 Jan 2013 10:16:25 -0500 Subject: Need volunteer to push JDK-8004729 Message-ID: <50FFFEC9.2080703@oracle.com> I'm not a committer, so I need someone to push this changeset for me. Thanks, Eric From Alan.Bateman at oracle.com Wed Jan 23 15:48:42 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 15:48:42 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <50FE3EE5.20600@oracle.com> References: <50FE3EE5.20600@oracle.com> Message-ID: <5100065A.9080801@oracle.com> Moving to core-libs-dev to allow for wider review. As Dan mentions, we've been looking to remove the Solairs-specific interruptible I/O for a long time. -------- Original Message -------- Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code Date: Mon, 21 Jan 2013 23:25:25 -0800 From: Dan Xu To: nio-dev Hi, Interruptible I/O on Solaris has been highly problematicand undercut portability. And the long term plan is to remove it completely from JDK. In JDK6, the VM option, UseVMInterruptibleIO, was introduced as part of a phase-out plan to allow developers/customers to disable it. In JDK7, the default value of UseVMInterruptibleIO flag was changed to"false" to make Solaris blockingI/O operations uninterruptible by Java thread interruptsby default. The last stepof this phase-out plan is to remove the feature completely. And it is good to do it now in JDK8. In this fix, I removed all related codes in IO area by replacing JVM_* functions with direct system calls. Please help review the proposed fix. Similar changes in networking area will be done via a different bug. Bug: https://jbs.oracle.com/bugs/browse/JDK-8001334 webrev: http://cr.openjdk.java.net/~dxu/8001334/webrev.00/ Best, -Dan From Alan.Bateman at oracle.com Wed Jan 23 15:56:18 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 15:56:18 +0000 Subject: Need volunteer to push JDK-8004729 In-Reply-To: <50FFFEC9.2080703@oracle.com> References: <50FFFEC9.2080703@oracle.com> Message-ID: <51000822.5080609@oracle.com> On 23/01/2013 15:16, Eric McCorkle wrote: > I'm not a committer, so I need someone to push this changeset for me. > > Thanks, > Eric I'm not volunteering (sorry) but just checking that the HotSpot changes are in jdk8/tl/hotspot already? I think they are, but just doubling checking to avoid problems if someone pushes this to jdk8/tl/jdk today. -Alan From eric.mccorkle at oracle.com Wed Jan 23 16:00:05 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Wed, 23 Jan 2013 11:00:05 -0500 Subject: Need volunteer to push JDK-8004729 In-Reply-To: <51000822.5080609@oracle.com> References: <50FFFEC9.2080703@oracle.com> <51000822.5080609@oracle.com> Message-ID: <51000905.4040006@oracle.com> The first set (JDK-8004728) are in as of last week. The second set (JDK-8006005) are not, and it doesn't look like they are going to make it. However, JDK-8006005 only fixes some small bugs, so I can mark one of the tests I wrote @ignore. On 01/23/13 10:56, Alan Bateman wrote: > On 23/01/2013 15:16, Eric McCorkle wrote: >> I'm not a committer, so I need someone to push this changeset for me. >> >> Thanks, >> Eric > I'm not volunteering (sorry) but just checking that the HotSpot changes > are in jdk8/tl/hotspot already? I think they are, but just doubling > checking to avoid problems if someone pushes this to jdk8/tl/jdk today. > > -Alan From rob.mckenna at oracle.com Wed Jan 23 16:15:56 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 23 Jan 2013 16:15:56 +0000 Subject: Need volunteer to push JDK-8004729 In-Reply-To: <50FFFEC9.2080703@oracle.com> References: <50FFFEC9.2080703@oracle.com> Message-ID: <51000CBC.6030100@oracle.com> Hi Erik, I can take care of this later this evening. -Rob On 23/01/13 15:16, Eric McCorkle wrote: > I'm not a committer, so I need someone to push this changeset for me. > > Thanks, > Eric From rob.mckenna at oracle.com Wed Jan 23 16:16:45 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 23 Jan 2013 16:16:45 +0000 Subject: Need volunteer to push JDK-8004729 In-Reply-To: <51000822.5080609@oracle.com> References: <50FFFEC9.2080703@oracle.com> <51000822.5080609@oracle.com> Message-ID: <51000CED.4060305@oracle.com> ..once this is confirmed. -Rob On 23/01/13 15:56, Alan Bateman wrote: > On 23/01/2013 15:16, Eric McCorkle wrote: >> I'm not a committer, so I need someone to push this changeset for me. >> >> Thanks, >> Eric > I'm not volunteering (sorry) but just checking that the HotSpot > changes are in jdk8/tl/hotspot already? I think they are, but just > doubling checking to avoid problems if someone pushes this to > jdk8/tl/jdk today. > > -Alan From rob.mckenna at oracle.com Wed Jan 23 16:22:18 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 23 Jan 2013 16:22:18 +0000 Subject: Need volunteer to push JDK-8004729 In-Reply-To: <51000905.4040006@oracle.com> References: <50FFFEC9.2080703@oracle.com> <51000822.5080609@oracle.com> <51000905.4040006@oracle.com> Message-ID: <51000E3A.1010203@oracle.com> There seems to be some mail delivery problems. I volunteered to push the change in an earlier mail. It sounds like that testcase change makes sense, so send the details when you're ready and I'll push later this evening. -Rob On 23/01/13 16:00, Eric McCorkle wrote: > The first set (JDK-8004728) are in as of last week. The second set > (JDK-8006005) are not, and it doesn't look like they are going to make > it. However, JDK-8006005 only fixes some small bugs, so I can mark one > of the tests I wrote @ignore. > > On 01/23/13 10:56, Alan Bateman wrote: >> On 23/01/2013 15:16, Eric McCorkle wrote: >>> I'm not a committer, so I need someone to push this changeset for me. >>> >>> Thanks, >>> Eric >> I'm not volunteering (sorry) but just checking that the HotSpot changes >> are in jdk8/tl/hotspot already? I think they are, but just doubling >> checking to avoid problems if someone pushes this to jdk8/tl/jdk today. >> >> -Alan From jim.gish at oracle.com Wed Jan 23 17:08:58 2013 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 23 Jan 2013 12:08:58 -0500 Subject: RFR: 4247235 (spec str) StringBuffer.insert(int, char[]) specification is inconsistent In-Reply-To: <50FEEE76.9090304@oracle.com> References: <50EDF350.7050302@oracle.com> <50EEE585.6000800@oracle.com> <50FEEB2A.5030509@oracle.com> <50FEEE76.9090304@oracle.com> Message-ID: <5100192A.6040208@oracle.com> This time with the attachment... Thanks, Jim On 01/22/2013 02:54 PM, Jim Gish wrote: > change set/patch attached for pushing. > > Thanks, > Jim > On 01/22/2013 02:40 PM, Jim Gish wrote: >> I've made the changes as suggested by Mike, and this has now been >> approved by CCC. Could someone please give it one more look and push >> it for me, please? >> >> Thanks, >> Jim >> >> http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ >> >> >> On 01/10/2013 11:00 AM, Jim Gish wrote: >>> Stephen, >>> Currently here's (a sampling) of how the other methods work. >>> Although most check indices first, not all do... (The original bug >>> was about this very inconsistency, however one answer given to it >>> was that in general we don't say anything about order of >>> exceptions). However, given that most of the methods do index >>> checking first, I think I agree with Mike on this one. >>> >>> Jim >>> >>> getChars(int srcBegin, int srcEnd, char[]dst, int dstBegin) >>> - will check for srcBegin, srcEnd first and throw >>> StringIndexOutOfBoundsException >>> - then System.arraycopy checks for null and throws NPE >>> >>> replace(int start, int end, String str) >>> - same as above (checking start and end first) >>> >>> insert(int index, char[] str, int offset, int len) >>> - same as above (checking index and offset first) >>> >>> insert(int offset, char[] str) >>> - same (checking offset first) >>> >>> String(char value[], int offset, int count) >>> - same >>> String(int[] codePoints, int offset, int count) >>> - same >>> String(byte ascii[], int hibyte, int offset, int count) >>> - same >>> String(byte bytes[], int offset, int length, String >>> charsetName) >>> - same >>> >>> * String(byte bytes[], int offset, int length, Charset charset) >>> - checks charset == null first! >>> - then checks offset and length >>> - and then checks bytes==null >>> >>> String.getChars(char dst[], int dstBegin) >>> - checks for dst==null first >>> - then for bad and throw ArrayIndexOutOfBoundsException >>> >>> >>> On 01/10/2013 06:47 AM, Stephen Colebourne wrote: >>>> I would encourage null checking to be done first, rather than >>>> sometimes getting StringIndexOutOfBoundsException for a null input. >>>> Reasoning about the JDK methods is much easier that way around. >>>> >>>> Stephen >>>> >>>> >>>> On 9 January 2013 23:09, Mike Duigou wrote: >>>>> AbstractStringBuilder probably needs the "Unless otherwise noted," >>>>> blanket statement as well (Same as StringBuffer/StringBuilder) >>>>> >>>>> You might want to move the Objects.requireNonNull(dst); in >>>>> String.getBytes() to after the existing checks so as not to >>>>> unnecessarily change the exception thrown for bad inputs. An >>>>> exception will still be thrown but some bad code may anticipate >>>>> StringIndexOutOfBoundsException rather than NPE. This is a very >>>>> minor matter though. >>>>> >>>>> Otherwise, it looks good. >>>>> >>>>> Mike >>>>> >>>>> On Jan 9 2013, at 14:46 , Jim Gish wrote: >>>>> >>>>>> Please review the following: >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/ >>>>>> >>>>>> >>>>>> Here's a specdiff: >>>>>> http://cr.openjdk.java.net/~jgish/Bug4247235-string-specdiff/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: This change replaces java/lang/*String*.java javadoc, >>>>>> method-specific @throws NullPointerException clauses with >>>>>> blanket null-handling statements like that currently in String.java >>>>>> >>>>>> That was motivated by a discussion awhile back, strongly favoring >>>>>> a blanket statement over individual @throws clauses. >>>>>> >>>>>> For String, the following blanket statement is already in place: >>>>>> >>>>>> *

Unless otherwise noted, passing a null argument to >>>>>> a constructor >>>>>> * or method in this class will cause a {@link >>>>>> NullPointerException} to be >>>>>> * thrown. >>>>>> >>>>>> >>>>>> However, despite the blanket statement, the following methods >>>>>> also have @throws clauses: >>>>>> >>>>>> public boolean contains(java.lang.CharSequence s) >>>>>> >>>>>> Throws: >>>>>> |java.lang.NullPointerException|- if|s|is|null| >>>>>> --------------------------------------------------------------- >>>>>> >>>>>> public staticString >>>>>> >>>>>> format(String >>>>>> >>>>>> format, >>>>>> java.lang.Object... args) >>>>>> >>>>>> >>>>>> Throws: >>>>>> |java.lang.NullPointerException|- If the|format|is|null >>>>>> |----------------------------------------------------------------------- >>>>>> >>>>>> || >>>>>> >>>>>> public staticString >>>>>> >>>>>> format(java.util.Locale l, >>>>>> String >>>>>> >>>>>> format, >>>>>> java.lang.Object... args) >>>>>> >>>>>> Throws: >>>>>> |java.lang.NullPointerException|- If the|format|is|null >>>>>> |-------------------------------------------------------------------------- >>>>>> >>>>>> All of the above are properly specified with the blanket >>>>>> statement or other parts of their spec (such as format w.r.t. >>>>>> null Locale) and the @throws can safely be removed. >>>>>> >>>>>> Because the blanket statement is already in effect for >>>>>> String.java, I wrote tests for all methods/constructors to ensure >>>>>> compliance. Running them revealed the following: >>>>>> >>>>>> public void getBytes(int srcBegin, int srcEnd, byte dst[], int >>>>>> dstBegin) >>>>>> - I would expect an NPE to be thrown if dst == null. However, >>>>>> this isn't always the case. If dst isn't accessed because of the >>>>>> values of the other parameters (as in >>>>>> getBytes(1,2,(byte[]null,1), then no NPE is thrown. >>>>>> - This brings up the question as to the correctness of the >>>>>> blanket statement w.r.t. this method. I think this method (and >>>>>> others like it) should use Objects.requireNonNull(dst). (The >>>>>> correspoding method public void getChars(int srcBegin, int >>>>>> srcEnd, char dst[], int dstBegin), does always throw NPE for >>>>>> dst==null) >>>>>> >>>>>> All other methods/constructors in StringBuffer and StringBuilder >>>>>> either correctly state null-handling behavior that differs from >>>>>> the blanket statement or are correct w.r.t. the blanket statement. >>>>>> >>>>>> This has been reviewed by the JCK team. It will require CCC >>>>>> approval (because of the new blanket statement, and the fact that >>>>>> some of the existing methods were previously silent on null >>>>>> handling, but all already conform to the blanket statement). >>>>>> >>>>>> Thanks, >>>>>> Jim Gish >>>>>> >>>>>> >>>>>> -- >>>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>>>>> Oracle Java Platform Group | Core Libraries Team >>>>>> 35 Network Drive >>>>>> Burlington, MA 01803 >>>>>> jim.gish at oracle.com >>>>>> >>>>>> -- >>>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>>>>> Oracle Java Platform Group | Core Libraries Team >>>>>> 35 Network Drive >>>>>> Burlington, MA 01803 >>>>>> jim.gish at oracle.com >>>>>> >>> >> > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From xueming.shen at oracle.com Wed Jan 23 17:46:33 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 23 Jan 2013 09:46:33 -0800 Subject: Codereview request for 8006773: test/java/util/zip/ZipFile/FinalizeZipFile.java failing intermittently Message-ID: <510021F9.5060801@oracle.com> Alan, Here is the webrev for the intermittently j.u.zf regression failure we talked about last night. I'm using the limited loop instead of while(true) to just be cautious. http://cr.openjdk.java.net/~sherman/8006773/webrev Thanks, -Sherman From Alan.Bateman at oracle.com Wed Jan 23 17:51:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 17:51:48 +0000 Subject: Codereview request for 8006773: test/java/util/zip/ZipFile/FinalizeZipFile.java failing intermittently In-Reply-To: <510021F9.5060801@oracle.com> References: <510021F9.5060801@oracle.com> Message-ID: <51002334.1000801@oracle.com> On 23/01/2013 17:46, Xueming Shen wrote: > Alan, > > Here is the webrev for the intermittently j.u.zf regression failure we > talked > about last night. > > I'm using the limited loop instead of while(true) to just be cautious. > > http://cr.openjdk.java.net/~sherman/8006773/webrev Looks okay to me (although if tzdb.jar is chosen 20 times or so in succession then it will fail). -Alan. From rob.mckenna at oracle.com Wed Jan 23 18:00:35 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 23 Jan 2013 18:00:35 +0000 Subject: hg: jdk8/tl/jdk: 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Message-ID: <20130123180114.08DA3474D4@hg.openjdk.java.net> Changeset: c9eb1d3ef37f Author: robm Date: 2013-01-23 17:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9eb1d3ef37f 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Reviewed-by: darcy, forax, psandoz, dholmes, tbell ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java + src/share/classes/java/lang/reflect/Parameter.java ! src/share/javavm/export/jvm.h + src/share/native/java/lang/reflect/Executable.c + test/java/lang/reflect/Parameter/WithParameters.java + test/java/lang/reflect/Parameter/WithoutParameters.java From xueming.shen at oracle.com Wed Jan 23 18:26:36 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 18:26:36 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130123182710.1873D474D5@hg.openjdk.java.net> Changeset: e0552f13f4a2 Author: sherman Date: 2013-01-23 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0552f13f4a2 8006773: test/java/util/zip/ZipFile/FinalizeZipFile.java failing intermittently Summary: fixed the test case Reviewed-by: alanb ! test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 87f5569effdd Author: sherman Date: 2013-01-23 10:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87f5569effdd Merge From vladimir.kozlov at oracle.com Wed Jan 23 19:19:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Jan 2013 11:19:22 -0800 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> Message-ID: <510037BA.6060403@oracle.com> To close this discussion before I do the push here are performance numbers for C1. Numbers are almost similar (few % worser, note that with C2 it improved) because C1 does not do loop optimizations. size: 1 time: 25 26 size: 7 time: 33 34 size: 8 time: 34 36 size: 16 time: 45 47 size: 32 time: 66 68 size: 64 time: 117 119 size: 128 time: 203 205 size: 256 time: 374 376 size: 512 time: 718 719 size: 1024 time: 1407 1403 size: 2048 time: 2776 2775 size: 4096 time: 5519 5517 Today is the last day when I can do this push before feature freeze. And I did tons of testing with current code (latest webrev) so I am not going to change it just before the push. Thanks, Vladimir On 1/22/13 11:56 PM, Kirk Pepperdine wrote: > > On 2013-01-23, at 1:14 AM, Vitaly Davidovich > wrote: > >> Personally, optimizing for interpreter (or even C1) doesn't seem worth >> it. If something's truly hot and best perf is desired then use C2 or >> tiered. If the method isn't hot enough to trigger the C2 threshold, >> then why bother? You're already behind the 8 ball in terms of >> performance. Maybe this is heresy though :). >> >> > Maybe, maybe not.. what I can say is this is a case of an optimization > that doesn't scale down. In cases where scale down was needed I > have recommended to customers that they "flash" their system just to > push the counter beyond the compile threshold. In those cases naively > compiled code was still a lot better than interrupting byte code. I've > also turned off decay in a number of applications where loads weren't > quite enough to beat the decay behaviour. Yeah I know this is at the > risk of filling code cache but code cache occupancy is something that I > regularly recommend people monitor for (check my VisualVM memory pool > plug-in). In fact, I just tuned an app where I used -Xcomp to estimate > how big the code cache needed to be to avoid filling it. Production > settings had decay turned off. So, I can't say your wrong and I > generally don't like fiddling with these setting but I will if I have to > and I've had to in a number of instances where ensuring a compile beat > leaving it alone. > > Regards, > Kirk > From vicente.romero at oracle.com Wed Jan 23 21:00:05 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 23 Jan 2013 21:00:05 +0000 Subject: hg: jdk8/tl/langtools: 8006694: temporarily workaround combo tests are causing time out in several platforms Message-ID: <20130123210011.5DE04474E4@hg.openjdk.java.net> Changeset: 5c956be64b9e Author: vromero Date: 2013-01-23 20:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c956be64b9e 8006694: temporarily workaround combo tests are causing time out in several platforms Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! test/Makefile ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From vincent.x.ryan at oracle.com Wed Jan 23 21:27:34 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 21:27:34 +0000 Subject: hg: jdk8/tl/jdk: 8006591: Protect keystore entries using stronger PBE algorithms Message-ID: <20130123212752.E5816474E5@hg.openjdk.java.net> Changeset: 0c86df653029 Author: vinnie Date: 2013-01-23 21:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c86df653029 8006591: Protect keystore entries using stronger PBE algorithms Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/java/security/KeyStore/PBETest.java From jonathan.gibbons at oracle.com Wed Jan 23 21:28:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 21:28:05 +0000 Subject: hg: jdk8/tl/langtools: 8006775: JSR 308: Compiler changes in JDK8 Message-ID: <20130123212807.D5A39474E6@hg.openjdk.java.net> Changeset: 71f35e4b93a5 Author: jjg Date: 2013-01-23 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71f35e4b93a5 8006775: JSR 308: Compiler changes in JDK8 Reviewed-by: jjg Contributed-by: mernst at cs.washington.edu, wmdietl at cs.washington.edu, mpapi at csail.mit.edu, mahmood at notnoop.com + src/share/classes/com/sun/javadoc/AnnotatedType.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Type.java ! src/share/classes/com/sun/javadoc/TypeVariable.java + src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/MethodTree.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/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! 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/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! 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/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.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/Annotate.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/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.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/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.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/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java + src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java + src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/SourceVersion.java + src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java + test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java + test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java + test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java + test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref ! test/tools/javac/T6873845.java + test/tools/javac/T6985181.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.java + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.out + test/tools/javac/annotations/typeAnnotations/InnerClass.java + test/tools/javac/annotations/typeAnnotations/MultipleTargets.java + test/tools/javac/annotations/typeAnnotations/TargetTypes.java + test/tools/javac/annotations/typeAnnotations/TypeParameterTarget.java + test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java + test/tools/javac/annotations/typeAnnotations/TypeUseTarget.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/attribution/Scopes.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/DeadCode.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/AnnotatedImport.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out + test/tools/javac/annotations/typeAnnotations/failures/BadCast.java + test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java + test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out + test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java + test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out + test/tools/javac/annotations/typeAnnotations/failures/LintCast.java + test/tools/javac/annotations/typeAnnotations/failures/LintCast.out + test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/Scopes.java + test/tools/javac/annotations/typeAnnotations/failures/Scopes.out + test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java + test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out + test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java + test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out + test/tools/javac/annotations/typeAnnotations/failures/TypeAndField.java + test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.java + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.out + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.out + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.java + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.out + test/tools/javac/annotations/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/ConstructorTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Expressions.java + test/tools/javac/annotations/typeAnnotations/newlocations/Fields.java + test/tools/javac/annotations/typeAnnotations/newlocations/LocalVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodReturnType.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/newlocations/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/newlocations/Parameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Receivers.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out + test/tools/javac/annotations/typeAnnotations/newlocations/ResourceVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/Throws.java + test/tools/javac/annotations/typeAnnotations/newlocations/TopLevelBlocks.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java + test/tools/javac/annotations/typeAnnotations/newlocations/Wildcards.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 ! test/tools/javac/api/EndPositions.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateStaticClass.java + test/tools/javac/diags/examples/IncorrectReceiverType.java + test/tools/javac/diags/examples/NoAnnotationsOnDotClass.java + test/tools/javac/diags/examples/ThisAsIdentifier.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/processing/6994946/SemanticErrorTest.2.out ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java + test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java + test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/tools/javac/tree/TreeKindTest.java ! test/tools/javac/tree/TreePosTest.java + test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/TestProcessor.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out + test/tools/javap/typeAnnotations/JSR175Annotations.java + test/tools/javap/typeAnnotations/NewArray.java + test/tools/javap/typeAnnotations/Presence.java + test/tools/javap/typeAnnotations/PresenceInner.java + test/tools/javap/typeAnnotations/T6855990.java + test/tools/javap/typeAnnotations/TypeCasts.java + test/tools/javap/typeAnnotations/Visibility.java + test/tools/javap/typeAnnotations/Wildcards.java From vincent.x.ryan at oracle.com Wed Jan 23 23:14:41 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 23:14:41 +0000 Subject: hg: jdk8/tl/jdk: 8005408: KeyStore API enhancements Message-ID: <20130123231505.DF6E7474F6@hg.openjdk.java.net> Changeset: 1da93663f8f3 Author: vinnie Date: 2013-01-23 23:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da93663f8f3 8005408: KeyStore API enhancements Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/java/security/PKCS12Attribute.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/pkcs12/StorePasswordTest.java + test/sun/security/pkcs12/StoreSecretKeyTest.java + test/sun/security/pkcs12/StoreTrustedCertTest.java + test/sun/security/pkcs12/trusted.pem From martinrb at google.com Thu Jan 24 00:10:36 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 23 Jan 2013 16:10:36 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> Message-ID: Ping. On Wed, Jan 16, 2013 at 12:24 PM, Martin Buchholz wrote: > On Tue, Jan 15, 2013 at 5:33 PM, Martin Buchholz > wrote: > > Actually, I think y'all should do 3 things: > > - backport Kumar's bug fix to jdk7 > > - introduce a system property to turn off the zip64 support. > > I am working on a patch to introduce such a system property. > > We will probably default to disabling zip64 by default, but you will > > probably find that unacceptable. But you can default the other way. > > - fix up some remaining largefile issues in parse_manifest > > I might contribute a bit of code here as well. > > As I said, I'm willing to do more work on this mini-project myself, > but we need rough consensus on the direction we should go. > From sean.mullan at oracle.com Thu Jan 24 01:47:52 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 24 Jan 2013 01:47:52 +0000 Subject: hg: jdk8/tl/jdk: 8006813: Compilation error in PKCS12KeyStore.java Message-ID: <20130124014816.49EFF474FE@hg.openjdk.java.net> Changeset: 89f37f7188df Author: mullan Date: 2013-01-23 20:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89f37f7188df 8006813: Compilation error in PKCS12KeyStore.java Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From david.holmes at oracle.com Thu Jan 24 01:56:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2013 11:56:10 +1000 Subject: OPENJDK env var not playing well with new build In-Reply-To: <50FFD39B.5050105@oracle.com> References: <50FFBBD1.2070507@oracle.com> <50FFC23B.2060905@oracle.com> <50FFCF78.4060307@oracle.com> <50FFD39B.5050105@oracle.com> Message-ID: <510094BA.7070508@oracle.com> On 23/01/2013 10:12 PM, Erik Joelsson wrote: > On 2013-01-23 12:54, David Holmes wrote: >> On 23/01/2013 8:58 PM, Erik Joelsson wrote: >>> On 2013-01-23 11:30, Weijun Wang wrote: >>>> I thought building an OpenJDK or Oracle JDK can be fully controlled by >>>> using the --enable-openjdk-only configure option, but it seems the >>>> OPENJDK env variable still plays a part. If the variable is set to >>>> true and --enable-openjdk-only is not provided, the new build process >>>> gets confused and fails. >> >> Can you point us at a log? I'd like to see exactly where the confusion >> arises. >> >>>> I understand this is my fault and I should not have that variable >>>> around. However, it will be nice if the build can deny all external >>>> variables like it did with all those ALT_*** variables. Are there any >>>> other variables I should be aware of? >>>> >>> This is bad, I agree. We initially kept the same variable for >>> controlling if the build was OpenJDK only or not as the old build, >>> because it made it easier during the conversion. The problem with this >>> variable is that it is either set or not, which makes it harder to >>> override in makefiles. The proper solution would be to replace this in >>> the new build with something like OPENJDK_ONLY=true/false and completely >>> ignore the old OPENJDK. >> >> Not sure why the set/unset situation is a problem. If OPENJDK is set >> then it must be set to true else the sanity checks fail. >> >> But we should locate anywhere that the make files still examine the >> environment for such variables - not that I thought there were such >> places. The environment variables should only be used to influence how >> configure runs, and the variables it sets should then be used by the >> make files. >> > The problem I can imagine is this: Configure creates a configuration > without --enable-openjdk-only, which results in a spec.gmk with no > OPENJDK=true in it. OPENJDK=true is then set in the environment, which > will trigger all ifdef OPENJDK in the makefiles. Right - sorry. I was mistakenly thinking that make only looks at environment variables if asked via -e. This was not a problem in the old build as the makefiles were responsible for setting up all the "environment", but now if --enable-openjdk-only influences the setting of other variables, then as you say we get a hybrid effect. :( > This would end up being > a hybrid between fully open and a closed build since configure has > already done things differently at configure time, but the makefiles > will try to behave as if it was an open build. I don't know where this > fails, but I'm not surprised that it does, and even if it didn't fail, > the resulting bits would be bad. If instead spec.gmk would have a line > like OPENJDK_ONLY=false, this would always override any environment > variable. Maybe we can at least detect this by setting OPENJDK_ONLY=true for --enable-openjdk-only and then doing in spec.gmk: ifeq ($(OPENJDK_ONLY), false) ifeq ($(OPENJDK), true) error This is not an OPENJDK configuration. Ensure OPENJDK is not set in your environmemt fi fi David > /Erik From joe.darcy at oracle.com Thu Jan 24 04:11:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 24 Jan 2013 04:11:18 +0000 Subject: hg: jdk8/tl/langtools: 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Message-ID: <20130124041124.3C31447505@hg.openjdk.java.net> Changeset: 09f65aad4759 Author: darcy Date: 2013-01-23 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09f65aad4759 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/AnnotationValueVisitor.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java From xueming.shen at oracle.com Thu Jan 24 05:17:06 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 23 Jan 2013 21:17:06 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F6010D.5000806@oracle.com> Message-ID: <5100C3D2.6040604@oracle.com> Hi Martin, sorry for the late response, was busy on other stuff these days. I'm OK with the idea of introducing a system property to turn off zip64 support, but NOT by default. You can make it default in your internal build. You do the code, I do the internal process/paper work (need go CCC for it). Let's do it for 8 first. -Sherman On 1/23/13 4:10 PM, Martin Buchholz wrote: > Ping. > > On Wed, Jan 16, 2013 at 12:24 PM, Martin Buchholz > wrote: > > On Tue, Jan 15, 2013 at 5:33 PM, Martin Buchholz > > wrote: > > Actually, I think y'all should do 3 things: > > - backport Kumar's bug fix to jdk7 > > - introduce a system property to turn off the zip64 support. > > I am working on a patch to introduce such a system property. > > We will probably default to disabling zip64 by default, but you will > > probably find that unacceptable. But you can default the other way. > > - fix up some remaining largefile issues in parse_manifest > > I might contribute a bit of code here as well. > > As I said, I'm willing to do more work on this mini-project myself, > but we need rough consensus on the direction we should go. > > From martinrb at google.com Thu Jan 24 08:27:28 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 24 Jan 2013 00:27:28 -0800 Subject: zip64 compatibility problems In-Reply-To: <5100C3D2.6040604@oracle.com> References: <50F6010D.5000806@oracle.com> <5100C3D2.6040604@oracle.com> Message-ID: On Wed, Jan 23, 2013 at 9:17 PM, Xueming Shen wrote: > Hi Martin, sorry for the late response, was busy on other stuff these days. Current deadline pressures are understood! > I'm OK > with the idea of introducing a system property to turn off zip64 support, > but NOT > by default. You can make it default in your internal build. You do the code, > I do > the internal process/paper work (need go CCC for it). Let's do it for 8 > first. OK - I'll prepare some changes. From alan.bateman at oracle.com Thu Jan 24 09:49:07 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Jan 2013 09:49:07 +0000 Subject: hg: jdk8/tl/jdk: 8006524: JSR-3: Allows java.beans to be optional Message-ID: <20130124094930.1C5AC4750C@hg.openjdk.java.net> Changeset: b68ac92d0b2a Author: alanb Date: 2013-01-24 09:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b68ac92d0b2a 8006524: JSR-3: Allows java.beans to be optional Reviewed-by: dfuchs, mchung ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/monitor/package.html From peter.levart at gmail.com Thu Jan 24 13:49:56 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 24 Jan 2013 14:49:56 +0100 Subject: Proxy.isProxyClass scalability Message-ID: <51013C04.8020809@gmail.com> Hello, Recently I stumbled upon the scalability problem of j.l.r.Proxy.isProxyClass(Class) method when trying to find-out why the equals() method of annotations is not scalable. The reason is that j.l.r.Proxy uses a single synchronized wrapper around WeakHashMap to keep track of proxy classes in order to implement isProxyClass method: 244 /** set of all generated proxy classes, for isProxyClass implementation */ 245 private static Map, Void> proxyClasses = 246 Collections.synchronizedMap(new WeakHashMap, Void>()); 631 public static boolean isProxyClass(Class cl) { 632 if (cl == null) { 633 throw new NullPointerException(); 634 } 635 636 return proxyClasses.containsKey(cl); 637 } In the discussion on the cuncurrency-interest list: * http://cs.oswego.edu/pipermail/concurrency-interest/2013-January/010642.html ...it was indicated that other places in JDK besides the annotation's equals() method suffer from this scalability bottleneck, mainly in the field of serialization, RMI and JMX. With the help from this discussion, I prepared a possible fix which I'm proposing here: http://dl.dropbox.com/u/101777488/jdk8-tl/isProxyClass/webrev.01/index.html The fix drops usage of synchronized wrapper and WeakHashMap and replaces them with a ClassValue and a little ThreadLocal trick to initialize it. The ThreadLocal trick could be replaced with a simple static variable guarded by a synchronized block if desired. I have some results from a micro-benchmark that exercises the annotation's equals method. The results were obtained on two different systems: * https://raw.github.com/plevart/jdk8-tl/proxy/test/benchmark_results.txt The benchmark sources: * https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/AnnotationEqualsTest.java * https://github.com/plevart/micro-bench/blob/master/src/si/pele/microbench/TestRunner.java Thanks to Aleksey Shipilev for showing me the obvious pitfalls when designing a micro-benchmark. I hope this time it does the job correctly... What do you thik? Should I file a RFE first? Regards, Peter From Alan.Bateman at oracle.com Thu Jan 24 14:10:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Jan 2013 14:10:53 +0000 Subject: Proxy.isProxyClass scalability In-Reply-To: <51013C04.8020809@gmail.com> References: <51013C04.8020809@gmail.com> Message-ID: <510140ED.7080205@oracle.com> On 24/01/2013 13:49, Peter Levart wrote: > Should I file a RFE first? Sorry I don't have time at the moment to study the proposed patch but just to mention that it has come up a few times, its just that it never bubbled up to the top of anyone's list. Here's the bug tracking it: http://bugs.sun.com/view_bug.do?bug_id=7123493 -Alan. From peter.levart at gmail.com Thu Jan 24 14:34:20 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 24 Jan 2013 15:34:20 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <510140ED.7080205@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> Message-ID: <5101466C.9080705@gmail.com> On 01/24/2013 03:10 PM, Alan Bateman wrote: > On 24/01/2013 13:49, Peter Levart wrote: >> Should I file a RFE first? > Sorry I don't have time at the moment to study the proposed patch but > just to mention that it has come up a few times, its just that it > never bubbled up to the top of anyone's list. Here's the bug tracking it: > > http://bugs.sun.com/view_bug.do?bug_id=7123493 > > -Alan. I belive that is another bottleneck. It is mentioning the Proxy.getProxyClass method which also uses synchronization for maintaining a cache of proxy classes by request parameters. I could as well try to fix this too in the same patch if there is interest. Regards, Peter From vitalyd at gmail.com Thu Jan 24 14:40:31 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 24 Jan 2013 09:40:31 -0500 Subject: Proxy.isProxyClass scalability In-Reply-To: <5101466C.9080705@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> Message-ID: Peter, I know this was brought up on your c-i mailing list thread, but it really feels like a new boolean field in j.l.Class is the cleaner solution (and infinitely scalable and doesn't require bookkeeping in the Proxy class). Is there really no existing alignment gap in j.l.Class layout that a boolean can slide into? Sent from my phone On Jan 24, 2013 9:35 AM, "Peter Levart" wrote: > On 01/24/2013 03:10 PM, Alan Bateman wrote: > >> On 24/01/2013 13:49, Peter Levart wrote: >> >>> Should I file a RFE first? >>> >> Sorry I don't have time at the moment to study the proposed patch but >> just to mention that it has come up a few times, its just that it never >> bubbled up to the top of anyone's list. Here's the bug tracking it: >> >> http://bugs.sun.com/view_bug.**do?bug_id=7123493 >> >> -Alan. >> > I belive that is another bottleneck. It is mentioning the > Proxy.getProxyClass method which also uses synchronization for maintaining > a cache of proxy classes by request parameters. I could as well try to fix > this too in the same patch if there is interest. > > Regards, Peter > > From peter.levart at gmail.com Thu Jan 24 15:45:57 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 24 Jan 2013 16:45:57 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> Message-ID: <51015735.2090106@gmail.com> On 01/24/2013 03:40 PM, Vitaly Davidovich wrote: > > Peter, > > I know this was brought up on your c-i mailing list thread, but it > really feels like a new boolean field in j.l.Class is the cleaner > solution (and infinitely scalable and doesn't require bookkeeping in > the Proxy class). Is there really no existing alignment gap in > j.l.Class layout that a boolean can slide into? > There might be, I will check. The ClassValue is scalable too (check the benchmarks), and bookkeeping is performed in the ClassValue.ClassValueMap that is referenced from the Class - not in the Proxy class. Unfortunately the j.l.r.Proxy class is in another package from j.l.Class, so the solution with a simple boolean field would require JavaLangAccess or Unsafe acrobatics. Another thing is this separate bug: http://bugs.sun.com/view_bug.do?bug_id=7123493 To solve it, a reference field in j.l.ClassLoader or a hypothetical ClassLoaderValue implementation would be required. I looked at the bug reporter's solution (ConcurrentProxy). He guards the WeakHashMap with a ReadWriteLock: /* * Find or create the proxy class cache for the class loader. */ Map> cache; try{ loaderToCacheLock.readLock().lock(); cache = loaderToCache.get(loader); }finally{ loaderToCacheLock.readLock().unlock(); } // window of opportunity here between locks that would result in duplicate put(..) call if (cache == null) { try{ loaderToCacheLock.writeLock().lock(); cache = new ConcurrentHashMap>(); loaderToCache.put(loader, cache); }finally{ loaderToCacheLock.writeLock().unlock(); } } That code is broken twice. First, it is not double-checking the existence of cache in the writeLock guarded section. That's not so serious and could be fixed. The other fault is using ReadWriteLock.readLock() to guard the WeakHashMap.get(). This is dangerous, since WeakHashMap.get() is a mutating method (expunging stale entries). I don't think fixing this bug without either: - new field in ClassLoader or - ClassLoaderValue or - WeakConcurrentHashMap ...is possible. Since we don't have the later two at the moment, the best bet for it unfortunately seems to be the first solution. Regards, Peter > Sent from my phone > > On Jan 24, 2013 9:35 AM, "Peter Levart" > wrote: > > On 01/24/2013 03:10 PM, Alan Bateman wrote: > > On 24/01/2013 13:49, Peter Levart wrote: > > Should I file a RFE first? > > Sorry I don't have time at the moment to study the proposed > patch but just to mention that it has come up a few times, its > just that it never bubbled up to the top of anyone's list. > Here's the bug tracking it: > > http://bugs.sun.com/view_bug.do?bug_id=7123493 > > -Alan. > > I belive that is another bottleneck. It is mentioning the > Proxy.getProxyClass method which also uses synchronization for > maintaining a cache of proxy classes by request parameters. I > could as well try to fix this too in the same patch if there is > interest. > > Regards, Peter > From vitalyd at gmail.com Thu Jan 24 15:55:55 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 24 Jan 2013 10:55:55 -0500 Subject: Proxy.isProxyClass scalability In-Reply-To: <51015735.2090106@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> Message-ID: The boolean seems better from an intent standpoint as well - all this wants to do is tag a Class as having been internally generated by the proxy. This information is present at the point of generation, obviously (and the new. field can be marked final). Doing the tagging via indirection (ClassValue or otherwise) feels circuitous. If the new boolean would actually increase footprint, then OK - tagging via indirection to avoid footprint increase for a relatively uncommon thing seems worthwhile. I'm not that familiar with ClassValue but I don't doubt it scales better than a synch map, and it may scale "well enough" for the expected usage. But a read of a final field is obviously the best case. Are there any downsides to using ClassValue? That is, what could go wrong? Thanks Sent from my phone On Jan 24, 2013 10:46 AM, "Peter Levart" wrote: > On 01/24/2013 03:40 PM, Vitaly Davidovich wrote: > > Peter, > > I know this was brought up on your c-i mailing list thread, but it really > feels like a new boolean field in j.l.Class is the cleaner solution (and > infinitely scalable and doesn't require bookkeeping in the Proxy class). > Is there really no existing alignment gap in j.l.Class layout that a > boolean can slide into? > > There might be, I will check. The ClassValue is scalable too (check the > benchmarks), and bookkeeping is performed in the ClassValue.ClassValueMap > that is referenced from the Class - not in the Proxy class. Unfortunately > the j.l.r.Proxy class is in another package from j.l.Class, so the solution > with a simple boolean field would require JavaLangAccess or Unsafe > acrobatics. > > Another thing is this separate bug: > > http://bugs.sun.com/view_bug.do?bug_id=7123493 > > To solve it, a reference field in j.l.ClassLoader or a hypothetical > ClassLoaderValue implementation would be required. I looked at the bug > reporter's solution (ConcurrentProxy). He guards the > WeakHashMap with a ReadWriteLock: > > /* > * Find or create the proxy class cache for the class loader. > */ > Map> cache; > try{ > loaderToCacheLock.readLock().lock(); > cache = loaderToCache.get(loader); > }finally{ > loaderToCacheLock.readLock().unlock(); > } > // window of opportunity here between locks that would result in duplicate put(..) call > if (cache == null) { > try{ > loaderToCacheLock.writeLock().lock(); > & > nbsp; cache = new ConcurrentHashMap>(); > loaderToCache.put(loader, cache); > }finally{ > & > nbsp; loaderToCacheLock.writeLock().unlock(); > } > } > > > That code is broken twice. First, it is not double-checking the existence > of cache in the writeLock guarded section. That's not so serious and could > be fixed. > The other fault is using ReadWriteLock.readLock() to guard the > WeakHashMap.get(). This is dangerous, since WeakHashMap.get() is a mutating > method (expunging stale entries). > > I don't think fixing this bug without either: > - new field in ClassLoader or > - ClassLoaderValue or > - WeakConcurrentHashMap > > ...is possible. Since we don't have the later two at the moment, the best > bet for it unfortunately seems to be the first solution. > > Regards, Peter > > Sent from my phone > On Jan 24, 2013 9:35 AM, "Peter Levart" wrote: > >> On 01/24/2013 03:10 PM, Alan Bateman wrote: >> >>> On 24/01/2013 13:49, Peter Levart wrote: >>> >>>> Should I file a RFE first? >>>> >>> Sorry I don't have time at the moment to study the proposed patch but >>> just to mention that it has come up a few times, its just that it never >>> bubbled up to the top of anyone's list. Here's the bug tracking it: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=7123493 >>> >>> -Alan. >>> >> I belive that is another bottleneck. It is mentioning the >> Proxy.getProxyClass method which also uses synchronization for maintaining >> a cache of proxy classes by request parameters. I could as well try to fix >> this too in the same patch if there is interest. >> >> Regards, Peter >> >> > From eric.mccorkle at oracle.com Thu Jan 24 15:59:55 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 10:59:55 -0500 Subject: Request for Review JDK-8006503: Message-ID: <51015A7B.1080804@oracle.com> Hello, Please review this trivial patch which removes JVM_PrintStackTrace from jvm.h. It is no longer being used. The webrev is here: http://cr.openjdk.java.net/~emc/8006503/webrev.00/ The bug is here: http://bugs.sun.com/view_bug.do?bug_id=8006503 Thanks, Eric From kumar.x.srinivasan at oracle.com Thu Jan 24 16:07:45 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 24 Jan 2013 08:07:45 -0800 Subject: RFR: JDK-8006850: [pack200] disable pack200 tests until JSR-308 is implemented Message-ID: <51015C51.8070005@oracle.com> Hi, Please review, this test needs to be disabled until Pack200/JSR-200 conforms and adjusts to TypeAnnotations/JSR-308. Thanks Kumar diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -321,6 +321,9 @@ tools/pack200/CommandLineTests.java generic-all tools/pack200/Pack200Test.java generic-all +# 8001163 +tools/pack200/AttributeTests.java generic-all + # 7150569 tools/launcher/UnicodeTest.java macosx-all From Alan.Bateman at oracle.com Thu Jan 24 16:13:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Jan 2013 08:13:48 -0800 (PST) Subject: RFR: JDK-8006850: [pack200] disable pack200 tests until JSR-308 is implemented In-Reply-To: <51015C51.8070005@oracle.com> References: <51015C51.8070005@oracle.com> Message-ID: <51015DBC.2030702@oracle.com> On 24/01/2013 16:07, Kumar Srinivasan wrote: > Hi, > > Please review, this test needs to be disabled until Pack200/JSR-200 > conforms > and adjusts to TypeAnnotations/JSR-308. Looks fine to me. -Alan From eric.mccorkle at oracle.com Thu Jan 24 16:17:22 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 08:17:22 -0800 (PST) Subject: Request for Review JDK-8006503: JVM_PrintStackTrace is not used in JDK In-Reply-To: <51015A7B.1080804@oracle.com> References: <51015A7B.1080804@oracle.com> Message-ID: <51015E92.8030000@oracle.com> Forgot to put the bug's title in the subject line... On 01/24/13 10:59, Eric McCorkle wrote: > Hello, > > Please review this trivial patch which removes JVM_PrintStackTrace from > jvm.h. It is no longer being used. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8006503/webrev.00/ > > The bug is here: > http://bugs.sun.com/view_bug.do?bug_id=8006503 > > Thanks, > Eric From peter.levart at gmail.com Thu Jan 24 16:36:50 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 24 Jan 2013 17:36:50 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <51015735.2090106@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> Message-ID: <51016322.80101@gmail.com> On 01/24/2013 04:45 PM, Peter Levart wrote: >> >> Is there really no existing alignment gap in j.l.Class layout that a >> boolean can slide into? >> > There might be, I will check. All instance fields in j.l.Class are either references or ints. Regards, Peter From vincent.x.ryan at oracle.com Thu Jan 24 16:45:00 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 24 Jan 2013 16:45:00 +0000 Subject: hg: jdk8/tl/jdk: 8006855: PKCS12 test failures due to unsupported algorithm Message-ID: <20130124164544.CB4414751C@hg.openjdk.java.net> Changeset: 943af87e0269 Author: vinnie Date: 2013-01-24 16:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/943af87e0269 8006855: PKCS12 test failures due to unsupported algorithm Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java From kumar.x.srinivasan at oracle.com Thu Jan 24 17:38:08 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 24 Jan 2013 17:38:08 +0000 Subject: hg: jdk8/tl/jdk: 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Message-ID: <20130124173834.B2D4447525@hg.openjdk.java.net> Changeset: 1fd613016ad9 Author: ksrini Date: 2013-01-24 09:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fd613016ad9 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Reviewed-by: alanb ! test/ProblemList.txt From vincent.x.ryan at oracle.com Thu Jan 24 18:21:58 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 24 Jan 2013 18:21:58 +0000 Subject: hg: jdk8/tl/jdk: 8006863: javadoc cleanup for 8005408 Message-ID: <20130124182221.A5E4747527@hg.openjdk.java.net> Changeset: b3f0e0c79bcc Author: vinnie Date: 2013-01-24 18:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3f0e0c79bcc 8006863: javadoc cleanup for 8005408 Reviewed-by: alanb ! src/share/classes/java/security/PKCS12Attribute.java From eric.mccorkle at oracle.com Thu Jan 24 19:33:29 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 14:33:29 -0500 Subject: Parameter reflection: parameters with "" as their name Message-ID: <51018C89.6040605@oracle.com> The current version of the spec for parameter reflection, found here: http://cr.openjdk.java.net/~abuckley/8misc.pdf states that if a parameter has no name, then the reflection API should synthesize a name of the form "argN", where N is the index of the parameter. It also states that if a MethodParameters attribute has a name index of 0, then it indicates a parameter with no name. The question I have is, what if a MethodParameters attribute indicates a name of "" (meaning, the empty string)? Does this count as a valid name, or should it be treated as a parameter with no name? It is probably also worth thinking about invalid parameter names, for example "10", "_", "+", " ", other whitespace characters, and so on. From jonathan.gibbons at oracle.com Thu Jan 24 19:40:29 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 24 Jan 2013 11:40:29 -0800 Subject: Parameter reflection: parameters with "" as their name In-Reply-To: <51018C89.6040605@oracle.com> References: <51018C89.6040605@oracle.com> Message-ID: <51018E2D.8080405@oracle.com> On 01/24/2013 11:33 AM, Eric McCorkle wrote: > The current version of the spec for parameter reflection, found here: > > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > states that if a parameter has no name, then the reflection API should > synthesize a name of the form "argN", where N is the index of the > parameter. It also states that if a MethodParameters attribute has a > name index of 0, then it indicates a parameter with no name. > > The question I have is, what if a MethodParameters attribute indicates a > name of "" (meaning, the empty string)? Does this count as a valid > name, or should it be treated as a parameter with no name? > > > It is probably also worth thinking about invalid parameter names, for > example "10", "_", "+", " ", other whitespace characters, and so on. What about name clashes, such as if I choose to name my args "arg3, arg2, arg1, arg0" Are valid parameter names JVMS identifiers or JLS identifiers? -- Jon From eric.mccorkle at oracle.com Thu Jan 24 19:55:51 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 14:55:51 -0500 Subject: Parameter reflection: parameters with "" as their name In-Reply-To: <51018E2D.8080405@oracle.com> References: <51018C89.6040605@oracle.com> <51018E2D.8080405@oracle.com> Message-ID: <510191C7.3020006@oracle.com> On 01/24/13 14:40, Jonathan Gibbons wrote: > On 01/24/2013 11:33 AM, Eric McCorkle wrote: >> The current version of the spec for parameter reflection, found here: >> >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> states that if a parameter has no name, then the reflection API should >> synthesize a name of the form "argN", where N is the index of the >> parameter. It also states that if a MethodParameters attribute has a >> name index of 0, then it indicates a parameter with no name. >> >> The question I have is, what if a MethodParameters attribute indicates a >> name of "" (meaning, the empty string)? Does this count as a valid >> name, or should it be treated as a parameter with no name? >> >> >> It is probably also worth thinking about invalid parameter names, for >> example "10", "_", "+", " ", other whitespace characters, and so on. > > What about name clashes, such as if I choose to name my args "arg3, > arg2, arg1, arg0" > > Are valid parameter names JVMS identifiers or JLS identifiers? > It bears mention that Java may not be the only language using this feature. Lisp (clojure) comes to mind, where names frequently have "-" in them. There might also be languages out there where "0" is a valid identifier. Also, one could imagine a language with nameless parameters in the style of C++, or _ in the style of SML. But I really can't see a compelling case why "" would be distinct from being unnamed. From coleen.phillimore at oracle.com Thu Jan 24 19:59:24 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 24 Jan 2013 14:59:24 -0500 Subject: Request for Review JDK-8006503: In-Reply-To: <51015A7B.1080804@oracle.com> References: <51015A7B.1080804@oracle.com> Message-ID: <5101929C.70608@oracle.com> What was the disposition of the CCC request? Was it decided not to do one because this function hasn't been used since before 1.4? Code looks good to me. I removed the one in hotspot last week. Thanks, Coleen On 01/24/2013 10:59 AM, Eric McCorkle wrote: > Hello, > > Please review this trivial patch which removes JVM_PrintStackTrace from > jvm.h. It is no longer being used. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8006503/webrev.00/ > > The bug is here: > http://bugs.sun.com/view_bug.do?bug_id=8006503 > > Thanks, > Eric From eric.mccorkle at oracle.com Thu Jan 24 20:11:48 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 15:11:48 -0500 Subject: Request for Review JDK-8006503:JVM_PrintStackTrace is not used in JDK In-Reply-To: <5101929C.70608@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> Message-ID: <51019584.2090207@oracle.com> Joe, can you comment on this? On 01/24/13 14:59, Coleen Phillimore wrote: > > > What was the disposition of the CCC request? Was it decided not to do > one because this function hasn't been used since before 1.4? > > Code looks good to me. I removed the one in hotspot last week. > Thanks, > Coleen > > On 01/24/2013 10:59 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this trivial patch which removes JVM_PrintStackTrace from >> jvm.h. It is no longer being used. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >> >> The bug is here: >> http://bugs.sun.com/view_bug.do?bug_id=8006503 >> >> Thanks, >> Eric > From joe.darcy at oracle.com Thu Jan 24 20:15:51 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 24 Jan 2013 12:15:51 -0800 Subject: Request for Review JDK-8006503:JVM_PrintStackTrace is not used in JDK In-Reply-To: <51019584.2090207@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <51019584.2090207@oracle.com> Message-ID: <51019677.1040109@oracle.com> There is as of yet no ccc request for 8006503. -Joe On 1/24/2013 12:11 PM, Eric McCorkle wrote: > Joe, can you comment on this? > > On 01/24/13 14:59, Coleen Phillimore wrote: >> >> What was the disposition of the CCC request? Was it decided not to do >> one because this function hasn't been used since before 1.4? >> >> Code looks good to me. I removed the one in hotspot last week. >> Thanks, >> Coleen >> >> On 01/24/2013 10:59 AM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this trivial patch which removes JVM_PrintStackTrace from >>> jvm.h. It is no longer being used. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >>> >>> The bug is here: >>> http://bugs.sun.com/view_bug.do?bug_id=8006503 >>> >>> Thanks, >>> Eric From eric.mccorkle at oracle.com Thu Jan 24 20:26:37 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 15:26:37 -0500 Subject: Request for Review JDK-8006503:JVM_PrintStackTrace is not used in JDK In-Reply-To: <51019677.1040109@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <51019584.2090207@oracle.com> <51019677.1040109@oracle.com> Message-ID: <510198FD.6020205@oracle.com> I think the question was more of "does one need to be filed?" On 01/24/13 15:15, Joe Darcy wrote: > There is as of yet no ccc request for 8006503. > > -Joe > > On 1/24/2013 12:11 PM, Eric McCorkle wrote: >> Joe, can you comment on this? >> >> On 01/24/13 14:59, Coleen Phillimore wrote: >>> >>> What was the disposition of the CCC request? Was it decided not to do >>> one because this function hasn't been used since before 1.4? >>> >>> Code looks good to me. I removed the one in hotspot last week. >>> Thanks, >>> Coleen >>> >>> On 01/24/2013 10:59 AM, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review this trivial patch which removes JVM_PrintStackTrace from >>>> jvm.h. It is no longer being used. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >>>> >>>> The bug is here: >>>> http://bugs.sun.com/view_bug.do?bug_id=8006503 >>>> >>>> Thanks, >>>> Eric > From eric.mccorkle at oracle.com Thu Jan 24 20:29:40 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 15:29:40 -0500 Subject: Request for Review JDK-8006503: JVM_PrintStackTrace is not used in JDK In-Reply-To: <5101929C.70608@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> Message-ID: <510199B4.3040707@oracle.com> Also, can someone more experienced in core-libs please confirm that it has indeed not been used since that long ago (and perhaps more importantly, that there are no current plans to use it)? On 01/24/13 14:59, Coleen Phillimore wrote: > > > What was the disposition of the CCC request? Was it decided not to do > one because this function hasn't been used since before 1.4? > > Code looks good to me. I removed the one in hotspot last week. > Thanks, > Coleen > > On 01/24/2013 10:59 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this trivial patch which removes JVM_PrintStackTrace from >> jvm.h. It is no longer being used. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >> >> The bug is here: >> http://bugs.sun.com/view_bug.do?bug_id=8006503 >> >> Thanks, >> Eric > From joe.darcy at oracle.com Thu Jan 24 20:41:15 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 24 Jan 2013 12:41:15 -0800 Subject: Request for Review JDK-8006503:JVM_PrintStackTrace is not used in JDK In-Reply-To: <510198FD.6020205@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <51019584.2090207@oracle.com> <51019677.1040109@oracle.com> <510198FD.6020205@oracle.com> Message-ID: <51019C6B.40907@oracle.com> If this function was only usable with the JDK implementation (an internal JDK contract), then a ccc request is not needed. HTH, -Joe On 1/24/2013 12:26 PM, Eric McCorkle wrote: > I think the question was more of "does one need to be filed?" > > On 01/24/13 15:15, Joe Darcy wrote: >> There is as of yet no ccc request for 8006503. >> >> -Joe >> >> On 1/24/2013 12:11 PM, Eric McCorkle wrote: >>> Joe, can you comment on this? >>> >>> On 01/24/13 14:59, Coleen Phillimore wrote: >>>> What was the disposition of the CCC request? Was it decided not to do >>>> one because this function hasn't been used since before 1.4? >>>> >>>> Code looks good to me. I removed the one in hotspot last week. >>>> Thanks, >>>> Coleen >>>> >>>> On 01/24/2013 10:59 AM, Eric McCorkle wrote: >>>>> Hello, >>>>> >>>>> Please review this trivial patch which removes JVM_PrintStackTrace from >>>>> jvm.h. It is no longer being used. >>>>> >>>>> The webrev is here: >>>>> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >>>>> >>>>> The bug is here: >>>>> http://bugs.sun.com/view_bug.do?bug_id=8006503 >>>>> >>>>> Thanks, >>>>> Eric From david.holmes at oracle.com Thu Jan 24 22:54:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 08:54:56 +1000 Subject: build failure with tl repo: pack200 assertion failure Message-ID: <5101BBC0.1030105@oracle.com> I was trying to test the fixes for the langtools jtreg issue but when I submitted my tl forest to JPRT the windows builds failed: Packing /cygdrive/c/jprt/T/P1/024730.daholme/s/build/windows-x86-normal-clientANDserver-release/install/j2re-image/lib/rt.jar 61395044 bytes Exception in thread "main" java.lang.AssertionError at com.sun.java.util.jar.pack.ConstantPool$Index.indexOf(ConstantPool.java:1102) at com.sun.java.util.jar.pack.BandStructure.encodeRef(BandStructure.java:1055) at com.sun.java.util.jar.pack.BandStructure$CPRefBand.encodeRefOrNull(BandStructure.java:1032) at com.sun.java.util.jar.pack.BandStructure$CPRefBand.putRef(BandStructure.java:1004) at com.sun.java.util.jar.pack.PackageWriter.writeByteCodes(PackageWriter.java:1622) at com.sun.java.util.jar.pack.PackageWriter.writeMembers(PackageWriter.java:1227) at com.sun.java.util.jar.pack.PackageWriter.writeClassesAndByteCodes(PackageWriter.java:1202) at com.sun.java.util.jar.pack.PackageWriter.write(PackageWriter.java:79) at com.sun.java.util.jar.pack.PackerImpl$DoPack.flushPackage(PackerImpl.java:594) at com.sun.java.util.jar.pack.PackerImpl$DoPack.flushAll(PackerImpl.java:548) at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:483) at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:98) at com.sun.java.util.jar.pack.Driver.main(Driver.java:313) I see you just disabled the pack tests. David From eric.mccorkle at oracle.com Thu Jan 24 23:30:37 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 24 Jan 2013 18:30:37 -0500 Subject: Request for Review JDK-8006503:JVM_PrintStackTrace is not used in JDK In-Reply-To: <51019C6B.40907@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <51019584.2090207@oracle.com> <51019677.1040109@oracle.com> <510198FD.6020205@oracle.com> <51019C6B.40907@oracle.com> Message-ID: <5101C41D.4000003@oracle.com> As far as Coleen and I are aware, this is internal-only. If anyone knows otherwise, please comment before the end of tomorrow. Other than that, do you see any problems, Joe? On 01/24/13 15:41, Joe Darcy wrote: > If this function was only usable with the JDK implementation (an > internal JDK contract), then a ccc request is not needed. > > HTH, > > -Joe > > On 1/24/2013 12:26 PM, Eric McCorkle wrote: >> I think the question was more of "does one need to be filed?" >> >> On 01/24/13 15:15, Joe Darcy wrote: >>> There is as of yet no ccc request for 8006503. >>> >>> -Joe >>> >>> On 1/24/2013 12:11 PM, Eric McCorkle wrote: >>>> Joe, can you comment on this? >>>> >>>> On 01/24/13 14:59, Coleen Phillimore wrote: >>>>> What was the disposition of the CCC request? Was it decided not >>>>> to do >>>>> one because this function hasn't been used since before 1.4? >>>>> >>>>> Code looks good to me. I removed the one in hotspot last week. >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 01/24/2013 10:59 AM, Eric McCorkle wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this trivial patch which removes JVM_PrintStackTrace >>>>>> from >>>>>> jvm.h. It is no longer being used. >>>>>> >>>>>> The webrev is here: >>>>>> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >>>>>> >>>>>> The bug is here: >>>>>> http://bugs.sun.com/view_bug.do?bug_id=8006503 >>>>>> >>>>>> Thanks, >>>>>> Eric > From joe.darcy at oracle.com Fri Jan 25 00:54:27 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 25 Jan 2013 00:54:27 +0000 Subject: hg: jdk8/tl/jdk: 8006895: Clarify that FunctionalInferface is only informative Message-ID: <20130125005448.4AEDD4753C@hg.openjdk.java.net> Changeset: 4d3c05cc21d5 Author: darcy Date: 2013-01-24 16:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d3c05cc21d5 8006895: Clarify that FunctionalInferface is only informative Reviewed-by: briangoetz ! src/share/classes/java/lang/FunctionalInterface.java From david.holmes at oracle.com Fri Jan 25 05:35:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2013 15:35:51 +1000 Subject: Proxy.isProxyClass scalability In-Reply-To: <51016322.80101@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> Message-ID: <510219B7.3090507@oracle.com> On 25/01/2013 2:36 AM, Peter Levart wrote: > On 01/24/2013 04:45 PM, Peter Levart wrote: >>> >>> Is there really no existing alignment gap in j.l.Class layout that a >>> boolean can slide into? >>> >> There might be, I will check. > All instance fields in j.l.Class are either references or ints. Instance are also 8-byte aligned though so does that leave any slop where an extra field would not make an actual difference. (I should know the answer to that after the ReflectionData changes but don't recall.) Note: I have not looked at this, just considering the "add a field" aspect of it. David > Regards, Peter From Alan.Bateman at oracle.com Fri Jan 25 08:33:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2013 08:33:43 +0000 Subject: build failure with tl repo: pack200 assertion failure In-Reply-To: <5101BBC0.1030105@oracle.com> References: <5101BBC0.1030105@oracle.com> Message-ID: <51024367.6040606@oracle.com> On 24/01/2013 22:54, David Holmes wrote: > I was trying to test the fixes for the langtools jtreg issue but when > I submitted my tl forest to JPRT the windows builds failed: Kumar may have replied to you already but see 8006846 and 8003549. -Alan, From luchsh at linux.vnet.ibm.com Fri Jan 25 09:09:13 2013 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 25 Jan 2013 09:09:13 +0000 Subject: hg: jdk8/tl/jdk: 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Message-ID: <20130125090934.E627047555@hg.openjdk.java.net> Changeset: 4c9fcb5cbc07 Author: dingxmin Date: 2013-01-25 17:00 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c9fcb5cbc07 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/sun/misc/URLClassPath/JarLoaderTest.java From chris.hegarty at oracle.com Fri Jan 25 10:21:10 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 25 Jan 2013 10:21:10 +0000 Subject: build failure with tl repo: pack200 assertion failure In-Reply-To: <51024367.6040606@oracle.com> References: <5101BBC0.1030105@oracle.com> <51024367.6040606@oracle.com> Message-ID: <51025C96.3070404@oracle.com> On 25/01/2013 08:33, Alan Bateman wrote: > On 24/01/2013 22:54, David Holmes wrote: >> I was trying to test the fixes for the langtools jtreg issue but when >> I submitted my tl forest to JPRT the windows builds failed: > Kumar may have replied to you already but see 8006846 and 8003549. This only started to fail very recently in tl. Either yesterday, 24th, or the day before. tl code freeze for M6 was officially the 23th, but I believe there may be some scope to get changes in after that, until the 28th? So I guess, my question is will this issue have to be fixed, or be a blocker for tl to integrate into MASTER for M6? Or is there a buildable snapshot, as of the 23rd, that can be used for integration? -Chris. > > -Alan, From Alan.Bateman at oracle.com Fri Jan 25 11:22:45 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2013 11:22:45 +0000 Subject: Request for Review JDK-8006503: JVM_PrintStackTrace is not used in JDK In-Reply-To: <510199B4.3040707@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <510199B4.3040707@oracle.com> Message-ID: <51026B05.8050701@oracle.com> On 24/01/2013 20:29, Eric McCorkle wrote: > Also, can someone more experienced in core-libs please confirm that it > has indeed not been used since that long ago (and perhaps more > importantly, that there are no current plans to use it)? The only usage that I can find is in the distance past, long before OpenJDK. I'm not aware of anything or anyone planning to use it. When hotspot builds were going into several JDK trains then great care was required, particularly with removing functions but I think that has been rare. In any case, it is my understanding that the JVM_* functions are not a supported interface, at least definitely not for applications/libraries outside of the JDK to use directly. To my knowledge, we've never documented these functions beyond the header files (except perhaps perhaps porting documentation for those porting this code base). There are moves afoot on cvmdi-dev [1] to document these functions but I'm not tracking it closely to know what labels (private, unstable, etc.) are planned. -Alan [1] http://mail.openjdk.java.net/pipermail/cvmi-dev/ From alan.bateman at oracle.com Fri Jan 25 13:11:51 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 25 Jan 2013 13:11:51 +0000 Subject: hg: jdk8/tl/jdk: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Message-ID: <20130125131214.C95A14755B@hg.openjdk.java.net> Changeset: 4a4b97f7f83b Author: alanb Date: 2013-01-25 13:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4b97f7f83b 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Reviewed-by: sla, dcubed, mchung ! src/share/classes/java/lang/instrument/package.html From eric.mccorkle at oracle.com Fri Jan 25 14:39:52 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 25 Jan 2013 09:39:52 -0500 Subject: Request for Review JDK-8006503: JVM_PrintStackTrace is not used in JDK In-Reply-To: <51026B05.8050701@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <510199B4.3040707@oracle.com> <51026B05.8050701@oracle.com> Message-ID: <51029938.9020704@oracle.com> Thanks for the input, everyone. I take it this is ok to push, then? On 01/25/13 06:22, Alan Bateman wrote: > On 24/01/2013 20:29, Eric McCorkle wrote: >> Also, can someone more experienced in core-libs please confirm that it >> has indeed not been used since that long ago (and perhaps more >> importantly, that there are no current plans to use it)? > The only usage that I can find is in the distance past, long before > OpenJDK. I'm not aware of anything or anyone planning to use it. > > When hotspot builds were going into several JDK trains then great care > was required, particularly with removing functions but I think that has > been rare. > > In any case, it is my understanding that the JVM_* functions are not a > supported interface, at least definitely not for applications/libraries > outside of the JDK to use directly. To my knowledge, we've never > documented these functions beyond the header files (except perhaps > perhaps porting documentation for those porting this code base). There > are moves afoot on cvmdi-dev [1] to document these functions but I'm not > tracking it closely to know what labels (private, unstable, etc.) are > planned. > > -Alan > > [1] http://mail.openjdk.java.net/pipermail/cvmi-dev/ From Alan.Bateman at oracle.com Fri Jan 25 14:53:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2013 14:53:10 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <5100065A.9080801@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> Message-ID: <51029C56.9020302@oracle.com> Dan, I've taken a pass over this and overall this is good clean-up and something that was just not possible before jdk8 because of the need to keep -XX:+UseVMInterruptibleIO working on Solaris. A few comments: - I don't understand why these changes require the make file changes to link io_util_md and canonicalize_md into nio.dll. - In the definition of ISNANF on Solaris it uses isnand. I'll bet the comment in globalDefinitions_xxx dates back to the original port and might not be true anymore (I'm not suggesting you change it without intensive testing, just a comment that I'll bet it is not an issue now). - "FD" is probably okay, I just wonder about how easy it might be to get a conflict. - src/solaris/native/java/io/UnixFileSystem_md.c, did you test access to "/", I just wonder if it would be better to keep the existing test. - handleClose in src/solaris/native/java/io/io_util_md.c, close is not restartable (I think we have this wrong in a few places). - handleOpen - looks like a bug where it should use "mode" instead of the 0666. - I don't think the O_CLOEXEC code is needed in handleOpen, was this copied from HotSpot? - handleAvailable - assume the file is changing, in which case this could return a negative available. I see the existing code lseeks to the end whereas you are using the size from the stat, I think that is okay, just need to properly handle the case that the file is truncated between calls. - getLastErrorString => I wonder if we should move to strerror_r (less ambiguity as to whether it is thread-safe). Probably best to use strncpy too. - src/solaris/native/java/io/io_util_md.h - minor nit, alignment of RESTARTABLE. - src/windows/native/java/io/io_util_md.h - it's not obvious to me why these need JNIEXPORT but this might be tied into my first question about the make changes. That's all I have. I assume you will run all tests on all platforms before this is pushed. -Alan > : > > > -------- Original Message -------- > Subject: Review Request: JDK-8001334 - Remove use of JVM_* > functions from java.io code > Date: Mon, 21 Jan 2013 23:25:25 -0800 > From: Dan Xu > To: nio-dev > > > > Hi, > > Interruptible I/O on Solaris has been highly problematicand undercut > portability. And the long term plan is to remove it completely from > JDK. In JDK6, the VM option, UseVMInterruptibleIO, was introduced as > part of a phase-out plan to allow developers/customers to disable it. > In JDK7, the default value of UseVMInterruptibleIO flag was changed > to"false" to make Solaris blockingI/O operations uninterruptible by > Java thread interruptsby default. > > The last stepof this phase-out plan is to remove the feature > completely. And it is good to do it now in JDK8. In this fix, I > removed all related codes in IO area by replacing JVM_* functions with > direct system calls. Please help review the proposed fix. Similar > changes in networking area will be done via a different bug. > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8001334 > webrev: http://cr.openjdk.java.net/~dxu/8001334/webrev.00/ > > > Best, > > -Dan > From Alan.Bateman at oracle.com Fri Jan 25 15:00:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Jan 2013 15:00:48 +0000 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: <51029E20.7090300@oracle.com> On 24/01/2013 13:37, 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/ This looks okay to me (for jdk7u-dev). -Alan From rob.mckenna at oracle.com Fri Jan 25 15:37:02 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 25 Jan 2013 15:37:02 +0000 Subject: RFR: [jdk7u-dev] - 8003898: X11 toolkit can be chosen as the default toolkit In-Reply-To: <50D38D22.8030807@oracle.com> References: <50CF689A.6090905@oracle.com> <50D17B86.2050005@oracle.com> <50D38D22.8030807@oracle.com> Message-ID: <5102A69E.5050401@oracle.com> Had a chat with Alexey off list. Since 7162111 is indeed required to get these tests running on headless systems we've agreed to go ahead with this fix. (but not 8004928) A webrev with this change is at: http://cr.openjdk.java.net/~robm/7162111/webrev.02/ -Rob On 20/12/12 22:11, Stuart Marks wrote: > On 12/19/12 12:32 AM, Alan Bateman wrote: >> On 17/12/2012 18:46, Rob McKenna wrote: >>> Hi folks, >>> >>> This review contains: >>> >>> 8003898: X11 toolkit can be chosen as the default toolkit >>> 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) >>> 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT >>> subsystem >>> >>> Unfortunately the last two patches didn't apply cleanly, hence the >>> review >>> request. (the commit comments will be altered appropriately before >>> integration) >>> >>> Webrev at: >>> >>> http://cr.openjdk.java.net/~robm/7162111/webrev.01/ >>> >> 8003898 is important to get into jdk7u, but I don't think 7162111 or >> 8004928 is >> really needed there. > > Isn't 7162111 important to avoid hangs/failures when running the tests > on the Mac? Plus it removes tests from the problem list so we get > better test coverage in 7u. > > s'marks From peter.levart at gmail.com Fri Jan 25 16:02:01 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 17:02:01 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <510219B7.3090507@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> Message-ID: <5102AC79.9060008@gmail.com> On 01/25/2013 06:35 AM, David Holmes wrote: > On 25/01/2013 2:36 AM, Peter Levart wrote: >> On 01/24/2013 04:45 PM, Peter Levart wrote: >>>> >>>> Is there really no existing alignment gap in j.l.Class layout that a >>>> boolean can slide into? >>>> >>> There might be, I will check. >> All instance fields in j.l.Class are either references or ints. > > Instance are also 8-byte aligned though so does that leave any slop > where an extra field would not make an actual difference. (I should > know the answer to that after the ReflectionData changes but don't > recall.) > > Note: I have not looked at this, just considering the "add a field" > aspect of it. > > David Here's what the Unsafe reports about current layout of j.l.Class (ReflectionData changes already taken into account): 32 bit pointers: java.lang.Class instance field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 12 Class newInstanceCallerCache 16 String name 20 SoftReference reflectionData 24 ClassRepository genericInfo 28 Object[] enumConstants 32 Map enumConstantDirectory 36 Map annotations 40 Map declaredAnnotations 44 AnnotationType annotationType 48 ClassValueMap classValueMap 52 int classRedefinedCount 80 int lastAnnotationsRedefinedCount 84 java.lang.String static field offsets: Field Type Field Name Offset ---------- ---------- ------ ObjectStreamField[] serialPersistentFields 96 Comparator CASE_INSENSITIVE_ORDER 100 long serialVersionUID 104 int HASHING_SEED 112 64 bit pointers: java.lang.Class instance field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 16 Class newInstanceCallerCache 24 String name 32 SoftReference reflectionData 40 ClassRepository genericInfo 48 Object[] enumConstants 56 Map enumConstantDirectory 64 Map annotations 72 Map declaredAnnotations 80 AnnotationType annotationType 88 ClassValueMap classValueMap 96 int classRedefinedCount 128 int lastAnnotationsRedefinedCount 132 java.lang.String static field offsets: Field Type Field Name Offset ---------- ---------- ------ ObjectStreamField[] serialPersistentFields 144 Comparator CASE_INSENSITIVE_ORDER 152 long serialVersionUID 160 int HASHING_SEED 168 If I add a boolean instance field "isProxy" to j.l.Class the report changes to: 32 bit pointers: java.lang.Class instance field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 12 Class newInstanceCallerCache 16 String name 20 SoftReference reflectionData 24 ClassRepository genericInfo 28 Object[] enumConstants 32 Map enumConstantDirectory 36 Map annotations 40 Map declaredAnnotations 44 AnnotationType annotationType 48 ClassValueMap classValueMap 52 int classRedefinedCount 80 int lastAnnotationsRedefinedCount 84 boolean isProxy 96 java.lang.String static field offsets: Field Type Field Name Offset ---------- ---------- ------ ObjectStreamField[] serialPersistentFields 104 Comparator CASE_INSENSITIVE_ORDER 108 long serialVersionUID 112 int HASHING_SEED 120 64 bit pointers: java.lang.Class instance field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 16 Class newInstanceCallerCache 24 String name 32 SoftReference reflectionData 40 ClassRepository genericInfo 48 Object[] enumConstants 56 Map enumConstantDirectory 64 Map annotations 72 Map declaredAnnotations 80 AnnotationType annotationType 88 ClassValueMap classValueMap 96 int classRedefinedCount 128 int lastAnnotationsRedefinedCount 132 boolean isProxy 144 java.lang.String static field offsets: Field Type Field Name Offset ---------- ---------- ------ ObjectStreamField[] serialPersistentFields 152 Comparator CASE_INSENSITIVE_ORDER 160 long serialVersionUID 168 int HASHING_SEED 176 ...so it seems that in both cases, adding a boolean to j.l.Class wastes 8 bytes per Class object :-( Regards, Peter From vitalyd at gmail.com Fri Jan 25 16:04:52 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 25 Jan 2013 11:04:52 -0500 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102AC79.9060008@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> Message-ID: That's unfortunate. Can you steal a bit in one of the int fields? E.g. lastAnnotationsRedefinedCount surely doesn't need the full range right? :) Sent from my phone On Jan 25, 2013 11:02 AM, "Peter Levart" wrote: > On 01/25/2013 06:35 AM, David Holmes wrote: > >> On 25/01/2013 2:36 AM, Peter Levart wrote: >> >>> On 01/24/2013 04:45 PM, Peter Levart wrote: >>> >>>> >>>>> Is there really no existing alignment gap in j.l.Class layout that a >>>>> boolean can slide into? >>>>> >>>>> There might be, I will check. >>>> >>> All instance fields in j.l.Class are either references or ints. >>> >> >> Instance are also 8-byte aligned though so does that leave any slop where >> an extra field would not make an actual difference. (I should know the >> answer to that after the ReflectionData changes but don't recall.) >> >> Note: I have not looked at this, just considering the "add a field" >> aspect of it. >> >> David >> > > Here's what the Unsafe reports about current layout of j.l.Class > (ReflectionData changes already taken into account): > > 32 bit pointers: > > java.lang.Class instance field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > Constructor cachedConstructor 12 > Class newInstanceCallerCache 16 > String name 20 > SoftReference reflectionData 24 > ClassRepository genericInfo 28 > Object[] enumConstants 32 > Map enumConstantDirectory 36 > Map annotations 40 > Map declaredAnnotations 44 > AnnotationType annotationType 48 > ClassValueMap classValueMap 52 > int classRedefinedCount 80 > int lastAnnotationsRedefinedCount 84 > > java.lang.String static field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > ObjectStreamField[] serialPersistentFields 96 > Comparator CASE_INSENSITIVE_ORDER 100 > long serialVersionUID 104 > int HASHING_SEED 112 > > > 64 bit pointers: > > java.lang.Class instance field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > Constructor cachedConstructor 16 > Class newInstanceCallerCache 24 > String name 32 > SoftReference reflectionData 40 > ClassRepository genericInfo 48 > Object[] enumConstants 56 > Map enumConstantDirectory 64 > Map annotations 72 > Map declaredAnnotations 80 > AnnotationType annotationType 88 > ClassValueMap classValueMap 96 > int classRedefinedCount 128 > int lastAnnotationsRedefinedCount 132 > > java.lang.String static field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > ObjectStreamField[] serialPersistentFields 144 > Comparator CASE_INSENSITIVE_ORDER 152 > long serialVersionUID 160 > int HASHING_SEED 168 > > > If I add a boolean instance field "isProxy" to j.l.Class the report > changes to: > > 32 bit pointers: > > java.lang.Class instance field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > Constructor cachedConstructor 12 > Class newInstanceCallerCache 16 > String name 20 > SoftReference reflectionData 24 > ClassRepository genericInfo 28 > Object[] enumConstants 32 > Map enumConstantDirectory 36 > Map annotations 40 > Map declaredAnnotations 44 > AnnotationType annotationType 48 > ClassValueMap classValueMap 52 > int classRedefinedCount 80 > int lastAnnotationsRedefinedCount 84 > boolean isProxy 96 > > java.lang.String static field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > ObjectStreamField[] serialPersistentFields 104 > Comparator CASE_INSENSITIVE_ORDER 108 > long serialVersionUID 112 > int HASHING_SEED 120 > > > 64 bit pointers: > > java.lang.Class instance field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > Constructor cachedConstructor 16 > Class newInstanceCallerCache 24 > String name 32 > SoftReference reflectionData 40 > ClassRepository genericInfo 48 > Object[] enumConstants 56 > Map enumConstantDirectory 64 > Map annotations 72 > Map declaredAnnotations 80 > AnnotationType annotationType 88 > ClassValueMap classValueMap 96 > int classRedefinedCount 128 > int lastAnnotationsRedefinedCount 132 > boolean isProxy 144 > > java.lang.String static field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > ObjectStreamField[] serialPersistentFields 152 > Comparator CASE_INSENSITIVE_ORDER 160 > long serialVersionUID 168 > int HASHING_SEED 176 > > > ...so it seems that in both cases, adding a boolean to j.l.Class wastes 8 > bytes per Class object :-( > > > Regards, Peter > > > From alexey.utkin at oracle.com Fri Jan 25 16:07:39 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 25 Jan 2013 20:07:39 +0400 Subject: RFR: [jdk7u-dev] - 8003898: X11 toolkit can be chosen as the default toolkit In-Reply-To: <5102A69E.5050401@oracle.com> References: <50CF689A.6090905@oracle.com> <50D17B86.2050005@oracle.com> <50D38D22.8030807@oracle.com> <5102A69E.5050401@oracle.com> Message-ID: <5102ADCB.7040802@oracle.com> Looks good. Did you test the fix in ssh session to Mac? -uta On 25.01.2013 19:37, Rob McKenna wrote: > Had a chat with Alexey off list. Since 7162111 is indeed required to > get these tests running on headless systems we've agreed to go ahead > with this fix. (but not 8004928) A webrev with this change is at: > > http://cr.openjdk.java.net/~robm/7162111/webrev.02/ > > > -Rob > > > On 20/12/12 22:11, Stuart Marks wrote: >> On 12/19/12 12:32 AM, Alan Bateman wrote: >>> On 17/12/2012 18:46, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> This review contains: >>>> >>>> 8003898: X11 toolkit can be chosen as the default toolkit >>>> 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) >>>> 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT >>>> subsystem >>>> >>>> Unfortunately the last two patches didn't apply cleanly, hence the >>>> review >>>> request. (the commit comments will be altered appropriately before >>>> integration) >>>> >>>> Webrev at: >>>> >>>> http://cr.openjdk.java.net/~robm/7162111/webrev.01/ >>>> >>> 8003898 is important to get into jdk7u, but I don't think 7162111 or >>> 8004928 is >>> really needed there. >> >> Isn't 7162111 important to avoid hangs/failures when running the >> tests on the Mac? Plus it removes tests from the problem list so we >> get better test coverage in 7u. >> >> s'marks > From vincent.x.ryan at oracle.com Fri Jan 25 16:20:56 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 25 Jan 2013 16:20:56 +0000 Subject: hg: jdk8/tl/jdk: 8006946: PKCS12 test failure due to incorrect alias name Message-ID: <20130125162133.27CF94755F@hg.openjdk.java.net> Changeset: c6ea84a629db Author: vinnie Date: 2013-01-25 16:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6ea84a629db 8006946: PKCS12 test failure due to incorrect alias name Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From aleksey.shipilev at oracle.com Fri Jan 25 16:34:03 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 25 Jan 2013 20:34:03 +0400 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102AC79.9060008@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> Message-ID: <5102B3FB.5000807@oracle.com> On 01/25/2013 08:02 PM, Peter Levart wrote: > On 01/25/2013 06:35 AM, David Holmes wrote: >> On 25/01/2013 2:36 AM, Peter Levart wrote: >>> On 01/24/2013 04:45 PM, Peter Levart wrote: > ...so it seems that in both cases, adding a boolean to j.l.Class wastes > 8 bytes per Class object :-( Seems to be the case, we are hitting the 8-byte alignment boundary. java-object-layout [1] on jdk7u12: $ java -jar ~/projects/java-object-layout/target/java-object-layout.jar java.lang.Class Running 64-bit HotSpot VM. Using compressed references with 3-bit shift. Objects are 8 bytes aligned. java.lang.Class offset size type description 0 12 (assumed to be the object header) 12 4 Constructor Class.cachedConstructor 16 4 Class Class.newInstanceCallerCache 20 4 String Class.name 24 4 SoftReference Class.declaredFields 28 4 SoftReference Class.publicFields 32 4 SoftReference Class.declaredMethods 36 4 SoftReference Class.publicMethods 40 4 SoftReference Class.declaredConstructors 44 4 SoftReference Class.publicConstructors 48 4 SoftReference Class.declaredPublicFields 52 4 SoftReference Class.declaredPublicMethods 56 4 ClassRepository Class.genericInfo 60 4 Object[] Class.enumConstants 64 4 Map Class.enumConstantDirectory 68 4 Map Class.annotations 72 4 Map Class.declaredAnnotations 76 4 AnnotationType Class.annotationType 80 4 ClassValueMap Class.classValueMap 84 12 (alignment/padding gap) 96 4 int Class.classRedefinedCount 100 4 int Class.lastRedefinedCount 104 (object boundary, size estimate) But, otherwise, can't we use java.lang.ClassValue to associate this flag with each class? -Aleksey. [1] https://github.com/shipilev/java-field-layout From peter.levart at gmail.com Fri Jan 25 16:34:26 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 17:34:26 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102AC79.9060008@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> Message-ID: <5102B412.5050502@gmail.com> Hi David, I was surprised to see Usafe report these offsets. See below: java.lang.Class *instance* field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 12 Class newInstanceCallerCache 16 String name 20 SoftReference reflectionData 24 ClassRepository genericInfo 28 Object[] enumConstants 32 Map enumConstantDirectory 36 Map annotations 40 Map declaredAnnotations 44 AnnotationType annotationType 48 ClassValueMap classValueMap *52* Why the *24 bytes* gap between /classValueMap/ and /classRedefinedCount/ fields? int classRedefinedCount *80* int lastAnnotationsRedefinedCount 84 java.lang.String *static* field offsets: Field Type Field Name Offset ---------- ---------- ------ ObjectStreamField[] serialPersistentFields 96 Comparator CASE_INSENSITIVE_ORDER 100 long serialVersionUID 104 int HASHING_SEED 112 The 64 bit pointers variant: java.lang.Class instance field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 16 Class newInstanceCallerCache 24 String name 32 SoftReference reflectionData 40 ClassRepository genericInfo 48 Object[] enumConstants 56 Map enumConstantDirectory 64 Map annotations 72 Map declaredAnnotations 80 AnnotationType annotationType 88 ClassValueMap classValueMap *96* *24 bytes* gap here too! int classRedefinedCount *128* int lastAnnotationsRedefinedCount 132 java.lang.String static field offsets: Field Type Field Name Offset ---------- ---------- ------ ObjectStreamField[] serialPersistentFields 144 Comparator CASE_INSENSITIVE_ORDER 152 long serialVersionUID 160 int HASHING_SEED 168 Might it be that the "classRedefinedCount" field offset is fixed somehow in VM, since the VM has to update it? Should there be VM changes also to accomodate ReflectionData changes? Are there VM fields inserted here that don't have a Java mapping? Regards, Peter From peter.levart at gmail.com Fri Jan 25 16:37:06 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 17:37:06 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102B3FB.5000807@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B3FB.5000807@oracle.com> Message-ID: <5102B4B2.7060702@gmail.com> On 01/25/2013 05:34 PM, Aleksey Shipilev wrote: > On 01/25/2013 08:02 PM, Peter Levart wrote: >> On 01/25/2013 06:35 AM, David Holmes wrote: >>> On 25/01/2013 2:36 AM, Peter Levart wrote: >>>> On 01/24/2013 04:45 PM, Peter Levart wrote: >> ...so it seems that in both cases, adding a boolean to j.l.Class wastes >> 8 bytes per Class object :-( > Seems to be the case, we are hitting the 8-byte alignment boundary. > > java-object-layout [1] on jdk7u12: > > $ java -jar ~/projects/java-object-layout/target/java-object-layout.jar > java.lang.Class > Running 64-bit HotSpot VM. > Using compressed references with 3-bit shift. > Objects are 8 bytes aligned. > > java.lang.Class > offset size type description > 0 12 (assumed to be the object header) > 12 4 Constructor Class.cachedConstructor > 16 4 Class Class.newInstanceCallerCache > 20 4 String Class.name > 24 4 SoftReference Class.declaredFields > 28 4 SoftReference Class.publicFields > 32 4 SoftReference Class.declaredMethods > 36 4 SoftReference Class.publicMethods > 40 4 SoftReference Class.declaredConstructors > 44 4 SoftReference Class.publicConstructors > 48 4 SoftReference Class.declaredPublicFields > 52 4 SoftReference Class.declaredPublicMethods > 56 4 ClassRepository Class.genericInfo > 60 4 Object[] Class.enumConstants > 64 4 Map Class.enumConstantDirectory > 68 4 Map Class.annotations > 72 4 Map Class.declaredAnnotations > 76 4 AnnotationType Class.annotationType > 80 4 ClassValueMap Class.classValueMap > 84 12 (alignment/padding gap) What's this? why 12 bytes? > 96 4 int Class.classRedefinedCount > 100 4 int Class.lastRedefinedCount > 104 (object boundary, size estimate) > > But, otherwise, can't we use java.lang.ClassValue to associate this flag > with each class? > > -Aleksey. > > [1] https://github.com/shipilev/java-field-layout > From peter.levart at gmail.com Fri Jan 25 16:40:34 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 17:40:34 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102B3FB.5000807@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B3FB.5000807@oracle.com> Message-ID: <5102B582.5030408@gmail.com> On 01/25/2013 05:34 PM, Aleksey Shipilev wrote: > But, otherwise, can't we use java.lang.ClassValue to associate this flag > with each class? That is my proposed patch. It tries to be space saving and does not associate the flag with each class, but only with each subclass of java.lang.reflect.Proxy. Regards, Peter From aleksey.shipilev at oracle.com Fri Jan 25 16:42:25 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 25 Jan 2013 20:42:25 +0400 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102B4B2.7060702@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B3FB.5000807@oracle.com> <5102B4B2.7060702@gmail.com> Message-ID: <5102B5F1.1040403@oracle.com> On 01/25/2013 08:37 PM, Peter Levart wrote: > On 01/25/2013 05:34 PM, Aleksey Shipilev wrote: >> 80 4 ClassValueMap Class.classValueMap >> 84 12 (alignment/padding gap) > What's this? why 12 bytes? >> 96 4 int Class.classRedefinedCount Beats me, some voodoo VM magic? This is what Unsafe reports anyway. Your data have the same gap (though not immediately evident because you don't calculate the offset differences). -Aleksey. From aleksey.shipilev at oracle.com Fri Jan 25 16:43:51 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 25 Jan 2013 20:43:51 +0400 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102B582.5030408@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B3FB.5000807@oracle.com> <5102B582.5030408@gmail.com> Message-ID: <5102B647.1080402@oracle.com> On 01/25/2013 08:40 PM, Peter Levart wrote: > On 01/25/2013 05:34 PM, Aleksey Shipilev wrote: >> But, otherwise, can't we use java.lang.ClassValue to associate this flag >> with each class? > That is my proposed patch. It tries to be space saving and does not > associate the flag with each class, but only with each subclass of > java.lang.reflect.Proxy. Ah, I see. Sorry, I wasn't following the thread carefully. Cramming the boolean field into j.l.Class when we have ClassValue does not seem worth considering. -Aleksey. From peter.levart at gmail.com Fri Jan 25 17:12:16 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 18:12:16 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102B5F1.1040403@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B3FB.5000807@oracle.com> <5102B4B2.7060702@gmail.com> <5102B5F1.1040403@oracle.com> Message-ID: <5102BCF0.3070106@gmail.com> On 01/25/2013 05:42 PM, Aleksey Shipilev wrote: > On 01/25/2013 08:37 PM, Peter Levart wrote: >> On 01/25/2013 05:34 PM, Aleksey Shipilev wrote: >>> 80 4 ClassValueMap Class.classValueMap >>> 84 12 (alignment/padding gap) >> What's this? why 12 bytes? >>> 96 4 int Class.classRedefinedCount > Beats me, some voodoo VM magic? This is what Unsafe reports anyway. Your > data have the same gap (though not immediately evident because you don't > calculate the offset differences). > > -Aleksey. j.l.Class seems to be very special with it's own layout lo(ma)gic. For example, I copied the source of j.l.Class into j.l.MyClass and chopped-out all the methods, which gives the following (32 bit pointers): java.lang.MyClass instance field offsets: Field Type Field Name Offset ---------- ---------- ------ * int classRedefinedCount 12** ** int lastAnnotationsRedefinedCount 16* Constructor cachedConstructor 20 Class newInstanceCallerCache 24 String name 28 SoftReference reflectionData 32 ClassRepository genericInfo 36 Object[] enumConstants 40 Map enumConstantDirectory 44 Map annotations 48 Map declaredAnnotations 52 AnnotationType annotationType 56 ClassValueMap classValueMap 60 the primitive fields come before pointers whereas in j.l.Class: java.lang.Class instance field offsets: Field Type Field Name Offset ---------- ---------- ------ Constructor cachedConstructor 12 Class newInstanceCallerCache 16 String name 20 SoftReference reflectionData 24 ClassRepository genericInfo 28 Object[] enumConstants 32 Map enumConstantDirectory 36 Map annotations 40 Map declaredAnnotations 44 AnnotationType annotationType 48 ClassValueMap classValueMap 52 * int classRedefinedCount 80** ** int lastAnnotationsRedefinedCount 84* ...they come after the pointers and the first one has a strange alignment... Regards, Peter From kelly.ohair at oracle.com Fri Jan 25 17:24:27 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 25 Jan 2013 09:24:27 -0800 Subject: RFR: [jdk7u-dev] - 8003898: X11 toolkit can be chosen as the default toolkit In-Reply-To: <5102A69E.5050401@oracle.com> References: <50CF689A.6090905@oracle.com> <50D17B86.2050005@oracle.com> <50D38D22.8030807@oracle.com> <5102A69E.5050401@oracle.com> Message-ID: But the build uses applescript, preventing builds via ssh. But I commend this effort, I consider it important that our testing is as robust as possible. -kto On Jan 25, 2013, at 7:37 AM, Rob McKenna wrote: > Had a chat with Alexey off list. Since 7162111 is indeed required to get these tests running on headless systems we've agreed to go ahead with this fix. (but not 8004928) A webrev with this change is at: > > http://cr.openjdk.java.net/~robm/7162111/webrev.02/ > > -Rob > > > On 20/12/12 22:11, Stuart Marks wrote: >> On 12/19/12 12:32 AM, Alan Bateman wrote: >>> On 17/12/2012 18:46, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> This review contains: >>>> >>>> 8003898: X11 toolkit can be chosen as the default toolkit >>>> 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) >>>> 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem >>>> >>>> Unfortunately the last two patches didn't apply cleanly, hence the review >>>> request. (the commit comments will be altered appropriately before integration) >>>> >>>> Webrev at: >>>> >>>> http://cr.openjdk.java.net/~robm/7162111/webrev.01/ >>>> >>> 8003898 is important to get into jdk7u, but I don't think 7162111 or 8004928 is >>> really needed there. >> >> Isn't 7162111 important to avoid hangs/failures when running the tests on the Mac? Plus it removes tests from the problem list so we get better test coverage in 7u. >> >> s'marks > From peter.levart at gmail.com Fri Jan 25 17:32:34 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 18:32:34 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102B412.5050502@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B412.5050502@gmail.com> Message-ID: <5102C1B2.9020009@gmail.com> Hi David, I think I already have a kind of answer. You wrote it in "RFR: 8005232 (JEP-149) Class Instance size reduction": On 01/06/2013 11:46 PM, David Holmes wrote: > In Java 8, using a 32-bit example, a java.lang.Class instance is 112 > bytes consisting of: > > - 8 byte object header > - 20 declared fields (mostly references, some int) > *- 5 injected fields (3 references, 2 ints) * > > That gives: 8 + (20*4) +(5*4) = 108 bytes. But as we need 8-byte > alignment that increases to 112 bytes. Regards, Peter On 01/25/2013 05:34 PM, Peter Levart wrote: > Hi David, > > I was surprised to see Usafe report these offsets. See below: > > java.lang.Class *instance* field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > Constructor cachedConstructor 12 > Class newInstanceCallerCache 16 > String name 20 > SoftReference reflectionData 24 > ClassRepository genericInfo 28 > Object[] enumConstants 32 > Map enumConstantDirectory 36 > Map annotations 40 > Map declaredAnnotations 44 > AnnotationType annotationType 48 > ClassValueMap classValueMap *52* > > > Why the *24 bytes* gap between /classValueMap/ and > /classRedefinedCount/ fields? > > int classRedefinedCount *80* > int lastAnnotationsRedefinedCount 84 > > java.lang.String *static* field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > ObjectStreamField[] serialPersistentFields 96 > Comparator CASE_INSENSITIVE_ORDER 100 > long serialVersionUID 104 > int HASHING_SEED 112 > > > The 64 bit pointers variant: > > java.lang.Class instance field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > Constructor cachedConstructor 16 > Class newInstanceCallerCache 24 > String name 32 > SoftReference reflectionData 40 > ClassRepository genericInfo 48 > Object[] enumConstants 56 > Map enumConstantDirectory 64 > Map annotations 72 > Map declaredAnnotations 80 > AnnotationType annotationType 88 > ClassValueMap classValueMap *96* > > *24 bytes* gap here too! > > int classRedefinedCount *128* > int lastAnnotationsRedefinedCount 132 > > java.lang.String static field offsets: > > Field Type Field Name Offset > ---------- ---------- ------ > ObjectStreamField[] serialPersistentFields 144 > Comparator CASE_INSENSITIVE_ORDER 152 > long serialVersionUID 160 > int HASHING_SEED 168 > > > Might it be that the "classRedefinedCount" field offset is fixed > somehow in VM, since the VM has to update it? Should there be VM > changes also to accomodate ReflectionData changes? Are there VM fields > inserted here that don't have a Java mapping? > > Regards, Peter > From vincent.x.ryan at oracle.com Fri Jan 25 17:51:33 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 25 Jan 2013 17:51:33 +0000 Subject: hg: jdk8/tl/jdk: 8006951: Avoid storing duplicate PKCS12 attributes Message-ID: <20130125175154.6083347570@hg.openjdk.java.net> Changeset: 117491dd58c2 Author: vinnie Date: 2013-01-25 17:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/117491dd58c2 8006951: Avoid storing duplicate PKCS12 attributes Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From eric.mccorkle at oracle.com Fri Jan 25 17:53:59 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Fri, 25 Jan 2013 12:53:59 -0500 Subject: MethodParameters class file format change Message-ID: <5102C6B7.5040108@oracle.com> I don't think anyone is using MethodParameters at this point, but I want to post this just to be sure. The latest version of the spec alters the class file format of MethodParameters attributes. The latest version can be found here: http://cr.openjdk.java.net/~abuckley/8misc.pdf I will be committing patches to tl and hsx which update hotspot and the langtools tools to reflect this change. However, this will take some time to propagate, and may affect anyone using this feature (most likely, to write tests). Apologies for any inconvenience, Eric From peter.levart at gmail.com Fri Jan 25 17:55:03 2013 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 25 Jan 2013 18:55:03 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <5101466C.9080705@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> Message-ID: <5102C6F7.4010300@gmail.com> On 01/24/2013 03:34 PM, Peter Levart wrote: > On 01/24/2013 03:10 PM, Alan Bateman wrote: >> On 24/01/2013 13:49, Peter Levart wrote: >>> Should I file a RFE first? >> Sorry I don't have time at the moment to study the proposed patch but >> just to mention that it has come up a few times, its just that it >> never bubbled up to the top of anyone's list. Here's the bug tracking >> it: >> >> http://bugs.sun.com/view_bug.do?bug_id=7123493 >> >> -Alan. > I belive that is another bottleneck. It is mentioning the > Proxy.getProxyClass method which also uses synchronization for > maintaining a cache of proxy classes by request parameters. I could as > well try to fix this too in the same patch if there is interest. > > Regards, Peter > Hi Alan, David, I thought about the ways to fix Proxy.isProxyClass() scalability and the Proxy.getProxyClass() scalability. While they are different methods, each with it's own data structure, I think that both problems can be solved with a single solution and that solution does not involve neither adding fields to j.l.Class nor ClassValue. The solution is actually very simple. I just want to validate my reasoning before jumping to implement it: - for solving scalability of getProxyClass cache, a field with a reference to ConcurrentHashMap, Class> is added to j.l.ClassLoader - for solving scalability of isProxyClass, a field with a reference to ConcurrentHashMap, Boolean> is added to j.l.ClassLoader Both maps hold strong references to Class objects, but only for the classes that are loaded by the ClassLoader that references them. Each ClassLoader already holds a strong reference to all the Class objects for the classes that were loaded by it in a Vector. Holding another reference does not present any problem, right? I think this would be the best solution and it would solve both scalability problems of j.l.Proxy in one go. Am I missing something? Regards, Peter From kurchi.subhra.hazra at oracle.com Fri Jan 25 19:44:38 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 25 Jan 2013 19:44:38 +0000 Subject: hg: jdk8/tl/jdk: 7017962: Obsolete link is used in URL class level spec Message-ID: <20130125194502.E68CD47578@hg.openjdk.java.net> Changeset: 77bde15bc6a9 Author: khazra Date: 2013-01-25 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77bde15bc6a9 7017962: Obsolete link is used in URL class level spec Summary: Change the link to an archived document Reviewed-by: chegar, mduigou ! src/share/classes/java/net/URL.java From rob.mckenna at oracle.com Fri Jan 25 20:43:38 2013 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 25 Jan 2013 20:43:38 +0000 Subject: RFR: [jdk7u-dev] - 8003898: X11 toolkit can be chosen as the default toolkit In-Reply-To: <5102ADCB.7040802@oracle.com> References: <50CF689A.6090905@oracle.com> <50D17B86.2050005@oracle.com> <50D38D22.8030807@oracle.com> <5102A69E.5050401@oracle.com> <5102ADCB.7040802@oracle.com> Message-ID: <5102EE7A.9080000@oracle.com> Yup, all affected tests pass in both jprt and via an ssh session to a mac. -Rob On 25/01/13 16:07, Alexey Utkin wrote: > Looks good. Did you test the fix in ssh session to Mac? > -uta > > On 25.01.2013 19:37, Rob McKenna wrote: >> Had a chat with Alexey off list. Since 7162111 is indeed required to >> get these tests running on headless systems we've agreed to go ahead >> with this fix. (but not 8004928) A webrev with this change is at: >> >> http://cr.openjdk.java.net/~robm/7162111/webrev.02/ >> >> >> -Rob >> >> >> On 20/12/12 22:11, Stuart Marks wrote: >>> On 12/19/12 12:32 AM, Alan Bateman wrote: >>>> On 17/12/2012 18:46, Rob McKenna wrote: >>>>> Hi folks, >>>>> >>>>> This review contains: >>>>> >>>>> 8003898: X11 toolkit can be chosen as the default toolkit >>>>> 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) >>>>> 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the AWT >>>>> subsystem >>>>> >>>>> Unfortunately the last two patches didn't apply cleanly, hence the >>>>> review >>>>> request. (the commit comments will be altered appropriately before >>>>> integration) >>>>> >>>>> Webrev at: >>>>> >>>>> http://cr.openjdk.java.net/~robm/7162111/webrev.01/ >>>>> >>>> 8003898 is important to get into jdk7u, but I don't think 7162111 >>>> or 8004928 is >>>> really needed there. >>> >>> Isn't 7162111 important to avoid hangs/failures when running the >>> tests on the Mac? Plus it removes tests from the problem list so we >>> get better test coverage in 7u. >>> >>> s'marks >> > From Roger.Riggs at oracle.com Fri Jan 25 21:12:19 2013 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 25 Jan 2013 16:12:19 -0500 Subject: [threeten-dev] Codereview request for 8003680: JSR 310: Date/Time API In-Reply-To: <50F70483.9090202@oracle.com> References: <50F5F08D.5000008@oracle.com> <50F70483.9090202@oracle.com> Message-ID: <5102F533.9020503@oracle.com> Hi Kuchi, Javadoc always alphabetizes the summary sections. But if you scroll down you'll see them in declaration order. Roger On 1/16/2013 2:50 PM, Kurchi Hazra wrote: > Hi Sherman, > > As I was telling you, I had a very minor comment - the javadoc for the > enums DayOfWeek and Month shows the days/months in alphabetical order. > I am not sure if it is somehow possible to bypass that and show them > in the order of their occurrence instead. > > Thanks, > - Kurchi > > On 15.01.2013 16:13, Xueming Shen wrote: >> Hi, >> >> The Threeten project [1] is planned to be integrated into OpenJDK8 M6 >> milestone. >> >> Here is the webrev >> http://cr.openjdk.java.net/~sherman/8003680/webrev >> >> and the latest javadoc >> http://cr.openjdk.java.net/~sherman/8003680/javadoc >> >> Review comments can be sent to the threeten-dev email list [2] and/or >> core-libs-dev email list[3]. >> >> Thanks, >> Sherman >> >> [1] http://openjdk.java.net/projects/threeten >> [2] threeten-dev @ openjdk.java.net >> [3] core-libs-dev @ openjdk.java.net >> >> > -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Fri Jan 25 21:19:51 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Fri, 25 Jan 2013 13:19:51 -0800 Subject: Request for Review JDK-8006503:JVM_PrintStackTrace is not used in JDK In-Reply-To: <5101C41D.4000003@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <51019584.2090207@oracle.com> <51019677.1040109@oracle.com> <510198FD.6020205@oracle.com> <51019C6B.40907@oracle.com> <5101C41D.4000003@oracle.com> Message-ID: <5102F6F7.2090801@oracle.com> Looks fine as far as I can see. Thanks, -Joe On 1/24/2013 3:30 PM, Eric McCorkle wrote: > As far as Coleen and I are aware, this is internal-only. If anyone > knows otherwise, please comment before the end of tomorrow. > > Other than that, do you see any problems, Joe? > > On 01/24/13 15:41, Joe Darcy wrote: >> If this function was only usable with the JDK implementation (an >> internal JDK contract), then a ccc request is not needed. >> >> HTH, >> >> -Joe >> >> On 1/24/2013 12:26 PM, Eric McCorkle wrote: >>> I think the question was more of "does one need to be filed?" >>> >>> On 01/24/13 15:15, Joe Darcy wrote: >>>> There is as of yet no ccc request for 8006503. >>>> >>>> -Joe >>>> >>>> On 1/24/2013 12:11 PM, Eric McCorkle wrote: >>>>> Joe, can you comment on this? >>>>> >>>>> On 01/24/13 14:59, Coleen Phillimore wrote: >>>>>> What was the disposition of the CCC request? Was it decided not >>>>>> to do >>>>>> one because this function hasn't been used since before 1.4? >>>>>> >>>>>> Code looks good to me. I removed the one in hotspot last week. >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 01/24/2013 10:59 AM, Eric McCorkle wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this trivial patch which removes JVM_PrintStackTrace >>>>>>> from >>>>>>> jvm.h. It is no longer being used. >>>>>>> >>>>>>> The webrev is here: >>>>>>> http://cr.openjdk.java.net/~emc/8006503/webrev.00/ >>>>>>> >>>>>>> The bug is here: >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=8006503 >>>>>>> >>>>>>> Thanks, >>>>>>> Eric From Ulf.Zibis at CoSoCo.de Sat Jan 26 01:06:28 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 02:06:28 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <51032C14.3070904@CoSoCo.de> Am 18.01.2013 19:26, schrieb Vladimir Kozlov: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev Hi Vladimir, now I've tried to understand your hotspot code :-) I tried to do some optimization with less jumps for small strings: jmp(len >= 8) --> L_check_16_chars L_check_1_char: jmp(len = 0) --> L_done L_init_1_mask: init_1_mask(); L_copy_1_char: jmp(*src | mask) --> L_unmappable copy_1_char(len++); jmp(len != 0) --> copy_1_char L_done: return(result) L_check_16_chars: jmp(len >= 16) --> L_check_32_chars L_init_8_masks: init_8_masks(); jmp(*src | mask) --> L_init_1_mask copy_8_chars(len++8); jmp(len != 0) --> L_init_1_mask jmp() --> L_done L_check_32_chars: jmp(len >= 32) --> L_init_32_masks: L_init_16_masks: init_16_masks(); jmp(*src | mask) --> L_init_8_masks copy_16_chars(len++16); jmp(len >= 8) --> L_init_8_masks jmp() --> L_check_1_char L_init_32_masks: init_32_masks(); L_copy_32_chars: jmp(*src | mask) --> L_init_16_masks copy_32_chars(len++32); jmp(len >= 32) --> copy_32_chars jmp() --> L_check_16_chars L_unmappable: result += len; jmp() --> L_done -Ulf From Ulf.Zibis at CoSoCo.de Sat Jan 26 01:38:07 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 02:38:07 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <5103337F.2070900@CoSoCo.de> Am 18.01.2013 19:26, schrieb Vladimir Kozlov: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev Hi Vladimir, additionnally instead: 6322 load_unsigned_short(tmp5, Address(src, len, Address::times_2, 0)); 6323 testl(tmp5, 0xff00); // check if Unicode char 6324 jccb(Assembler::notZero, L_copy_1_char_exit); 6325 movb(Address(dst, len, Address::times_1, 0), tmp5); you could do something like: 6322 load_unsigned_byte(tmp5, Address(src, len, Address::times_2, 1)); 6323 jccb(Assembler::notZero, L_copy_1_char_exit); // check if ISO-8859-1 char 6324 movb(Address(dst, len, Address::times_1, 0), Address(src, len, Address::times_2, 0)); There is no need to compare against an additional constant, just check the high-byte for 0. ... and your comment // check if Unicode char is wrong, as it is always a Unicode char, so correct: // check if ISO-8859-1 char Similar for lines 6245, 6269 ! -Ulf From Ulf.Zibis at CoSoCo.de Sat Jan 26 02:51:15 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 03:51:15 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50F993BD.5020607@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50F993BD.5020607@oracle.com> Message-ID: <510344A3.4020305@CoSoCo.de> Am 18.01.2013 19:26, schrieb Vladimir Kozlov: > Here are Hotspot changes with new jtreg test: > > http://cr.openjdk.java.net/~kvn/6896617/webrev Hi Vladimir, I'm wondering if there would be a similar intrinsic for the reverse decode case? Also sun.nio.cs.ASCII$Encode.encodeArrayLoop() could profit from PACKUSWB intrinsic. Maybe the mask, here 0xFF80, could be passed by an additional parameter, so the same intrinsic could serve for both. Maybe Base64 coders could be considered too. What about XXX$encodeBufferLoop()? Could there implemented a similar intrinsic? -Ulf From Ulf.Zibis at CoSoCo.de Sat Jan 26 03:08:50 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 04:08:50 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> Message-ID: <510348C2.6070605@CoSoCo.de> Am 23.01.2013 08:56, schrieb Kirk Pepperdine: > > On 2013-01-23, at 1:14 AM, Vitaly Davidovich > wrote: > >> Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly >> hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger >> the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. >> Maybe this is heresy though :). >> >> > Maybe, maybe not.. what I can say is this is a case of an optimization that doesn't scale down. In > cases where scale down was needed I have recommended to customers that they "flash" their system > just to push the counter beyond the compile threshold. In those cases naively compiled code was > still a lot better than interrupting byte code. I've also turned off decay in a number of > applications where loads weren't quite enough to beat the decay behaviour. Yeah I know this is at > the risk of filling code cache but code cache occupancy is something that I regularly recommend > people monitor for (check my VisualVM memory pool plug-in). In fact, I just tuned an app where I > used -Xcomp to estimate how big the code cache needed to be to avoid filling it. Production > settings had decay turned off. So, I can't say your wrong and I generally don't like fiddling with > these setting but I will if I have to and I've had to in a number of instances where ensuring a > compile beat leaving it alone. This is why I considered to include the surrounding code/API in the optimization thoughts as well for possible better performance for small strings, even on C2 or for less than 10.000 invocations. -Ulf From Ulf.Zibis at CoSoCo.de Sat Jan 26 03:12:38 2013 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 26 Jan 2013 04:12:38 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: <50FF39CD.6020709@oracle.com> References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> <50FF39CD.6020709@oracle.com> Message-ID: <510349A6.1000908@CoSoCo.de> Am 23.01.2013 02:15, schrieb David Holmes: > On 23/01/2013 10:14 AM, Vitaly Davidovich wrote: >> Personally, optimizing for interpreter (or even C1) doesn't seem worth it. >> If something's truly hot and best perf is desired then use C2 or tiered. >> If the method isn't hot enough to trigger the C2 threshold, then why >> bother? You're already behind the 8 ball in terms of performance. Maybe >> this is heresy though :). > > Not all platforms/products have C2. And some people may use C1 intentionally for faster start-up. -Ulf From mike.duigou at oracle.com Sat Jan 26 04:33:53 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 26 Jan 2013 04:33:53 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130126043437.BAFC04758E@hg.openjdk.java.net> Changeset: 4209b3936a7f Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4209b3936a7f 8005632: Extend java.util.Logger to use Supplier for messages Reviewed-by: briangoetz, mduigou Contributed-by: henry.jen at oracle.com ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerSupplierAPIsTest.java Changeset: 1d918647332e Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d918647332e 8004201: Add static utility methods to primitives to be used for redution operations. Reviewed-by: darcy, mduigou, briangoetz, dholmes Contributed-by: akhil.arora at oracle.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java + test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 86a5b435c928 Author: jgish Date: 2013-01-22 11:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86a5b435c928 4247235: (spec str) StringBuffer.insert(int, char[]) specification is inconsistent Summary: Add blanket null-handling statement to StringBuilder and StringBuffer Reviewed-by: mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java From david.holmes at oracle.com Sat Jan 26 07:41:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 17:41:57 +1000 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102C1B2.9020009@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> <51016322.80101@gmail.com> <510219B7.3090507@oracle.com> <5102AC79.9060008@gmail.com> <5102B412.5050502@gmail.com> <5102C1B2.9020009@gmail.com> Message-ID: <510388C5.1030703@oracle.com> Right - I was going to ask if those tools took into account injected fields. David On 26/01/2013 3:32 AM, Peter Levart wrote: > Hi David, > > I think I already have a kind of answer. You wrote it in "RFR: 8005232 > (JEP-149) Class Instance size reduction": > > On 01/06/2013 11:46 PM, David Holmes wrote: >> In Java 8, using a 32-bit example, a java.lang.Class instance is 112 >> bytes consisting of: >> >> - 8 byte object header >> - 20 declared fields (mostly references, some int) >> *- 5 injected fields (3 references, 2 ints) * >> >> That gives: 8 + (20*4) +(5*4) = 108 bytes. But as we need 8-byte >> alignment that increases to 112 bytes. > > Regards, Peter > > > On 01/25/2013 05:34 PM, Peter Levart wrote: >> Hi David, >> >> I was surprised to see Usafe report these offsets. See below: >> >> java.lang.Class *instance* field offsets: >> >> Field Type Field Name Offset >> ---------- ---------- ------ >> Constructor cachedConstructor 12 >> Class newInstanceCallerCache 16 >> String name 20 >> SoftReference reflectionData 24 >> ClassRepository genericInfo 28 >> Object[] enumConstants 32 >> Map enumConstantDirectory 36 >> Map annotations 40 >> Map declaredAnnotations 44 >> AnnotationType annotationType 48 >> ClassValueMap classValueMap *52* >> >> >> Why the *24 bytes* gap between /classValueMap/ and >> /classRedefinedCount/ fields? >> >> int classRedefinedCount *80* >> int lastAnnotationsRedefinedCount 84 >> >> java.lang.String *static* field offsets: >> >> Field Type Field Name Offset >> ---------- ---------- ------ >> ObjectStreamField[] serialPersistentFields 96 >> Comparator CASE_INSENSITIVE_ORDER 100 >> long serialVersionUID 104 >> int HASHING_SEED 112 >> >> >> The 64 bit pointers variant: >> >> java.lang.Class instance field offsets: >> >> Field Type Field Name Offset >> ---------- ---------- ------ >> Constructor cachedConstructor 16 >> Class newInstanceCallerCache 24 >> String name 32 >> SoftReference reflectionData 40 >> ClassRepository genericInfo 48 >> Object[] enumConstants 56 >> Map enumConstantDirectory 64 >> Map annotations 72 >> Map declaredAnnotations 80 >> AnnotationType annotationType 88 >> ClassValueMap classValueMap *96* >> >> *24 bytes* gap here too! >> >> int classRedefinedCount *128* >> int lastAnnotationsRedefinedCount 132 >> >> java.lang.String static field offsets: >> >> Field Type Field Name Offset >> ---------- ---------- ------ >> ObjectStreamField[] serialPersistentFields 144 >> Comparator CASE_INSENSITIVE_ORDER 152 >> long serialVersionUID 160 >> int HASHING_SEED 168 >> >> >> Might it be that the "classRedefinedCount" field offset is fixed >> somehow in VM, since the VM has to update it? Should there be VM >> changes also to accomodate ReflectionData changes? Are there VM fields >> inserted here that don't have a Java mapping? >> >> Regards, Peter >> > From david.holmes at oracle.com Sat Jan 26 07:52:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 17:52:20 +1000 Subject: MethodParameters class file format change In-Reply-To: <5102C6B7.5040108@oracle.com> References: <5102C6B7.5040108@oracle.com> Message-ID: <51038B34.5060209@oracle.com> Eric, These situations are historically known as Flag Days and they require careful management. I don't know exactly what has to be done but the way to approach this is to modify the VM to be prepared to handle both the old format and the new. Then after it has reached TL/jdk&langtools update jdk/langtools to start using the new format. Then if needs be once everything is in sync you can remove the hotspot code that handles the old format. (I assume that both old and new format are new with regard class version 52?) That way nothing breaks. There must already be tests for this new feature else you would be pushing untested code, so you would break these tests while your changes sync up. David On 26/01/2013 3:53 AM, Eric McCorkle wrote: > I don't think anyone is using MethodParameters at this point, but I want > to post this just to be sure. > > The latest version of the spec alters the class file format of > MethodParameters attributes. > > The latest version can be found here: > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > I will be committing patches to tl and hsx which update hotspot and the > langtools tools to reflect this change. However, this will take some > time to propagate, and may affect anyone using this feature (most > likely, to write tests). > > Apologies for any inconvenience, > Eric From chris.hegarty at oracle.com Sat Jan 26 08:22:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 26 Jan 2013 08:22:17 +0000 Subject: MethodParameters class file format change In-Reply-To: <51038B34.5060209@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> Message-ID: <51039239.6020905@oracle.com> David, As you know, recently we have seen jdk changes coming in from the hotspot integration forests, thus potentially avoiding a flag day. I'm not saying that this is necessarily a good idea, but just wondering if it is now something that we should reconsider, over the hefty process you described below? That said, it would require the said engineer observe the general engineering processes that are required to integrated into both TL and the hotspot forests. -Chris. On 01/26/2013 07:52 AM, David Holmes wrote: > Eric, > > These situations are historically known as Flag Days and they require > careful management. > > I don't know exactly what has to be done but the way to approach this is > to modify the VM to be prepared to handle both the old format and the > new. Then after it has reached TL/jdk&langtools update jdk/langtools to > start using the new format. Then if needs be once everything is in sync > you can remove the hotspot code that handles the old format. (I assume > that both old and new format are new with regard class version 52?) That > way nothing breaks. > > There must already be tests for this new feature else you would be > pushing untested code, so you would break these tests while your changes > sync up. > > David > > On 26/01/2013 3:53 AM, Eric McCorkle wrote: >> I don't think anyone is using MethodParameters at this point, but I want >> to post this just to be sure. >> >> The latest version of the spec alters the class file format of >> MethodParameters attributes. >> >> The latest version can be found here: >> http://cr.openjdk.java.net/~abuckley/8misc.pdf >> >> I will be committing patches to tl and hsx which update hotspot and the >> langtools tools to reflect this change. However, this will take some >> time to propagate, and may affect anyone using this feature (most >> likely, to write tests). >> >> Apologies for any inconvenience, >> Eric From david.holmes at oracle.com Sat Jan 26 12:36:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 22:36:40 +1000 Subject: MethodParameters class file format change In-Reply-To: <51039239.6020905@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> Message-ID: <5103CDD8.2020009@oracle.com> Hi Chris, On 26/01/2013 6:22 PM, Chris Hegarty wrote: > David, > > As you know, recently we have seen jdk changes coming in from the > hotspot integration forests, thus potentially avoiding a flag day. I'm > not saying that this is necessarily a good idea, but just wondering if > it is now something that we should reconsider, over the hefty process > you described below? That said, it would require the said engineer > observe the general engineering processes that are required to > integrated into both TL and the hotspot forests. There was a lengthy discussion on this twelve months ago. At the time JSR-292 was flagged as a special case and not intended as a long-term case. Until we have the testing resources, gatekeeping and integration resources and processes in place, this is not something that can become the norm. David ----- > -Chris. > > On 01/26/2013 07:52 AM, David Holmes wrote: >> Eric, >> >> These situations are historically known as Flag Days and they require >> careful management. >> >> I don't know exactly what has to be done but the way to approach this is >> to modify the VM to be prepared to handle both the old format and the >> new. Then after it has reached TL/jdk&langtools update jdk/langtools to >> start using the new format. Then if needs be once everything is in sync >> you can remove the hotspot code that handles the old format. (I assume >> that both old and new format are new with regard class version 52?) That >> way nothing breaks. >> >> There must already be tests for this new feature else you would be >> pushing untested code, so you would break these tests while your changes >> sync up. >> >> David >> >> On 26/01/2013 3:53 AM, Eric McCorkle wrote: >>> I don't think anyone is using MethodParameters at this point, but I want >>> to post this just to be sure. >>> >>> The latest version of the spec alters the class file format of >>> MethodParameters attributes. >>> >>> The latest version can be found here: >>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>> >>> I will be committing patches to tl and hsx which update hotspot and the >>> langtools tools to reflect this change. However, this will take some >>> time to propagate, and may affect anyone using this feature (most >>> likely, to write tests). >>> >>> Apologies for any inconvenience, >>> Eric From david.holmes at oracle.com Sat Jan 26 12:47:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2013 22:47:14 +1000 Subject: MethodParameters class file format change In-Reply-To: <5103CDD8.2020009@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> <5103CDD8.2020009@oracle.com> Message-ID: <5103D052.3050008@oracle.com> On 26/01/2013 10:36 PM, David Holmes wrote: > Hi Chris, > > On 26/01/2013 6:22 PM, Chris Hegarty wrote: >> David, >> >> As you know, recently we have seen jdk changes coming in from the >> hotspot integration forests, thus potentially avoiding a flag day. I'm >> not saying that this is necessarily a good idea, but just wondering if >> it is now something that we should reconsider, over the hefty process >> you described below? That said, it would require the said engineer >> observe the general engineering processes that are required to >> integrated into both TL and the hotspot forests. > > There was a lengthy discussion on this twelve months ago. At the time > JSR-292 was flagged as a special case and not intended as a long-term > case. Until we have the testing resources, gatekeeping and integration > resources and processes in place, this is not something that can become > the norm. To be clear I'm not saying this can't happen. I'm just saying that the right people need to ensure that all the necessary pieces are in place, and the procedures established before we actually start doing it on a regular basis. David > David > ----- > >> -Chris. >> >> On 01/26/2013 07:52 AM, David Holmes wrote: >>> Eric, >>> >>> These situations are historically known as Flag Days and they require >>> careful management. >>> >>> I don't know exactly what has to be done but the way to approach this is >>> to modify the VM to be prepared to handle both the old format and the >>> new. Then after it has reached TL/jdk&langtools update jdk/langtools to >>> start using the new format. Then if needs be once everything is in sync >>> you can remove the hotspot code that handles the old format. (I assume >>> that both old and new format are new with regard class version 52?) That >>> way nothing breaks. >>> >>> There must already be tests for this new feature else you would be >>> pushing untested code, so you would break these tests while your changes >>> sync up. >>> >>> David >>> >>> On 26/01/2013 3:53 AM, Eric McCorkle wrote: >>>> I don't think anyone is using MethodParameters at this point, but I >>>> want >>>> to post this just to be sure. >>>> >>>> The latest version of the spec alters the class file format of >>>> MethodParameters attributes. >>>> >>>> The latest version can be found here: >>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>> >>>> I will be committing patches to tl and hsx which update hotspot and the >>>> langtools tools to reflect this change. However, this will take some >>>> time to propagate, and may affect anyone using this feature (most >>>> likely, to write tests). >>>> >>>> Apologies for any inconvenience, >>>> Eric From chris.hegarty at oracle.com Sat Jan 26 12:50:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 26 Jan 2013 12:50:14 +0000 Subject: MethodParameters class file format change In-Reply-To: <5103D052.3050008@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> <5103CDD8.2020009@oracle.com> <5103D052.3050008@oracle.com> Message-ID: <3D20D90C-8420-4DC2-870F-46703233C04A@oracle.com> On 26 Jan 2013, at 12:47, David Holmes wrote: > On 26/01/2013 10:36 PM, David Holmes wrote: >> Hi Chris, >> >> On 26/01/2013 6:22 PM, Chris Hegarty wrote: >>> David, >>> >>> As you know, recently we have seen jdk changes coming in from the >>> hotspot integration forests, thus potentially avoiding a flag day. I'm >>> not saying that this is necessarily a good idea, but just wondering if >>> it is now something that we should reconsider, over the hefty process >>> you described below? That said, it would require the said engineer >>> observe the general engineering processes that are required to >>> integrated into both TL and the hotspot forests. >> >> There was a lengthy discussion on this twelve months ago. At the time >> JSR-292 was flagged as a special case and not intended as a long-term >> case. Until we have the testing resources, gatekeeping and integration >> resources and processes in place, this is not something that can become >> the norm. > > To be clear I'm not saying this can't happen. I'm just saying that the right people need to ensure that all the necessary pieces are in place, and the procedures established before we actually start doing it on a regular basis. Yes, I agree. -Chris > > David > >> David >> ----- >> >>> -Chris. >>> >>> On 01/26/2013 07:52 AM, David Holmes wrote: >>>> Eric, >>>> >>>> These situations are historically known as Flag Days and they require >>>> careful management. >>>> >>>> I don't know exactly what has to be done but the way to approach this is >>>> to modify the VM to be prepared to handle both the old format and the >>>> new. Then after it has reached TL/jdk&langtools update jdk/langtools to >>>> start using the new format. Then if needs be once everything is in sync >>>> you can remove the hotspot code that handles the old format. (I assume >>>> that both old and new format are new with regard class version 52?) That >>>> way nothing breaks. >>>> >>>> There must already be tests for this new feature else you would be >>>> pushing untested code, so you would break these tests while your changes >>>> sync up. >>>> >>>> David >>>> >>>> On 26/01/2013 3:53 AM, Eric McCorkle wrote: >>>>> I don't think anyone is using MethodParameters at this point, but I >>>>> want >>>>> to post this just to be sure. >>>>> >>>>> The latest version of the spec alters the class file format of >>>>> MethodParameters attributes. >>>>> >>>>> The latest version can be found here: >>>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf >>>>> >>>>> I will be committing patches to tl and hsx which update hotspot and the >>>>> langtools tools to reflect this change. However, this will take some >>>>> time to propagate, and may affect anyone using this feature (most >>>>> likely, to write tests). >>>>> >>>>> Apologies for any inconvenience, >>>>> Eric From Alan.Bateman at oracle.com Sat Jan 26 16:59:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 26 Jan 2013 16:59:26 +0000 Subject: Request for Review JDK-8006503: JVM_PrintStackTrace is not used in JDK In-Reply-To: <51029938.9020704@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <510199B4.3040707@oracle.com> <51026B05.8050701@oracle.com> <51029938.9020704@oracle.com> Message-ID: <51040B6E.5090401@oracle.com> On 25/01/2013 14:39, Eric McCorkle wrote: > Thanks for the input, everyone. > > I take it this is ok to push, then? > Yes, I can do this for you shortly. -Alan From alan.bateman at oracle.com Sat Jan 26 17:00:28 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 26 Jan 2013 17:00:28 +0000 Subject: hg: jdk8/tl/jdk: 8006503: JVM_PrintStackTrace is not used in JDK Message-ID: <20130126170117.3D2F647594@hg.openjdk.java.net> Changeset: e96577d82cbb Author: alanb Date: 2013-01-26 16:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e96577d82cbb 8006503: JVM_PrintStackTrace is not used in JDK Reviewed-by: alanb, darcy Contributed-by: eric.mccorkle at oracle.com ! src/share/javavm/export/jvm.h From martinrb at google.com Sat Jan 26 17:14:03 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 26 Jan 2013 09:14:03 -0800 Subject: zip64 compatibility problems In-Reply-To: <50F60532.80306@oracle.com> References: <50F60532.80306@oracle.com> Message-ID: On Tue, Jan 15, 2013 at 5:41 PM, Kumar Srinivasan < kumar.x.srinivasan at oracle.com> wrote: > >> >> You changed calls to open to do this: >> >> if ((fd = open(jarfile, O_RDONLY >> #ifdef O_LARGEFILE >> | O_LARGEFILE /* large file mode on solaris */ >> #endif >> #ifdef O_BINARY >> | O_BINARY /* use binary mode on windows */ >> #endif >> )) == -1) >> >> But this is not done consistently - there are 2 other calls to open in >> the same file that didn't get the LARGEFILE treatment. Why isn't >> there a JLI_Open? >> > Maybe if you had reviewed my code changes, you would've caught this. :) > > I will look into it, maybe time for a JLI_Open as you suggested. > 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. From kumar.x.srinivasan at oracle.com Sat Jan 26 20:11:39 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 26 Jan 2013 12:11:39 -0800 Subject: zip64 compatibility problems In-Reply-To: References: <50F60532.80306@oracle.com> Message-ID: <5104387B.2070502@oracle.com> On 1/26/2013 9:14 AM, Martin Buchholz wrote: > > > On Tue, Jan 15, 2013 at 5:41 PM, Kumar Srinivasan > > > wrote: > > > > You changed calls to open to do this: > > if ((fd = open(jarfile, O_RDONLY > #ifdef O_LARGEFILE > | O_LARGEFILE /* large file mode on solaris */ > #endif > #ifdef O_BINARY > | O_BINARY /* use binary mode on windows */ > #endif > )) == -1) > > But this is not done consistently - there are 2 other calls to > open in > the same file that didn't get the LARGEFILE treatment. Why isn't > there a JLI_Open? > > Maybe if you had reviewed my code changes, you would've caught > this. :) > > I will look into it, maybe time for a JLI_Open as you suggested. > > > 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. To be perfectly honest, I am swamped right now, I will try to fit this in. Sherman if you have cycles then go for it, I will help as needed. Kumar From martinrb at google.com Sat Jan 26 21:25:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Sat, 26 Jan 2013 13:25:30 -0800 Subject: zip64 compatibility problems In-Reply-To: <5104387B.2070502@oracle.com> References: <50F60532.80306@oracle.com> <5104387B.2070502@oracle.com> Message-ID: On Sat, Jan 26, 2013 at 12:11 PM, Kumar Srinivasan > > So next step here is up to you. > > To be perfectly honest, I am swamped right now, I will try to fit this in. > Sherman if you have cycles then go for it, I will help as needed. > Understood. One possibility is to lower our standards a bit, and just check this in as is without proof that it will fix a bug, because the chance that it will is very much higher than the risk of injecting a new undetected bug. The real world use case (seen in the wild) is someone creating a non-zip64 3GB jar file, with the manifest at the end (yeah, they shouldn't do that) and then running with java -jar on that. From andrej.hollmann at gmx.de Sun Jan 27 10:30:05 2013 From: andrej.hollmann at gmx.de (Andrej Hollmann) Date: Sun, 27 Jan 2013 11:30:05 +0100 Subject: Logical inconsistence between Set and SortedSet interfaces Message-ID: <510501AD.9040608@gmx.de> Hello, I want to add few products to the SortedSet and sort them by price. I add four different elements to TreeSet: ["salt",0.5$], ["milk", 1$], ["bread", 1$], ["bananas", 2$] But at the end my TreeSet contains only three elements: ["salt",0.5$], ["bread", 1$], ["bananas", 2$] The "bread" replaced the "milk" because it has the same price. I think ordering and equity are different aspects and should be separated. A logically correct SortedSet implementation should contain all four elements in ordered style. In that way SortedSet would be downward compatible to inherited Set interface. To test my thinks I wrote my own SortedSet, which is based on TreeList from apache-collection and achieved desired results. PS: With new SortedSet I can sort products by date, or supplier, ... . I just need to implement my own comparator and can be sure that added products will be not replaced by others because elements are the same during comparison. Best Regards Andrej From peter.levart at gmail.com Sun Jan 27 11:34:07 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 27 Jan 2013 12:34:07 +0100 Subject: Logical inconsistence between Set and SortedSet interfaces In-Reply-To: <510501AD.9040608@gmx.de> References: <510501AD.9040608@gmx.de> Message-ID: <510510AF.6080603@gmail.com> You can also create your own java.util.Comparator implementation that never returns 0 for two "different" keys. In your example, you would have to break the ties by 1st comparing the desired attribute(s) that you want to order by and then some unique attribute - you might want to add it to the key just for that purpose (a sequence for example, allocated transiently in the VM - don't use identityHashCode, it is not unique). Regards, Peter On 01/27/2013 11:30 AM, Andrej Hollmann wrote: > Hello, > > I want to add few products to the SortedSet and sort them by price. I > add four different elements to TreeSet: > ["salt",0.5$], ["milk", 1$], ["bread", 1$], ["bananas", 2$] > > But at the end my TreeSet contains only three elements: > ["salt",0.5$], ["bread", 1$], ["bananas", 2$] > > The "bread" replaced the "milk" because it has the same price. I think > ordering and equity are different aspects and should be separated. A > logically correct SortedSet implementation should contain all four > elements in ordered style. In that way SortedSet would be downward > compatible to inherited Set interface. > > To test my thinks I wrote my own SortedSet, which is based on TreeList > from apache-collection and achieved desired results. > > PS: With new SortedSet I can sort products by date, or supplier, ... . > I just need to implement my own comparator and can be sure that added > products will be not replaced by others because elements are the same > during comparison. > > Best Regards > Andrej > From fweimer at redhat.com Sun Jan 27 13:22:10 2013 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 27 Jan 2013 14:22:10 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <51015735.2090106@gmail.com> Message-ID: <51052A02.5040804@redhat.com> On 01/24/2013 04:55 PM, Vitaly Davidovich wrote: > I'm not that familiar with ClassValue but I don't doubt it scales better > than a synch map, It should be quite a bit faster. Here's an example: It's quite a bit code, but no synchronization is needed, and all branches should be predictable. -- Florian Weimer / Red Hat Product Security Team From peter.levart at gmail.com Sun Jan 27 13:32:56 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 27 Jan 2013 14:32:56 +0100 Subject: Proxy.[isProxyClass|getProxyClass] scalability In-Reply-To: <5102C6F7.4010300@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> Message-ID: <51052C88.8040902@gmail.com> Hi Alan, David, I think I have a solution for scalability problems of java.lang.reflect.Proxy: * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.01/index.html I designed it along the lines mentioned in previous mail (see below). First I thought that both caches (a cache mapping request parameters of Proxy.getProxyClass to a proxy Class and a cache for resolving the Proxy.isProxyClass method) could be placed inside the j.l.ClassLoader. And they actually could. I tried this and it worked correctly, but the raw (single-threaded) performance of Proxy.isProxyClass was half the performance of current JDK8 isProxyClass method that way. The main performance hog I identified was the Class.getClassLoader() method. This method delegates to a native JVM method after checking the callers permissions. So the plan to keep the isProxyClass cache inside the ClassLoader failed. But then the ClassValue solution that I proposed in previous revision works beautifully and fast, so I kept this solution for isProxyClass cache. The ThreadLocal trick to initialize the ClassValue for a particular proxy class is necessary because ClassValue does not have a put() method. It does have actually, but it's package private and the comment suggests that it might not be there forever: // Possible functionality for JSR 292 MR 1 /*public*/ void put(Class type, T value) { ClassValueMap map = getMap(type); map.changeEntry(this, value); } I could use the JavaLangAccess to access it from Proxy code though, so this is another refinement that is possible and would eliminate the need for ThreadLocal trick. The cache for getProxyClass method on the other hand is most naturally hosted by j.l.ClassLoader and that's where I put it in the proposed patch. Currently the cross-package access to it is implemented using Unsafe, but the performance aspect is not so critical that It couldn't be changed to using JavaLangAccess instead if desired. I did some performance testing too. Here are the results taken on 3 different systems (i7 Linux PC, Raspberry Pi and Sun-Blade-T6320 Solaris machine): * https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results.txt These are the test sources i used: * https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/ProxyBenchmarkTest.java * https://github.com/plevart/micro-bench/blob/master/src/si/pele/microbench/TestRunner.java Results show scalability and raw performance improvements for both critical Proxy methods. So what do you think? Regards, Peter On 01/25/2013 06:55 PM, Peter Levart wrote: > On 01/24/2013 03:34 PM, Peter Levart wrote: >> On 01/24/2013 03:10 PM, Alan Bateman wrote: >>> On 24/01/2013 13:49, Peter Levart wrote: >>>> Should I file a RFE first? >>> Sorry I don't have time at the moment to study the proposed patch >>> but just to mention that it has come up a few times, its just that >>> it never bubbled up to the top of anyone's list. Here's the bug >>> tracking it: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=7123493 >>> >>> -Alan. >> I belive that is another bottleneck. It is mentioning the >> Proxy.getProxyClass method which also uses synchronization for >> maintaining a cache of proxy classes by request parameters. I could >> as well try to fix this too in the same patch if there is interest. >> >> Regards, Peter >> > > Hi Alan, David, > > I thought about the ways to fix Proxy.isProxyClass() scalability and > the Proxy.getProxyClass() scalability. While they are different > methods, each with it's own data structure, I think that both problems > can be solved with a single solution and that solution does not > involve neither adding fields to j.l.Class nor ClassValue. > > The solution is actually very simple. I just want to validate my > reasoning before jumping to implement it: > > - for solving scalability of getProxyClass cache, a field with a > reference to ConcurrentHashMap, Class> > is added to j.l.ClassLoader > - for solving scalability of isProxyClass, a field with a reference to > ConcurrentHashMap, Boolean> is added to > j.l.ClassLoader > > Both maps hold strong references to Class objects, but only for the > classes that are loaded by the ClassLoader that references them. Each > ClassLoader already holds a strong reference to all the Class objects > for the classes that were loaded by it in a Vector. Holding another > reference does not present any problem, right? > > I think this would be the best solution and it would solve both > scalability problems of j.l.Proxy in one go. > > Am I missing something? > > Regards, Peter > From peter.levart at gmail.com Sun Jan 27 14:34:24 2013 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 27 Jan 2013 15:34:24 +0100 Subject: Proxy.[isProxyClass|getProxyClass] scalability In-Reply-To: <51052C88.8040902@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <51052C88.8040902@gmail.com> Message-ID: <51053AF0.9090502@gmail.com> Hi again, By simple rearrangement of code in Proxy.getProxyClass (moved the parameters validation to slow-path) I managed to speed-up the fast-path getProxyClass so that now it's raw speed is 40x the speed of current getProxyClass method: * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.02/index.html Here are quick measurements (only for i7 this time): * https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results_v2.txt Regards, Peter On 01/27/2013 02:32 PM, Peter Levart wrote: > Hi Alan, David, > > I think I have a solution for scalability problems of > java.lang.reflect.Proxy: > > * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.01/index.html > > I designed it along the lines mentioned in previous mail (see below). > First I thought that both caches (a cache mapping request parameters > of Proxy.getProxyClass to a proxy Class and a cache for resolving the > Proxy.isProxyClass method) could be placed inside the j.l.ClassLoader. > And they actually could. I tried this and it worked correctly, but the > raw (single-threaded) performance of Proxy.isProxyClass was half the > performance of current JDK8 isProxyClass method that way. The main > performance hog I identified was the Class.getClassLoader() method. > This method delegates to a native JVM method after checking the > callers permissions. So the plan to keep the isProxyClass cache inside > the ClassLoader failed. But then the ClassValue solution that I > proposed in previous revision works beautifully and fast, so I kept > this solution for isProxyClass cache. The ThreadLocal trick to > initialize the ClassValue for a particular proxy class is necessary > because ClassValue does not have a put() method. It does have > actually, but it's package private and the comment suggests that it > might not be there forever: > > // Possible functionality for JSR 292 MR 1 > /*public*/ void put(Class type, T value) { > ClassValueMap map = getMap(type); > map.changeEntry(this, value); > } > > I could use the JavaLangAccess to access it from Proxy code though, so > this is another refinement that is possible and would eliminate the > need for ThreadLocal trick. > The cache for getProxyClass method on the other hand is most naturally > hosted by j.l.ClassLoader and that's where I put it in the proposed > patch. Currently the cross-package access to it is implemented using > Unsafe, but the performance aspect is not so critical that It couldn't > be changed to using JavaLangAccess instead if desired. > I did some performance testing too. Here are the results taken on 3 > different systems (i7 Linux PC, Raspberry Pi and Sun-Blade-T6320 > Solaris machine): > > * > https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results.txt > > These are the test sources i used: > > * > https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/ProxyBenchmarkTest.java > * > https://github.com/plevart/micro-bench/blob/master/src/si/pele/microbench/TestRunner.java > > Results show scalability and raw performance improvements for both > critical Proxy methods. > > So what do you think? > > > Regards, Peter > > > On 01/25/2013 06:55 PM, Peter Levart wrote: >> On 01/24/2013 03:34 PM, Peter Levart wrote: >>> On 01/24/2013 03:10 PM, Alan Bateman wrote: >>>> On 24/01/2013 13:49, Peter Levart wrote: >>>>> Should I file a RFE first? >>>> Sorry I don't have time at the moment to study the proposed patch >>>> but just to mention that it has come up a few times, its just that >>>> it never bubbled up to the top of anyone's list. Here's the bug >>>> tracking it: >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=7123493 >>>> >>>> -Alan. >>> I belive that is another bottleneck. It is mentioning the >>> Proxy.getProxyClass method which also uses synchronization for >>> maintaining a cache of proxy classes by request parameters. I could >>> as well try to fix this too in the same patch if there is interest. >>> >>> Regards, Peter >>> >> >> Hi Alan, David, >> >> I thought about the ways to fix Proxy.isProxyClass() scalability and >> the Proxy.getProxyClass() scalability. While they are different >> methods, each with it's own data structure, I think that both >> problems can be solved with a single solution and that solution does >> not involve neither adding fields to j.l.Class nor ClassValue. >> >> The solution is actually very simple. I just want to validate my >> reasoning before jumping to implement it: >> >> - for solving scalability of getProxyClass cache, a field with a >> reference to ConcurrentHashMap, Class> >> is added to j.l.ClassLoader >> - for solving scalability of isProxyClass, a field with a reference >> to ConcurrentHashMap, Boolean> is added to >> j.l.ClassLoader >> >> Both maps hold strong references to Class objects, but only for the >> classes that are loaded by the ClassLoader that references them. Each >> ClassLoader already holds a strong reference to all the Class objects >> for the classes that were loaded by it in a Vector. Holding another >> reference does not present any problem, right? >> >> I think this would be the best solution and it would solve both >> scalability problems of j.l.Proxy in one go. >> >> Am I missing something? >> >> Regards, Peter >> > From vicente.romero at oracle.com Mon Jan 28 08:55:35 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 28 Jan 2013 08:55:35 +0000 Subject: hg: jdk8/tl/langtools: 8006944: javac, combo tests should print out the number of threads used Message-ID: <20130128085542.628DD475B4@hg.openjdk.java.net> Changeset: cbcd9b484759 Author: vromero Date: 2013-01-27 19:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cbcd9b484759 8006944: javac, combo tests should print out the number of threads used Reviewed-by: mcimadamore ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java From chris.hegarty at oracle.com Mon Jan 28 11:32:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 28 Jan 2013 11:32:02 +0000 Subject: 8005697: Add StampedLock - JEP 155 Message-ID: <510661B2.8090509@oracle.com> As part of JEP 155 (Concurrency Updates) we are proposing to add StampedLock. A capability-based lock with three modes for controlling read/write access. Javadoc: http://cr.openjdk.java.net/~chegar/8005697/ver.00/javadoc/StampedLock.html (some external links are not working in this online version) Webrev: http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/ StampedLock, as usual, is coming from Doug Lea, with assistance from members of the former JCP JSR-166 Expert Group. Aleksey Shipilev, Dave Dice, and I, have all informally reviewed this, and our feedback is already incorporated in this version. This is an official call for review before finalizing the API for inclusion in jdk8. Thanks, -Chris. From Alan.Bateman at oracle.com Mon Jan 28 11:36:46 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Jan 2013 11:36:46 +0000 Subject: zip64 compatibility problems In-Reply-To: References: <50F60532.80306@oracle.com> Message-ID: <510662CE.4050305@oracle.com> 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 Alan.Bateman at oracle.com Mon Jan 28 11:49:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Jan 2013 11:49:55 +0000 Subject: Proxy.isProxyClass scalability In-Reply-To: <5102C6F7.4010300@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> Message-ID: <510665E3.6040102@oracle.com> On 25/01/2013 17:55, Peter Levart wrote: > > : > > The solution is actually very simple. I just want to validate my > reasoning before jumping to implement it: > > - for solving scalability of getProxyClass cache, a field with a > reference to ConcurrentHashMap, Class> > is added to j.l.ClassLoader > - for solving scalability of isProxyClass, a field with a reference to > ConcurrentHashMap, Boolean> is added to > j.l.ClassLoader I haven't had time to look very closely as your more recent changes (you are clearly doing very good work here). The only thing I wonder if whether it would be possible to avoid adding to ClassLoader. I can't say what percentage of frameworks and applications use proxies but it would be nice if the impact on applications that don't use proxies is zero. -Alan From aleksey.shipilev at oracle.com Mon Jan 28 12:13:48 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 28 Jan 2013 16:13:48 +0400 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <510661B2.8090509@oracle.com> References: <510661B2.8090509@oracle.com> Message-ID: <51066B7C.4030806@oracle.com> On 01/28/2013 03:32 PM, Chris Hegarty wrote: > StampedLock, as usual, is coming from Doug Lea, with assistance from > members of the former JCP JSR-166 Expert Group. Aleksey Shipilev, Dave > Dice, and I, have all informally reviewed this, and our feedback is > already incorporated in this version. I want to dub my informal OK here (not a Reviewer by OpenJDK census). We will follow up with the extensive functional and performance testing once this basic version lands in JDK8. -Aleksey. N.B.: This class marks the first usage of Unsafe.*fence() intrinsics Doug et al. added in HS last year, replacing the weird Unsafe.putVolatileLong hacks from the strange world before. From aleksey.shipilev at oracle.com Mon Jan 28 12:16:53 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 28 Jan 2013 16:16:53 +0400 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <510661B2.8090509@oracle.com> References: <510661B2.8090509@oracle.com> Message-ID: <51066C35.1080303@oracle.com> On 01/28/2013 03:32 PM, Chris Hegarty wrote: > Webrev: > http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/ The only nit I find unlucky is that we need to duplicate the TLR code in LockSupport. It looks like we would be better off with the helper class sharing this functionality. I would speculate Doug will contaminate more classes in j.u.c.* with these TLR copy-paste patches, and so we can figure this out once and for all when the dust settles. -Aleksey. From dl at cs.oswego.edu Mon Jan 28 12:22:55 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 28 Jan 2013 07:22:55 -0500 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <51066C35.1080303@oracle.com> References: <510661B2.8090509@oracle.com> <51066C35.1080303@oracle.com> Message-ID: <51066D9F.3020108@cs.oswego.edu> On 01/28/13 07:16, Aleksey Shipilev wrote: > On 01/28/2013 03:32 PM, Chris Hegarty wrote: >> Webrev: >> http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/ > > The only nit I find unlucky is that we need to duplicate the TLR code in > LockSupport. It looks like we would be better off with the helper class > sharing this functionality. I would speculate Doug will contaminate more > classes in j.u.c.* with these TLR copy-paste patches, and so we can > figure this out once and for all when the dust settles. > Yes, exactly so. Maybe someday with module support there will be a nicer way of coping with package-protection problems accessing Thread fields. Until then, because j.u.c has two subpackages (atomic, locks), there's no nice workaround that I know of. -Doug From peter.levart at gmail.com Mon Jan 28 12:57:44 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 28 Jan 2013 13:57:44 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <510665E3.6040102@oracle.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> Message-ID: <510675C8.3020307@gmail.com> On 01/28/2013 12:49 PM, Alan Bateman wrote: > On 25/01/2013 17:55, Peter Levart wrote: >> >> : >> >> The solution is actually very simple. I just want to validate my >> reasoning before jumping to implement it: >> >> - for solving scalability of getProxyClass cache, a field with a >> reference to ConcurrentHashMap, Class> >> is added to j.l.ClassLoader >> - for solving scalability of isProxyClass, a field with a reference >> to ConcurrentHashMap, Boolean> is added to >> j.l.ClassLoader > I haven't had time to look very closely as your more recent changes > (you are clearly doing very good work here). The only thing I wonder > if whether it would be possible to avoid adding to ClassLoader. I > can't say what percentage of frameworks and applications use proxies > but it would be nice if the impact on applications that don't use > proxies is zero. Hi Alan, Hm, well. Any application that uses run-time annotations, is implicitly using Proxies. But I agree that there are applications that don't use either. Such applications usually don't use many ClassLoaders either. Applications that use many ClassLoaders are typically application servers or applications written for modular systems (such as OSGI or NetBeans) and all those applications are also full of runtime annotations nowadays. So a typical application that does not use neither Proxies nor runtime annotations is composed of bootstrap classloader, AppClassLoader and ExtClassLoader. The ConcurrentHashMap for the bootstrap classloader is hosted by j.l.r.Proxy class and is only initialized when the j.l.r.Proxy class is initialized - so in this case never. The overhead for such applications is therefore an empty ConcurrentHashMap instance plus the overhead for a pointer slot in the ClassLoader object multiplied by the number of ClassLoaders (typically 2). An empty ConcurrentHashMap in JDK8 is only pre-allocating a single internal Segment: java.util.concurrent.ConcurrentHashMap at 642b6fc7(48 bytes) { keySet: null values: null hashSeed: int segmentMask: int segmentShift: int segments: java.util.concurrent.ConcurrentHashMap$Segment[16]@8e1dfb1(80 bytes) { java.util.concurrent.ConcurrentHashMap$Segment at 2524e205(40 bytes) { sync: java.util.concurrent.locks.ReentrantLock$NonfairSync at 17feafba(32 bytes) { exclusiveOwnerThread: null head: null tail: null state: int }->(32 deep bytes) table: java.util.concurrent.ConcurrentHashMap$HashEntry[2]@1c3aacb4(24 bytes) { null null }->(24 deep bytes) count: int modCount: int threshold: int loadFactor: float }->(96 deep bytes) null null null null null null null null null null null null null null null }->(176 deep bytes) keySet: null entrySet: null values: null }->(224 deep bytes) ...therefore the overhead is approx. 224+4 = 228 bytes (on 32 bit pointer environments) per ClassLoader. In typical application (with 2 ClassLoader objects) this amounts to approx. 456 bytes. Is 456 bytes overhead too much? If it is, I could do lazy initialization of per-classloader CHM instances, but then the fast-path would incur a little additional penalty (not to be taken seriously though). Regards, Peter P.S. I was inspecting the ClassValue internal implementation. This is a very nice piece of Java code. Without using any Unsafe magic, it provides a perfect performant an scalable map of lazily initialized independent data structures associated with Class instances. There's nothing special about ClassValue/ClassValueMap that would tie it to Class instances. In fact I think the ClassValueMap could be made generic so it could be reused for implementing a ClasLoaderValue, for example. This would provide a more performant and scalable alternative to using WeakHashMap wrapped by synchronized wrappers for other uses. If anything like that happens in the future, the proposed patch can be quickly adapted to using that infrastructure instead of a direct reference in the ClassLoader. > > -Alan From coleen.phillimore at oracle.com Mon Jan 28 13:19:43 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 28 Jan 2013 08:19:43 -0500 Subject: Request for Review JDK-8006503: JVM_PrintStackTrace is not used in JDK In-Reply-To: <51029938.9020704@oracle.com> References: <51015A7B.1080804@oracle.com> <5101929C.70608@oracle.com> <510199B4.3040707@oracle.com> <51026B05.8050701@oracle.com> <51029938.9020704@oracle.com> Message-ID: <51067AEF.1020908@oracle.com> On 1/25/2013 9:39 AM, Eric McCorkle wrote: > Thanks for the input, everyone. > > I take it this is ok to push, then? Looks good to me. Thank you for doing this. Coleen > > On 01/25/13 06:22, Alan Bateman wrote: >> On 24/01/2013 20:29, Eric McCorkle wrote: >>> Also, can someone more experienced in core-libs please confirm that it >>> has indeed not been used since that long ago (and perhaps more >>> importantly, that there are no current plans to use it)? >> The only usage that I can find is in the distance past, long before >> OpenJDK. I'm not aware of anything or anyone planning to use it. >> >> When hotspot builds were going into several JDK trains then great care >> was required, particularly with removing functions but I think that has >> been rare. >> >> In any case, it is my understanding that the JVM_* functions are not a >> supported interface, at least definitely not for applications/libraries >> outside of the JDK to use directly. To my knowledge, we've never >> documented these functions beyond the header files (except perhaps >> perhaps porting documentation for those porting this code base). There >> are moves afoot on cvmdi-dev [1] to document these functions but I'm not >> tracking it closely to know what labels (private, unstable, etc.) are >> planned. >> >> -Alan >> >> [1] http://mail.openjdk.java.net/pipermail/cvmi-dev/ From peter.levart at gmail.com Mon Jan 28 13:42:35 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 28 Jan 2013 14:42:35 +0100 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <51066D9F.3020108@cs.oswego.edu> References: <510661B2.8090509@oracle.com> <51066C35.1080303@oracle.com> <51066D9F.3020108@cs.oswego.edu> Message-ID: <5106804B.60901@gmail.com> On 01/28/2013 01:22 PM, Doug Lea wrote: > On 01/28/13 07:16, Aleksey Shipilev wrote: >> On 01/28/2013 03:32 PM, Chris Hegarty wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/ >> >> The only nit I find unlucky is that we need to duplicate the TLR code in >> LockSupport. It looks like we would be better off with the helper class >> sharing this functionality. I would speculate Doug will contaminate more >> classes in j.u.c.* with these TLR copy-paste patches, and so we can >> figure this out once and for all when the dust settles. >> > > Yes, exactly so. Maybe someday with module support there will > be a nicer way of coping with package-protection problems accessing > Thread fields. Until then, because j.u.c has two subpackages > (atomic, locks), there's no nice workaround that I know of. > > -Doug What about copying the Unsafe? A singleton instance that does access checks in the public factory method with usages that cache this instance privately in static fields... Regards, Peter From eric.mccorkle at oracle.com Mon Jan 28 14:42:39 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 28 Jan 2013 09:42:39 -0500 Subject: MethodParameters class file format change In-Reply-To: <51038B34.5060209@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> Message-ID: <51068E5F.6080102@oracle.com> On 01/26/13 02:52, David Holmes wrote: > There must already be tests for this new feature else you would be > pushing untested code, so you would break these tests while your changes > sync up. > Tests do exist, but they are presently disabled. The end-to-end tests were part of JDK-8004729, which was pushed before the M6 deadline for tl. However, they fail on SPARC without JDK-8006005, which was pushed to hsx, but didn't make it over to tl in time for M6. Additionally, Peter Jensen is working with me to develop a more comprehensive test suite. And lastly, the spec for MethodParameters is not yet finalized. Therefore, the end-to-end tests are presently disabled. There are tests in javac as well, but they are being updated as part of the langtools patch. From peter.levart at gmail.com Mon Jan 28 16:13:11 2013 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 28 Jan 2013 17:13:11 +0100 Subject: Proxy.isProxyClass scalability In-Reply-To: <510675C8.3020307@gmail.com> References: <51013C04.8020809@gmail.com> <510140ED.7080205@oracle.com> <5101466C.9080705@gmail.com> <5102C6F7.4010300@gmail.com> <510665E3.6040102@oracle.com> <510675C8.3020307@gmail.com> Message-ID: <5106A397.1060203@gmail.com> Hi Alan, I prepared the variant with lazy initialization of ConcurrentHashMaps per ClassLoader and performance measurements show no differences. So here's this variant: * http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.03/index.html I also checked the ClassLoader layout and as it happens the additional pointer slot increases the ClassLoader object size by 8 bytes in both addressing modes: 32bit and 64bit. But that's a small overhead compared to for example the deep-size of AppClassLoader at the beginning of the main method: 14648 bytes (32bit) / 22432 bytes (64bit). Regards, Peter On 01/28/2013 01:57 PM, Peter Levart wrote: > On 01/28/2013 12:49 PM, Alan Bateman wrote: >> On 25/01/2013 17:55, Peter Levart wrote: >>> >>> : >>> >>> The solution is actually very simple. I just want to validate my >>> reasoning before jumping to implement it: >>> >>> - for solving scalability of getProxyClass cache, a field with a >>> reference to ConcurrentHashMap, Class> >>> is added to j.l.ClassLoader >>> - for solving scalability of isProxyClass, a field with a reference >>> to ConcurrentHashMap, Boolean> is added to >>> j.l.ClassLoader >> I haven't had time to look very closely as your more recent changes >> (you are clearly doing very good work here). The only thing I wonder >> if whether it would be possible to avoid adding to ClassLoader. I >> can't say what percentage of frameworks and applications use proxies >> but it would be nice if the impact on applications that don't use >> proxies is zero. > Hi Alan, > > Hm, well. Any application that uses run-time annotations, is > implicitly using Proxies. But I agree that there are applications that > don't use either. Such applications usually don't use many > ClassLoaders either. Applications that use many ClassLoaders are > typically application servers or applications written for modular > systems (such as OSGI or NetBeans) and all those applications are also > full of runtime annotations nowadays. So a typical application that > does not use neither Proxies nor runtime annotations is composed of > bootstrap classloader, AppClassLoader and ExtClassLoader. The > ConcurrentHashMap for the bootstrap classloader is hosted by > j.l.r.Proxy class and is only initialized when the j.l.r.Proxy class > is initialized - so in this case never. The overhead for such > applications is therefore an empty ConcurrentHashMap instance plus the > overhead for a pointer slot in the ClassLoader object multiplied by > the number of ClassLoaders (typically 2). An empty ConcurrentHashMap > in JDK8 is only pre-allocating a single internal Segment: > > java.util.concurrent.ConcurrentHashMap at 642b6fc7(48 bytes) { > keySet: null > values: null > hashSeed: int > segmentMask: int > segmentShift: int > segments: > java.util.concurrent.ConcurrentHashMap$Segment[16]@8e1dfb1(80 bytes) { > java.util.concurrent.ConcurrentHashMap$Segment at 2524e205(40 bytes) { > sync: > java.util.concurrent.locks.ReentrantLock$NonfairSync at 17feafba(32 bytes) { > exclusiveOwnerThread: null > head: null > tail: null > state: int > }->(32 deep bytes) > table: > java.util.concurrent.ConcurrentHashMap$HashEntry[2]@1c3aacb4(24 bytes) { > null > null > }->(24 deep bytes) > count: int > modCount: int > threshold: int > loadFactor: float > }->(96 deep bytes) > null > null > null > null > null > null > null > null > null > null > null > null > null > null > null > }->(176 deep bytes) > keySet: null > entrySet: null > values: null > }->(224 deep bytes) > > ...therefore the overhead is approx. 224+4 = 228 bytes (on 32 bit > pointer environments) per ClassLoader. In typical application (with 2 > ClassLoader objects) this amounts to approx. 456 bytes. > > Is 456 bytes overhead too much? > > If it is, I could do lazy initialization of per-classloader CHM > instances, but then the fast-path would incur a little additional > penalty (not to be taken seriously though). > > Regards, Peter > > P.S. I was inspecting the ClassValue internal implementation. This is > a very nice piece of Java code. Without using any Unsafe magic, it > provides a perfect performant an scalable map of lazily initialized > independent data structures associated with Class instances. There's > nothing special about ClassValue/ClassValueMap that would tie it to > Class instances. In fact I think the ClassValueMap could be made > generic so it could be reused for implementing a ClasLoaderValue, for > example. This would provide a more performant and scalable alternative > to using WeakHashMap wrapped by synchronized > wrappers for other uses. > If anything like that happens in the future, the proposed patch can be > quickly adapted to using that infrastructure instead of a direct > reference in the ClassLoader. > >> >> -Alan > From dan.xu at oracle.com Mon Jan 28 19:02:32 2013 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 28 Jan 2013 11:02:32 -0800 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <51029C56.9020302@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> Message-ID: <5106CB48.3010102@oracle.com> Hi Alan, On 01/25/2013 06:53 AM, Alan Bateman wrote: > Dan, > > I've taken a pass over this and overall this is good clean-up and > something that was just not possible before jdk8 because of the need > to keep -XX:+UseVMInterruptibleIO working on Solaris. > > A few comments: > > - I don't understand why these changes require the make file changes > to link io_util_md and canonicalize_md into nio.dll. These two .obj are needed during the link process in windows platform. Because getLastErrorString functions, used in io_util.c, are inside io_util_md.obj. And after adding io_util_md.obj, it also introduces another dependency on getPrefixed function which is implemented in canonicalize_md.obj. Here is the first exception I got if I keep make files untouched. The compilation passed. But the link afterwards failed, c:/PROGRA~2/MICROS~2.0/VC/Bin/AMD64/link -dll -out:C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.dll \ "-map:C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.map" \ -nologo -opt:REF -incremental:no -debug -LIBPATH:C:/DXSDK/Lib/x64 @C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.lcf \ C:/jprt/T/P1/183441.dan/s/build/windows-amd64/lib/jvm.lib ws2_32.lib -libpath:C:/jprt/T/P1/183441.dan/s/build/windows-amd64/lib java.lib C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/../../../../sun/java.net/net/obj64/net.lib C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/../../../java.lang/java/obj64/io_util.obj C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/../../../java.lang/java/obj64/FileDescriptor_md.obj advapi32.lib Creating library C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.lib and object C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.exp io_util.obj : error LNK2019: unresolved external symbol getLastErrorString referenced in function throwFileNotFoundException I wonder whether I can avoid these link dependencies if I move those functions into other files. But I found it might cause other issues. Here is the comment for getPrefixed() function. The appropriate location of getPrefixed() should be io_util_md.c, but java.lang.instrument package has hardwired canonicalize_md.c into their dll, to avoid complicate solution such as including io_util_md.c into that package, as a workaround we put this method here. > > - In the definition of ISNANF on Solaris it uses isnand. I'll bet the > comment in globalDefinitions_xxx dates back to the original port and > might not be true anymore (I'm not suggesting you change it without > intensive testing, just a comment that I'll bet it is not an issue now). > > - "FD" is probably okay, I just wonder about how easy it might be to > get a conflict. > FD is defined to jlong on windows and to jint on other platforms. The way of using FD is the same as the way of defining IO_Read, IO_write, and other similar functions. I think the conflict is minimum. This makes the code easier to maintain and understand. > - src/solaris/native/java/io/UnixFileSystem_md.c, did you test access > to "/", I just wonder if it would be better to keep the existing test. The current change works the same as the old logic. The old one assign JVM_EEXIST to fd if it is root directory, and bypass JVM_EEXIST error.In the current logic, it also only handles the condition if it is not the root directory. > > - handleClose in src/solaris/native/java/io/io_util_md.c, close is not > restartable (I think we have this wrong in a few places). > I see one of errors that close() may encounter is EINTR in its man page, which means it can be interruptible, right? > - handleOpen - looks like a bug where it should use "mode" instead of > the 0666. You are right. I will fix it. > > - 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. > > - handleAvailable - assume the file is changing, in which case this > could return a negative available. I see the existing code lseeks to > the end whereas you are using the size from the stat, I think that is > okay, just need to properly handle the case that the file is truncated > between calls. I have the code to lseek to the end if size < 0. Should I change it to size < current? > > - getLastErrorString => I wonder if we should move to strerror_r (less > ambiguity as to whether it is thread-safe). Probably best to use > strncpy too. I will change to use strerror_r. > > - src/solaris/native/java/io/io_util_md.h - minor nit, alignment of > RESTARTABLE. I will fix it. > > - src/windows/native/java/io/io_util_md.h - it's not obvious to me why > these need JNIEXPORT but this might be tied into my first question > about the make changes. Actually, I don't know why the old code needs JNIEXPORT, neither. I only change it to use FD. And I did not touch other parts. And for those new method declarations I added to solaris/native/java/io/io_util_md.h, I did not add JNIEXPORT. I will check whether it can solve the link issue if I remove JNIEXPORT from the method signature. > > That's all I have. I assume you will run all tests on all platforms > before this is pushed.\ Sure, I will run it. Thanks, -Dan > > -Alan > > > >> : >> >> >> -------- Original Message -------- >> Subject: Review Request: JDK-8001334 - Remove use of JVM_* >> functions from java.io code >> Date: Mon, 21 Jan 2013 23:25:25 -0800 >> From: Dan Xu >> To: nio-dev >> >> >> >> Hi, >> >> Interruptible I/O on Solaris has been highly problematicand undercut >> portability. And the long term plan is to remove it completely from >> JDK. In JDK6, the VM option, UseVMInterruptibleIO, was introduced as >> part of a phase-out plan to allow developers/customers to disable it. >> In JDK7, the default value of UseVMInterruptibleIO flag was changed >> to"false" to make Solaris blockingI/O operations uninterruptible by >> Java thread interruptsby default. >> >> The last stepof this phase-out plan is to remove the feature >> completely. And it is good to do it now in JDK8. In this fix, I >> removed all related codes in IO area by replacing JVM_* functions >> with direct system calls. Please help review the proposed fix. >> Similar changes in networking area will be done via a different bug. >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8001334 >> webrev: http://cr.openjdk.java.net/~dxu/8001334/webrev.00/ >> >> >> Best, >> >> -Dan >> > From john.r.rose at oracle.com Mon Jan 28 19:59:15 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 28 Jan 2013 11:59:15 -0800 Subject: MethodParameters class file format change In-Reply-To: <3D20D90C-8420-4DC2-870F-46703233C04A@oracle.com> References: <5102C6B7.5040108@oracle.com> <51038B34.5060209@oracle.com> <51039239.6020905@oracle.com> <5103CDD8.2020009@oracle.com> <5103D052.3050008@oracle.com> <3D20D90C-8420-4DC2-870F-46703233C04A@oracle.com> Message-ID: On Jan 26, 2013, at 4:50 AM, Chris Hegarty wrote: >> To be clear I'm not saying this can't happen. I'm just saying that the right people need to ensure that all the necessary pieces are in place, and the procedures established before we actually start doing it on a regular basis. > > Yes, I agree. I agree vigorously with David about the high risk and cost of flag days. If your job as an individual engineer is complicated 10x by the cost of avoiding a flag day, it is still well worth the effort. I will say this: It shouldn't happen very often at all. The last 292 flag day involved 10,000's of LOC, replacing an old implementation by a new one. It was also very expensive and difficult and distracting to manage. It required 10's of engineers throughout the engineering pipeline to pay special attention, for days. It caused semi-expected regressions and hiccups in the backport processes. It required SQE to know when *not* to pay attention to certain regressions. This is so totally not worth it for almost all changes! One engineer with a little cleverness can figure out a way to make the micro-version matrix pass nightly tests. (That's at least three of {jdk0,jdk1}x{jvm0,jvm1}.) It makes ugly code, but that is far preferable to ugly process adventures. Mark the code as "FIXME: clean up after ..." and then trust that, if it's important, it will get cleaned up. The 292-scoped JDK changes are a special case also, which has been discussed at length elsewhere. It requires a lot of groundwork laying, and a significant "teething process" until everybody knows that stuff is coming from that direction. It is not a cut-and-paste-your-own type of process. Having been this this micro-version matrix many times with 292, I can point out some useful tricks for making things work out; just ask. (1-1 mail probably works best for that sort of question.) ? John P.S. This is mostly FTR. For the problem at hand, Eric tells me he already thought of a suitable "trick". Yay! From dl at cs.oswego.edu Tue Jan 29 00:01:57 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 28 Jan 2013 19:01:57 -0500 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <510661B2.8090509@oracle.com> References: <510661B2.8090509@oracle.com> Message-ID: <51071175.7080706@cs.oswego.edu> On 01/28/13 06:32, Chris Hegarty wrote: > As part of JEP 155 (Concurrency Updates) we are proposing to add StampedLock. A > capability-based lock with three modes for controlling read/write access. > > Javadoc: > > http://cr.openjdk.java.net/~chegar/8005697/ver.00/javadoc/StampedLock.html > (some external links are not working in this online version) > > Webrev: > http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/ > Martin Buchholz pointed out a javadoc warning. I also noticed that I had failed to include the simple toString-based informal debug/monitoring aids that we've been doing for synchronizers. Sorry. Now added. For example, printing a lock twice during a test: java.util.concurrent.locks.StampedLock at 29178281[Read-locks:13] ... java.util.concurrent.locks.StampedLock at 29178281[Unlocked] -Doug From stevenschlansker at gmail.com Tue Jan 29 03:20:20 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 28 Jan 2013 19:20:20 -0800 Subject: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: <50FD22AE.9090005@oracle.com> References: <1D5C783C-A599-4FD5-B6C2-4346662AA02F@gmail.com> <50EEB930.1090005@oracle.com> <430A2634-5B37-4979-8B87-C6F360CB297C@gmail.com> <50FD22AE.9090005@oracle.com> Message-ID: <80B0B8E7-D6E2-4447-BD7A-A41ABD7EFAE6@gmail.com> On Jan 21, 2013, at 3:12 AM, Aleksey Shipilev wrote: > > Ok, now as this is being taken care of, you need to follow these steps: > > a) prepare the code, and create the webrev [1] for the change. > > b) upload the webrev somewhere, submit the link to webrev for formal > review on this list, clearly stating the subject, and the CR. I had > submitted CR for this change (8006627), it will be eventually available > in public [2]. So, for reviews, you should use this subject line: > "RFR (S) CR 8006627: Improving performance and reducing object > allocations of java.util.UUID to/from string" > > c) Work with sponsors to commit this. > > Thanks, > -Aleksey. > > [1] "ksh make/scripts/webrev.ksh -f", maybe with "-N" if you have not > committed, and your changes are against the working copy. > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006627 > Thank you again for all your help Aleksey; I have done this and will now start a new thread. Since you made it clearer that it was OK to introduce new helpers, I have factored out some functionality into a new sun.util class. Best, Steven From stevenschlansker at gmail.com Tue Jan 29 03:23:46 2013 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Mon, 28 Jan 2013 19:23:46 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string Message-ID: 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 alexey.utkin at oracle.com Tue Jan 29 07:54:55 2013 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Tue, 29 Jan 2013 11:54:55 +0400 Subject: approved : 8003898: X11 toolkit can be chosen as the default toolkit In-Reply-To: <51069B5A.2040506@oracle.com> References: <50CF689A.6090905@oracle.com> <50D17B86.2050005@oracle.com> <50D38D22.8030807@oracle.com> <5102A69E.5050401@oracle.com> <5102ADCB.7040802@oracle.com> <5102EE7A.9080000@oracle.com> <51069B5A.2040506@oracle.com> Message-ID: <5107804F.4070109@oracle.com> Looks good for me. You can add me as reviewer for the push. Regards, -uta On 28.01.2013 19:38, Rob McKenna wrote: > Can I take this as your final approval? (also, does this apply to the > closed review?) > > Thanks, > > -Rob > > On 25/01/13 20:43, Rob McKenna wrote: >> Yup, all affected tests pass in both jprt and via an ssh session to a >> mac. >> >> -Rob >> >> On 25/01/13 16:07, Alexey Utkin wrote: >>> Looks good. Did you test the fix in ssh session to Mac? >>> -uta >>> >>> On 25.01.2013 19:37, Rob McKenna wrote: >>>> Had a chat with Alexey off list. Since 7162111 is indeed required >>>> to get these tests running on headless systems we've agreed to go >>>> ahead with this fix. (but not 8004928) A webrev with this change is >>>> at: >>>> >>>> http://cr.openjdk.java.net/~robm/7162111/webrev.02/ >>>> >>>> >>>> -Rob >>>> >>>> >>>> On 20/12/12 22:11, Stuart Marks wrote: >>>>> On 12/19/12 12:32 AM, Alan Bateman wrote: >>>>>> On 17/12/2012 18:46, Rob McKenna wrote: >>>>>>> Hi folks, >>>>>>> >>>>>>> This review contains: >>>>>>> >>>>>>> 8003898: X11 toolkit can be chosen as the default toolkit >>>>>>> 7162111: TEST_BUG: change tests run in headless mode [macosx] >>>>>>> (open) >>>>>>> 8004928: TEST_BUG: Reduce dependence of CoreLib tests from the >>>>>>> AWT subsystem >>>>>>> >>>>>>> Unfortunately the last two patches didn't apply cleanly, hence >>>>>>> the review >>>>>>> request. (the commit comments will be altered appropriately >>>>>>> before integration) >>>>>>> >>>>>>> Webrev at: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~robm/7162111/webrev.01/ >>>>>>> >>>>>> 8003898 is important to get into jdk7u, but I don't think 7162111 >>>>>> or 8004928 is >>>>>> really needed there. >>>>> >>>>> Isn't 7162111 important to avoid hangs/failures when running the >>>>> tests on the Mac? Plus it removes tests from the problem list so >>>>> we get better test coverage in 7u. >>>>> >>>>> s'marks >>>> >>> >> > From martinrb at google.com Tue Jan 29 08:04:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 29 Jan 2013 00:04:45 -0800 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <51071175.7080706@cs.oswego.edu> References: <510661B2.8090509@oracle.com> <51071175.7080706@cs.oswego.edu> Message-ID: On Mon, Jan 28, 2013 at 4:01 PM, Doug Lea

wrote: > I also noticed that I had failed to include the simple > toString-based informal debug/monitoring aids that we've > been doing for synchronizers. Which suggests looking for other missing methods by comparing lock-like classes. Looking at the implementation of toString and comparing with RRWL suggests (untested): Index: src/main/java/util/concurrent/locks/StampedLock.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/locks/StampedLock.java,v retrieving revision 1.16 diff -u -r1.16 StampedLock.java --- src/main/java/util/concurrent/locks/StampedLock.java 28 Jan 2013 23:54:42 -0000 1.16 +++ src/main/java/util/concurrent/locks/StampedLock.java 29 Jan 2013 07:56:20 -0000 @@ -886,6 +886,23 @@ } } + private int getReadLockCount(long s) { + long readers; + if ((readers = s & RBITS) >= RFULL) + readers = RFULL + readerOverflow; + return (int) readers; + } + + /** + * Queries the number of read locks held for this lock. This + * method is designed for use in monitoring system state, not for + * synchronization control. + * @return the number of read locks held + */ + public int getReadLockCount() { + return getReadLockCount(state); + } + /** * Returns a string identifying this lock, as well as its lock * state. The state, in brackets, includes the String {@code @@ -896,15 +913,11 @@ * @return a string identifying this lock, as well as its lock state */ public String toString() { - long readers; long s = state; - if ((readers = s & RBITS) >= RFULL) - readers = RFULL + readerOverflow; - return super.toString() + ((s & WBIT) != 0L ? - "[Write-locked]" : - readers == 0 ? - "[Unlocked]" : - "[Read-locks:" + readers + "]"); + return super.toString() + + ((s & ABITS) == 0L ? "[Unlocked]" : + (s & WBIT) != 0L ? "[Write-locked]" : + "[Read-locks:" + getReadLockCount(s) + "]"); } // internals From joel.franck at oracle.com Tue Jan 29 09:38:02 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 29 Jan 2013 09:38:02 +0000 Subject: hg: jdk8/tl/jdk: 8004698: Implement Core Reflection for Type Annotations Message-ID: <20130129093814.3EF4A4763E@hg.openjdk.java.net> Changeset: a343d280bd8c Author: jfranck Date: 2013-01-29 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a343d280bd8c 8004698: Implement Core Reflection for Type Annotations Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java + src/share/classes/java/lang/reflect/AnnotatedArrayType.java + src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java + src/share/classes/java/lang/reflect/AnnotatedType.java + src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java + src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/ReflectionFactory.java + src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/TypeAnnotation.java + src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c + test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/TypeParamAnnotation.java From chris.hegarty at oracle.com Tue Jan 29 10:57:40 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Jan 2013 10:57:40 +0000 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <51071175.7080706@cs.oswego.edu> References: <510661B2.8090509@oracle.com> <51071175.7080706@cs.oswego.edu> Message-ID: <5107AB24.6080602@oracle.com> On 01/29/2013 12:01 AM, Doug Lea wrote: > On 01/28/13 06:32, Chris Hegarty wrote: >> As part of JEP 155 (Concurrency Updates) we are proposing to add >> StampedLock. A >> capability-based lock with three modes for controlling read/write access. >> >> Javadoc: >> >> http://cr.openjdk.java.net/~chegar/8005697/ver.00/javadoc/StampedLock.html >> >> (some external links are not working in this online version) >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/ >> > > Martin Buchholz pointed out a javadoc warning. I missed these warnings as they were to javadoc on private members. Quite trivially, the commented assert added with these fixes is missing a trailing ';'. // assert (s & ABITS) >= RFULL > I also noticed that I had failed to include the simple > toString-based informal debug/monitoring aids that we've > been doing for synchronizers. Sorry. Now added. > For example, printing a lock twice during a test: > java.util.concurrent.locks.StampedLock at 29178281[Read-locks:13] > ... > java.util.concurrent.locks.StampedLock at 29178281[Unlocked] Ah yes, this is nice, and consistent. It effects the API, so I will regenerate the javadoc. Martin made another good suggestion. I will regenerate the webrev/javadoc after you give this some consideration. -Chris. > > -Doug > > > > From Alan.Bateman at oracle.com Tue Jan 29 11:55:06 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Jan 2013 11:55:06 +0000 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <5106CB48.3010102@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> Message-ID: <5107B89A.3050400@oracle.com> On 28/01/2013 19:02, Dan Xu wrote: > These two .obj are needed during the link process in windows platform. > Because getLastErrorString functions, used in io_util.c, are inside > io_util_md.obj. And after adding io_util_md.obj, it also introduces > another dependency on getPrefixed function which is implemented in > canonicalize_md.obj. > > Here is the first exception I got if I keep make files untouched. > > The compilation passed. But the link afterwards failed, > c:/PROGRA~2/MICROS~2.0/VC/Bin/AMD64/link -dll > -out:C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.dll > \ > "-map:C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.map" > \ -nologo -opt:REF -incremental:no -debug > -LIBPATH:C:/DXSDK/Lib/x64 > @C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.lcf > \ C:/jprt/T/P1/183441.dan/s/build/windows-amd64/lib/jvm.lib > ws2_32.lib > -libpath:C:/jprt/T/P1/183441.dan/s/build/windows-amd64/lib > java.lib > C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/../../../../sun/java.net/net/obj64/net.lib > C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/../../../java.lang/java/obj64/io_util.obj > C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/../../../java.lang/java/obj64/FileDescriptor_md.obj > advapi32.lib Creating library > C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.lib > and object > C:/jprt/T/P1/183441.dan/s/build/windows-amd64/tmp/java/java.nio/nio/obj64/nio.exp > io_util.obj : error LNK2019: unresolved external symbol > getLastErrorString referenced in function throwFileNotFoundException > > > > I wonder whether I can avoid these link dependencies if I move those > functions into other files. But I found it might cause other issues. > Here is the comment for getPrefixed() function. > > The appropriate location of getPrefixed() should be io_util_md.c, > but java.lang.instrument package has hardwired canonicalize_md.c > into their dll, to avoid complicate solution such as including > io_util_md.c into that package, as a workaround we put this method > here. > I think the link failure you are seeing is because io_util.obj and FileDescriptor_md.obj are also being linked into nio.dll, they shouldn't be but perhaps someone added them a long time ago to workaround another issue. I checked the build of the JPLIS agent (and instrument.dll specifically) and it just links canonicalize_md into that DLL. That is a bit messy, and I remember some of the history as to why this was done this way, but I don't think it should impact anything here. > : >> - src/solaris/native/java/io/UnixFileSystem_md.c, did you test access >> to "/", I just wonder if it would be better to keep the existing test. > The current change works the same as the old logic. The old one assign > JVM_EEXIST to fd if it is root directory, and bypass JVM_EEXIST > error.In the current logic, it also only handles the condition if it > is not the root directory. Okay, it would good to check if we have any tests because file operations on "/" can have subtle difference to other directories, at least on Solaris. >> - handleClose in src/solaris/native/java/io/io_util_md.c, close is >> not restartable (I think we have this wrong in a few places). >> > I see one of errors that close() may encounter is EINTR in its man > page, which means it can be interruptible, right? It can be interrupted but the issue is that the file descriptor is invalid at that point so we can't call close with it again. > >> >> - 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. > >> >> - handleAvailable - assume the file is changing, in which case this >> could return a negative available. I see the existing code lseeks to >> the end whereas you are using the size from the stat, I think that is >> okay, just need to properly handle the case that the file is >> truncated between calls. > I have the code to lseek to the end if size < 0. Should I change it to > size < current? I think it should be (size > current) ? (size - current) : 0. Alternatively MAX(size-current, 0). >> >> - src/windows/native/java/io/io_util_md.h - it's not obvious to me >> why these need JNIEXPORT but this might be tied into my first >> question about the make changes. > Actually, I don't know why the old code needs JNIEXPORT, neither. I > only change it to use FD. And I did not touch other parts. And for > those new method declarations I added to > solaris/native/java/io/io_util_md.h, I did not add JNIEXPORT. I will > check whether it can solve the link issue if I remove JNIEXPORT from > the method signature. Thanks, I suspect that some/most of these are not needed. -Alan. From dl at cs.oswego.edu Tue Jan 29 12:24:11 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 29 Jan 2013 07:24:11 -0500 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: References: <510661B2.8090509@oracle.com> <51071175.7080706@cs.oswego.edu> Message-ID: <5107BF6B.5060109@cs.oswego.edu> On 01/29/13 03:04, Martin Buchholz wrote: > On Mon, Jan 28, 2013 at 4:01 PM, Doug Lea
> wrote: > > I also noticed that I had failed to include the simple > toString-based informal debug/monitoring aids that we've > been doing for synchronizers. > > > Which suggests looking for other missing methods by comparing lock-like classes. > Looking at the implementation of toString and comparing with RRWL suggests > + > + /** > + * Queries the number of read locks held for this lock. This > + * method is designed for use in monitoring system state, not for > + * synchronization control. > + * @return the number of read locks held > + */ > + public int getReadLockCount() { Yes, thanks. This also falls under the heading of never tempting people to parse toString() output because they don't see a corresponding method. I added it, with a few file rearrangements to keep the status methods all together. On 01/29/13 05:57, Chris Hegarty wrote: >> trivially, the commented assert added with these fixes is missing a trailing ';'. >> // assert (s & ABITS) >= RFULL Thanks! Also: Given all the flag-day discussions, I had used, for now, ThreadLocalRandom for adaptive spins to avoid dependencies on the internal-support additions done with TLR update. But as mentioned with the TLR updates, it is better for internal components to use the "secondary seed" support now in updated LockSupport. This avoids all possibility of disrupting expected user-visible statistical properties of the public ThreadLocalRandom, without otherwise impacting performance in either direction. But since the LockSupport method will be part of this openjdk commit, I changed to use it now, rather than requiring a future resync. -Doug From chris.hegarty at oracle.com Tue Jan 29 13:38:01 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Jan 2013 13:38:01 +0000 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <5107BF6B.5060109@cs.oswego.edu> References: <510661B2.8090509@oracle.com> <51071175.7080706@cs.oswego.edu> <5107BF6B.5060109@cs.oswego.edu> Message-ID: <5107D0B9.6000202@oracle.com> This now beggers the question, should we also include a 'public boolean isWriteLocked()' method ? -Chris. On 01/29/2013 12:24 PM, Doug Lea wrote: > On 01/29/13 03:04, Martin Buchholz wrote: > >> On Mon, Jan 28, 2013 at 4:01 PM, Doug Lea
> > wrote: >> >> I also noticed that I had failed to include the simple >> toString-based informal debug/monitoring aids that we've >> been doing for synchronizers. >> >> >> Which suggests looking for other missing methods by comparing >> lock-like classes. >> Looking at the implementation of toString and comparing with RRWL >> suggests > >> + >> + /** >> + * Queries the number of read locks held for this lock. This >> + * method is designed for use in monitoring system state, not for >> + * synchronization control. >> + * @return the number of read locks held >> + */ >> + public int getReadLockCount() { > > Yes, thanks. This also falls under the heading of never tempting > people to parse toString() output because they don't see a > corresponding method. I added it, with a few file rearrangements > to keep the status methods all together. > > On 01/29/13 05:57, Chris Hegarty wrote: >>> trivially, the commented assert added with these fixes is missing a >>> trailing ';'. >>> // assert (s & ABITS) >= RFULL > > Thanks! > > Also: Given all the flag-day discussions, I had used, for now, > ThreadLocalRandom for adaptive spins to avoid dependencies > on the internal-support additions done with TLR update. > But as mentioned with the TLR updates, it is better for > internal components to use the "secondary seed" support > now in updated LockSupport. This avoids all possibility > of disrupting expected user-visible statistical properties > of the public ThreadLocalRandom, without otherwise impacting > performance in either direction. > But since the LockSupport method will be part of this > openjdk commit, I changed to use it now, rather than requiring > a future resync. > > -Doug > From dl at cs.oswego.edu Tue Jan 29 14:33:40 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 29 Jan 2013 09:33:40 -0500 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <5107D0B9.6000202@oracle.com> References: <510661B2.8090509@oracle.com> <51071175.7080706@cs.oswego.edu> <5107BF6B.5060109@cs.oswego.edu> <5107D0B9.6000202@oracle.com> Message-ID: <5107DDC4.5000805@cs.oswego.edu> On 01/29/13 08:38, Chris Hegarty wrote: > This now beggers the question, should we also include a 'public boolean > isWriteLocked()' method ? Should and do :-) (Approx line 783) /** * Returns true if the lock is currently held exclusively. * * @return true if the lock is currently held exclusively */ public boolean isWriteLocked() { return (state & WBIT) != 0L; } > > -Chris. > > On 01/29/2013 12:24 PM, Doug Lea wrote: >> On 01/29/13 03:04, Martin Buchholz wrote: >> >>> On Mon, Jan 28, 2013 at 4:01 PM, Doug Lea
>> > wrote: >>> >>> I also noticed that I had failed to include the simple >>> toString-based informal debug/monitoring aids that we've >>> been doing for synchronizers. >>> >>> >>> Which suggests looking for other missing methods by comparing >>> lock-like classes. >>> Looking at the implementation of toString and comparing with RRWL >>> suggests >> >>> + >>> + /** >>> + * Queries the number of read locks held for this lock. This >>> + * method is designed for use in monitoring system state, not for >>> + * synchronization control. >>> + * @return the number of read locks held >>> + */ >>> + public int getReadLockCount() { >> >> Yes, thanks. This also falls under the heading of never tempting >> people to parse toString() output because they don't see a >> corresponding method. I added it, with a few file rearrangements >> to keep the status methods all together. >> >> On 01/29/13 05:57, Chris Hegarty wrote: >>>> trivially, the commented assert added with these fixes is missing a >>>> trailing ';'. >>>> // assert (s & ABITS) >= RFULL >> >> Thanks! >> >> Also: Given all the flag-day discussions, I had used, for now, >> ThreadLocalRandom for adaptive spins to avoid dependencies >> on the internal-support additions done with TLR update. >> But as mentioned with the TLR updates, it is better for >> internal components to use the "secondary seed" support >> now in updated LockSupport. This avoids all possibility >> of disrupting expected user-visible statistical properties >> of the public ThreadLocalRandom, without otherwise impacting >> performance in either direction. >> But since the LockSupport method will be part of this >> openjdk commit, I changed to use it now, rather than requiring >> a future resync. >> >> -Doug >> > From chris.hegarty at oracle.com Tue Jan 29 16:24:00 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Jan 2013 16:24:00 +0000 Subject: 8005697: Add StampedLock - JEP 155 In-Reply-To: <5107DDC4.5000805@cs.oswego.edu> References: <510661B2.8090509@oracle.com> <51071175.7080706@cs.oswego.edu> <5107BF6B.5060109@cs.oswego.edu> <5107D0B9.6000202@oracle.com> <5107DDC4.5000805@cs.oswego.edu> Message-ID: <5107F7A0.3030700@oracle.com> Updated javadoc and webrev: http://cr.openjdk.java.net/~chegar/8005697/ver.01/javadoc/StampedLock.html http://cr.openjdk.java.net/~chegar/8005697/ver.01/webrev/webrev/ -Chris. On 01/29/2013 02:33 PM, Doug Lea wrote: > On 01/29/13 08:38, Chris Hegarty wrote: >> This now beggers the question, should we also include a 'public boolean >> isWriteLocked()' method ? > > Should and do :-) (Approx line 783) > > /** > * Returns true if the lock is currently held exclusively. > * > * @return true if the lock is currently held exclusively > */ > public boolean isWriteLocked() { > return (state & WBIT) != 0L; > } > >> >> -Chris. >> >> On 01/29/2013 12:24 PM, Doug Lea wrote: >>> On 01/29/13 03:04, Martin Buchholz wrote: >>> >>>> On Mon, Jan 28, 2013 at 4:01 PM, Doug Lea
>>> > wrote: >>>> >>>> I also noticed that I had failed to include the simple >>>> toString-based informal debug/monitoring aids that we've >>>> been doing for synchronizers. >>>> >>>> >>>> Which suggests looking for other missing methods by comparing >>>> lock-like classes. >>>> Looking at the implementation of toString and comparing with RRWL >>>> suggests >>> >>>> + >>>> + /** >>>> + * Queries the number of read locks held for this lock. This >>>> + * method is designed for use in monitoring system state, not for >>>> + * synchronization control. >>>> + * @return the number of read locks held >>>> + */ >>>> + public int getReadLockCount() { >>> >>> Yes, thanks. This also falls under the heading of never tempting >>> people to parse toString() output because they don't see a >>> corresponding method. I added it, with a few file rearrangements >>> to keep the status methods all together. >>> >>> On 01/29/13 05:57, Chris Hegarty wrote: >>>>> trivially, the commented assert added with these fixes is missing a >>>>> trailing ';'. >>>>> // assert (s & ABITS) >= RFULL >>> >>> Thanks! >>> >>> Also: Given all the flag-day discussions, I had used, for now, >>> ThreadLocalRandom for adaptive spins to avoid dependencies >>> on the internal-support additions done with TLR update. >>> But as mentioned with the TLR updates, it is better for >>> internal components to use the "secondary seed" support >>> now in updated LockSupport. This avoids all possibility >>> of disrupting expected user-visible statistical properties >>> of the public ThreadLocalRandom, without otherwise impacting >>> performance in either direction. >>> But since the LockSupport method will be part of this >>> openjdk commit, I changed to use it now, rather than requiring >>> a future resync. >>> >>> -Doug >>> >> > From mike.duigou at oracle.com Tue Jan 29 19:31:12 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 29 Jan 2013 11:31:12 -0800 Subject: RFR : 8006594/8006595 : Define jdk_core test set In-Reply-To: <50FFF51B.1030809@oracle.com> References: <216D5987-F917-473E-98EF-C84BAB302C53@oracle.com> <50FFF51B.1030809@oracle.com> Message-ID: 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 david.buck at oracle.com Tue Jan 29 23:36:10 2013 From: david.buck at oracle.com (David Buck) Date: Wed, 30 Jan 2013 08:36:10 +0900 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak Message-ID: <51085CEA.7060202@oracle.com> Hi! This is a review request to add only the test case for the following OracleJDK issue : [ 7042126 : (alt-rt) HashMap.clone implementation should be re-examined ] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 * please note: I just marked the bug as "public" this morning, so there will be a short delay before the above link is available. The issue (root cause) is not in OpenJDK (i.e. the problem was OracleJDK specific), but the test case is valid for any Java SE implementation so it should go into OpenJDK so we can prevent a similar issue from ever happening in both releases moving forward. The test case simply helps ensure that the contents of a HashMap are not leaked when we clone the HashMap. webrev: [ Code Review for jdk ] http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ The OracleJDK fix (closed source) for the original issue has already passed code review and has been pushed into the appropriate closed source tree. Regards, -Buck From dingxmin at linux.vnet.ibm.com Wed Jan 30 02:06:23 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 30 Jan 2013 10:06:23 +0800 Subject: Java 8 syntax change between b63 and b65 Message-ID: <5108801F.4010306@linux.vnet.ibm.com> Hi guys, I noticed there is a change in Java 8 between b63 and b65. The change can be illustrated by compiling following Issue class. public class Issue { interface Handler { public void handle(); } interface Listener { public void listen(); } Handler handlerImpl = new Handler() { public void listen(Object... obj) { // do nothing } @Override public void handle() { new Listener() { @Override public void listen() { listen(null); } }; } }; } With OpenJDK 8 b65, compilation goes well whereas b63 failed, complaining that Issue.java:22: error: method listen in class cannot be applied to given types; listen(null); ^ required: no arguments found: reason: actual and formal argument lists differ in length 1 error Could anybody kindly take a look at it and point out what Oracle bug or feature has been built into b65 which is not available in b63? It would be very helpful. Best regards, Frank From david.holmes at oracle.com Wed Jan 30 09:58:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2013 19:58:33 +1000 Subject: Java 8 syntax change between b63 and b65 In-Reply-To: <5108801F.4010306@linux.vnet.ibm.com> References: <5108801F.4010306@linux.vnet.ibm.com> Message-ID: <5108EEC9.6080707@oracle.com> Hi Frank, Probably best to confirm this on lambda-dev but I suspect that default method support introduced a bug in b63 that was fixed by b65. David On 30/01/2013 12:06 PM, Frank Ding wrote: > Hi guys, > I noticed there is a change in Java 8 between b63 and b65. The change > can be illustrated by compiling following Issue class. > > public class Issue { > interface Handler { > public void handle(); > } > > interface Listener { > public void listen(); > } > > Handler handlerImpl = new Handler() { > public void listen(Object... obj) { > // do nothing > } > > @Override > public void handle() { > new Listener() { > > @Override > public void listen() { > listen(null); > } > }; > } > }; > } > > With OpenJDK 8 b65, compilation goes well whereas b63 failed, > complaining that > > Issue.java:22: error: method listen in class cannot > be applied to given types; > listen(null); > ^ > required: no arguments > found: > reason: actual and formal argument lists differ in length > 1 error > > Could anybody kindly take a look at it and point out what Oracle bug or > feature has been built into b65 which is not available in b63? It would > be very helpful. > > Best regards, > Frank > From Alan.Bateman at oracle.com Wed Jan 30 13:09:12 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Jan 2013 13:09:12 +0000 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <51085CEA.7060202@oracle.com> References: <51085CEA.7060202@oracle.com> Message-ID: <51091B78.7060909@oracle.com> On 29/01/2013 23:36, David Buck wrote: > Hi! > > This is a review request to add only the test case for the following > OracleJDK issue : > > [ 7042126 : (alt-rt) HashMap.clone implementation should be re-examined ] > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 > > * please note: I just marked the bug as "public" this morning, so > there will be a short delay before the above link is available. > > The issue (root cause) is not in OpenJDK (i.e. the problem was > OracleJDK specific), but the test case is valid for any Java SE > implementation so it should go into OpenJDK so we can prevent a > similar issue from ever happening in both releases moving forward. The > test case simply helps ensure that the contents of a HashMap are not > leaked when we clone the HashMap. > > webrev: > [ Code Review for jdk ] > http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ How robust is this test? I'm concerned that it might fail intermittently if the System.gc doesn't immediately GC the now un-references entries in hm. Minor nit, should be WeakReference to avoid the raw type. -Alan. From david.buck at oracle.com Wed Jan 30 13:32:19 2013 From: david.buck at oracle.com (David Buck) Date: Wed, 30 Jan 2013 22:32:19 +0900 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <51091B78.7060909@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> Message-ID: <510920E3.7090702@oracle.com> Hi Alan! Thank you for your help. TL;DR version: Strictly speaking (going only by the specifications), this could give us false positives, but I believe this is VERY unlikely to actually happen in real life. Long version: Yes, I gave this some thought myself. For example, on JRockit, if the object were in old space and System.gc() only did a young collection (the default behavior for JRockit), this test would result in a false positive. In fact, as the JVM is allowed by the specification to completely ignore explicit GC calls, we could never guarantee that we would the WeakReference would always get nulled out. That said, in pactice this works very well for both HotSpot and JRockit. Every scenario I have tried it out on (with both JVMs) has provided the expected result every single time (i.e. failing when expected; never resulting in false positive otherwise). It seems that both of Oracle's JVMs as currently implemented are very unlikely to run into any issues here. Marking the test cases as "othervm" also helps to remove most edge case scenarios where you could still somehow imagine this failing. (For example, on a JRockit-like JVM, other tests running concurrently could trigger a gc in the middle of this test resulting in the HashMap and its contents being promoted to old space and the null reference not being cleared during the call to System.gc() as expected.) One option would be to mark this as a manually-run test if we wanted to be extra cautious. What do you think? > Minor nit, should be WeakReference to avoid the raw type. I will update the webrev once we have decided what (if anything) to do regarding the risk of false positives. Cheers, -Buck On 2013/01/30 22:09, Alan Bateman wrote: > On 29/01/2013 23:36, David Buck wrote: >> Hi! >> >> This is a review request to add only the test case for the following >> OracleJDK issue : >> >> [ 7042126 : (alt-rt) HashMap.clone implementation should be re-examined ] >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 >> >> * please note: I just marked the bug as "public" this morning, so >> there will be a short delay before the above link is available. >> >> The issue (root cause) is not in OpenJDK (i.e. the problem was >> OracleJDK specific), but the test case is valid for any Java SE >> implementation so it should go into OpenJDK so we can prevent a >> similar issue from ever happening in both releases moving forward. The >> test case simply helps ensure that the contents of a HashMap are not >> leaked when we clone the HashMap. >> >> webrev: >> [ Code Review for jdk ] >> http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ > How robust is this test? I'm concerned that it might fail intermittently > if the System.gc doesn't immediately GC the now un-references entries in > hm. > > Minor nit, should be WeakReference to avoid the raw type. > > -Alan. From jonathan.gibbons at oracle.com Wed Jan 30 17:41:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 30 Jan 2013 17:41:27 +0000 Subject: hg: jdk8/tl/langtools: 8007096: DocLint parsing problems with some comments Message-ID: <20130130174132.C765D476AD@hg.openjdk.java.net> Changeset: 950d8195a5a4 Author: jjg Date: 2013-01-30 09:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/950d8195a5a4 8007096: DocLint parsing problems with some comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + test/tools/doclint/EndWithIdentifierTest.java + test/tools/doclint/EndWithIdentifierTest.out + test/tools/doclint/UnfinishedInlineTagTest.java + test/tools/doclint/UnfinishedInlineTagTest.out From jonathan.gibbons at oracle.com Wed Jan 30 17:47:45 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 30 Jan 2013 17:47:45 +0000 Subject: hg: jdk8/tl/langtools: 8007034: debug printer for javac internals Message-ID: <20130130174748.46FE4476AE@hg.openjdk.java.net> Changeset: c924291865e5 Author: jjg Date: 2013-01-30 09:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c924291865e5 8007034: debug printer for javac internals Reviewed-by: mcimadamore + test/tools/javac/lib/DPrinter.java From brian.burkhalter at oracle.com Wed Jan 30 18:34:47 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 30 Jan 2013 10:34:47 -0800 Subject: RFR: 6471906 - NegativeArraySizeException in tenToThe() Message-ID: Please review at your convenience. Issue: JDK-6471906 Assessment: The problem occurs because an attempt is made to allocate an array of length > Integer.MAX_VALUE. Proposed solution: --- a/src/share/classes/java/math/BigDecimal.java Fri Jan 25 12:25:10 2013 -0800 +++ b/src/share/classes/java/math/BigDecimal.java Tue Jan 29 13:23:47 2013 -0800 @@ -3537,13 +3537,25 @@ else return expandBigIntegerTenPowers(n); } - // BigInteger.pow is slow, so make 10**n by constructing a - // BigInteger from a character string (still not very fast) - char tenpow[] = new char[n + 1]; - tenpow[0] = '1'; - for (int i = 1; i <= n; i++) - tenpow[i] = '0'; - return new BigInteger(tenpow,1, tenpow.length); + + if (n < 1024*524288) { + // BigInteger.pow is slow, so make 10**n by constructing a + // BigInteger from a character string (still not very fast) + // which occupies no more than 1GB (!) of memory. + char tenpow[] = new char[n + 1]; + tenpow[0] = '1'; + for (int i = 1; i <= n; i++) { + tenpow[i] = '0'; + } + return new BigInteger(tenpow, 1, tenpow.length); + } + + if ((n & 0x1) == 0x1) { + return BigInteger.TEN.multiply(bigTenToThe(n - 1)); + } else { + BigInteger tmp = bigTenToThe(n/2); + return tmp.multiply(tmp); + } } The portion of the method using the tenpow array is retained for performance (speed of execution) reasons as the BigInteger multiplications for large values are slow. It is intended to address this latter problem separately. Thanks, Brian From joe.darcy at oracle.com Wed Jan 30 18:58:16 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Jan 2013 10:58:16 -0800 Subject: RFR: 6471906 - NegativeArraySizeException in tenToThe() In-Reply-To: References: Message-ID: <51096D48.5040701@oracle.com> Hi Brian, Looks fine. I think not have a regression test for this is okay since it would take a relatively long time to run and use a significant amount of memory. Thanks, -Joe On 01/30/2013 10:34 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: JDK-6471906 > > Assessment: > > The problem occurs because an attempt is made to allocate an array of length > Integer.MAX_VALUE. > > Proposed solution: > > --- a/src/share/classes/java/math/BigDecimal.java Fri Jan 25 12:25:10 2013 -0800 > +++ b/src/share/classes/java/math/BigDecimal.java Tue Jan 29 13:23:47 2013 -0800 > @@ -3537,13 +3537,25 @@ > else > return expandBigIntegerTenPowers(n); > } > - // BigInteger.pow is slow, so make 10**n by constructing a > - // BigInteger from a character string (still not very fast) > - char tenpow[] = new char[n + 1]; > - tenpow[0] = '1'; > - for (int i = 1; i <= n; i++) > - tenpow[i] = '0'; > - return new BigInteger(tenpow,1, tenpow.length); > + > + if (n < 1024*524288) { > + // BigInteger.pow is slow, so make 10**n by constructing a > + // BigInteger from a character string (still not very fast) > + // which occupies no more than 1GB (!) of memory. > + char tenpow[] = new char[n + 1]; > + tenpow[0] = '1'; > + for (int i = 1; i <= n; i++) { > + tenpow[i] = '0'; > + } > + return new BigInteger(tenpow, 1, tenpow.length); > + } > + > + if ((n & 0x1) == 0x1) { > + return BigInteger.TEN.multiply(bigTenToThe(n - 1)); > + } else { > + BigInteger tmp = bigTenToThe(n/2); > + return tmp.multiply(tmp); > + } > } > > The portion of the method using the tenpow array is retained for performance (speed of execution) reasons as the BigInteger multiplications for large values are slow. It is intended to address this latter problem separately. > > Thanks, > > Brian From brian.burkhalter at oracle.com Wed Jan 30 18:59:56 2013 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 30 Jan 2013 10:59:56 -0800 Subject: RFR: 6471906 - NegativeArraySizeException in tenToThe() In-Reply-To: <51096D48.5040701@oracle.com> References: <51096D48.5040701@oracle.com> Message-ID: <95C5D2A2-6AAD-42C6-A0E9-E2823774D905@oracle.com> OK, I shall label the issue accordingly. Thanks, Brian On Jan 30, 2013, at 10:58 AM, Joe Darcy wrote: > Looks fine. I think not have a regression test for this is okay since it would take a relatively long time to run and use a significant amount of memory. From mike.duigou at oracle.com Wed Jan 30 19:42:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 30 Jan 2013 11:42:21 -0800 Subject: RFR (S) CR 8006627: Improving performance and reducing object allocations of java.util.UUID to/from string In-Reply-To: References: Message-ID: <84A32ABE-B1E7-4E03-9843-DDFE20897B77@oracle.com> Good work Steven! 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. - 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. - 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? 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 joe.darcy at oracle.com Wed Jan 30 19:56:32 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Jan 2013 11:56:32 -0800 Subject: JDK 8 code review request for 8007115: Refactor regression tests for java.lang.reflect.Parameter Message-ID: <51097AF0.6020305@oracle.com> Hello, Please review my refactoring of a regression test for the java.lang.reflect.Parameter feature: 8007115: Refactor regression tests for java.lang.reflect.Parameter http://cr.openjdk.java.net/~darcy/8007115.0/ The new approach is to encode the expected information in annotations and check for consistency between the annotations and the computed result. Thanks, -Joe From mike.duigou at oracle.com Wed Jan 30 20:24:25 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 30 Jan 2013 12:24:25 -0800 Subject: RFR: 8006709 : Add minimal support of MacOSX platform for JDK NetBeans Projects In-Reply-To: <1C444A52-9B11-41BB-8B73-990097AC914C@oracle.com> References: <1C444A52-9B11-41BB-8B73-990097AC914C@oracle.com> Message-ID: <9A51B7B9-BB2C-4F25-9FD6-22D4389980C0@oracle.com> This issue still needs a reviewer. Mike On Jan 22 2013, at 13:27 , Mike Duigou wrote: > Hello all; > > This is a patch that has been lingering around in the lambda/lambda repo for a long time. It adds minimal support for the MacOSX platform to the JDK NetBeans projects. It could also be used as the basis for similar support for the langtools NetBeans projects. > > The patch also adjust the source level of the project to 1.8 and removes some long obsolete cruft. > > http://cr.openjdk.java.net/~mduigou/8006709/0/webrev/ > > Mike From kelly.ohair at oracle.com Wed Jan 30 20:36:39 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 30 Jan 2013 12:36:39 -0800 Subject: RFR: 8006709 : Add minimal support of MacOSX platform for JDK NetBeans Projects In-Reply-To: <9A51B7B9-BB2C-4F25-9FD6-22D4389980C0@oracle.com> References: <1C444A52-9B11-41BB-8B73-990097AC914C@oracle.com> <9A51B7B9-BB2C-4F25-9FD6-22D4389980C0@oracle.com> Message-ID: <8169D370-829E-40B1-AA9B-E43DB858667D@oracle.com> I don't use these netbeans projects, but the changes seem fine to me. The copyright on the new files says 2007, I assume they need to say 2013? -kto On Jan 30, 2013, at 12:24 PM, Mike Duigou wrote: > This issue still needs a reviewer. > > Mike > > On Jan 22 2013, at 13:27 , Mike Duigou wrote: > >> Hello all; >> >> This is a patch that has been lingering around in the lambda/lambda repo for a long time. It adds minimal support for the MacOSX platform to the JDK NetBeans projects. It could also be used as the basis for similar support for the langtools NetBeans projects. >> >> The patch also adjust the source level of the project to 1.8 and removes some long obsolete cruft. >> >> http://cr.openjdk.java.net/~mduigou/8006709/0/webrev/ >> >> Mike > From martinrb at google.com Wed Jan 30 20:37:45 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2013 12:37:45 -0800 Subject: 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <5107D8F7.4040308@oracle.com> <51092A24.6050009@oracle.com> Message-ID: [ email address fail: JDK-CORE-LIBS-DEV_WW_GRP at oracle.com] On Wed, Jan 30, 2013 at 12:36 PM, Martin Buchholz wrote: > I don't have time for a detailed review, but I have some high-level > comments. > > A lot of this is good functionality that should be provided in the jdk > proper, > notably getting process ids and manipulating process output (a higher > level interface to ProcessBuilder). See the test ProcessBuilder/Basic for > previous work by myself. > > Source files need to be newline-terminated. > > is so 1990s. Use {@code instead. > > Do you really need test.jdk to find yourself? Why not use java.home, > which is always present? > > > On Wed, Jan 30, 2013 at 6:40 AM, Rickard B?ckman < > rickard.backman at oracle.com> wrote: > >> Katja, >> >> I think the change looks good. >> However we need to find an official reviewer before we can push this. >> >> Can we get an official reviewer to look on this change please? >> >> Thanks >> /R >> >> On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote: >> >> > Hi everyone, >> > >> > In the previous mail I've referred to already existing BUG number, >> which was wrong. Here comes the webrev referred to the new BUG >> > >> > http://cr.openjdk.java.net/~ykantser/8007142/webrev.00/ >> > >> > Thanks, >> > Katja >> > >> > -------- Original Message -------- >> > Subject: 8006413: Add utility classes for writing better >> multiprocess tests in jtreg >> > Date: Tue, 29 Jan 2013 15:13:11 +0100 >> > From: Yekaterina Kantserova >> > To: core-libs-dev at openjdk.java.net >> > CC: jfr_dev_ww_grp >> > >> > Hi everyone, >> > >> > Christian T?rnqvist has done a great job to make it easier to run >> > multi-process tests in jtreg. His webrev >> > ( >> > http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ >> > ) is >> > already approved and on the way into the hotspot repo. >> > >> > This webrev >> > http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ >> > is >> > for putting these utility classes into the jdk repo. I'm going to use >> > them for the JFR testing in the first hand. >> > >> > The webrev is almost a copy of Christian's except JcmdBase.java, utility >> > class for starting jcmd, and some extra methods in OutputAnalyzer.java. >> > >> > Thanks, >> > Katja >> > >> > >> >> > From martinrb at google.com Wed Jan 30 20:48:15 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Jan 2013 12:48:15 -0800 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <51091B78.7060909@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> Message-ID: Consider importing the popular GcFinalization https://cs.corp.google.com/#google3/java/com/google/common/testing/GcFinalization.java&sq=package:google3%20-file:%5Eexperimental&q=gcfinalization&type=cs&l=61 as a testing utility for the jdk proper. On Wed, Jan 30, 2013 at 5:09 AM, Alan Bateman wrote: > How robust is this test? I'm concerned that it might fail intermittently > if the System.gc doesn't immediately GC the now un-references entries in hm. > From weijun.wang at oracle.com Thu Jan 31 00:54:37 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 31 Jan 2013 08:54:37 +0800 Subject: 8007142: Add utility classes for writing better multiprocess tests in jtreg In-Reply-To: References: <5107D8F7.4040308@oracle.com> <51092A24.6050009@oracle.com> Message-ID: <5109C0CD.4080107@oracle.com> Just take a brief look at the codes. It seems the library can launch a Java process, wait for it to finish, and collect all the output (stdout and stderr). Is that all? I would be glad if it supports manipulating the stdin, i.e. simulating input to a process. For example, I sometimes need to start two processes, one is a client, and one is a server, and they need to talk to each other. I could create sockets inside but it will be much simpler (and more stable) if they can just communicate through stdin/stdout. This also means you cannot drain the stdout in a single method, but read it after each input, you might need to prepare for blocking. Also, It will be nice if there is an example on how to use it. In fact, I'm working on something similar right now: http://cr.openjdk.java.net/~weijun/9999999/webrev.13/ Thanks Max On 01/30/2013 10:40 PM, Rickard B?ckman wrote: > Katja, > > I think the change looks good. > However we need to find an official reviewer before we can push this. > > Can we get an official reviewer to look on this change please? > > Thanks > /R > > On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote: > >> Hi everyone, >> >> In the previous mail I've referred to already existing BUG number, which was wrong. Here comes the webrev referred to the new BUG >> >> http://cr.openjdk.java.net/~ykantser/8007142/webrev.00/ >> >> Thanks, >> Katja >> >> -------- Original Message -------- >> Subject: 8006413: Add utility classes for writing better multiprocess tests in jtreg >> Date: Tue, 29 Jan 2013 15:13:11 +0100 >> From: Yekaterina Kantserova >> To: core-libs-dev at openjdk.java.net >> CC: jfr_dev_ww_grp >> >> Hi everyone, >> >> Christian T?rnqvist has done a great job to make it easier to run >> multi-process tests in jtreg. His webrev >> ( >> http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/ >> ) is >> already approved and on the way into the hotspot repo. >> >> This webrev >> http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ >> is >> for putting these utility classes into the jdk repo. I'm going to use >> them for the JFR testing in the first hand. >> >> The webrev is almost a copy of Christian's except JcmdBase.java, utility >> class for starting jcmd, and some extra methods in OutputAnalyzer.java. >> >> Thanks, >> Katja >> >> > From Bob.Vandette at oracle.COM Tue Jan 29 19:28:41 2013 From: Bob.Vandette at oracle.COM (Bob Vandette) Date: Tue, 29 Jan 2013 14:28:41 -0500 Subject: JEP for adding support for static JNI libraries Message-ID: <6867C2FE-6885-4030-A7CB-BCBA4CD390F6@oracle.COM> Please review this JEP I'd like to propose for Java SE 8. -------------- next part -------------- Bob Vandette Java SE Embedded Architect From bob.vandette at oracle.com Tue Jan 29 19:44:32 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 29 Jan 2013 14:44:32 -0500 Subject: Please review this JEP I'd like to propose for Java SE 8. Message-ID: <74F15266-C949-4EBE-AA28-E55ED53E3B48@oracle.com> Resending, mailer stripped out my attachment. Please review this JEP I'd like to propose for Java SE 8. Bob Vandette Java SE Embedded Architect -------------------------------------------------------------------------------------------- Title: Add support for static JNI libraries Author: Bob Vandette Organization: Oracle Java SE Embedded Owner: Bob Vandette Created: 2913/01/23 Type: Feature State: Draft Exposure: Open Component: core/libs Scope: SE RFE: 8005716 Discussion: jdk8 dash dev at openjdk dot java dot net Start: 2013/Q1 Effort: XS Duration: XS Template: 1.0 Reviewed-by: Alan Bateman Endorsed-by: Michael Vidsted Funded-by: Oracle Java SE Summary ------- The JNI specification doesn't fully support or specify how to use statically linked native libraries. There are at least two possible uses for this. 1. Native applications that embedded the JRE may wish to use statically linked JNI code rather than dynamically linked libraries. 2. Java applications that are developed for devices where shared libraries are not supported. On this type of platform, the JRE and all of it's supported JNI native code would be linked into a single application binary. At least two problems need to be addressed: 1. The current Java APIs that are used to initiate the loading process and as a result allow the native library entrypoints to be recognized need to be enhanced to support build-in libraries. A Java application wishing to use a build-in JNI library need a mechanism for notifying the VM that this library code is already included in the application image. In this situation, a System.loadLibrary request for a built-in library should avoid the platform native load but process the library as if the load succeeded. The current JNI specification alludes to this type of support but the currentHotspot VM does not support this behavior. "If the underlying operating system does not support dynamic linking, all native methods must be prelinked with the VM. In this case, the VM completes the System.loadLibrary call without actually loading the library." 2. The JNI_OnLoad and JNI_OnUnload function interface need to be enhanced to support library specific names since only a single function name can exist within an application. This could be implemented by appending the library name to these well-known-names. For example libnet.so could use JNI_OnLoad_net, JNI_OnUnload_net. Goals ----- 1. Modify the specification and implementation of Java SE in order to enable developers to build a java runtime into a single Java application binary without requiring the use of shared libraries. 2. Maintain Java source level compatibility. For example: System.loadLibrary("foobar") APIs should be able to transparently load dynamic or static libraries. 3. Support Java applications that use a combination of static and/or dynamic libraries. 4. Static libraries must be in memory prior to the initialization of the VM. Static libraries should not be linked with other dynamic shared libraries. Non-Goals --------- Complete native C/C++ source compatibility in not expected. It is expected that some minimal source changes will be required in order to rename the JNI_OnLoad and JNI_OnUnLoad functions in order to allow multiple static libraries to co-exist. Success Metrics --------------- This feature will be successful when there is support for static linkingand mixed static/dynamic linking in a Java runtime. Motivation ---------- Having the ability to link JNI static libraries within Java applications provides multiple benefits: 1. Enables the Link Time Optimization supported by most linkers to perform optimizations across the entire application. This results in smaller and faster executable. 2. Allows for the possibility of supporting Java SE on platforms that limit or do not support dynamic shared libraries. Description ----------- This change requires specification changes to both the Java SE library loading APIs and the JNI specification. Here is an initial draft of the specification updates in both areas: JAVA LIBRARY API CHANGES System.load, Runtime.load method Changes The System.load and Runtime.load specification descriptions will be change in to: Loads the native library specified by the filename argument. The filename argument must be an absolute path name. If the filename argument, when stripped of any platform-specific library prefix, path, and file extension, indicates a library whose name is L, and a native library called L is statically linked with the VM, then the JNI_OnLoad_L function exported by the library is invoked rather than attempting to load a dynamic library. A filename matching the argument does not have to exist in the file system. See the JNI Specification for more details. Otherwise, the filename argument is mapped to a native library image in an implementation-dependent manner. The UnsatisfiedLinkError - if either the filename is not an absolute path name, the native library is not statically linked with the VM, or the library cannot be mapped to a native library image by the host system. System.loadLibrary, Runtime.loadLibrary changes The System.loadLibrary and Runtime.loadLibrary specification descriptions will be changed to: Loads the native library specified by the libname argument. The libname argument must not contain any platform specific prefix, file extension or path. If a native library called libname is statically linked with the VM, then the JNI_OnLoad_libname function exported by the library is invoked. See the JNI Specification for more details. Otherwise, the libname argument is loaded from a system library location and mapped to a native library image in an implementation-dependent manner. The UnsatisfiedLinkError - if either the libname argument contains a file path, the native library is not statically linked with the VM, or the library cannot be mapped to a native library image by the host system. JNI SPECIFICATION CHANGE - A native library may be statically linked with the VM. The manner in which the library and VM image are combined is implementation-dependent. - A System.loadLibrary or equivalent API must succeed for this library to be considered loaded. - A library L whose image has been combined with the VM is defined as _statically linked_ if and only if the library exports a function called JNI_OnLoad_L. - If a _statically linked_ library L exports a function called JNI_OnLoad_L _and_ a function called JNI_OnLoad, the JNI_OnLoad function will be ignored. - If a library L is _statically linked_, then upon the first invocation of System.loadLibrary("L") or equivalent API, the Java runtime will invoke the JNI_OnLoad_L function with the same arguments and expected return value as specified for the JNI_OnLoad function. - A library L that is _statically linked_ will prohibit a library of the same name from being loaded dynamically. - When the class loader containing a _statically linked_ native library L is garbage collected, the VM will invoke the JNI_OnUnload_L function of the library if such a function is exported. - If a _statically linked_ library L exports a function called JNI_OnUnLoad_L _and_ a function called JNI_OnUnLoad, the JNI_OnUnLoad function will be ignored. The JNI version specification will be incremented to JNI_VERSION_1_8. This new functionality will only be supported in JNI_VERSION_1_8 or greater. Alternatives ------------ There are no alternatives. Testing ------- The JNI TCK tests need to be enhanced to validate native static libraries in addition to the currently supported dynamic libraries. Impact ------ - Compatibility: New configuration no issues with existing dynamic libraries - Portability: JNI native sources require function name changes when built static - Documentation: javadoc for impacted java/lang APIS and JNI specification - TCK: TCK JNI native library will need to be ported as a static lib From kirk at kodewerk.com Wed Jan 23 07:56:18 2013 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 23 Jan 2013 08:56:18 +0100 Subject: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 In-Reply-To: References: <50ECA935.2030703@oracle.com> <50EFA768.40006@oracle.com> <50F05798.30306@CoSoCo.de> <06078680-610A-4CAD-9622-CD8657733B74@oracle.com> <50F120CD.6020207@CoSoCo.de> <50F77DB7.50806@oracle.com> <50FDCF9E.5040600@CoSoCo.de> <50FEF49A.6090409@oracle.com> <50FF2772.7080807@CoSoCo.de> Message-ID: <6C37BA75-993A-4367-BC8A-7DA95C91451A@kodewerk.com> On 2013-01-23, at 1:14 AM, Vitaly Davidovich wrote: > Personally, optimizing for interpreter (or even C1) doesn't seem worth it. If something's truly hot and best perf is desired then use C2 or tiered. If the method isn't hot enough to trigger the C2 threshold, then why bother? You're already behind the 8 ball in terms of performance. Maybe this is heresy though :). > > Maybe, maybe not.. what I can say is this is a case of an optimization that doesn't scale down. In cases where scale down was needed I have recommended to customers that they "flash" their system just to push the counter beyond the compile threshold. In those cases naively compiled code was still a lot better than interrupting byte code. I've also turned off decay in a number of applications where loads weren't quite enough to beat the decay behaviour. Yeah I know this is at the risk of filling code cache but code cache occupancy is something that I regularly recommend people monitor for (check my VisualVM memory pool plug-in). In fact, I just tuned an app where I used -Xcomp to estimate how big the code cache needed to be to avoid filling it. Production settings had decay turned off. So, I can't say your wrong and I generally don't like fiddling with these setting but I will if I have to and I've had to in a number of instances where ensuring a compile beat leaving it alone. Regards, Kirk From claes.redestad at oracle.com Thu Jan 24 13:37:25 2013 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 24 Jan 2013 14:37:25 +0100 Subject: Request for review: 8006757: Refactor Socket and File I/O tracing Message-ID: <51013915.5080305@oracle.com> 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 alex.buckley at oracle.com Thu Jan 24 19:55:09 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Jan 2013 11:55:09 -0800 Subject: Parameter reflection: parameters with "" as their name In-Reply-To: <51018C89.6040605@oracle.com> References: <51018C89.6040605@oracle.com> Message-ID: <5101919D.2080606@oracle.com> This is a design/spec question, so should be discussed on enhanced-metadata-spec-discuss, not core-libs-dev. Alex On 1/24/2013 11:33 AM, Eric McCorkle wrote: > The current version of the spec for parameter reflection, found here: > > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > states that if a parameter has no name, then the reflection API should > synthesize a name of the form "argN", where N is the index of the > parameter. It also states that if a MethodParameters attribute has a > name index of 0, then it indicates a parameter with no name. > > The question I have is, what if a MethodParameters attribute indicates a > name of "" (meaning, the empty string)? Does this count as a valid > name, or should it be treated as a parameter with no name? > > > It is probably also worth thinking about invalid parameter names, for > example "10", "_", "+", " ", other whitespace characters, and so on. From yekaterina.kantserova at oracle.com Tue Jan 29 14:13:11 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 29 Jan 2013 15:13:11 +0100 Subject: 8006413: Add utility classes for writing better multiprocess tests in jtreg Message-ID: <5107D8F7.4040308@oracle.com> Hi everyone, Christian T?rnqvist has done a great job to make it easier to run multi-process tests in jtreg. His webrev (http://cr.openjdk.java.net/~ctornqvi/webrev/8006413/webrev.03/) is already approved and on the way into the hotspot repo. This webrev http://cr.openjdk.java.net/~ykantser/8006413/webrev.00/ is for putting these utility classes into the jdk repo. I'm going to use them for the JFR testing in the first hand. The webrev is almost a copy of Christian's except JcmdBase.java, utility class for starting jcmd, and some extra methods in OutputAnalyzer.java. Thanks, Katja From joel.franck at oracle.com Thu Jan 31 09:12:40 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 31 Jan 2013 09:12:40 +0000 Subject: hg: jdk8/tl/jdk: 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement; ... Message-ID: <20130131091301.331DF476D9@hg.openjdk.java.net> Changeset: 5097fe015763 Author: jfranck Date: 2013-01-31 10:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5097fe015763 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement 8004919: AnnotationSupport uses possibly half-constructed AnnotationType instances Summary: Implements the simplified semantics for repeating annotations and removes the incorrect obtaining of an AnnotationType Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.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/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java From david.holmes at oracle.com Thu Jan 31 09:26:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2013 19:26:19 +1000 Subject: WITHDRAWN Re: Proposal: Fully Concurrent ClassLoading In-Reply-To: <50BF371A.1060604@oracle.com> References: <50BF371A.1060604@oracle.com> Message-ID: <510A38BB.3090103@oracle.com> 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 david.buck at oracle.com Thu Jan 31 09:40:26 2013 From: david.buck at oracle.com (David Buck) Date: Thu, 31 Jan 2013 18:40:26 +0900 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510920E3.7090702@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> Message-ID: <510A3C0A.4060405@oracle.com> Hi! I was curious to see what others have done in the past and took a look at about 15 different testcases for memory leaks in the jdk tree and basically found 3 patterns: Pattern A: Use a loop that would exercise the relevant code for a finite number of runs. If an OOME is not thrown, the test passes. In order for the test to finish quickly, most people seem to specify a very small Xmx to limit the number of iterations needed. (example: java/util/concurrent/BlockingQueue/PollMemoryLeak.java) Pattern B: Code similar to what I have submitted for this review that tries to leak one object, explicitly triggers a GC event, and then confirms that the WeakReference was nulled out. One thing to note is that in every case I found of this the author chose to run multiple GC events, usually somewhere between 5 to 10000 iterations. (example: javax/management/Introspector/ClassLeakTest.java) Pattern C: These cases used a WeakReference like Pattern B above, but instead of depending on an explicit call to System.gc(), would intentionally fill the heap until an OOME is thrown to trigger at least 1 "full" gc event. (example: java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java) Patterns A and B were most common (with pattern B being slightly more common), and I only found Pattern C 2 times Strictly speaking, all 3 patters are problematic as they each depend on undefined behavior in some way or another. Patterns A and C require the JVM to handle OOMEs somewhat gracefully (Pattern A when we fail, Pattern C when we pass), and pattern B requires an explicit call to System.gc to collect an arbitrary object. The fact that we do not routinely see false positives from these cases indicates that in practice, they all seem to work OK for the time being. After thinking about this for a bit, I actually really like pattern C. Even though the JVM is not technically guaranteed to gracefully handle all OOME conditions, we try very hard to be as robust as possible in the face of Java-heap OOME. Again, the fact that we do not routinely see false positives from these tests proves that in practice, this works very well. Even if an otherwise "correct" change (say in the JVM) resulted in Pattern C suddenly failing, it is something we would almost certainly want to investigate as it would indicate that the robustness of the JVM has somehow regressed. I plan to modify my testcase to follow pattern C and resubmit for review. If anyone has any other ideas or comments, I would be grateful for your input. Cheers, -Buck On 2013/01/30 22:32, David Buck wrote: > Hi Alan! > > Thank you for your help. > > TL;DR version: > > Strictly speaking (going only by the specifications), this could give us > false positives, but I believe this is VERY unlikely to actually happen > in real life. > > Long version: > > Yes, I gave this some thought myself. For example, on JRockit, if the > object were in old space and System.gc() only did a young collection > (the default behavior for JRockit), this test would result in a false > positive. In fact, as the JVM is allowed by the specification to > completely ignore explicit GC calls, we could never guarantee that we > would the WeakReference would always get nulled out. > > That said, in pactice this works very well for both HotSpot and JRockit. > Every scenario I have tried it out on (with both JVMs) has provided the > expected result every single time (i.e. failing when expected; never > resulting in false positive otherwise). It seems that both of Oracle's > JVMs as currently implemented are very unlikely to run into any issues > here. Marking the test cases as "othervm" also helps to remove most edge > case scenarios where you could still somehow imagine this failing. (For > example, on a JRockit-like JVM, other tests running concurrently could > trigger a gc in the middle of this test resulting in the HashMap and its > contents being promoted to old space and the null reference not being > cleared during the call to System.gc() as expected.) > > One option would be to mark this as a manually-run test if we wanted to > be extra cautious. What do you think? > > > Minor nit, should be WeakReference to avoid the raw type. > > I will update the webrev once we have decided what (if anything) to do > regarding the risk of false positives. > > Cheers, > -Buck > > On 2013/01/30 22:09, Alan Bateman wrote: >> On 29/01/2013 23:36, David Buck wrote: >>> Hi! >>> >>> This is a review request to add only the test case for the following >>> OracleJDK issue : >>> >>> [ 7042126 : (alt-rt) HashMap.clone implementation should be >>> re-examined ] >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 >>> >>> * please note: I just marked the bug as "public" this morning, so >>> there will be a short delay before the above link is available. >>> >>> The issue (root cause) is not in OpenJDK (i.e. the problem was >>> OracleJDK specific), but the test case is valid for any Java SE >>> implementation so it should go into OpenJDK so we can prevent a >>> similar issue from ever happening in both releases moving forward. The >>> test case simply helps ensure that the contents of a HashMap are not >>> leaked when we clone the HashMap. >>> >>> webrev: >>> [ Code Review for jdk ] >>> http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ >> How robust is this test? I'm concerned that it might fail intermittently >> if the System.gc doesn't immediately GC the now un-references entries in >> hm. >> >> Minor nit, should be WeakReference to avoid the raw type. >> >> -Alan. From peter.levart at gmail.com Thu Jan 31 13:07:23 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 31 Jan 2013 14:07:23 +0100 Subject: WITHDRAWN Re: Proposal: Fully Concurrent ClassLoading In-Reply-To: <510A38BB.3090103@oracle.com> References: <50BF371A.1060604@oracle.com> <510A38BB.3090103@oracle.com> Message-ID: <510A6C8B.60701@gmail.com> Hi David, Could the parallel classloading be at least space optimized somehow in the JDK8 timeframe if there was a solution ready? 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 peter.levart at gmail.com Thu Jan 31 13:47:39 2013 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 31 Jan 2013 14:47:39 +0100 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510A3C0A.4060405@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> Message-ID: <510A75FB.8070903@gmail.com> Hi David, You could combine the B and C in the following pattern: - Create a WeakReference to the observed object; - Execute the potentially "leaky" operation; - Trigger gc with after check of WeakReference. Maybe a couple of times. - If that does not clear the reference, fill-in heap until OOME is thrown and after that check the reference. Regards, Peter On 01/31/2013 10:40 AM, David Buck wrote: > Hi! > > I was curious to see what others have done in the past and took a look > at about 15 different testcases for memory leaks in the jdk tree and > basically found 3 patterns: > > Pattern A: Use a loop that would exercise the relevant code for a > finite number of runs. If an OOME is not thrown, the test passes. In > order for the test to finish quickly, most people seem to specify a > very small Xmx to limit the number of iterations needed. (example: > java/util/concurrent/BlockingQueue/PollMemoryLeak.java) > > Pattern B: Code similar to what I have submitted for this review that > tries to leak one object, explicitly triggers a GC event, and then > confirms that the WeakReference was nulled out. One thing to note is > that in every case I found of this the author chose to run multiple GC > events, usually somewhere between 5 to 10000 iterations. (example: > javax/management/Introspector/ClassLeakTest.java) > > Pattern C: These cases used a WeakReference like Pattern B above, but > instead of depending on an explicit call to System.gc(), would > intentionally fill the heap until an OOME is thrown to trigger at > least 1 "full" gc event. (example: > java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java) > > Patterns A and B were most common (with pattern B being slightly more > common), and I only found Pattern C 2 times > > Strictly speaking, all 3 patters are problematic as they each depend > on undefined behavior in some way or another. Patterns A and C require > the JVM to handle OOMEs somewhat gracefully (Pattern A when we fail, > Pattern C when we pass), and pattern B requires an explicit call to > System.gc to collect an arbitrary object. > > The fact that we do not routinely see false positives from these cases > indicates that in practice, they all seem to work OK for the time being. > > After thinking about this for a bit, I actually really like pattern C. > Even though the JVM is not technically guaranteed to gracefully handle > all OOME conditions, we try very hard to be as robust as possible in > the face of Java-heap OOME. Again, the fact that we do not routinely > see false positives from these tests proves that in practice, this > works very well. Even if an otherwise "correct" change (say in the > JVM) resulted in Pattern C suddenly failing, it is something we would > almost certainly want to investigate as it would indicate that the > robustness of the JVM has somehow regressed. > > I plan to modify my testcase to follow pattern C and resubmit for > review. If anyone has any other ideas or comments, I would be grateful > for your input. > > Cheers, > -Buck > > On 2013/01/30 22:32, David Buck wrote: >> Hi Alan! >> >> Thank you for your help. >> >> TL;DR version: >> >> Strictly speaking (going only by the specifications), this could give us >> false positives, but I believe this is VERY unlikely to actually happen >> in real life. >> >> Long version: >> >> Yes, I gave this some thought myself. For example, on JRockit, if the >> object were in old space and System.gc() only did a young collection >> (the default behavior for JRockit), this test would result in a false >> positive. In fact, as the JVM is allowed by the specification to >> completely ignore explicit GC calls, we could never guarantee that we >> would the WeakReference would always get nulled out. >> >> That said, in pactice this works very well for both HotSpot and JRockit. >> Every scenario I have tried it out on (with both JVMs) has provided the >> expected result every single time (i.e. failing when expected; never >> resulting in false positive otherwise). It seems that both of Oracle's >> JVMs as currently implemented are very unlikely to run into any issues >> here. Marking the test cases as "othervm" also helps to remove most edge >> case scenarios where you could still somehow imagine this failing. (For >> example, on a JRockit-like JVM, other tests running concurrently could >> trigger a gc in the middle of this test resulting in the HashMap and its >> contents being promoted to old space and the null reference not being >> cleared during the call to System.gc() as expected.) >> >> One option would be to mark this as a manually-run test if we wanted to >> be extra cautious. What do you think? >> >> > Minor nit, should be WeakReference to avoid the raw type. >> >> I will update the webrev once we have decided what (if anything) to do >> regarding the risk of false positives. >> >> Cheers, >> -Buck >> >> On 2013/01/30 22:09, Alan Bateman wrote: >>> On 29/01/2013 23:36, David Buck wrote: >>>> Hi! >>>> >>>> This is a review request to add only the test case for the following >>>> OracleJDK issue : >>>> >>>> [ 7042126 : (alt-rt) HashMap.clone implementation should be >>>> re-examined ] >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 >>>> >>>> * please note: I just marked the bug as "public" this morning, so >>>> there will be a short delay before the above link is available. >>>> >>>> The issue (root cause) is not in OpenJDK (i.e. the problem was >>>> OracleJDK specific), but the test case is valid for any Java SE >>>> implementation so it should go into OpenJDK so we can prevent a >>>> similar issue from ever happening in both releases moving forward. The >>>> test case simply helps ensure that the contents of a HashMap are not >>>> leaked when we clone the HashMap. >>>> >>>> webrev: >>>> [ Code Review for jdk ] >>>> http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ >>> How robust is this test? I'm concerned that it might fail >>> intermittently >>> if the System.gc doesn't immediately GC the now un-references >>> entries in >>> hm. >>> >>> Minor nit, should be WeakReference to avoid the raw type. >>> >>> -Alan. From Alan.Bateman at oracle.com Thu Jan 31 14:05:11 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jan 2013 14:05:11 +0000 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510A3C0A.4060405@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> Message-ID: <510A7A17.6000600@oracle.com> On 31/01/2013 09:40, David Buck wrote: > Hi! > > I was curious to see what others have done in the past and took a look > at about 15 different testcases for memory leaks in the jdk tree and > basically found 3 patterns: Another one that you'll find is tests that use jmap to look at the instance count of specific objects to see if they are increasing. I personally do not like these tests as they are too targeted, also they involve a second process and historically have been troublesome. Anyway, my concern with the test as proposed is that it will might fail intermittently. Last year there were fixes to several issues like this, here are two that Eric Wang that come to mind: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433 http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd Adding a loop + sleep to your test should be fine for now. I see Martin's suggestion about adding a supporting library to the test suite for use by tests like this. As it's something that tests in may areas then it may be worth exploring. -Alan From karen.kinnear at oracle.com Thu Jan 31 15:30:47 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 31 Jan 2013 10:30:47 -0500 Subject: Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code In-Reply-To: <5107B89A.3050400@oracle.com> References: <50FE3EE5.20600@oracle.com> <5100065A.9080801@oracle.com> <51029C56.9020302@oracle.com> <5106CB48.3010102@oracle.com> <5107B89A.3050400@oracle.com> Message-ID: 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 martinrb at google.com Thu Jan 31 15:36:54 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 31 Jan 2013 07:36:54 -0800 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> Message-ID: Oops. Retry Consider importing the popular GcFinalization http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java as a testing utility for the jdk proper. From david.buck at oracle.com Thu Jan 31 16:24:24 2013 From: david.buck at oracle.com (David Buck) Date: Fri, 01 Feb 2013 01:24:24 +0900 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510A7A17.6000600@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> <510A7A17.6000600@oracle.com> Message-ID: <510A9AB8.8070505@oracle.com> Hi Alen (and everyone else)! Thank you for your replies. I have added an explicit-GC/sleep loop similar to the example fixes. I have also added type parameters to avoid use of raw types as suggested. The updated webrev is available below. Please have a look and let me know if this is acceptable for pushing. http://cr.openjdk.java.net/~dbuck/7042126/webrev.01/ Cheers, -Buck On 2013/01/31 23:05, Alan Bateman wrote: > On 31/01/2013 09:40, David Buck wrote: >> Hi! >> >> I was curious to see what others have done in the past and took a look >> at about 15 different testcases for memory leaks in the jdk tree and >> basically found 3 patterns: > Another one that you'll find is tests that use jmap to look at the > instance count of specific objects to see if they are increasing. I > personally do not like these tests as they are too targeted, also they > involve a second process and historically have been troublesome. > > Anyway, my concern with the test as proposed is that it will might fail > intermittently. Last year there were fixes to several issues like this, > here are two that Eric Wang that come to mind: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433 > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd > > Adding a loop + sleep to your test should be fine for now. > > I see Martin's suggestion about adding a supporting library to the test > suite for use by tests like this. As it's something that tests in may > areas then it may be worth exploring. > > -Alan From joe.darcy at oracle.com Thu Jan 31 17:45:31 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 31 Jan 2013 09:45:31 -0800 Subject: JDK 8 code review request for 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Message-ID: <510AADBB.8020805@oracle.com> Hello, 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/ Thanks, -Joe From eric.mccorkle at oracle.com Thu Jan 31 17:51:09 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 31 Jan 2013 12:51:09 -0500 Subject: JDK 8 code review request for 8007115: Refactor regression tests for java.lang.reflect.Parameter In-Reply-To: <51097AF0.6020305@oracle.com> References: <51097AF0.6020305@oracle.com> Message-ID: <510AAF0D.7050300@oracle.com> I'm not a reviewer, but I did write the original test. The annotations method is preferable, so I give a thumbs up to this change. On 01/30/13 14:56, Joe Darcy wrote: > Hello, > > Please review my refactoring of a regression test for the > java.lang.reflect.Parameter feature: > > 8007115: Refactor regression tests for java.lang.reflect.Parameter > http://cr.openjdk.java.net/~darcy/8007115.0/ > > The new approach is to encode the expected information in annotations > and check for consistency between the annotations and the computed result. > > Thanks, > > -Joe From kumar.x.srinivasan at oracle.com Thu Jan 31 17:59:53 2013 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 31 Jan 2013 09:59:53 -0800 Subject: RFR: 8003549: (pack200) assertion errors when processing lambda class files with IMethods Message-ID: <510AB119.9030802@oracle.com> Hello, Please review. http://cr.openjdk.java.net/~ksrini/8003549/webrev.0/ Thanks Kumar From mike.duigou at oracle.com Thu Jan 31 18:03:45 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 31 Jan 2013 10:03:45 -0800 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510A75FB.8070903@gmail.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> <510A75FB.8070903@gmail.com> Message-ID: <47F4F064-E614-4683-991A-50380E8A006A@oracle.com> I like this suggestion. David's most recent webrev with while(true) loop could easily be extended to create linked list of reference arrays in each loop. ie. Object[] chain = null; while (wr.get() != null) { try { Object[] allocate = new Object[1000000]; allocate[0] = chain; chain = allocate; } catch( OutOfMemoryError ) { chain = null; } System.gc(); Thread.sleep(100); } Mike On Jan 31 2013, at 05:47 , Peter Levart wrote: > Hi David, > > You could combine the B and C in the following pattern: > > - Create a WeakReference to the observed object; > - Execute the potentially "leaky" operation; > - Trigger gc with after check of WeakReference. Maybe a couple of times. > - If that does not clear the reference, fill-in heap until OOME is thrown and after that check the reference. > > Regards, Peter > > On 01/31/2013 10:40 AM, David Buck wrote: >> Hi! >> >> I was curious to see what others have done in the past and took a look at about 15 different testcases for memory leaks in the jdk tree and basically found 3 patterns: >> >> Pattern A: Use a loop that would exercise the relevant code for a finite number of runs. If an OOME is not thrown, the test passes. In order for the test to finish quickly, most people seem to specify a very small Xmx to limit the number of iterations needed. (example: java/util/concurrent/BlockingQueue/PollMemoryLeak.java) >> >> Pattern B: Code similar to what I have submitted for this review that tries to leak one object, explicitly triggers a GC event, and then confirms that the WeakReference was nulled out. One thing to note is that in every case I found of this the author chose to run multiple GC events, usually somewhere between 5 to 10000 iterations. (example: javax/management/Introspector/ClassLeakTest.java) >> >> Pattern C: These cases used a WeakReference like Pattern B above, but instead of depending on an explicit call to System.gc(), would intentionally fill the heap until an OOME is thrown to trigger at least 1 "full" gc event. (example: java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java) >> >> Patterns A and B were most common (with pattern B being slightly more common), and I only found Pattern C 2 times >> >> Strictly speaking, all 3 patters are problematic as they each depend on undefined behavior in some way or another. Patterns A and C require the JVM to handle OOMEs somewhat gracefully (Pattern A when we fail, Pattern C when we pass), and pattern B requires an explicit call to System.gc to collect an arbitrary object. >> >> The fact that we do not routinely see false positives from these cases indicates that in practice, they all seem to work OK for the time being. >> >> After thinking about this for a bit, I actually really like pattern C. Even though the JVM is not technically guaranteed to gracefully handle all OOME conditions, we try very hard to be as robust as possible in the face of Java-heap OOME. Again, the fact that we do not routinely see false positives from these tests proves that in practice, this works very well. Even if an otherwise "correct" change (say in the JVM) resulted in Pattern C suddenly failing, it is something we would almost certainly want to investigate as it would indicate that the robustness of the JVM has somehow regressed. >> >> I plan to modify my testcase to follow pattern C and resubmit for review. If anyone has any other ideas or comments, I would be grateful for your input. >> >> Cheers, >> -Buck >> >> On 2013/01/30 22:32, David Buck wrote: >>> Hi Alan! >>> >>> Thank you for your help. >>> >>> TL;DR version: >>> >>> Strictly speaking (going only by the specifications), this could give us >>> false positives, but I believe this is VERY unlikely to actually happen >>> in real life. >>> >>> Long version: >>> >>> Yes, I gave this some thought myself. For example, on JRockit, if the >>> object were in old space and System.gc() only did a young collection >>> (the default behavior for JRockit), this test would result in a false >>> positive. In fact, as the JVM is allowed by the specification to >>> completely ignore explicit GC calls, we could never guarantee that we >>> would the WeakReference would always get nulled out. >>> >>> That said, in pactice this works very well for both HotSpot and JRockit. >>> Every scenario I have tried it out on (with both JVMs) has provided the >>> expected result every single time (i.e. failing when expected; never >>> resulting in false positive otherwise). It seems that both of Oracle's >>> JVMs as currently implemented are very unlikely to run into any issues >>> here. Marking the test cases as "othervm" also helps to remove most edge >>> case scenarios where you could still somehow imagine this failing. (For >>> example, on a JRockit-like JVM, other tests running concurrently could >>> trigger a gc in the middle of this test resulting in the HashMap and its >>> contents being promoted to old space and the null reference not being >>> cleared during the call to System.gc() as expected.) >>> >>> One option would be to mark this as a manually-run test if we wanted to >>> be extra cautious. What do you think? >>> >>> > Minor nit, should be WeakReference to avoid the raw type. >>> >>> I will update the webrev once we have decided what (if anything) to do >>> regarding the risk of false positives. >>> >>> Cheers, >>> -Buck >>> >>> On 2013/01/30 22:09, Alan Bateman wrote: >>>> On 29/01/2013 23:36, David Buck wrote: >>>>> Hi! >>>>> >>>>> This is a review request to add only the test case for the following >>>>> OracleJDK issue : >>>>> >>>>> [ 7042126 : (alt-rt) HashMap.clone implementation should be >>>>> re-examined ] >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 >>>>> >>>>> * please note: I just marked the bug as "public" this morning, so >>>>> there will be a short delay before the above link is available. >>>>> >>>>> The issue (root cause) is not in OpenJDK (i.e. the problem was >>>>> OracleJDK specific), but the test case is valid for any Java SE >>>>> implementation so it should go into OpenJDK so we can prevent a >>>>> similar issue from ever happening in both releases moving forward. The >>>>> test case simply helps ensure that the contents of a HashMap are not >>>>> leaked when we clone the HashMap. >>>>> >>>>> webrev: >>>>> [ Code Review for jdk ] >>>>> http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ >>>> How robust is this test? I'm concerned that it might fail intermittently >>>> if the System.gc doesn't immediately GC the now un-references entries in >>>> hm. >>>> >>>> Minor nit, should be WeakReference to avoid the raw type. >>>> >>>> -Alan. > From david.buck at oracle.com Thu Jan 31 18:39:53 2013 From: david.buck at oracle.com (David Buck) Date: Fri, 01 Feb 2013 03:39:53 +0900 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <47F4F064-E614-4683-991A-50380E8A006A@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> <510A75FB.8070903@gmail.com> <47F4F064-E614-4683-991A-50380E8A006A@oracle.com> Message-ID: <510ABA79.6000003@oracle.com> Hi Mike (and others)! Sounds like we have a (sort of) consensus. I have updated the test case and retested. Please have a look and let me know what you think. http://cr.openjdk.java.net/~dbuck/7042126/webrev.02/ Cheers, -Buck On 2013/02/01 3:03, Mike Duigou wrote: > I like this suggestion. David's most recent webrev with while(true) loop could easily be extended to create linked list of reference arrays in each loop. ie. > > Object[] chain = null; > while (wr.get() != null) { > try { > Object[] allocate = new Object[1000000]; > allocate[0] = chain; > chain = allocate; > } catch( OutOfMemoryError ) { > chain = null; > } > > System.gc(); > Thread.sleep(100); > } > > Mike > > On Jan 31 2013, at 05:47 , Peter Levart wrote: > >> Hi David, >> >> You could combine the B and C in the following pattern: >> >> - Create a WeakReference to the observed object; >> - Execute the potentially "leaky" operation; >> - Trigger gc with after check of WeakReference. Maybe a couple of times. >> - If that does not clear the reference, fill-in heap until OOME is thrown and after that check the reference. >> >> Regards, Peter >> >> On 01/31/2013 10:40 AM, David Buck wrote: >>> Hi! >>> >>> I was curious to see what others have done in the past and took a look at about 15 different testcases for memory leaks in the jdk tree and basically found 3 patterns: >>> >>> Pattern A: Use a loop that would exercise the relevant code for a finite number of runs. If an OOME is not thrown, the test passes. In order for the test to finish quickly, most people seem to specify a very small Xmx to limit the number of iterations needed. (example: java/util/concurrent/BlockingQueue/PollMemoryLeak.java) >>> >>> Pattern B: Code similar to what I have submitted for this review that tries to leak one object, explicitly triggers a GC event, and then confirms that the WeakReference was nulled out. One thing to note is that in every case I found of this the author chose to run multiple GC events, usually somewhere between 5 to 10000 iterations. (example: javax/management/Introspector/ClassLeakTest.java) >>> >>> Pattern C: These cases used a WeakReference like Pattern B above, but instead of depending on an explicit call to System.gc(), would intentionally fill the heap until an OOME is thrown to trigger at least 1 "full" gc event. (example: java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java) >>> >>> Patterns A and B were most common (with pattern B being slightly more common), and I only found Pattern C 2 times >>> >>> Strictly speaking, all 3 patters are problematic as they each depend on undefined behavior in some way or another. Patterns A and C require the JVM to handle OOMEs somewhat gracefully (Pattern A when we fail, Pattern C when we pass), and pattern B requires an explicit call to System.gc to collect an arbitrary object. >>> >>> The fact that we do not routinely see false positives from these cases indicates that in practice, they all seem to work OK for the time being. >>> >>> After thinking about this for a bit, I actually really like pattern C. Even though the JVM is not technically guaranteed to gracefully handle all OOME conditions, we try very hard to be as robust as possible in the face of Java-heap OOME. Again, the fact that we do not routinely see false positives from these tests proves that in practice, this works very well. Even if an otherwise "correct" change (say in the JVM) resulted in Pattern C suddenly failing, it is something we would almost certainly want to investigate as it would indicate that the robustness of the JVM has somehow regressed. >>> >>> I plan to modify my testcase to follow pattern C and resubmit for review. If anyone has any other ideas or comments, I would be grateful for your input. >>> >>> Cheers, >>> -Buck >>> >>> On 2013/01/30 22:32, David Buck wrote: >>>> Hi Alan! >>>> >>>> Thank you for your help. >>>> >>>> TL;DR version: >>>> >>>> Strictly speaking (going only by the specifications), this could give us >>>> false positives, but I believe this is VERY unlikely to actually happen >>>> in real life. >>>> >>>> Long version: >>>> >>>> Yes, I gave this some thought myself. For example, on JRockit, if the >>>> object were in old space and System.gc() only did a young collection >>>> (the default behavior for JRockit), this test would result in a false >>>> positive. In fact, as the JVM is allowed by the specification to >>>> completely ignore explicit GC calls, we could never guarantee that we >>>> would the WeakReference would always get nulled out. >>>> >>>> That said, in pactice this works very well for both HotSpot and JRockit. >>>> Every scenario I have tried it out on (with both JVMs) has provided the >>>> expected result every single time (i.e. failing when expected; never >>>> resulting in false positive otherwise). It seems that both of Oracle's >>>> JVMs as currently implemented are very unlikely to run into any issues >>>> here. Marking the test cases as "othervm" also helps to remove most edge >>>> case scenarios where you could still somehow imagine this failing. (For >>>> example, on a JRockit-like JVM, other tests running concurrently could >>>> trigger a gc in the middle of this test resulting in the HashMap and its >>>> contents being promoted to old space and the null reference not being >>>> cleared during the call to System.gc() as expected.) >>>> >>>> One option would be to mark this as a manually-run test if we wanted to >>>> be extra cautious. What do you think? >>>> >>>>> Minor nit, should be WeakReference to avoid the raw type. >>>> >>>> I will update the webrev once we have decided what (if anything) to do >>>> regarding the risk of false positives. >>>> >>>> Cheers, >>>> -Buck >>>> >>>> On 2013/01/30 22:09, Alan Bateman wrote: >>>>> On 29/01/2013 23:36, David Buck wrote: >>>>>> Hi! >>>>>> >>>>>> This is a review request to add only the test case for the following >>>>>> OracleJDK issue : >>>>>> >>>>>> [ 7042126 : (alt-rt) HashMap.clone implementation should be >>>>>> re-examined ] >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 >>>>>> >>>>>> * please note: I just marked the bug as "public" this morning, so >>>>>> there will be a short delay before the above link is available. >>>>>> >>>>>> The issue (root cause) is not in OpenJDK (i.e. the problem was >>>>>> OracleJDK specific), but the test case is valid for any Java SE >>>>>> implementation so it should go into OpenJDK so we can prevent a >>>>>> similar issue from ever happening in both releases moving forward. The >>>>>> test case simply helps ensure that the contents of a HashMap are not >>>>>> leaked when we clone the HashMap. >>>>>> >>>>>> webrev: >>>>>> [ Code Review for jdk ] >>>>>> http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ >>>>> How robust is this test? I'm concerned that it might fail intermittently >>>>> if the System.gc doesn't immediately GC the now un-references entries in >>>>> hm. >>>>> >>>>> Minor nit, should be WeakReference to avoid the raw type. >>>>> >>>>> -Alan. >> > From mike.duigou at oracle.com Thu Jan 31 18:46:21 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 31 Jan 2013 10:46:21 -0800 (PST) Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510ABA79.6000003@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> <510A75FB.8070903@gmail.com> <47F4F064-E614-4683-991A-50380E8A006A@oracle.com> <510ABA79.6000003@oracle.com> Message-ID: <5D89908B-A8DD-4F2E-8FAE-94EA3BFFF695@oracle.com> Looks good to me. Longer term I do think we should consider importing the utility that Martin suggests rather than doing something similar ad hoc as we have done in this test. Mike On Jan 31 2013, at 10:39 , David Buck wrote: > Hi Mike (and others)! > > Sounds like we have a (sort of) consensus. I have updated the test case and retested. Please have a look and let me know what you think. > > http://cr.openjdk.java.net/~dbuck/7042126/webrev.02/ > > Cheers, > -Buck > > On 2013/02/01 3:03, Mike Duigou wrote: >> I like this suggestion. David's most recent webrev with while(true) loop could easily be extended to create linked list of reference arrays in each loop. ie. >> >> Object[] chain = null; >> while (wr.get() != null) { >> try { >> Object[] allocate = new Object[1000000]; >> allocate[0] = chain; >> chain = allocate; >> } catch( OutOfMemoryError ) { >> chain = null; >> } >> >> System.gc(); >> Thread.sleep(100); >> } >> >> Mike >> >> On Jan 31 2013, at 05:47 , Peter Levart wrote: >> >>> Hi David, >>> >>> You could combine the B and C in the following pattern: >>> >>> - Create a WeakReference to the observed object; >>> - Execute the potentially "leaky" operation; >>> - Trigger gc with after check of WeakReference. Maybe a couple of times. >>> - If that does not clear the reference, fill-in heap until OOME is thrown and after that check the reference. >>> >>> Regards, Peter >>> >>> On 01/31/2013 10:40 AM, David Buck wrote: >>>> Hi! >>>> >>>> I was curious to see what others have done in the past and took a look at about 15 different testcases for memory leaks in the jdk tree and basically found 3 patterns: >>>> >>>> Pattern A: Use a loop that would exercise the relevant code for a finite number of runs. If an OOME is not thrown, the test passes. In order for the test to finish quickly, most people seem to specify a very small Xmx to limit the number of iterations needed. (example: java/util/concurrent/BlockingQueue/PollMemoryLeak.java) >>>> >>>> Pattern B: Code similar to what I have submitted for this review that tries to leak one object, explicitly triggers a GC event, and then confirms that the WeakReference was nulled out. One thing to note is that in every case I found of this the author chose to run multiple GC events, usually somewhere between 5 to 10000 iterations. (example: javax/management/Introspector/ClassLeakTest.java) >>>> >>>> Pattern C: These cases used a WeakReference like Pattern B above, but instead of depending on an explicit call to System.gc(), would intentionally fill the heap until an OOME is thrown to trigger at least 1 "full" gc event. (example: java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java) >>>> >>>> Patterns A and B were most common (with pattern B being slightly more common), and I only found Pattern C 2 times >>>> >>>> Strictly speaking, all 3 patters are problematic as they each depend on undefined behavior in some way or another. Patterns A and C require the JVM to handle OOMEs somewhat gracefully (Pattern A when we fail, Pattern C when we pass), and pattern B requires an explicit call to System.gc to collect an arbitrary object. >>>> >>>> The fact that we do not routinely see false positives from these cases indicates that in practice, they all seem to work OK for the time being. >>>> >>>> After thinking about this for a bit, I actually really like pattern C. Even though the JVM is not technically guaranteed to gracefully handle all OOME conditions, we try very hard to be as robust as possible in the face of Java-heap OOME. Again, the fact that we do not routinely see false positives from these tests proves that in practice, this works very well. Even if an otherwise "correct" change (say in the JVM) resulted in Pattern C suddenly failing, it is something we would almost certainly want to investigate as it would indicate that the robustness of the JVM has somehow regressed. >>>> >>>> I plan to modify my testcase to follow pattern C and resubmit for review. If anyone has any other ideas or comments, I would be grateful for your input. >>>> >>>> Cheers, >>>> -Buck >>>> >>>> On 2013/01/30 22:32, David Buck wrote: >>>>> Hi Alan! >>>>> >>>>> Thank you for your help. >>>>> >>>>> TL;DR version: >>>>> >>>>> Strictly speaking (going only by the specifications), this could give us >>>>> false positives, but I believe this is VERY unlikely to actually happen >>>>> in real life. >>>>> >>>>> Long version: >>>>> >>>>> Yes, I gave this some thought myself. For example, on JRockit, if the >>>>> object were in old space and System.gc() only did a young collection >>>>> (the default behavior for JRockit), this test would result in a false >>>>> positive. In fact, as the JVM is allowed by the specification to >>>>> completely ignore explicit GC calls, we could never guarantee that we >>>>> would the WeakReference would always get nulled out. >>>>> >>>>> That said, in pactice this works very well for both HotSpot and JRockit. >>>>> Every scenario I have tried it out on (with both JVMs) has provided the >>>>> expected result every single time (i.e. failing when expected; never >>>>> resulting in false positive otherwise). It seems that both of Oracle's >>>>> JVMs as currently implemented are very unlikely to run into any issues >>>>> here. Marking the test cases as "othervm" also helps to remove most edge >>>>> case scenarios where you could still somehow imagine this failing. (For >>>>> example, on a JRockit-like JVM, other tests running concurrently could >>>>> trigger a gc in the middle of this test resulting in the HashMap and its >>>>> contents being promoted to old space and the null reference not being >>>>> cleared during the call to System.gc() as expected.) >>>>> >>>>> One option would be to mark this as a manually-run test if we wanted to >>>>> be extra cautious. What do you think? >>>>> >>>>>> Minor nit, should be WeakReference to avoid the raw type. >>>>> >>>>> I will update the webrev once we have decided what (if anything) to do >>>>> regarding the risk of false positives. >>>>> >>>>> Cheers, >>>>> -Buck >>>>> >>>>> On 2013/01/30 22:09, Alan Bateman wrote: >>>>>> On 29/01/2013 23:36, David Buck wrote: >>>>>>> Hi! >>>>>>> >>>>>>> This is a review request to add only the test case for the following >>>>>>> OracleJDK issue : >>>>>>> >>>>>>> [ 7042126 : (alt-rt) HashMap.clone implementation should be >>>>>>> re-examined ] >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7042126 >>>>>>> >>>>>>> * please note: I just marked the bug as "public" this morning, so >>>>>>> there will be a short delay before the above link is available. >>>>>>> >>>>>>> The issue (root cause) is not in OpenJDK (i.e. the problem was >>>>>>> OracleJDK specific), but the test case is valid for any Java SE >>>>>>> implementation so it should go into OpenJDK so we can prevent a >>>>>>> similar issue from ever happening in both releases moving forward. The >>>>>>> test case simply helps ensure that the contents of a HashMap are not >>>>>>> leaked when we clone the HashMap. >>>>>>> >>>>>>> webrev: >>>>>>> [ Code Review for jdk ] >>>>>>> http://cr.openjdk.java.net/~dbuck/7042126/webrev.00/ >>>>>> How robust is this test? I'm concerned that it might fail intermittently >>>>>> if the System.gc doesn't immediately GC the now un-references entries in >>>>>> hm. >>>>>> >>>>>> Minor nit, should be WeakReference to avoid the raw type. >>>>>> >>>>>> -Alan. >>> >> From xueming.shen at oracle.com Thu Jan 31 18:51:57 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 10:51:57 -0800 Subject: Codereview request for 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Message-ID: <510ABD4D.4030004@oracle.com> Alan, Would you please help review this one? http://cr.openjdk.java.net/~sherman/8005394/webrev/ Thanks! -Sherman From david.buck at oracle.com Thu Jan 31 18:56:21 2013 From: david.buck at oracle.com (david.buck at oracle.com) Date: Thu, 31 Jan 2013 18:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7042126: (alt-rt) HashMap.clone implementation should be re-examined Message-ID: <20130131185643.CC531476F4@hg.openjdk.java.net> Changeset: 3f766f58c48a Author: dbuck Date: 2013-01-31 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f766f58c48a 7042126: (alt-rt) HashMap.clone implementation should be re-examined Summary: Test case for cr7042126. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou + test/java/util/HashMap/HashMapCloneLeak.java From Alan.Bateman at oracle.com Thu Jan 31 19:03:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jan 2013 19:03:28 +0000 Subject: code review request: Test case for JDK-7042126 HashMap.clone() memory leak In-Reply-To: <510ABA79.6000003@oracle.com> References: <51085CEA.7060202@oracle.com> <51091B78.7060909@oracle.com> <510920E3.7090702@oracle.com> <510A3C0A.4060405@oracle.com> <510A75FB.8070903@gmail.com> <47F4F064-E614-4683-991A-50380E8A006A@oracle.com> <510ABA79.6000003@oracle.com> Message-ID: <510AC000.7000108@oracle.com> On 31/01/2013 18:39, David Buck wrote: > Hi Mike (and others)! > > Sounds like we have a (sort of) consensus. I have updated the test > case and retested. Please have a look and let me know what you think. > > http://cr.openjdk.java.net/~dbuck/7042126/webrev.02/ > Your previous of the test seemed okay too. For this version then its probably best to limit the heap size in the @run. -Alan. From Alan.Bateman at oracle.com Thu Jan 31 19:04:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jan 2013 19:04:10 +0000 Subject: Codereview request for 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed In-Reply-To: <510ABD4D.4030004@oracle.com> References: <510ABD4D.4030004@oracle.com> Message-ID: <510AC02A.1010708@oracle.com> On 31/01/2013 18:51, Xueming Shen wrote: > Alan, > > Would you please help review this one? > > http://cr.openjdk.java.net/~sherman/8005394/webrev/ > > Thanks! > -Sherman This looks fine to me. -Alan From xueming.shen at oracle.com Thu Jan 31 19:10:30 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 31 Jan 2013 19:10:30 +0000 Subject: hg: jdk8/tl/jdk: 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Message-ID: <20130131191041.A2BBB476F5@hg.openjdk.java.net> Changeset: 857d99bef21d Author: sherman Date: 2013-01-31 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/857d99bef21d 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Summary: to check null for dec/enc.wrap methods Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From dan.xu at oracle.com Thu Jan 31 20:07:24 2013 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 31 Jan 2013 12:07:24 -0800 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> Message-ID: <510ACEFC.2060607@oracle.com> 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 mike.duigou at oracle.com Thu Jan 31 20:07:44 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 31 Jan 2013 12:07:44 -0800 Subject: JDK 8 code review request for 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types In-Reply-To: <510AADBB.8020805@oracle.com> References: <510AADBB.8020805@oracle.com> Message-ID: Looks fine to me. I verified that these are no longer referenced and the changes are in sync with the intent of 8005712. Mike On Jan 31 2013, at 09:45 , Joe Darcy wrote: > Hello, > > 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/ > > Thanks, > > -Joe From alex.buckley at oracle.com Thu Jan 31 20:13:16 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 31 Jan 2013 12:13:16 -0800 Subject: JDK 8 code review request for 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types In-Reply-To: <510AADBB.8020805@oracle.com> References: <510AADBB.8020805@oracle.com> Message-ID: <510AD05C.6030502@oracle.com> 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 joe.darcy at oracle.com Thu Jan 31 20:13:45 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:13:45 +0000 Subject: hg: jdk8/tl/jdk: 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Message-ID: <20130131201358.B16CD476F8@hg.openjdk.java.net> Changeset: 278397f752da Author: darcy Date: 2013-01-31 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/278397f752da 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Reviewed-by: mduigou - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java ! src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java From joe.darcy at oracle.com Thu Jan 31 20:16:13 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:16:13 +0000 Subject: hg: jdk8/tl/langtools: 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Message-ID: <20130131201615.A7A28476F9@hg.openjdk.java.net> Changeset: 8e4c22acebeb Author: darcy Date: 2013-01-31 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e4c22acebeb 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java From xueming.shen at oracle.com Thu Jan 31 20:23:36 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 12:23:36 -0800 Subject: Codereview request for 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character Message-ID: <510AD2C8.1040602@oracle.com> Hi, Please help review changes for 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake http://cr.openjdk.java.net/~sherman/8007298_8006526/webrev thanks! -Sherman From joe.darcy at oracle.com Thu Jan 31 20:23:22 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:23:22 +0000 Subject: hg: jdk8/tl/jdk: 8007115: Refactor regression tests for java.lang.reflect.Parameter Message-ID: <20130131202335.7F191476FA@hg.openjdk.java.net> Changeset: a5f38e811ab0 Author: darcy Date: 2013-01-31 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5f38e811ab0 8007115: Refactor regression tests for java.lang.reflect.Parameter Reviewed-by: emc ! test/java/lang/reflect/Parameter/WithoutParameters.java From Alan.Bateman at oracle.com Thu Jan 31 21:01:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jan 2013 21:01:37 +0000 Subject: Codereview request for 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character In-Reply-To: <510AD2C8.1040602@oracle.com> References: <510AD2C8.1040602@oracle.com> Message-ID: <510ADBB1.6090701@oracle.com> On 31/01/2013 20:23, Xueming Shen wrote: > Hi, > > Please help review changes for > > 8007298: Base64.getMimeDecoder().decode() throws IAE for a single > non-base64 character > 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake > > http://cr.openjdk.java.net/~sherman/8007298_8006526/webrev This looks fine to me. I guess I probably would have done if (IsMIME & (base64[0] == -1) .. but no big deal. Will you add 8007298 to the list of bugs in the test before you push? -Alan. From xueming.shen at oracle.com Thu Jan 31 21:07:10 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 13:07:10 -0800 Subject: Codereview request for 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character In-Reply-To: <510ADBB1.6090701@oracle.com> References: <510AD2C8.1040602@oracle.com> <510ADBB1.6090701@oracle.com> Message-ID: <510ADCFE.2090206@oracle.com> Thanks! webrev has been updated accordingly. -Sherman On 01/31/2013 01:01 PM, Alan Bateman wrote: > On 31/01/2013 20:23, Xueming Shen wrote: >> Hi, >> >> Please help review changes for >> >> 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character >> 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake >> >> http://cr.openjdk.java.net/~sherman/8007298_8006526/webrev > This looks fine to me. > > I guess I probably would have done if (IsMIME & (base64[0] == -1) .. but no big deal. > > Will you add 8007298 to the list of bugs in the test before you push? > > -Alan. From xueming.shen at oracle.com Thu Jan 31 21:13:37 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 31 Jan 2013 21:13:37 +0000 Subject: hg: jdk8/tl/jdk: 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character; ... Message-ID: <20130131211351.72285476FF@hg.openjdk.java.net> Changeset: e5ce312a5b10 Author: sherman Date: 2013-01-31 13:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5ce312a5b10 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake Summary: to ignore single non-base64 char in mime decoding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From mike.duigou at oracle.com Thu Jan 31 21:27:56 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 31 Jan 2013 21:27:56 +0000 Subject: hg: jdk8/tl/jdk: 8006709: Add minimal support of MacOSX platform for NetBeans Projects Message-ID: <20130131212807.8091B47701@hg.openjdk.java.net> Changeset: cff8d7768d72 Author: mduigou Date: 2013-01-31 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cff8d7768d72 8006709: Add minimal support of MacOSX platform for NetBeans Projects Summary: Adds support for MacOSX platform and architecture detection. Other minor updates (-source/target 1.8) Reviewed-by: ohair + make/netbeans/common/architectures/arch-x86_64.properties + make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/make.xml ! make/netbeans/common/shared.xml From jeffhain at rocketmail.com Thu Jan 31 21:26:20 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 31 Jan 2013 21:26:20 +0000 (GMT) Subject: Math.round(...) and bug 6430675 Message-ID: <1359667580.92728.YahooMailNeo@web132106.mail.ird.yahoo.com> 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 xueming.shen at oracle.com Thu Jan 31 22:15:10 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 14:15:10 -0800 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 Message-ID: <510AECEE.7060908@oracle.com> 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/ Thanks -Sherman From lana.steuck at oracle.com Thu Jan 31 22:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl: 19 new changesets Message-ID: <20130131221903.1B5C147703@hg.openjdk.java.net> Changeset: 50307da0149e Author: jqzuo Date: 2012-12-31 14:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/50307da0149e 8005583: Install build(gnumake all) failed preventing RE from doing JDK8 combo builds Reviewed-by: paulk, billyh ! make/install-rules.gmk Changeset: e5664599a127 Author: cgruszka Date: 2013-01-02 14:54 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e5664599a127 Merge Changeset: 75634cbeab47 Author: cgruszka Date: 2013-01-04 13:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/75634cbeab47 Merge Changeset: 61d7e2971723 Author: cgruszka Date: 2013-01-14 14:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/61d7e2971723 Merge Changeset: f9163f9cb1da Author: cgruszka Date: 2013-01-23 08:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f9163f9cb1da Merge Changeset: 5a5e97f9ac0a Author: erikj Date: 2013-01-18 09:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a5e97f9ac0a 8006520: build-infra: Fix sparkle-framework configure parameter Reviewed-by: tbell, ohair ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: edad83acbd46 Author: erikj Date: 2013-01-18 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/edad83acbd46 8003693: build-infra: bridgeBuild should allow for partial build (no hotspot) Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: c3bf62746a80 Author: tbell Date: 2013-01-23 13:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c3bf62746a80 8006797: build-infra JPRT builds need JPRT_ARCHIVE_INSTALL_BUNDLE in common/makefiles/Jprt.gmk Reviewed-by: ohair ! common/makefiles/Jprt.gmk Changeset: b43aa5bd8ca5 Author: katleman Date: 2013-01-23 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b43aa5bd8ca5 Merge Changeset: cd2fa0d0ed3d Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd2fa0d0ed3d Added tag jdk8-b74 for changeset b43aa5bd8ca5 ! .hgtags Changeset: 039783b67959 Author: lana Date: 2013-01-26 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/039783b67959 Merge Changeset: e28985c549aa Author: raginip Date: 2013-01-18 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e28985c549aa 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! common/bin/compare_exceptions.sh.incl Changeset: db46b1c27a93 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/db46b1c27a93 Merge - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 8baaaba2ee6b Author: lana Date: 2013-01-29 20:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8baaaba2ee6b Merge Changeset: 0d4b0a13adb2 Author: erikj Date: 2013-01-23 11:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0d4b0a13adb2 8005855: build-infra: Remove -R flag when cross compiling Reviewed-by: dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: ea6379d4624f Author: erikj Date: 2013-01-23 11:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ea6379d4624f 8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 0d46733cfffb Author: erikj Date: 2013-01-23 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0d46733cfffb 8006658: build-infra: Make MILESTONE behave the same as JDK_BUILD_NUMBER Reviewed-by: ohrstrom, dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 9e5847257731 Author: erikj Date: 2013-01-24 09:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9e5847257731 Merge Changeset: 2a713921952c Author: katleman Date: 2013-01-30 13:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2a713921952c Merge ! common/autoconf/generated-configure.sh From lana.steuck at oracle.com Thu Jan 31 22:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b74 for changeset 2132845cf5f7 Message-ID: <20130131221903.DEC9E47704@hg.openjdk.java.net> Changeset: d4e68ce17795 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d4e68ce17795 Added tag jdk8-b74 for changeset 2132845cf5f7 ! .hgtags From lana.steuck at oracle.com Thu Jan 31 22:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b74 for changeset 12db3c5a3393 Message-ID: <20130131221908.1192047705@hg.openjdk.java.net> Changeset: 966bf9f3c41a Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/966bf9f3c41a Added tag jdk8-b74 for changeset 12db3c5a3393 ! .hgtags From lana.steuck at oracle.com Thu Jan 31 22:19:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:03 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130131221912.452ED47706@hg.openjdk.java.net> Changeset: 69bc57b1ebdd Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/69bc57b1ebdd Added tag jdk8-b74 for changeset 2087e24a4357 ! .hgtags Changeset: ff0b73a6b3f6 Author: lana Date: 2013-01-26 18:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ff0b73a6b3f6 Merge From lana.steuck at oracle.com Thu Jan 31 22:19:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:23 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130131221935.EA3DD47707@hg.openjdk.java.net> Changeset: 54e4ba223319 Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/54e4ba223319 Added tag jdk8-b74 for changeset 56c97aff46bb ! .hgtags Changeset: c2e11e2ec4a3 Author: lana Date: 2013-01-26 19:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c2e11e2ec4a3 Merge - 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: b7cb3d7ade25 Author: lana Date: 2013-01-31 10:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7cb3d7ade25 Merge Changeset: 7b269e916e06 Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7b269e916e06 Merge From lana.steuck at oracle.com Thu Jan 31 22:19:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:39 +0000 Subject: hg: jdk8/tl/hotspot: 65 new changesets Message-ID: <20130131222145.0B04947708@hg.openjdk.java.net> Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97ee8abd6ab2 Merge Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90a92d5bca17 Merge Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/617b18aadb33 Merge Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! 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/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d754ef7b9352 Merge Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/274a29bf5682 Merge Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags From lana.steuck at oracle.com Thu Jan 31 22:21:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:21:22 +0000 Subject: hg: jdk8/tl/jdk: 40 new changesets Message-ID: <20130131222907.A772647709@hg.openjdk.java.net> Changeset: 6d849e883c40 Author: yhuang Date: 2013-01-13 18:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d849e883c40 7114053: [sq] Inproper tanslation for iso lanugage of Albanian Reviewed-by: naoto ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 2de23975ee10 Author: yhuang Date: 2013-01-15 19:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2de23975ee10 Merge Changeset: 68fc838d5e89 Author: yhuang Date: 2013-01-16 19:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68fc838d5e89 Merge Changeset: 595baf3cc781 Author: yhuang Date: 2013-01-16 23:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/595baf3cc781 Merge Changeset: 478d8354285a Author: erikj Date: 2013-01-18 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/478d8354285a 8006567: jre/lib/applet missing from Mac JDK installation Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: 92d8880d5406 Author: erikj Date: 2013-01-21 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d8880d5406 8006583: build-infra: Remove /javax/swing/SwingBeanInfoBase.java from src.zip Reviewed-by: tbell ! makefiles/GensrcSwing.gmk Changeset: a9839ed93340 Author: erikj Date: 2013-01-21 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9839ed93340 Merge Changeset: 506bf3d23f06 Author: erikj Date: 2013-01-21 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/506bf3d23f06 8006579: build-infra: In jvm.cfg, alias -server to -client when no server jvm is built. Reviewed-by: tbell ! makefiles/CopyFiles.gmk Changeset: 57d5d9544628 Author: erikj Date: 2013-01-22 09:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57d5d9544628 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable Reviewed-by: dholmes, ohrstrom ! makefiles/GensrcX11Wrappers.gmk + src/solaris/classes/sun/awt/X11/generator/sizes.32 + src/solaris/classes/sun/awt/X11/generator/sizes.64 Changeset: ef592aceb40e Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef592aceb40e Added tag jdk8-b74 for changeset 57d5d9544628 ! .hgtags Changeset: 57561ea851d2 Author: lana Date: 2013-01-26 19:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57561ea851d2 Merge - 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 ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 4faaaf5027a5 Author: alexsch Date: 2013-01-14 08:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4faaaf5027a5 7166409: bug4331515.java fail with NullPointerException on ubuntu10.04-x86 for JDK8 Reviewed-by: serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: 9c6ca265b4a1 Author: alexsch Date: 2013-01-15 12:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c6ca265b4a1 8003978: closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx Reviewed-by: serb, leonidr ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/sun/swing/SwingUtilities2.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java Changeset: 1b886bd5e5bf Author: serb Date: 2013-01-15 21:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b886bd5e5bf 7124525: [macosx] No animation on certain Swing components in Aqua LaF Reviewed-by: alexsch, swingler ! src/macosx/classes/com/apple/laf/AquaPainter.java ! src/macosx/classes/com/apple/laf/ImageCache.java Changeset: 7ea1372be2fe Author: mcherkas Date: 2013-01-16 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ea1372be2fe 8005492: Reduce number of warnings in sun/awt/* classes Reviewed-by: art, anthony ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/sun/awt/image/SurfaceManager.java Changeset: 23f9955ae34a Author: lana Date: 2013-01-16 15:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23f9955ae34a Merge Changeset: 47243a4efb8b Author: kshefov Date: 2013-01-17 15:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47243a4efb8b 7124209: [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] Reviewed-by: serb, alexsch + test/javax/swing/SpringLayout/4726194/bug4726194.java Changeset: 035f87fc9f74 Author: anthony Date: 2013-01-18 14:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/035f87fc9f74 8005465: [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m Summary: Allow one to start AWT on the main thread w/o exceptions Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m Changeset: 5309fed435b5 Author: serb Date: 2013-01-18 18:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5309fed435b5 7179050: [macosx] Make LWAWT be able to run on AppKit thread Summary: Removed irrelevant assertions from the LWAWT native methods Reviewed-by: serb, anthony Contributed-by: petr.pchelko at oracle.com ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CDesktopPeer.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! src/macosx/native/sun/awt/CImage.m ! src/macosx/native/sun/awt/CInputMethod.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuComponent.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/CPopupMenu.m ! src/macosx/native/sun/awt/CTrayIcon.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: 112c08b41ca2 Author: alitvinov Date: 2013-01-18 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/112c08b41ca2 8006417: JComboBox.showPopup(), hidePopup() fails in JRE 1.7 on OS X Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/javax/swing/JComboBox/ShowPopupAfterHidePopupTest/ShowPopupAfterHidePopupTest.java Changeset: b4131358120a Author: raginip Date: 2013-01-18 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4131358120a 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! make/Makefile + make/bridge/AccessBridgeJava/Makefile + make/bridge/JAWTAccessBridge/Files_cpp.gmk + make/bridge/JAWTAccessBridge/Makefile + make/bridge/Jabswitch/Makefile + make/bridge/Jaccess/Makefile + make/bridge/JavaAccessBridge/Files_cpp.gmk + make/bridge/JavaAccessBridge/Makefile + make/bridge/Makefile + make/bridge/WindowsAccessBridge/Files_cpp.gmk + make/bridge/WindowsAccessBridge/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: f55d869052dd Author: alexsch Date: 2013-01-21 17:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f55d869052dd 8004298: NPE in WindowsTreeUI.ensureRowsAreVisible Reviewed-by: serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java + test/javax/swing/JTree/8004298/bug8004298.java Changeset: dd7e1cc4253c Author: alexp Date: 2013-01-24 15:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd7e1cc4253c 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 04d2005fa178 Author: alexp Date: 2013-01-24 15:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04d2005fa178 7132793: [macosx] setWheelScrollEnabled action reversed Reviewed-by: serb, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java Changeset: 40a45a72a120 Author: serb Date: 2013-01-24 15:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40a45a72a120 8005997: [macosx] Printer Dialog opens an additional title bar Reviewed-by: anthony, art Contributed-by: petr.pchelko at oracle.com ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: fab11b21ee6e Author: kizune Date: 2013-01-24 16:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fab11b21ee6e 7143768: [macosx] Unexpected NullPointerException and java.io.IOException during DnD Reviewed-by: alexp ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java Changeset: 7dd1896b37c8 Author: malenkov Date: 2013-01-24 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dd1896b37c8 6817933: Setting the background of an HTML Widget changes the native Windows JFileChooser Reviewed-by: alexsch ! src/share/classes/sun/swing/WindowsPlacesBar.java + test/javax/swing/JFileChooser/6817933/Test6817933.java Changeset: f8526b99b825 Author: serb Date: 2013-01-24 17:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8526b99b825 8003173: [macosx] Fullscreen on Mac leaves an empty rectangle Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java Changeset: 32721a1a8da8 Author: malenkov Date: 2013-01-24 17:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32721a1a8da8 8005138: test/java/beans/Introspector/TestTypeResolver.java fails Reviewed-by: alexsch ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 7cda96a78260 Author: malenkov Date: 2013-01-24 18:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cda96a78260 8003400: JTree scrolling problem when using large model in WindowsLookAndFeel Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003400/Test8003400.java Changeset: e616c28c5120 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e616c28c5120 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: a1a55db02f34 Author: lana Date: 2013-01-29 20:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1a55db02f34 Merge ! makefiles/CreateJars.gmk Changeset: 9d5c43050210 Author: dl Date: 2013-01-11 16:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d5c43050210 8006123: Support @Contended Annotation - JEP 142 (jdk part) Summary: jdk changes for 8003895. Reviewed-by: darcy, jrose, coleenp, dholmes, kvn Contributed-by: Aleksey Shipilev + src/share/classes/sun/misc/Contended.java Changeset: 739351a0a7a1 Author: kvn Date: 2013-01-23 11:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/739351a0a7a1 8006799: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() (jdk part of 6896617) Summary: Move hot loop in ISO_8859_1$Encode.encodeArrayLoop() into separate method encodeISOArray() to be replaced by JVM JIT compiler with optimized intrinsic code. Reviewed-by: alanb, sherman ! src/share/classes/sun/nio/cs/ISO_8859_1.java Changeset: e9d00d30fcca Author: amurillo Date: 2013-01-25 03:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9d00d30fcca Merge Changeset: ac286bf65242 Author: amurillo Date: 2013-01-30 10:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac286bf65242 Merge - 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: 3c499051a5df Author: erikj Date: 2013-01-29 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c499051a5df 8006873: SWAT-b74 msvcr100.dll does not have the permission for all Reviewed-by: alanb, tbell ! makefiles/CopyFiles.gmk Changeset: 4a67fdb752b7 Author: katleman Date: 2013-01-30 13:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a67fdb752b7 Merge ! makefiles/CopyFiles.gmk Changeset: 771551bc9e02 Author: lana Date: 2013-01-31 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771551bc9e02 Merge Changeset: e822b4d50a5b Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e822b4d50a5b Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java From Lance.Andersen at oracle.com Thu Jan 31 22:31:37 2013 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 31 Jan 2013 17:31:37 -0500 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: <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> +1 On Jan 31, 2013, at 5:15 PM, 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/ > > 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 mandy.chung at oracle.com Thu Jan 31 22:33:24 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 31 Jan 2013 22:33:24 +0000 Subject: hg: jdk8/tl/jdk: 6355704: (fmt) %f formatting of BigDecimals is incorrect Message-ID: <20130131223335.B07F14770A@hg.openjdk.java.net> Changeset: a09a37cff333 Author: mchung Date: 2013-01-31 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a09a37cff333 6355704: (fmt) %f formatting of BigDecimals is incorrect Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java From lowasser at google.com Thu Jan 31 22:46:34 2013 From: lowasser at google.com (Louis Wasserman) Date: Thu, 31 Jan 2013 14:46:34 -0800 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: <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> Message-ID: In what way is this "obviously" inappropriate? (I don't object, I just don't follow.) On Thu, Jan 31, 2013 at 2:31 PM, Lance Andersen - Oracle < Lance.Andersen at oracle.com> wrote: > +1 > On Jan 31, 2013, at 5:15 PM, 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/ > > > > Thanks > > -Sherman > > > > 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 > > > -- Louis Wasserman From xueming.shen at oracle.com Thu Jan 31 22:55:18 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 14:55:18 -0800 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> Message-ID: <510AF656.5040800@oracle.com> Because the error is not really triggered by an io operation when reading from the underlying input stream. Ideally it should be a more specific "InvalidedBase64EncodingException" exception in this kinda of situation (like we we do for the decoder/encoder in charset), but it is considered too heavy in Base64 class. Maybe the word "obviously" in my email is not appropriate, it may be more appropriate worded as "IAE is more appropriate than IOE for ...". -Sherman On 01/31/2013 02:46 PM, Louis Wasserman wrote: > In what way is this "obviously" inappropriate? (I don't object, I just don't follow.) > > > On Thu, Jan 31, 2013 at 2:31 PM, Lance Andersen - Oracle > wrote: > > +1 > On Jan 31, 2013, at 5:15 PM, 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/ > > > > Thanks > > -Sherman > > > > 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 > > > > > > -- > Louis Wasserman From xueming.shen at oracle.com Thu Jan 31 23:20:33 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 31 Jan 2013 15:20:33 -0800 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: <510AF656.5040800@oracle.com> References: <510AECEE.7060908@oracle.com> <0E058F43-187E-4AD0-B28C-815565584B72@oracle.com> <510AF656.5040800@oracle.com> Message-ID: <510AFC41.3000209@oracle.com> 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 On 01/31/2013 02:55 PM, Xueming Shen wrote: > > Because the error is not really triggered by an io operation when > reading from the underlying input stream. Ideally it should be a > more specific "InvalidedBase64EncodingException" exception in > this kinda of situation (like we we do for the decoder/encoder in > charset), but it is considered too heavy in Base64 class. Maybe > the word "obviously" in my email is not appropriate, it may be > more appropriate worded as "IAE is more appropriate than > IOE for ...". > > -Sherman > > > > On 01/31/2013 02:46 PM, Louis Wasserman wrote: >> In what way is this "obviously" inappropriate? (I don't object, I just don't follow.) >> >> >> On Thu, Jan 31, 2013 at 2:31 PM, Lance Andersen - Oracle > wrote: >> >> +1 >> On Jan 31, 2013, at 5:15 PM, 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/ >> > >> > Thanks >> > -Sherman >> >> >> >> 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 >> >> >> >> >> >> -- >> Louis Wasserman > From weijun.wang at oracle.com Thu Jan 31 23:39:59 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 31 Jan 2013 23:39:59 +0000 Subject: hg: jdk8/tl/jdk: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Message-ID: <20130131234019.DA1E547714@hg.openjdk.java.net> Changeset: d2495b9984fa Author: weijun Date: 2013-02-01 07:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d2495b9984fa 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Reviewed-by: alanb + test/sun/security/util/Oid/S11N.java - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java