From alexander.veit at gmx.net Mon Jan 4 15:15:19 2010 From: alexander.veit at gmx.net (Alexander Veit) Date: Mon, 4 Jan 2010 16:15:19 +0100 Subject: java.lang.String#contentEquals(CharSequence) suboptimal? Message-ID: Hi, it seems that if (cs.equals(this)) return true; should be replaced with if (cs instanceof String) return cs.equals(this); or completely left out. Does anyone agree? -- Cheers, Alex From serverperformance at gmail.com Mon Jan 4 16:42:35 2010 From: serverperformance at gmail.com (=?UTF-8?Q?Jes=C3=BAs_Vi=C3=B1uales?=) Date: Mon, 4 Jan 2010 17:42:35 +0100 Subject: java.lang.String#contentEquals(CharSequence) suboptimal? In-Reply-To: References: Message-ID: <008f01ca8d5c$ec2d2650$c48772f0$@com> Hi Alex, String.equals already performs that instanceof comparison, and is one of the first to be inlined by the hotspot. What I would do is to turn it... "this.equals(cs)" instead of "cs.equals(this)". Which would only improve performance if you have classes implementing CharSequence other than String, StringBuilder and StringBuffer... Anyway, does anyone know if the contentEquals method is actually used out there? (at least it isn't inside the JDK source code). Regards, --Jesus Alexander Veit wrote: > Hi, > > it seems that > > if (cs.equals(this)) > return true; > > should be replaced with > > if (cs instanceof String) > return cs.equals(this); > > or completely left out. > > Does anyone agree? > > -- > Cheers, > Alex From Ulf.Zibis at gmx.de Mon Jan 4 16:55:20 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 04 Jan 2010 17:55:20 +0100 Subject: java.lang.String#contentEquals(CharSequence) suboptimal? In-Reply-To: References: Message-ID: <4B421D78.10308@gmx.de> I agree, this would be a short cut in case of cs is not a String. In case of cs is a String, user likely would have used the standard equals() method to avoid the double check by instanceof. In case of HotSpot compilation AND inlining, there should be no difference. -Ulf Am 04.01.2010 16:15, Alexander Veit schrieb: > Hi, > > it seems that > > if (cs.equals(this)) > return true; > > should be replaced with > > if (cs instanceof String) > return cs.equals(this); > > or completely left out. > > Does anyone agree? > > From Ulf.Zibis at gmx.de Mon Jan 4 16:59:11 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 04 Jan 2010 17:59:11 +0100 Subject: java.lang.String#contentEquals(CharSequence) suboptimal? In-Reply-To: <008f01ca8d5c$ec2d2650$c48772f0$@com> References: <008f01ca8d5c$ec2d2650$c48772f0$@com> Message-ID: <4B421E5F.2030102@gmx.de> Am 04.01.2010 17:42, Jes?s Vi?uales schrieb: > Hi Alex, > > String.equals already performs that instanceof comparison, and is one of the first to be inlined by the hotspot. What I would do is to turn it... "this.equals(cs)" instead of "cs.equals(this)". > Why always waiting for HotSpot inlining to have Java fast? If not invoked so often, interpreter too should be fast as it can. -Ulf > Which would only improve performance if you have classes implementing CharSequence other than String, StringBuilder and StringBuffer... Anyway, does anyone know if the contentEquals method is actually used out there? (at least it isn't inside the JDK source code). > > Regards, > --Jesus > > > Alexander Veit wrote: > >> Hi, >> >> it seems that >> >> if (cs.equals(this)) >> return true; >> >> should be replaced with >> >> if (cs instanceof String) >> return cs.equals(this); >> >> or completely left out. >> >> Does anyone agree? >> >> -- >> Cheers, >> Alex >> > > > From alexander.veit at gmx.net Mon Jan 4 17:08:04 2010 From: alexander.veit at gmx.net (Alexander Veit) Date: Mon, 4 Jan 2010 18:08:04 +0100 Subject: java.lang.String#contentEquals(CharSequence) suboptimal? In-Reply-To: <008e01ca8d5c$bdc7dc60$39579520$@com> References: <008e01ca8d5c$bdc7dc60$39579520$@com> Message-ID: <98713FC8CFEE476CA6D6EF2D0CEADC67@helium> Hi Jes?s, > String.equals already performs that instanceof comparison, > and is one of the first to be inlined by the hotspot. What I > would do is to turn it... "this.equals(cs)" instead of > "cs.equals(this)". That's true, but given cs is a String with length equal to this, cs.equals(this) nevertheless may return false, and if (cs.equals(this)) return true; will not return. The remaining code performs the comparison a second time in this case. > [...] > Anyway, does anyone know if the > contentEquals method is actually used out there? (at least it > isn't inside the JDK source code). I use it ;-) It is useful to prevent from duplicate memory allocation in quite some cases. -- Cheers, Alex From serverperformance at gmail.com Mon Jan 4 17:20:48 2010 From: serverperformance at gmail.com (=?UTF-8?Q?Jes=C3=BAs_Vi=C3=B1uales?=) Date: Mon, 4 Jan 2010 18:20:48 +0100 Subject: java.lang.String#contentEquals(CharSequence) suboptimal? In-Reply-To: <98713FC8CFEE476CA6D6EF2D0CEADC67@helium> References: <008e01ca8d5c$bdc7dc60$39579520$@com> <98713FC8CFEE476CA6D6EF2D0CEADC67@helium> Message-ID: <00a701ca8d62$43dcb690$cb9623b0$@com> > That's true, but given cs is a String with length equal to this, > cs.equals(this) nevertheless may return false, and > > if (cs.equals(this)) > return true; > > will not return. The remaining code performs the comparison a second > time in this case. Oh, now I see it - you are absolutely right :-) From weijun.wang at sun.com Tue Jan 5 02:43:30 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 05 Jan 2010 02:43:30 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100105024356.518AB422D7@hg.openjdk.java.net> Changeset: ef9774dc4f5a Author: weijun Date: 2010-01-05 10:40 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ef9774dc4f5a 6895424: RFC 5653 Reviewed-by: valeriep ! src/share/classes/org/ietf/jgss/GSSName.java ! src/share/classes/sun/security/jgss/GSSManagerImpl.java ! src/share/classes/sun/security/jgss/GSSNameImpl.java ! src/share/classes/sun/security/jgss/GSSUtil.java ! src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java + test/sun/security/krb5/auto/Test5653.java Changeset: c028d78fa438 Author: weijun Date: 2010-01-05 10:40 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c028d78fa438 6913636: kvno check in JSSE Reviewed-by: valeriep ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java From kelly.ohair at sun.com Tue Jan 5 21:44:27 2010 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 05 Jan 2010 21:44:27 +0000 Subject: hg: jdk7/tl/jdk: 10 new changesets Message-ID: <20100105214650.D5D7B42414@hg.openjdk.java.net> Changeset: 7e116fd3a724 Author: ohair Date: 2010-01-04 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e116fd3a724 6910834: TEST: java/io/File/Basic.java fails on Windows CYGWIN environment Reviewed-by: tbell, alanb ! test/java/io/File/Basic.java ! test/java/io/File/basic.sh Changeset: ad19f61a0fa6 Author: ohair Date: 2010-01-04 15:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ad19f61a0fa6 6910835: TESTS: 3 java/io run.sh tests fail when run on Windows XP CYGWIN Reviewed-by: tbell, alanb ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh Changeset: f9aa7e58974d Author: ohair Date: 2010-01-04 15:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9aa7e58974d 6911113: These tests do not work with CYGWIN: java/nio Reviewed-by: tbell, alanb ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/file/Files/walk_file_tree.sh ! test/java/nio/file/Path/delete_on_close.sh Changeset: 7595c6a198d3 Author: ohair Date: 2010-01-04 15:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7595c6a198d3 6911117: These tests do not work with CYGWIN: com/sun/jdi Reviewed-by: tbell, alanb ! test/com/sun/jdi/ProcessAttachTest.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh Changeset: caf27afcae8d Author: ohair Date: 2010-01-04 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/caf27afcae8d 6911131: Test does not work with CYGWIN: sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh Reviewed-by: tbell, alanb ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh Changeset: f86db0646421 Author: ohair Date: 2010-01-04 15:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f86db0646421 6911112: Tests do not work with CYGWIN: javax/imageio/, javax/script/, and sun/misc/ Reviewed-by: tbell, alanb ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/script/CommonSetup.sh ! test/javax/script/ProviderTest.sh ! test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: 07fdd926aaea Author: ohair Date: 2010-01-04 15:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07fdd926aaea 6911129: These tests do not work with CYGWIN: java/lang Reviewed-by: tbell, alanb ! test/java/beans/Introspector/Test5102804.java ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/finalization/FinExit.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh Changeset: 1d6f315e42f1 Author: ohair Date: 2010-01-04 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1d6f315e42f1 6911108: These tests do not work with CYGWIN: java/util Reviewed-by: tbell, alanb ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/ExpirationTest.sh ! test/java/util/ServiceLoader/basic.sh Changeset: 6f2a5912f5be Author: ohair Date: 2010-01-04 15:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f2a5912f5be 6911104: Tests do not work with CYGWIN: tools, sun/tools, and com/sun/tools Reviewed-by: tbell, alanb ! test/com/sun/tools/attach/ApplicationSetup.sh ! test/com/sun/tools/attach/BasicTests.sh ! test/com/sun/tools/attach/CommonSetup.sh ! test/com/sun/tools/attach/PermissionTests.sh ! test/com/sun/tools/attach/ProviderTests.sh ! test/sun/jvmstat/testlibrary/utils.sh ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/common/CommonSetup.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatOptions1.sh ! test/sun/tools/jstatd/jstatdUsage1.sh ! test/sun/tools/native2ascii/Native2AsciiTests.sh ! test/tools/launcher/ChangeDataModel.sh ! test/tools/launcher/ClassPathWildCard.sh ! test/tools/launcher/DefaultLocaleTest.sh ! test/tools/launcher/UnicodeTest.sh Changeset: b7cf91e43c67 Author: ohair Date: 2010-01-05 13:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b7cf91e43c67 Merge From jonathan.gibbons at sun.com Wed Jan 6 21:11:53 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 06 Jan 2010 21:11:53 +0000 Subject: hg: jdk7/tl/langtools: 6307206: missing lint control for pkg-info Message-ID: <20100106211159.37EB342595@hg.openjdk.java.net> Changeset: 0220a3ab1a40 Author: jjg Date: 2010-01-06 13:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0220a3ab1a40 6307206: missing lint control for pkg-info Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/resources/compiler.properties From jonathan.gibbons at sun.com Wed Jan 6 21:17:40 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Wed, 06 Jan 2010 21:17:40 +0000 Subject: hg: jdk7/tl/langtools: 6855236: Compiler Tree API TreePath class generates NullPointerException from Iterator Message-ID: <20100106211742.0860D42599@hg.openjdk.java.net> Changeset: d4e0ae9b4ecb Author: jjg Date: 2010-01-06 13:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d4e0ae9b4ecb 6855236: Compiler Tree API TreePath class generates NullPointerException from Iterator Reviewed-by: darcy + test/tools/javac/T6855236.java From ravenex at qq.com Thu Jan 7 03:40:17 2010 From: ravenex at qq.com (=?ISO-8859-1?B?cmF2ZW5leA==?=) Date: Thu, 7 Jan 2010 11:40:17 +0800 Subject: question on class loading behavior on array classes Message-ID: Hi all, I asked the question on jdk6-dev list, and Joe Darcy said here's a better place to ask, so here I go. According the the JVM spec, 2nd edition, 5.3.3 Creating Array Classes, both the bootstrap class loader and user-defined class loaders can load array classes, and the corresponding class loaders involved are recorded as initiating class loaders. But starting from JDK 6, Sun's JDK by default doesn't allow array syntax in ClassLoader.loadClass()/ClassLoader.findSystemClass(); array classes couldn't be created by calling defineClass() anyway, so this effectively bans user-defined class loaders to be initiating class loaders for array classes. Calling Class.forName(className, initialize, classLoader) won't record classLoader as an initiating class loader for an array class either. Is this an intended behavior? I'm expecting a call to Class.forName() would mark the loader as an initiating one, for all classes (including array classes). That way I won't have to keep a cache of my own in my custom class loader to keep track of what's been loaded already. I read Bug 6500212 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212) and know that I shouldn't call ClassLoader.loadClass() with array syntax, so I switched to Class.forName(). But then when my class loader is asked to load the same array class again, it calls findLoadedClass() and gets a null back. That's pretty bad because I don't won't to get down to SystemDictionary::resolve_array_class_or_null() every time I load an array class. That'll force me to use my own cache to record just about the same info as what the VM already has, plus the array classes loaded, which looks like a bad smell to me. And, is it possible for future JDK releases to include more "default operations" in the reflection API? I mean, something like .NET's Binder (http://msdn.microsoft.com/en-us/library/system.reflection.binder.aspx ), or just increasing overloads of Class.getMethod()/getMethods() would be great. The project I'm working on requires lots of reflective calls, some of which only the receiver type, the target methods name, the number of arguments, and the exact type of each argument (not parameter) is known; overload resolution would have to be done at runtime, where I need to find a best matching overload to invoke. In .NET, a default Binder provided by the Base Class Library (fetched via System.Type.DefaultBinder property), and it'll do the overload resolution for users. I guess it might be more efficient to implement this kind of feature in the core library, and I wonder what you guys think. My scenario here is pretty much something like what Fredrik Ohrstrom's proposed version of MethodHandle's generic invocation support implements, and if that kind of binding feature exists in the VM already, exposing it in public API for general consumption should be easy, I suppose. Greetings, Raven From mandy.chung at sun.com Thu Jan 7 16:15:59 2010 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 07 Jan 2010 16:15:59 +0000 Subject: hg: jdk7/tl/jdk: 6911737: Module build: generate modules with native libraries and any other files not in jar Message-ID: <20100107161644.9D5CE426CC@hg.openjdk.java.net> Changeset: d30f2e22fffd Author: mchung Date: 2010-01-07 08:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d30f2e22fffd 6911737: Module build: generate modules with native libraries and any other files not in jar Summary: create modules under OUTPUTDIR/modules directory containing resources, native libraries Reviewed-by: alanb, ohair ! make/com/sun/crypto/provider/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/java/pack/prop/Makefile ! make/com/sun/jndi/cosnaming/Makefile ! make/com/sun/jndi/dns/Makefile ! make/com/sun/jndi/ldap/Makefile ! make/com/sun/jndi/rmi/registry/Makefile ! make/com/sun/nio/sctp/Makefile ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/com/sun/script/Makefile ! make/com/sun/security/auth/module/Makefile ! make/com/sun/servicetag/Makefile ! make/com/sun/tools/attach/Makefile ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/internal/BinaryPlugs.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Sanity.gmk ! make/java/awt/Makefile ! make/java/fdlibm/Makefile ! make/java/hpi/native/Makefile ! make/java/hpi/windows/Makefile ! make/java/instrument/Makefile ! make/java/java/Makefile ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/jvm/Makefile ! make/java/logging/Makefile ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/management/Makefile ! make/java/net/Makefile ! make/java/nio/Makefile ! make/java/npt/Makefile - make/java/redist/FILES.gmk ! make/java/redist/Makefile + make/java/redist/fonts/Makefile + make/java/redist/sajdi/Makefile ! make/java/security/Makefile ! make/java/sql/Makefile ! make/java/text/Makefile ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/javax/crypto/Makefile ! make/javax/imageio/Makefile ! make/javax/print/Makefile ! make/javax/sound/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/javax/sound/jsoundds/Makefile ! make/javax/sql/Makefile ! make/javax/swing/Makefile ! make/javax/swing/plaf/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jpda/tty/Makefile ! make/launchers/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/management/Makefile ! make/mksample/dtrace/Makefile ! make/mksample/jmx/jmx-scandir/Makefile ! make/mksample/nbproject/Makefile ! make/mksample/nio/file/Makefile ! make/mksample/nio/multicast/Makefile ! make/mksample/nio/server/Makefile ! make/mksample/scripting/scriptpad/Makefile ! make/mksample/webservices/EbayClient/Makefile ! make/mksample/webservices/EbayServer/Makefile ! make/modules/Makefile ! make/modules/modules.config ! make/modules/tools/nbproject/project.xml ! make/modules/tools/src/com/sun/classanalyzer/Module.java ! make/sun/applet/Makefile ! make/sun/awt/Makefile ! make/sun/cmm/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/cmm/lcms/Makefile ! make/sun/dcpr/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jdga/Makefile ! make/sun/jkernel/Makefile ! make/sun/jpeg/Makefile ! make/sun/launcher/Makefile ! make/sun/management/Makefile ! make/sun/native2ascii/Makefile ! make/sun/net/others/Makefile ! make/sun/net/spi/nameservice/dns/Makefile - make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/sun/nio/cs/FILES_java.gmk + make/sun/nio/cs/Makefile ! make/sun/org/mozilla/javascript/Makefile ! make/sun/pisces/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/security/tools/Makefile ! make/sun/serialver/Makefile ! make/sun/splashscreen/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/xawt/Makefile From Joe.Darcy at Sun.COM Fri Jan 8 02:41:42 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 07 Jan 2010 18:41:42 -0800 Subject: Code review request for checked/unchecked exception clarifications Message-ID: <4B469B66.5050000@sun.com> Hello. Please review the patch below to clarify which throwables are regarded as checked and unchecked exceptions. Thanks, -Joe --- old/src/share/classes/java/lang/Error.java 2010-01-07 18:35:40.000000000 -0800 +++ new/src/share/classes/java/lang/Error.java 2010-01-07 18:35:40.000000000 -0800 @@ -26,27 +26,31 @@ package java.lang; /** - * An Error is a subclass of Throwable + * An {@code Error} is a subclass of {@code Throwable} * that indicates serious problems that a reasonable application * should not try to catch. Most such errors are abnormal conditions. - * The ThreadDeath error, though a "normal" condition, - * is also a subclass of Error because most applications + * The {@code ThreadDeath} error, though a "normal" condition, + * is also a subclass of {@code Error} because most applications * should not try to catch it. *

- * A method is not required to declare in its throws - * clause any subclasses of Error that might be thrown + * A method is not required to declare in its {@code throws} + * clause any subclasses of {@code Error} that might be thrown * during the execution of the method but not caught, since these * errors are abnormal conditions that should never occur. * + * That is, {@code Error} and its subclasses are regarded as unchecked + * exceptions for the purposes of compile-time checking of exceptions. + * * @author Frank Yellin * @see java.lang.ThreadDeath + * @jls3 11.2 Compile-Time Checking of Exceptions * @since JDK1.0 */ public class Error extends Throwable { static final long serialVersionUID = 4980196508277280342L; /** - * Constructs a new error with null as its detail message. + * Constructs a new error with {@code null} as its detail message. * The cause is not initialized, and may subsequently be initialized by a * call to {@link #initCause}. */ @@ -69,7 +73,7 @@ /** * Constructs a new error with the specified detail message and * cause.

Note that the detail message associated with - * cause is not automatically incorporated in + * {@code cause} is not automatically incorporated in * this error's detail message. * * @param message the detail message (which is saved for later retrieval --- old/src/share/classes/java/lang/Exception.java 2010-01-07 18:35:41.000000000 -0800 +++ new/src/share/classes/java/lang/Exception.java 2010-01-07 18:35:41.000000000 -0800 @@ -26,19 +26,27 @@ package java.lang; /** - * The class Exception and its subclasses are a form of - * Throwable that indicates conditions that a reasonable + * The class {@code Exception} and its subclasses are a form of + * {@code Throwable} that indicates conditions that a reasonable * application might want to catch. * + *

The class {@code Exception} and any subclasses that are not also + * subclasses of {@link RuntimeException} are checked + * exceptions. Checked exceptions need to be declared in a + * method or constructor's {@code throws} clause if they can be thrown + * by the execution of the method or constructor and propagate outside + * the method or constructor boundary. + * * @author Frank Yellin * @see java.lang.Error + * @jls3 11.2 Compile-Time Checking of Exceptions * @since JDK1.0 */ public class Exception extends Throwable { static final long serialVersionUID = -3387516993124229948L; /** - * Constructs a new exception with null as its detail message. + * Constructs a new exception with {@code null} as its detail message. * The cause is not initialized, and may subsequently be initialized by a * call to {@link #initCause}. */ @@ -61,7 +69,7 @@ /** * Constructs a new exception with the specified detail message and * cause.

Note that the detail message associated with - * cause is not automatically incorporated in + * {@code cause} is not automatically incorporated in * this exception's detail message. * * @param message the detail message (which is saved for later retrieval --- old/src/share/classes/java/lang/RuntimeException.java 2010-01-07 18:35:42.000000000 -0800 +++ new/src/share/classes/java/lang/RuntimeException.java 2010-01-07 18:35:42.000000000 -0800 @@ -26,22 +26,24 @@ package java.lang; /** - * RuntimeException is the superclass of those + * {@code RuntimeException} is the superclass of those * exceptions that can be thrown during the normal operation of the * Java Virtual Machine. - *

- * A method is not required to declare in its throws - * clause any subclasses of RuntimeException that might - * be thrown during the execution of the method but not caught. * + *

{@code RuntimeException} and its subclasses are unchecked + * exceptions. Unchecked exceptions do not need to be + * declared in a method or constructor's {@code throws} clause if they + * can be thrown by the execution of the method or constructor and + * propagate outside the method or constructor boundary. * * @author Frank Yellin + * @jls3 11.2 Compile-Time Checking of Exceptions * @since JDK1.0 */ public class RuntimeException extends Exception { static final long serialVersionUID = -7034897190745766939L; - /** Constructs a new runtime exception with null as its + /** Constructs a new runtime exception with {@code null} as its * detail message. The cause is not initialized, and may subsequently be * initialized by a call to {@link #initCause}. */ @@ -63,7 +65,7 @@ /** * Constructs a new runtime exception with the specified detail message and * cause.

Note that the detail message associated with - * cause is not automatically incorporated in + * {@code cause} is not automatically incorporated in * this runtime exception's detail message. * * @param message the detail message (which is saved for later retrieval --- old/src/share/classes/java/lang/Throwable.java 2010-01-07 18:35:43.000000000 -0800 +++ new/src/share/classes/java/lang/Throwable.java 2010-01-07 18:35:43.000000000 -0800 @@ -34,6 +34,11 @@ * this class or one of its subclasses can be the argument type in a * catch clause. * + * For the purposes of compile-time checking of exceptions, {@code + * Throwable} and any subclass of {@code Throwable} that is not also a + * subclass of either {@link RuntimeException} or {@link Error} are + * regarded as checked exceptions. + * *

Instances of two subclasses, {@link java.lang.Error} and * {@link java.lang.Exception}, are conventionally used to indicate * that exceptional situations have occurred. Typically, these instances @@ -142,6 +147,7 @@ * @author unascribed * @author Josh Bloch (Added exception chaining and programmatic access to * stack trace in 1.4.) + * @jls3 11.2 Compile-Time Checking of Exceptions * @since JDK1.0 */ public class Throwable implements Serializable { From David.Holmes at Sun.COM Fri Jan 8 03:09:29 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 08 Jan 2010 13:09:29 +1000 Subject: Code review request for checked/unchecked exception clarifications In-Reply-To: <4B469B66.5050000@sun.com> References: <4B469B66.5050000@sun.com> Message-ID: <4B46A1E9.7060907@sun.com> Hi Joe, This looks fine to me. One minor consistency nit, sometimes you refer to "subclasses of" and sometimes "subclass of" eg: + *

The class {@code Exception} and any subclasses that are not also + * subclasses of {@link RuntimeException} are checked + * exceptions. + * For the purposes of compile-time checking of exceptions, {@code + * Throwable} and any subclass of {@code Throwable} that is not also a + * subclass of either {@link RuntimeException} or {@link Error} are + * regarded as checked exceptions. For consistency you could use the same wording for Exception as you do for Throwable. Cheers, David Joe Darcy said the following on 01/08/10 12:41: > Hello. > > Please review the patch below to clarify which throwables are regarded > as checked and unchecked exceptions. > > Thanks, > > -Joe > > --- old/src/share/classes/java/lang/Error.java 2010-01-07 > 18:35:40.000000000 -0800 > +++ new/src/share/classes/java/lang/Error.java 2010-01-07 > 18:35:40.000000000 -0800 > @@ -26,27 +26,31 @@ > package java.lang; > > /** > - * An Error is a subclass of Throwable > + * An {@code Error} is a subclass of {@code Throwable} > * that indicates serious problems that a reasonable application > * should not try to catch. Most such errors are abnormal conditions. > - * The ThreadDeath error, though a "normal" condition, > - * is also a subclass of Error because most applications > + * The {@code ThreadDeath} error, though a "normal" condition, > + * is also a subclass of {@code Error} because most applications > * should not try to catch it. > *

> - * A method is not required to declare in its throws > - * clause any subclasses of Error that might be thrown > + * A method is not required to declare in its {@code throws} > + * clause any subclasses of {@code Error} that might be thrown > * during the execution of the method but not caught, since these > * errors are abnormal conditions that should never occur. > * > + * That is, {@code Error} and its subclasses are regarded as unchecked > + * exceptions for the purposes of compile-time checking of exceptions. > + * > * @author Frank Yellin > * @see java.lang.ThreadDeath > + * @jls3 11.2 Compile-Time Checking of Exceptions > * @since JDK1.0 > */ > public class Error extends Throwable { > static final long serialVersionUID = 4980196508277280342L; > > /** > - * Constructs a new error with null as its detail > message. > + * Constructs a new error with {@code null} as its detail message. > * The cause is not initialized, and may subsequently be initialized > by a > * call to {@link #initCause}. > */ > @@ -69,7 +73,7 @@ > /** > * Constructs a new error with the specified detail message and > * cause.

Note that the detail message associated with > - * cause is not automatically incorporated in > + * {@code cause} is not automatically incorporated in > * this error's detail message. > * > * @param message the detail message (which is saved for later > retrieval > --- old/src/share/classes/java/lang/Exception.java 2010-01-07 > 18:35:41.000000000 -0800 > +++ new/src/share/classes/java/lang/Exception.java 2010-01-07 > 18:35:41.000000000 -0800 > @@ -26,19 +26,27 @@ > package java.lang; > > /** > - * The class Exception and its subclasses are a form of > - * Throwable that indicates conditions that a reasonable > + * The class {@code Exception} and its subclasses are a form of > + * {@code Throwable} that indicates conditions that a reasonable > * application might want to catch. > * > + *

The class {@code Exception} and any subclasses that are not also > + * subclasses of {@link RuntimeException} are checked > + * exceptions. Checked exceptions need to be declared in a > + * method or constructor's {@code throws} clause if they can be thrown > + * by the execution of the method or constructor and propagate outside > + * the method or constructor boundary. > + * > * @author Frank Yellin > * @see java.lang.Error > + * @jls3 11.2 Compile-Time Checking of Exceptions > * @since JDK1.0 > */ > public class Exception extends Throwable { > static final long serialVersionUID = -3387516993124229948L; > > /** > - * Constructs a new exception with null as its detail > message. > + * Constructs a new exception with {@code null} as its detail message. > * The cause is not initialized, and may subsequently be initialized > by a > * call to {@link #initCause}. > */ > @@ -61,7 +69,7 @@ > /** > * Constructs a new exception with the specified detail message and > * cause.

Note that the detail message associated with > - * cause is not automatically incorporated in > + * {@code cause} is not automatically incorporated in > * this exception's detail message. > * > * @param message the detail message (which is saved for later > retrieval > --- old/src/share/classes/java/lang/RuntimeException.java 2010-01-07 > 18:35:42.000000000 -0800 > +++ new/src/share/classes/java/lang/RuntimeException.java 2010-01-07 > 18:35:42.000000000 -0800 > @@ -26,22 +26,24 @@ > package java.lang; > > /** > - * RuntimeException is the superclass of those > + * {@code RuntimeException} is the superclass of those > * exceptions that can be thrown during the normal operation of the > * Java Virtual Machine. > - *

> - * A method is not required to declare in its throws > - * clause any subclasses of RuntimeException that might > - * be thrown during the execution of the method but not caught. > * > + *

{@code RuntimeException} and its subclasses are unchecked > + * exceptions. Unchecked exceptions do not need to be > + * declared in a method or constructor's {@code throws} clause if they > + * can be thrown by the execution of the method or constructor and > + * propagate outside the method or constructor boundary. > * > * @author Frank Yellin > + * @jls3 11.2 Compile-Time Checking of Exceptions > * @since JDK1.0 > */ > public class RuntimeException extends Exception { > static final long serialVersionUID = -7034897190745766939L; > > - /** Constructs a new runtime exception with null as its > + /** Constructs a new runtime exception with {@code null} as its > * detail message. The cause is not initialized, and may > subsequently be > * initialized by a call to {@link #initCause}. > */ > @@ -63,7 +65,7 @@ > /** > * Constructs a new runtime exception with the specified detail > message and > * cause.

Note that the detail message associated with > - * cause is not automatically incorporated in > + * {@code cause} is not automatically incorporated in > * this runtime exception's detail message. > * > * @param message the detail message (which is saved for later > retrieval > --- old/src/share/classes/java/lang/Throwable.java 2010-01-07 > 18:35:43.000000000 -0800 > +++ new/src/share/classes/java/lang/Throwable.java 2010-01-07 > 18:35:43.000000000 -0800 > @@ -34,6 +34,11 @@ > * this class or one of its subclasses can be the argument type in a > * catch clause. > * > + * For the purposes of compile-time checking of exceptions, {@code > + * Throwable} and any subclass of {@code Throwable} that is not also a > + * subclass of either {@link RuntimeException} or {@link Error} are > + * regarded as checked exceptions. > + * > *

Instances of two subclasses, {@link java.lang.Error} and > * {@link java.lang.Exception}, are conventionally used to indicate > * that exceptional situations have occurred. Typically, these instances > @@ -142,6 +147,7 @@ > * @author unascribed > * @author Josh Bloch (Added exception chaining and programmatic access to > * stack trace in 1.4.) > + * @jls3 11.2 Compile-Time Checking of Exceptions > * @since JDK1.0 > */ > public class Throwable implements Serializable { From Joe.Darcy at Sun.COM Fri Jan 8 03:36:54 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 07 Jan 2010 19:36:54 -0800 Subject: Code review request for checked/unchecked exception clarifications In-Reply-To: <4B46A1E9.7060907@sun.com> References: <4B469B66.5050000@sun.com> <4B46A1E9.7060907@sun.com> Message-ID: <4B46A856.30005@sun.com> David Holmes - Sun Microsystems wrote: > Hi Joe, > > This looks fine to me. > > One minor consistency nit, sometimes you refer to "subclasses of" and > sometimes "subclass of" eg: > > + *

The class {@code Exception} and any subclasses that are not also > + * subclasses of {@link RuntimeException} are checked > + * exceptions. > > + * For the purposes of compile-time checking of exceptions, {@code > + * Throwable} and any subclass of {@code Throwable} that is not also a > + * subclass of either {@link RuntimeException} or {@link Error} are > + * regarded as checked exceptions. > > For consistency you could use the same wording for Exception as you do > for Throwable. Hi David. That difference you spotted was intentional in this case. The "subclasses" wording is closer to the wording in JLSv3 section 11, but I thought "subclass" was clearer to state the "RuntimeException or Error" constraint Thanks for the review, -Joe From joe.darcy at sun.com Fri Jan 8 03:34:45 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 08 Jan 2010 03:34:45 +0000 Subject: hg: jdk7/tl/jdk: 6915171: Clarify checked/unchecked status of Throwable and its subclasses Message-ID: <20100108033511.09D8942785@hg.openjdk.java.net> Changeset: d36fa10de3cb Author: darcy Date: 2010-01-07 19:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d36fa10de3cb 6915171: Clarify checked/unchecked status of Throwable and its subclasses Reviewed-by: dholmes ! src/share/classes/java/lang/Error.java ! src/share/classes/java/lang/Exception.java ! src/share/classes/java/lang/RuntimeException.java ! src/share/classes/java/lang/Throwable.java From pcj at roundroom.net Fri Jan 8 05:00:04 2010 From: pcj at roundroom.net (Peter Jones) Date: Fri, 8 Jan 2010 00:00:04 -0500 Subject: Code review request for checked/unchecked exception clarifications In-Reply-To: <4B46A856.30005@sun.com> References: <4B469B66.5050000@sun.com> <4B46A1E9.7060907@sun.com> <4B46A856.30005@sun.com> Message-ID: Joe, Hi. Another nit: the wordings below seem to imply that "new Error()" and "new RuntimeException()" (i.e. not subclasses) make checked exceptions, but of course they are unchecked too. Cheers, -- Peter On Jan 7, 2010, at 10:36 PM, Joe Darcy wrote: > David Holmes - Sun Microsystems wrote: >> Hi Joe, >> >> This looks fine to me. >> >> One minor consistency nit, sometimes you refer to "subclasses of" and sometimes "subclass of" eg: >> >> + *

The class {@code Exception} and any subclasses that are not also >> + * subclasses of {@link RuntimeException} are checked >> + * exceptions. >> >> + * For the purposes of compile-time checking of exceptions, {@code >> + * Throwable} and any subclass of {@code Throwable} that is not also a >> + * subclass of either {@link RuntimeException} or {@link Error} are >> + * regarded as checked exceptions. >> >> For consistency you could use the same wording for Exception as you do for Throwable. > > Hi David. > > That difference you spotted was intentional in this case. The "subclasses" wording is closer to the wording in JLSv3 section 11, but I thought "subclass" was clearer to state the "RuntimeException or Error" constraint > > Thanks for the review, > > -Joe From David.Holmes at Sun.COM Fri Jan 8 05:16:49 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 08 Jan 2010 15:16:49 +1000 Subject: Code review request for checked/unchecked exception clarifications In-Reply-To: References: <4B469B66.5050000@sun.com> <4B46A1E9.7060907@sun.com> <4B46A856.30005@sun.com> Message-ID: <4B46BFC1.7010305@sun.com> Hi Peter, Peter Jones said the following on 01/08/10 15:00: > Hi. Another nit: the wordings below seem to imply that "new Error()" and "new RuntimeException()" (i.e. not subclasses) make checked exceptions, but of course they are unchecked too. What wording do you think implies this? These are quite clear: + * That is, {@code Error} and its subclasses are regarded as unchecked + * exceptions for the purposes of compile-time checking of exceptions. + *

{@code RuntimeException} and its subclasses are unchecked + * exceptions. David > Cheers, > -- Peter > > > On Jan 7, 2010, at 10:36 PM, Joe Darcy wrote: > >> David Holmes - Sun Microsystems wrote: >>> Hi Joe, >>> >>> This looks fine to me. >>> >>> One minor consistency nit, sometimes you refer to "subclasses of" and sometimes "subclass of" eg: >>> >>> + *

The class {@code Exception} and any subclasses that are not also >>> + * subclasses of {@link RuntimeException} are checked >>> + * exceptions. >>> >>> + * For the purposes of compile-time checking of exceptions, {@code >>> + * Throwable} and any subclass of {@code Throwable} that is not also a >>> + * subclass of either {@link RuntimeException} or {@link Error} are >>> + * regarded as checked exceptions. >>> >>> For consistency you could use the same wording for Exception as you do for Throwable. >> Hi David. >> >> That difference you spotted was intentional in this case. The "subclasses" wording is closer to the wording in JLSv3 section 11, but I thought "subclass" was clearer to state the "RuntimeException or Error" constraint >> >> Thanks for the review, >> >> -Joe > From pcj at roundroom.net Fri Jan 8 05:44:08 2010 From: pcj at roundroom.net (Peter Jones) Date: Fri, 8 Jan 2010 00:44:08 -0500 Subject: Code review request for checked/unchecked exception clarifications In-Reply-To: <4B46BFC1.7010305@sun.com> References: <4B469B66.5050000@sun.com> <4B46A1E9.7060907@sun.com> <4B46A856.30005@sun.com> <4B46BFC1.7010305@sun.com> Message-ID: Hi David, On Jan 8, 2010, at 12:16 AM, David Holmes - Sun Microsystems wrote: > Peter Jones said the following on 01/08/10 15:00: >> Hi. Another nit: the wordings below seem to imply that "new Error()" and "new RuntimeException()" (i.e. not subclasses) make checked exceptions, but of course they are unchecked too. > > What wording do you think implies this? > > These are quite clear: > > + * That is, {@code Error} and its subclasses are regarded as unchecked > + * exceptions for the purposes of compile-time checking of exceptions. > > + *

{@code RuntimeException} and its subclasses are unchecked > + * exceptions. Yes, those seem fine-- I was referring to the excerpts that you had quoted earlier, from the Exception and Throwable docs: >>>> + *

The class {@code Exception} and any subclasses that are not also >>>> + * subclasses of {@link RuntimeException} are checked >>>> + * exceptions. >>>> >>>> + * For the purposes of compile-time checking of exceptions, {@code >>>> + * Throwable} and any subclass of {@code Throwable} that is not also a >>>> + * subclass of either {@link RuntimeException} or {@link Error} are >>>> + * regarded as checked exceptions. In JLS usage I don't think that subclass is a reflexive relation (like subtype is). Compare the section 11.2 wording, "RuntimeException and its subclasses", etc.: http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#44121 Cheers, -- Peter From David.Holmes at Sun.COM Fri Jan 8 06:42:54 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 08 Jan 2010 16:42:54 +1000 Subject: Code review request for checked/unchecked exception clarifications In-Reply-To: References: <4B469B66.5050000@sun.com> <4B46A1E9.7060907@sun.com> <4B46A856.30005@sun.com> <4B46BFC1.7010305@sun.com> Message-ID: <4B46D3EE.6020701@sun.com> Peter Jones said the following on 01/08/10 15:44: > On Jan 8, 2010, at 12:16 AM, David Holmes - Sun Microsystems wrote: >> Peter Jones said the following on 01/08/10 15:00: >>> Hi. Another nit: the wordings below seem to imply that "new Error()" and "new RuntimeException()" (i.e. not subclasses) make checked exceptions, but of course they are unchecked too. >> What wording do you think implies this? >> >> These are quite clear: >> >> + * That is, {@code Error} and its subclasses are regarded as unchecked >> + * exceptions for the purposes of compile-time checking of exceptions. >> >> + *

{@code RuntimeException} and its subclasses are unchecked >> + * exceptions. > > Yes, those seem fine-- I was referring to the excerpts that you had quoted earlier, from the Exception and Throwable docs: > >>>>> + *

The class {@code Exception} and any subclasses that are not also >>>>> + * subclasses of {@link RuntimeException} are checked >>>>> + * exceptions. >>>>> >>>>> + * For the purposes of compile-time checking of exceptions, {@code >>>>> + * Throwable} and any subclass of {@code Throwable} that is not also a >>>>> + * subclass of either {@link RuntimeException} or {@link Error} are >>>>> + * regarded as checked exceptions. > > In JLS usage I don't think that subclass is a reflexive relation (like subtype is). Compare the section 11.2 wording, "RuntimeException and its subclasses", etc.: > > http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#44121 Ah I see. Yes in isolation those sentences do seem to exclude Error and RuntimeException themselves. David From pcj at roundroom.net Fri Jan 8 07:24:08 2010 From: pcj at roundroom.net (Peter Jones) Date: Fri, 8 Jan 2010 02:24:08 -0500 Subject: question on class loading behavior on array classes In-Reply-To: References: Message-ID: On Jan 6, 2010, at 10:40 PM, ravenex wrote: > According the the JVM spec, 2nd edition, 5.3.3 Creating Array Classes, > both the bootstrap class loader and user-defined class loaders can > load array classes, and the corresponding class loaders involved are > recorded as initiating class loaders. > > But starting from JDK 6, Sun's JDK by default doesn't allow array > syntax in ClassLoader.loadClass()/ClassLoader.findSystemClass(); array > classes couldn't be created by calling defineClass() anyway, Yes. > so this > effectively bans user-defined class loaders to be initiating class > loaders for array classes. I don't understand that conclusion. Class.forName and resolution of symbolic references for array classes should have that effect (even though the user-defined initiating loader isn't invoked for the array class). > Calling Class.forName(className, > initialize, classLoader) won't record classLoader as an initiating > class loader for an array class either. What exactly leads you to believe that? > I'm expecting a call to Class.forName() would mark the loader as an > initiating one, for all classes (including array classes). That way I > won't have to keep a cache of my own in my custom class loader to keep > track of what's been loaded already. I read Bug 6500212 > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6500212) and know > that I shouldn't call ClassLoader.loadClass() with array syntax, so I > switched to Class.forName(). But then when my class loader is asked to > load the same array class again, I'm confused: if you're not invoking ClassLoader.loadClass with array syntax, how does your class loader get "asked to load the same array class again"? Class.forName should process the array syntax itself and only ask your class loader to load the element type (if it is a reference type). > it calls findLoadedClass() and gets a > null back. Since JDK 6, ClassLoader.findLoadedClass always returns null when passed array syntax. That doesn't mean that the loader is not (effectively) recorded as an initiating loader of that array class, though. > That's pretty bad because I don't won't to get down to > SystemDictionary::resolve_array_class_or_null() every time I load an > array class. That'll force me to use my own cache to record just about > the same info as what the VM already has, plus the array classes > loaded, which looks like a bad smell to me. I'm not quite sure what that concern is, because Class.forName should begin with the same initiating-loader-based cache lookup that ClassLoader.findLoadedClass does, except that it understands array classes too. Implementation-wise, "getting down" to resolve_array_class_or_null gets you to the VM's relevant cache lookup. Cheers, -- Peter From aph at redhat.com Fri Jan 8 18:52:29 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 08 Jan 2010 18:52:29 +0000 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B1FC407.6010405@redhat.com> References: <4B1FC407.6010405@redhat.com> Message-ID: <4B477EED.2080806@redhat.com> On 12/09/2009 03:36 PM, Andrew Haley wrote: > This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 > The symptom is that jmap doesn't work because target libraries are stripped. > The fix is to allow the symtab reader to use the separate debuginfo files > that are available for all (AFAIK) GNU/Linux distributions. This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ I have now checked several Linux distros, old and new, and although they keep their debuginfo files in different places, this patch works on all of them. Is this OK? And, if so, which repos should I push the patch to? Thanks. Andrew. From jonathan.gibbons at sun.com Fri Jan 8 19:14:46 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 08 Jan 2010 19:14:46 +0000 Subject: hg: jdk7/tl/langtools: 6878147: Keywords.log is declared and initialized but unused Message-ID: <20100108191450.89D594288B@hg.openjdk.java.net> Changeset: c315df443ff2 Author: jjg Date: 2010-01-08 11:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c315df443ff2 6878147: Keywords.log is declared and initialized but unused Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/Keywords.java From jonathan.gibbons at sun.com Fri Jan 8 19:18:46 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 08 Jan 2010 19:18:46 +0000 Subject: hg: jdk7/tl/langtools: 6878146: incorrect unused value should be deleted Message-ID: <20100108191848.1B15B4288F@hg.openjdk.java.net> Changeset: 2d15bf467aea Author: jjg Date: 2010-01-08 11:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2d15bf467aea 6878146: incorrect unused value should be deleted Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java From Kelly.Ohair at Sun.COM Fri Jan 8 19:21:05 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 Jan 2010 11:21:05 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B477EED.2080806@redhat.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> Message-ID: <4B4785A1.8030604@sun.com> Andrew Haley wrote: > On 12/09/2009 03:36 PM, Andrew Haley wrote: >> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >> The symptom is that jmap doesn't work because target libraries are stripped. >> The fix is to allow the symtab reader to use the separate debuginfo files >> that are available for all (AFAIK) GNU/Linux distributions. > > This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 > > Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ > > I have now checked several Linux distros, old and new, and although > they keep their debuginfo files in different places, this patch works > on all of them. > > Is this OK? And, if so, which repos should I push the patch to? > I'm a little concerned about the impact this might have on hotspot as it will eventually get delivered into a jdk6 release (I assume). And jdk6 does builds on really old Linux systems, e.g. "Red Hat Enterprise Advanced Server 2.1 update 2". Can you think of anything that might be a problem with that? Either at compile time or runtime? I still am a bit uncomfortable with that 1K block of bytes we are adding, but I'll resign from that debate, if this is the official way to do it. How many of these 1K blocks are floating around the system? :^( The change probably needs to go through one of the hotspot forests, maybe hotspot-rt? In the meantime, I will take this patch and apply it, and make sure hotspot still builds with the jdk6 and jdk7 Linux systems we have. -kto > Thanks. > Andrew. From gnu_andrew at member.fsf.org Fri Jan 8 19:27:55 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 8 Jan 2010 19:27:55 +0000 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B4785A1.8030604@sun.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> <4B4785A1.8030604@sun.com> Message-ID: <17c6771e1001081127r11984f04n28848a4bdee644f6@mail.gmail.com> 2010/1/8 Kelly O'Hair : > > > Andrew Haley wrote: >> >> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>> >>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >>> The symptom is that jmap doesn't work because target libraries are >>> stripped. >>> The fix is to allow the symtab reader to use the separate debuginfo files >>> that are available for all (AFAIK) GNU/Linux distributions. >> >> This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 >> >> Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ >> >> I have now checked several Linux distros, old and new, and although >> they keep their debuginfo files in different places, this patch works >> on all of them. >> >> Is this OK? ?And, if so, which repos should I push the patch to? >> > > I'm a little concerned about the impact this might have on hotspot > as it will eventually get delivered into a jdk6 release (I assume). > And jdk6 does builds on really old Linux systems, e.g. > "Red Hat Enterprise Advanced Server 2.1 update 2". > Can you think of anything that might be a problem with that? > Either at compile time or runtime? > aph will be able to respond to this in more detail, but my understanding of the patch is that it only tries separate debug files if it doesn't find debuginfo in the binary itself. If the builds om RHEL AS 2.1 use non-stripped binaries, it won't even get that far AFAICS. And if they don't and /usr/lib/debug also doesn't exist, then it will just fail as it always did. So the only issue would be that the code relies on building against something newer than it did previously. > I still am a bit uncomfortable with that 1K block of bytes we are adding, > but I'll resign from that debate, if this is the official way to do it. > How many of these 1K blocks are floating around the system? :^( > > The change probably needs to go through one of the hotspot forests, maybe > hotspot-rt? > I would have assumed hotspot-svc as it's serviceability-related. > In the meantime, I will take this patch and apply it, and make sure > hotspot still builds with the jdk6 and jdk7 Linux systems we have. > Thanks. HotSpot patches go through JPRT so that should also give it some build testing. > -kto > >> Thanks. >> Andrew. > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From jonathan.gibbons at sun.com Fri Jan 8 19:29:35 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 08 Jan 2010 19:29:35 +0000 Subject: hg: jdk7/tl/langtools: 6665791: com.sun.source.tree.MethodTree.toString() does not output default values Message-ID: <20100108192937.B918942892@hg.openjdk.java.net> Changeset: 0e75f9f6d1d4 Author: jjg Date: 2010-01-08 11:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0e75f9f6d1d4 6665791: com.sun.source.tree.MethodTree.toString() does not output default values Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/T6665791.java From jonathan.gibbons at sun.com Fri Jan 8 19:33:48 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 08 Jan 2010 19:33:48 +0000 Subject: hg: jdk7/tl/langtools: 6915078: ALT_JDK_IMPORT_PATH typo in langtools/make/Makefile Message-ID: <20100108193350.9219742894@hg.openjdk.java.net> Changeset: aa06467be3a2 Author: jjg Date: 2010-01-08 11:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aa06467be3a2 6915078: ALT_JDK_IMPORT_PATH typo in langtools/make/Makefile Reviewed-by: tbell ! make/Makefile From Kelly.Ohair at Sun.COM Fri Jan 8 19:46:23 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 Jan 2010 11:46:23 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <17c6771e1001081127r11984f04n28848a4bdee644f6@mail.gmail.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> <4B4785A1.8030604@sun.com> <17c6771e1001081127r11984f04n28848a4bdee644f6@mail.gmail.com> Message-ID: <4B478B8F.7050702@sun.com> Andrew John Hughes wrote: > 2010/1/8 Kelly O'Hair : >> >> Andrew Haley wrote: >>> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >>>> The symptom is that jmap doesn't work because target libraries are >>>> stripped. >>>> The fix is to allow the symtab reader to use the separate debuginfo files >>>> that are available for all (AFAIK) GNU/Linux distributions. >>> This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 >>> >>> Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ >>> >>> I have now checked several Linux distros, old and new, and although >>> they keep their debuginfo files in different places, this patch works >>> on all of them. >>> >>> Is this OK? And, if so, which repos should I push the patch to? >>> >> I'm a little concerned about the impact this might have on hotspot >> as it will eventually get delivered into a jdk6 release (I assume). >> And jdk6 does builds on really old Linux systems, e.g. >> "Red Hat Enterprise Advanced Server 2.1 update 2". >> Can you think of anything that might be a problem with that? >> Either at compile time or runtime? >> > > aph will be able to respond to this in more detail, but my > understanding of the patch is that it only tries separate debug files > if it doesn't find debuginfo in the binary itself. If the builds om > RHEL AS 2.1 use non-stripped binaries, it won't even get that far > AFAICS. And if they don't and /usr/lib/debug also doesn't exist, then > it will just fail as it always did. > > So the only issue would be that the code relies on building against > something newer than it did previously. > >> I still am a bit uncomfortable with that 1K block of bytes we are adding, >> but I'll resign from that debate, if this is the official way to do it. >> How many of these 1K blocks are floating around the system? :^( >> >> The change probably needs to go through one of the hotspot forests, maybe >> hotspot-rt? >> > > I would have assumed hotspot-svc as it's serviceability-related. The hotspot-svc forest has been abandoned in favor of hotspot-rt, or hotspot-rt has consumed it, depends on your point of view. Strange, I remember an email on this back in Nov 2008, but it appears to never have been sent out to the serviceability-dev at openjdk.java.net alias. The primary issue was resources in doing testing and integration of a 4th developer forest, the 3 (gc, comp, rt) seemed to be consuming all our testing resources. > >> In the meantime, I will take this patch and apply it, and make sure >> hotspot still builds with the jdk6 and jdk7 Linux systems we have. >> > > Thanks. HotSpot patches go through JPRT so that should also give it > some build testing. I fired off two JPRT jobs, one for jdk6 and one for jdk7, with this patch applied. Builds and testing. I'll let you know what I find out. Testing this particular functionality is another story of course, never easy to test features that require something to go wrong... ;^) -kto > > >> -kto >> >>> Thanks. >>> Andrew. > > > From gnu_andrew at member.fsf.org Fri Jan 8 20:03:35 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 8 Jan 2010 20:03:35 +0000 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B478B8F.7050702@sun.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> <4B4785A1.8030604@sun.com> <17c6771e1001081127r11984f04n28848a4bdee644f6@mail.gmail.com> <4B478B8F.7050702@sun.com> Message-ID: <17c6771e1001081203t3bef9e8j36f0d8ef886775e8@mail.gmail.com> 2010/1/8 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2010/1/8 Kelly O'Hair : >>> >>> Andrew Haley wrote: >>>> >>>> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>>>> >>>>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >>>>> The symptom is that jmap doesn't work because target libraries are >>>>> stripped. >>>>> The fix is to allow the symtab reader to use the separate debuginfo >>>>> files >>>>> that are available for all (AFAIK) GNU/Linux distributions. >>>> >>>> This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 >>>> >>>> Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ >>>> >>>> I have now checked several Linux distros, old and new, and although >>>> they keep their debuginfo files in different places, this patch works >>>> on all of them. >>>> >>>> Is this OK? ?And, if so, which repos should I push the patch to? >>>> >>> I'm a little concerned about the impact this might have on hotspot >>> as it will eventually get delivered into a jdk6 release (I assume). >>> And jdk6 does builds on really old Linux systems, e.g. >>> "Red Hat Enterprise Advanced Server 2.1 update 2". >>> Can you think of anything that might be a problem with that? >>> Either at compile time or runtime? >>> >> >> aph will be able to respond to this in more detail, but my >> understanding of the patch is that it only tries separate debug files >> if it doesn't find debuginfo in the binary itself. ?If the builds om >> RHEL AS 2.1 use non-stripped binaries, it won't even get that far >> AFAICS. ?And if they don't and /usr/lib/debug also doesn't exist, then >> it will just fail as it always did. >> >> So the only issue would be that the code relies on building against >> something newer than it did previously. >> >>> I still am a bit uncomfortable with that 1K block of bytes we are adding, >>> but I'll resign from that debate, if this is the official way to do it. >>> How many of these 1K blocks are floating around the system? :^( >>> >>> The change probably needs to go through one of the hotspot forests, maybe >>> hotspot-rt? >>> >> >> I would have assumed hotspot-svc as it's serviceability-related. > > The hotspot-svc forest has been abandoned in favor of hotspot-rt, > or hotspot-rt has consumed it, depends on your point of view. > > Strange, I remember an email on this back in Nov 2008, but it appears > to never have been sent out to the serviceability-dev at openjdk.java.net > alias. The primary issue was resources in doing testing and integration > of a 4th developer forest, the 3 (gc, comp, rt) seemed to be consuming > all our testing resources. > Ah ok, that makes sense with the separate serviceability tree going too. I only checked hg.openjdk.java.net. Maybe it's time to nuke some of these dead trees? :) >> >>> In the meantime, I will take this patch and apply it, and make sure >>> hotspot still builds with the jdk6 and jdk7 Linux systems we have. >>> >> >> Thanks. ?HotSpot patches go through JPRT so that should also give it >> some build testing. > > I fired off two JPRT jobs, one for jdk6 and one for jdk7, with this patch > applied. Builds and testing. I'll let you know what I find out. > > Testing this particular functionality is another story of course, never > easy to test features that require something to go wrong... ;^) > > -kto > >> >> >>> -kto >>> >>>> Thanks. >>>> Andrew. >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From jonathan.gibbons at sun.com Fri Jan 8 21:36:33 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 08 Jan 2010 21:36:33 +0000 Subject: hg: jdk7/tl/langtools: 6915152: langtools build failures with import.jdk on Windows Message-ID: <20100108213636.E3650428B7@hg.openjdk.java.net> Changeset: 96c56220dcc2 Author: jjg Date: 2010-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/96c56220dcc2 6915152: langtools build failures with import.jdk on Windows Reviewed-by: ohair ! make/build.xml From Kelly.Ohair at Sun.COM Fri Jan 8 23:10:50 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 Jan 2010 15:10:50 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <17c6771e1001081203t3bef9e8j36f0d8ef886775e8@mail.gmail.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> <4B4785A1.8030604@sun.com> <17c6771e1001081127r11984f04n28848a4bdee644f6@mail.gmail.com> <4B478B8F.7050702@sun.com> <17c6771e1001081203t3bef9e8j36f0d8ef886775e8@mail.gmail.com> Message-ID: <4B47BB7A.3000509@sun.com> Andrew John Hughes wrote: > 2010/1/8 Kelly O'Hair : >> >> Andrew John Hughes wrote: >>> 2010/1/8 Kelly O'Hair : >>>> Andrew Haley wrote: >>>>> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>>>>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >>>>>> The symptom is that jmap doesn't work because target libraries are >>>>>> stripped. >>>>>> The fix is to allow the symtab reader to use the separate debuginfo >>>>>> files >>>>>> that are available for all (AFAIK) GNU/Linux distributions. >>>>> This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 >>>>> >>>>> Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ >>>>> >>>>> I have now checked several Linux distros, old and new, and although >>>>> they keep their debuginfo files in different places, this patch works >>>>> on all of them. >>>>> >>>>> Is this OK? And, if so, which repos should I push the patch to? >>>>> >>>> I'm a little concerned about the impact this might have on hotspot >>>> as it will eventually get delivered into a jdk6 release (I assume). >>>> And jdk6 does builds on really old Linux systems, e.g. >>>> "Red Hat Enterprise Advanced Server 2.1 update 2". >>>> Can you think of anything that might be a problem with that? >>>> Either at compile time or runtime? >>>> >>> aph will be able to respond to this in more detail, but my >>> understanding of the patch is that it only tries separate debug files >>> if it doesn't find debuginfo in the binary itself. If the builds om >>> RHEL AS 2.1 use non-stripped binaries, it won't even get that far >>> AFAICS. And if they don't and /usr/lib/debug also doesn't exist, then >>> it will just fail as it always did. >>> >>> So the only issue would be that the code relies on building against >>> something newer than it did previously. >>> >>>> I still am a bit uncomfortable with that 1K block of bytes we are adding, >>>> but I'll resign from that debate, if this is the official way to do it. >>>> How many of these 1K blocks are floating around the system? :^( >>>> >>>> The change probably needs to go through one of the hotspot forests, maybe >>>> hotspot-rt? >>>> >>> I would have assumed hotspot-svc as it's serviceability-related. >> The hotspot-svc forest has been abandoned in favor of hotspot-rt, >> or hotspot-rt has consumed it, depends on your point of view. >> >> Strange, I remember an email on this back in Nov 2008, but it appears >> to never have been sent out to the serviceability-dev at openjdk.java.net >> alias. The primary issue was resources in doing testing and integration >> of a 4th developer forest, the 3 (gc, comp, rt) seemed to be consuming >> all our testing resources. >> > > Ah ok, that makes sense with the separate serviceability tree going too. > I only checked hg.openjdk.java.net. Maybe it's time to nuke some of > these dead trees? :) I've pinged Dan on this. We will ask MarkR to purge these hotspot-svc repositories. > >>>> In the meantime, I will take this patch and apply it, and make sure >>>> hotspot still builds with the jdk6 and jdk7 Linux systems we have. >>>> >>> Thanks. HotSpot patches go through JPRT so that should also give it >>> some build testing. >> I fired off two JPRT jobs, one for jdk6 and one for jdk7, with this patch >> applied. Builds and testing. I'll let you know what I find out. >> Both JPRT jobs came back fine. -kto >> Testing this particular functionality is another story of course, never >> easy to test features that require something to go wrong... ;^) >> >> -kto >> >>> >>>> -kto >>>> >>>>> Thanks. >>>>> Andrew. >>> >>> > > > From Kelly.Ohair at Sun.COM Fri Jan 8 23:14:54 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 Jan 2010 15:14:54 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B477EED.2080806@redhat.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> Message-ID: <4B47BC6E.8040901@sun.com> Andrew Haley wrote: > On 12/09/2009 03:36 PM, Andrew Haley wrote: >> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >> The symptom is that jmap doesn't work because target libraries are stripped. >> The fix is to allow the symtab reader to use the separate debuginfo files >> that are available for all (AFAIK) GNU/Linux distributions. > > This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 > > Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ > > I have now checked several Linux distros, old and new, and although > they keep their debuginfo files in different places, this patch works > on all of them. > > Is this OK? And, if so, which repos should I push the patch to? I think you should send email to hotspot-runtime-dev at openjdk.java.net and serviceability-dev at openjdk.java.net, asking how to integrate this change. You can consider me a reviewer, and I'll attest that the changes make it through JPRT. Not exactly sure how they want to handle this. -kto > > Thanks. > Andrew. From Kelly.Ohair at Sun.COM Sat Jan 9 01:27:26 2010 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 08 Jan 2010 17:27:26 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B47BC6E.8040901@sun.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> <4B47BC6E.8040901@sun.com> Message-ID: <4B47DB7E.8050001@sun.com> I've been told That Tom had suggested an alternative fix, I had not seen this email. But if adding symbols to the mapfiles fixes it, then than seems easier. Does adding in the ability to read alternative debuginfo files provide some additional functionality? -kto ------------------------------- Subject: Re: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files From: Tom Rodriguez Date: Fri, 08 Jan 2010 11:54:46 -0800 To: Andrew Haley CC: hotspot-dev Source Developers , tl at openjdk.java.net I think a better fix is to add the required gHotSpot* symbols to the mapfile so that they are always exported. This way jmap would work even if the debug symbols for libjvm.so weren't installed on the machine. I actually thought we already did this because we explicitly export a few vtbls for use by the SA but apparently we don't. I must have been thinking of windows where you have to explicitly export them or they won't show up at all. Anyway, adding this to the mapfiles will allow it work as is: # SA symbols gHotSpotVMIntConstantEntryArrayStride; gHotSpotVMIntConstantEntryNameOffset; gHotSpotVMIntConstantEntryValueOffset; gHotSpotVMIntConstants; gHotSpotVMLongConstantEntryArrayStride; gHotSpotVMLongConstantEntryNameOffset; gHotSpotVMLongConstantEntryValueOffset; gHotSpotVMLongConstants; gHotSpotVMStructEntryAddressOffset; gHotSpotVMStructEntryArrayStride; gHotSpotVMStructEntryFieldNameOffset; gHotSpotVMStructEntryIsStaticOffset; gHotSpotVMStructEntryOffsetOffset; gHotSpotVMStructEntryTypeNameOffset; gHotSpotVMStructEntryTypeStringOffset; gHotSpotVMStructs; gHotSpotVMTypeEntryArrayStride; gHotSpotVMTypeEntryIsIntegerTypeOffset; gHotSpotVMTypeEntryIsOopTypeOffset; gHotSpotVMTypeEntryIsUnsignedOffset; gHotSpotVMTypeEntrySizeOffset; gHotSpotVMTypeEntrySuperclassNameOffset; gHotSpotVMTypeEntryTypeNameOffset; gHotSpotVMTypes; Would this be acceptable? tom On Jan 8, 2010, at 10:48 AM, Andrew Haley wrote: > > On 12/09/2009 03:36 PM, Andrew Haley wrote: >> >> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >> >> The symptom is that jmap doesn't work because target libraries are stripped. >> >> The fix is to allow the symtab reader to use the separate debuginfo files >> >> that are available for all (AFAIK) GNU/Linux distributions. > > > > This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 > > > > Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ > > > > I have now checked several Linux distros, old and new, and although > > they keep their debuginfo files in different places, this patch works > > on all of them. > > > > Is this OK? And, if so, which repos should I push the patch to? > > > > Thanks. > > Andrew. From aph at redhat.com Sat Jan 9 10:57:21 2010 From: aph at redhat.com (Andrew Haley) Date: Sat, 09 Jan 2010 10:57:21 +0000 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B478B8F.7050702@sun.com> References: <4B1FC407.6010405@redhat.com> <4B477EED.2080806@redhat.com> <4B4785A1.8030604@sun.com> <17c6771e1001081127r11984f04n28848a4bdee644f6@mail.gmail.com> <4B478B8F.7050702@sun.com> Message-ID: <4B486111.50206@redhat.com> On 01/08/2010 07:46 PM, Kelly O'Hair wrote: > > > Andrew John Hughes wrote: >> 2010/1/8 Kelly O'Hair : >>> >>> Andrew Haley wrote: >>>> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>>>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548 >>>>> The symptom is that jmap doesn't work because target libraries are >>>>> stripped. >>>>> The fix is to allow the symtab reader to use the separate debuginfo files >>>>> that are available for all (AFAIK) GNU/Linux distributions. >>>> This is now also https://bugs.openjdk.java.net/show_bug.cgi?id=100126 >>>> >>>> Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ >>>> >>>> I have now checked several Linux distros, old and new, and although >>>> they keep their debuginfo files in different places, this patch works >>>> on all of them. >>>> >>>> Is this OK? And, if so, which repos should I push the patch to? >>>> >>> I'm a little concerned about the impact this might have on hotspot >>> as it will eventually get delivered into a jdk6 release (I assume). >>> And jdk6 does builds on really old Linux systems, e.g. >>> "Red Hat Enterprise Advanced Server 2.1 update 2". >>> Can you think of anything that might be a problem with that? >>> Either at compile time or runtime? >>> >> >> aph will be able to respond to this in more detail, but my >> understanding of the patch is that it only tries separate debug files >> if it doesn't find debuginfo in the binary itself. If the builds om >> RHEL AS 2.1 use non-stripped binaries, it won't even get that far >> AFAICS. And if they don't and /usr/lib/debug also doesn't exist, then >> it will just fail as it always did. >> >> So the only issue would be that the code relies on building against >> something newer than it did previously. >> >>> I still am a bit uncomfortable with that 1K block of bytes we are adding, >>> but I'll resign from that debate, if this is the official way to do it. >>> How many of these 1K blocks are floating around the system? :^( >>> >>> The change probably needs to go through one of the hotspot forests, maybe >>> hotspot-rt? >>> >> >> I would have assumed hotspot-svc as it's serviceability-related. > > The hotspot-svc forest has been abandoned in favor of hotspot-rt, > or hotspot-rt has consumed it, depends on your point of view. > > Strange, I remember an email on this back in Nov 2008, but it appears > to never have been sent out to the serviceability-dev at openjdk.java.net > alias. The primary issue was resources in doing testing and integration > of a 4th developer forest, the 3 (gc, comp, rt) seemed to be consuming > all our testing resources. > >> >>> In the meantime, I will take this patch and apply it, and make sure >>> hotspot still builds with the jdk6 and jdk7 Linux systems we have. >>> >> >> Thanks. HotSpot patches go through JPRT so that should also give it >> some build testing. > > I fired off two JPRT jobs, one for jdk6 and one for jdk7, with this patch > applied. Builds and testing. I'll let you know what I find out. > > Testing this particular functionality is another story of course, never > easy to test features that require something to go wrong... ;^) I have a nice test for this, of course! for foo in do eu-strip $foo -f $foo.dbg done Then see if jprt and its friends still work. Andrew. From i30817 at gmail.com Sun Jan 10 08:14:48 2010 From: i30817 at gmail.com (Paulo Levi) Date: Sun, 10 Jan 2010 08:14:48 +0000 Subject: The new Objects class Message-ID: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> Just seen the new Objects class in the java.util. I'd like to ask why does the public static int *hash*(Object... values) method, has the warning: * Warning: When a single object reference is supplied, the returned value does not equal the hash code of that object reference.* This value can be computed by calling hashCode(Object) . When it could be rewritten as : public static int *hash*(Object value1, Object value2, Object... restOfValues) to avoid that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From i30817 at gmail.com Sun Jan 10 08:33:35 2010 From: i30817 at gmail.com (Paulo Levi) Date: Sun, 10 Jan 2010 08:33:35 +0000 Subject: Adding a constructor to AssertionError that takes throwable Message-ID: <212322091001100033ta48fd72j6d2f93dfed6036d9@mail.gmail.com> Hi. A funtion i had to implement is one that returns a assertionerror given a msg and a throwable (initCause with the throwable) simply because it's such a common pattern to throw a assertionerror on "impossible" (buggy) exceptions. Without the cause, it's sometimes hard to guess the problem without recompiling the code more than once. I'd like another constructor in AssertionError (that takes a msg and a throwable). As i said i did this on a static function, so it's not important to me, but might simplify things for others (-3 lines of code in catch clauses). -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at sun.com Sun Jan 10 12:45:24 2010 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Sun, 10 Jan 2010 12:45:24 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100110124632.EA1E842B34@hg.openjdk.java.net> Changeset: 755dd6bdccca Author: alanb Date: 2010-01-09 19:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/755dd6bdccca 6907760: (file) OVERFLOW event should cause pending events to be purged Reviewed-by: chegar ! src/share/classes/sun/nio/fs/AbstractWatchKey.java + test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: 0f0aee89e282 Author: alanb Date: 2010-01-10 12:29 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f0aee89e282 6913877: (fs) AsynchronousFileChannel.write can return wrong result under load [win] Reviewed-by: chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/native/sun/nio/ch/WindowsAsynchronousFileChannelImpl.c + test/java/nio/channels/AsynchronousFileChannel/LotsOfWrites.java From forax at univ-mlv.fr Sun Jan 10 15:48:55 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 10 Jan 2010 16:48:55 +0100 Subject: Adding a constructor to AssertionError that takes throwable In-Reply-To: <212322091001100033ta48fd72j6d2f93dfed6036d9@mail.gmail.com> References: <212322091001100033ta48fd72j6d2f93dfed6036d9@mail.gmail.com> Message-ID: <4B49F6E7.8090005@univ-mlv.fr> Le 10/01/2010 09:33, Paulo Levi a ?crit : > Hi. > A funtion i had to implement is one that returns a assertionerror > given a msg and a throwable (initCause with the throwable) simply > because it's such a common pattern to throw a assertionerror on > "impossible" (buggy) exceptions. Without the cause, it's sometimes > hard to guess the problem without recompiling the code more than once. > > I'd like another constructor in AssertionError (that takes a msg and a > throwable). > > As i said i did this on a static function, so it's not important to > me, but might simplify things for others (-3 lines of code in catch > clauses). You can't add constructor that takes a Throwable, this is not source compatible. Throwable is a subtype of Object and a constructor that takes an Object already exist. R?mi From i30817 at gmail.com Sun Jan 10 18:44:14 2010 From: i30817 at gmail.com (Paulo Levi) Date: Sun, 10 Jan 2010 18:44:14 +0000 Subject: Adding a constructor to AssertionError that takes throwable In-Reply-To: <212322091001100033ta48fd72j6d2f93dfed6036d9@mail.gmail.com> References: <212322091001100033ta48fd72j6d2f93dfed6036d9@mail.gmail.com> Message-ID: <212322091001101044l27aec3a4n9f9efdf04d6ff9e7@mail.gmail.com> For some reason i didn't receive your message in my mail Mr. Remi, but i hope you see this anyway. I explained it badly. I want a constructor like this: *AssertionError*(String detailMessage, Throwable thrown) -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at gafter.com Sun Jan 10 19:55:00 2010 From: neal at gafter.com (Neal Gafter) Date: Sun, 10 Jan 2010 11:55:00 -0800 Subject: The new Objects class In-Reply-To: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> References: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> Message-ID: <15e8b9d21001101155k471d92b8gc9b57cfa56a06cb2@mail.gmail.com> On Sun, Jan 10, 2010 at 12:14 AM, Paulo Levi wrote: > Just seen the new Objects class in the java.util. > > I'd like to ask why does the > > public static int hash(Object...?values) > > method, has the warning: > Warning: When a single object reference is supplied, the returned value does > not equal the hash code of that object reference. This value can be computed > by calling hashCode(Object). > > When it could be rewritten as : > > public static int hash(Object value1, Object value2, Object... restOfValues) > > to avoid that. That would make it hard to pass an array. From develop4lasu at gmail.com Mon Jan 11 10:20:10 2010 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Mon, 11 Jan 2010 11:20:10 +0100 Subject: The new Objects class In-Reply-To: <15e8b9d21001101155k471d92b8gc9b57cfa56a06cb2@mail.gmail.com> References: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> <15e8b9d21001101155k471d92b8gc9b57cfa56a06cb2@mail.gmail.com> Message-ID: <28bca0ff1001110220k15f1adafu270f47687f7cae08@mail.gmail.com> 2010/1/10 Neal Gafter : > On Sun, Jan 10, 2010 at 12:14 AM, Paulo Levi wrote: >> Just seen the new Objects class in the java.util. >> >> I'd like to ask why does the >> >> public static int hash(Object...?values) >> >> method, has the warning: >> Warning: When a single object reference is supplied, the returned value does >> not equal the hash code of that object reference. This value can be computed >> by calling hashCode(Object). >> >> When it could be rewritten as : >> >> public static int hash(Object value1, Object value2, Object... restOfValues) >> >> to avoid that. > > That would make it hard to pass an array. > Hello. Name "hashForArray" would not be better? If there is need for efficiency improvements other methods can be added to do not force arrays creation for low number of arguments: public static int hash(Object value) public static int hash(Object value, Object value1) public static int hash(Object value, Object value1, Object value3) public static int hash(Object... values) public static int hash() // maybe ? But I'm not sure if we need that, probably time will tell... -- Pozdrowionka. / Regards. Lasu aka Marek Kozie? From i30817 at gmail.com Mon Jan 11 19:32:48 2010 From: i30817 at gmail.com (Paulo Levi) Date: Mon, 11 Jan 2010 19:32:48 +0000 Subject: The new Objects class In-Reply-To: <28bca0ff1001110220k15f1adafu270f47687f7cae08@mail.gmail.com> References: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> <15e8b9d21001101155k471d92b8gc9b57cfa56a06cb2@mail.gmail.com> <28bca0ff1001110220k15f1adafu270f47687f7cae08@mail.gmail.com> Message-ID: <212322091001111132p7ec9b390s79dac20099a00f8@mail.gmail.com> Possibly two overloadings? One that takes a array public static int hash(Object[] values) The other* *hash(Object value1, Object value2, Object... restOfValues) The one object case is just object.hashcode() right? On Mon, Jan 11, 2010 at 10:20 AM, Marek Kozie? wrote: > 2010/1/10 Neal Gafter : > > On Sun, Jan 10, 2010 at 12:14 AM, Paulo Levi wrote: > >> Just seen the new Objects class in the java.util. > >> > >> I'd like to ask why does the > >> > >> public static int hash(Object... values) > >> > >> method, has the warning: > >> Warning: When a single object reference is supplied, the returned value > does > >> not equal the hash code of that object reference. This value can be > computed > >> by calling hashCode(Object). > >> > >> When it could be rewritten as : > >> > >> public static int hash(Object value1, Object value2, Object... > restOfValues) > >> > >> to avoid that. > > > > That would make it hard to pass an array. > > > Hello. > > Name "hashForArray" would not be better? > > If there is need for efficiency improvements other methods can be > added to do not force arrays creation for low number of arguments: > > public static int hash(Object value) > public static int hash(Object value, Object value1) > public static int hash(Object value, Object value1, Object value3) > public static int hash(Object... values) > public static int hash() // maybe ? > > > But I'm not sure if we need that, probably time will tell... > > -- > Pozdrowionka. / Regards. > Lasu aka Marek Kozie? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From develop4lasu at gmail.com Mon Jan 11 20:47:51 2010 From: develop4lasu at gmail.com (=?UTF-8?Q?Marek_Kozie=C5=82?=) Date: Mon, 11 Jan 2010 21:47:51 +0100 Subject: The new Objects class In-Reply-To: <212322091001111132p7ec9b390s79dac20099a00f8@mail.gmail.com> References: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> <15e8b9d21001101155k471d92b8gc9b57cfa56a06cb2@mail.gmail.com> <28bca0ff1001110220k15f1adafu270f47687f7cae08@mail.gmail.com> <212322091001111132p7ec9b390s79dac20099a00f8@mail.gmail.com> Message-ID: <28bca0ff1001111247r4d0d856ew51779f2f12f272b0@mail.gmail.com> 2010/1/11 Paulo Levi : > Possibly two overloadings? > One that takes a array > public static int hash(Object[] values) > The other > hash(Object value1, Object value2, Object... restOfValues) > > The one object case is just > object.hashcode() right? > > Can you tell me what target you want to obtain? Because I do not see any reason for that. -- Pozdrowionka. / Regards. Lasu aka Marek Kozie? http://lasu2string.blogspot.com/ From i30817 at gmail.com Mon Jan 11 21:03:01 2010 From: i30817 at gmail.com (Paulo Levi) Date: Mon, 11 Jan 2010 21:03:01 +0000 Subject: The new Objects class In-Reply-To: <28bca0ff1001111247r4d0d856ew51779f2f12f272b0@mail.gmail.com> References: <212322091001100014q78a734ecva9f0638df50fcaa9@mail.gmail.com> <15e8b9d21001101155k471d92b8gc9b57cfa56a06cb2@mail.gmail.com> <28bca0ff1001110220k15f1adafu270f47687f7cae08@mail.gmail.com> <212322091001111132p7ec9b390s79dac20099a00f8@mail.gmail.com> <28bca0ff1001111247r4d0d856ew51779f2f12f272b0@mail.gmail.com> Message-ID: <212322091001111303p72bc76e3hbc838e4e719d12f6@mail.gmail.com> Well. Avoid the need for the warning. But i see what you mean. A simple array would have to include the warning anyway, if it was a one element array. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Darcy at Sun.COM Mon Jan 11 21:17:51 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 11 Jan 2010 13:17:51 -0800 Subject: Code review request for 6828204 NavigableSet.subSet() documentation refers to nonexistent parameters Message-ID: <4B4B957F.7050102@sun.com> Hello. Please review this simple typo fix for 6828204 "NavigableSet.subSet() documentation refers to nonexistent parameters": --- old/src/share/classes/java/util/NavigableMap.java 2010-01-11 13:13:28.000000000 -0800 +++ new/src/share/classes/java/util/NavigableMap.java 2010-01-11 13:13:28.000000000 -0800 @@ -298,7 +298,7 @@ * Returns a view of the portion of this map whose keys range from * {@code fromKey} to {@code toKey}. If {@code fromKey} and * {@code toKey} are equal, the returned map is empty unless - * {@code fromExclusive} and {@code toExclusive} are both true. The + * {@code fromInclusive} and {@code toInclusive} are both true. The * returned map is backed by this map, so changes in the returned map are * reflected in this map, and vice-versa. The returned map supports all * optional map operations that this map supports. --- old/src/share/classes/java/util/NavigableSet.java 2010-01-11 13:13:29.000000000 -0800 +++ new/src/share/classes/java/util/NavigableSet.java 2010-01-11 13:13:29.000000000 -0800 @@ -192,7 +192,7 @@ * Returns a view of the portion of this set whose elements range from * {@code fromElement} to {@code toElement}. If {@code fromElement} and * {@code toElement} are equal, the returned set is empty unless {@code - * fromExclusive} and {@code toExclusive} are both true. The returned set + * fromInclusive} and {@code toInclusive} are both true. The returned set * is backed by this set, so changes in the returned set are reflected in * this set, and vice-versa. The returned set supports all optional set * operations that this set supports. http://cr.openjdk.java.net/~darcy/6828204.0/ Thanks, -Joe From christopher.hegarty at sun.com Mon Jan 11 21:58:05 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 11 Jan 2010 21:58:05 +0000 Subject: hg: jdk7/tl/jdk: 6915313: Reorganize implementation to make it more feasible to port to JDK6 Message-ID: <20100111215849.1D5CA42D47@hg.openjdk.java.net> Changeset: fc5578368a0c Author: chegar Date: 2010-01-11 16:04 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fc5578368a0c 6915313: Reorganize implementation to make it more feasible to port to JDK6 Summary: This makes the SCTP implementation easier to run with Suns JDK6. Reviewed-by: alanb ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/mapfile-vers ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java ! src/solaris/native/sun/nio/ch/SctpNet.c From jonathan.gibbons at sun.com Mon Jan 11 22:06:33 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Mon, 11 Jan 2010 22:06:33 +0000 Subject: hg: jdk7/tl/langtools: 6326754: Compiler will fail to handle -Xmaxerrs with -ve numbers Message-ID: <20100111220639.EFF4242D4A@hg.openjdk.java.net> Changeset: d02e99d31cc0 Author: jjg Date: 2010-01-11 14:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d02e99d31cc0 6326754: Compiler will fail to handle -Xmaxerrs with -ve numbers Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/T6326754.java + test/tools/javac/T6326754.out From jonathan.gibbons at sun.com Mon Jan 11 22:10:03 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Mon, 11 Jan 2010 22:10:03 +0000 Subject: hg: jdk7/tl/langtools: 6764569: [PATCH] Fix unused imports in list resource bundles Message-ID: <20100111221005.0BD0242D4B@hg.openjdk.java.net> Changeset: f983c1dca202 Author: jjg Date: 2010-01-11 14:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f983c1dca202 6764569: [PATCH] Fix unused imports in list resource bundles Reviewed-by: ksrini Contributed-by: jesse.glick at sun.com ! make/tools/CompileProperties/CompileProperties.java ! make/tools/CompileProperties/CompilePropertiesTask.java From jonathan.gibbons at sun.com Mon Jan 11 22:13:01 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Mon, 11 Jan 2010 22:13:01 +0000 Subject: hg: jdk7/tl/langtools: 6915476: java.util.regex.PatternSyntaxException in com.sun.tools.javac.nio.PathFileObject Message-ID: <20100111221303.9844A42D4D@hg.openjdk.java.net> Changeset: ca6bc36b2305 Author: jjg Date: 2010-01-11 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ca6bc36b2305 6915476: java.util.regex.PatternSyntaxException in com.sun.tools.javac.nio.PathFileObject Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! test/tools/javac/nio/compileTest/CompileTest.java From jonathan.gibbons at sun.com Mon Jan 11 22:17:48 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Mon, 11 Jan 2010 22:17:48 +0000 Subject: hg: jdk7/tl/langtools: 6915497: test test/tools/javac/nio/compileTest/CompileTest.java fails under Hudson Message-ID: <20100111221750.C51BC42D51@hg.openjdk.java.net> Changeset: 14a4c45ef734 Author: jjg Date: 2010-01-11 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/14a4c45ef734 6915497: test test/tools/javac/nio/compileTest/CompileTest.java fails under Hudson Reviewed-by: darcy ! test/tools/javac/nio/compileTest/CompileTest.java From martinrb at google.com Mon Jan 11 22:24:25 2010 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 Jan 2010 14:24:25 -0800 Subject: Code review request for 6828204 NavigableSet.subSet() documentation refers to nonexistent parameters In-Reply-To: <4B4B957F.7050102@sun.com> References: <4B4B957F.7050102@sun.com> Message-ID: <1ccfd1c11001111424w33340698n8c8812746da70cfd@mail.gmail.com> Approved! Thanks for the fix. Martin On Mon, Jan 11, 2010 at 13:17, Joseph D. Darcy wrote: > Hello. > > Please review this simple typo fix for 6828204 "NavigableSet.subSet() > documentation refers to nonexistent parameters": > > --- old/src/share/classes/java/util/NavigableMap.java ? ?2010-01-11 > 13:13:28.000000000 -0800 > +++ new/src/share/classes/java/util/NavigableMap.java ? ?2010-01-11 > 13:13:28.000000000 -0800 > @@ -298,7 +298,7 @@ > ? ? * Returns a view of the portion of this map whose keys range from > ? ? * {@code fromKey} to {@code toKey}. ?If {@code fromKey} and > ? ? * {@code toKey} are equal, the returned map is empty unless > - ? ? * {@code fromExclusive} and {@code toExclusive} are both true. ?The > + ? ? * {@code fromInclusive} and {@code toInclusive} are both true. ?The > ? ? * returned map is backed by this map, so changes in the returned map are > ? ? * reflected in this map, and vice-versa. ?The returned map supports all > ? ? * optional map operations that this map supports. > --- old/src/share/classes/java/util/NavigableSet.java ? ?2010-01-11 > 13:13:29.000000000 -0800 > +++ new/src/share/classes/java/util/NavigableSet.java ? ?2010-01-11 > 13:13:29.000000000 -0800 > @@ -192,7 +192,7 @@ > ? ? * Returns a view of the portion of this set whose elements range from > ? ? * {@code fromElement} to {@code toElement}. ?If {@code fromElement} and > ? ? * {@code toElement} are equal, the returned set is empty unless {@code > - ? ? * fromExclusive} and {@code toExclusive} are both true. ?The returned > set > + ? ? * fromInclusive} and {@code toInclusive} are both true. ?The returned > set > ? ? * is backed by this set, so changes in the returned set are reflected in > ? ? * this set, and vice-versa. ?The returned set supports all optional set > ? ? * operations that this set supports. > > http://cr.openjdk.java.net/~darcy/6828204.0/ > > Thanks, > > -Joe > From joe.darcy at sun.com Mon Jan 11 23:35:39 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Mon, 11 Jan 2010 23:35:39 +0000 Subject: hg: jdk7/tl/jdk: 6828204: NavigableSet.subSet() documentation refers to nonexistent parameters Message-ID: <20100111233552.6326F42D66@hg.openjdk.java.net> Changeset: 9d38ab65acff Author: darcy Date: 2010-01-11 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d38ab65acff 6828204: NavigableSet.subSet() documentation refers to nonexistent parameters Reviewed-by: martin ! src/share/classes/java/util/NavigableMap.java ! src/share/classes/java/util/NavigableSet.java From jonathan.gibbons at sun.com Tue Jan 12 00:19:13 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 12 Jan 2010 00:19:13 +0000 Subject: hg: jdk7/tl/langtools: 6909470: langtools stub generator should prune unnecessary imports Message-ID: <20100112001918.DB02F42D73@hg.openjdk.java.net> Changeset: 51011e02c02f Author: jjg Date: 2010-01-11 16:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/51011e02c02f 6909470: langtools stub generator should prune unnecessary imports Reviewed-by: darcy ! make/tools/GenStubs/GenStubs.java From mandy.chung at sun.com Tue Jan 12 23:22:06 2010 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Tue, 12 Jan 2010 23:22:06 +0000 Subject: hg: jdk7/tl/jdk: 6915502: Legal notice repairs needed in jdk/make/modules/tools Message-ID: <20100112232245.3E02342EE5@hg.openjdk.java.net> Changeset: ba74184a952c Author: mchung Date: 2010-01-12 15:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ba74184a952c 6915502: Legal notice repairs needed in jdk/make/modules/tools Summary: Fix the legal notice in jdk/make/modules/tools Reviewed-by: tbell ! make/modules/tools/build.xml ! make/modules/tools/nbproject/project.properties ! make/modules/tools/nbproject/project.xml From jonathan.gibbons at sun.com Thu Jan 14 01:40:51 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 14 Jan 2010 01:40:51 +0000 Subject: hg: jdk7/tl/langtools: 6472751: SourcePositions.getStartPos returns incorrect value for enum constants; ... Message-ID: <20100114014056.3BB944142C@hg.openjdk.java.net> Changeset: ccd51af119b4 Author: jjg Date: 2010-01-13 17:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ccd51af119b4 6472751: SourcePositions.getStartPos returns incorrect value for enum constants 6567414: javac compiler reports no source file or line on enum constant declaration error Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T6472751.java + test/tools/javac/T6567414.java + test/tools/javac/T6567414.out From Joe.Darcy at Sun.COM Thu Jan 14 06:44:08 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 13 Jan 2010 22:44:08 -0800 Subject: Code review request for 6908218 "java.lang.Deprecated should have explicit @Target meta-annotation" Message-ID: <4B4EBD38.10503@sun.com> Hello. Please review my patch to fix 6908218 "java.lang.Deprecated should have explicit @Target meta-annotation." For background, JSR 308 added two new enum constants to ElementType. ElementType constants are used in java.lang.annotation.Target meta-annotations to indicate what kind of elements an annotation is applicable to. If an annotation type does not have a @Target meta-annotation, annotations of the annotation type are allowed to be applied to all elements. Therefore, after JSR 308 added new ElementTypes, annotations without @Target meta-annotations can now be applied to more kinds of things, perhaps inappropriately given the semantics of the annotation. Conversely, annotations that do have a @Target meta-annotations might want to be applicable to the new locations. Two adjustments should be done to platform annotations: @Deprecated should get an explicit @Target meta-annotation and @SuppressWarnings should be applicable to another ElementType: --- old/src/share/classes/java/lang/Deprecated.java 2010-01-13 22:30:49.000000000 -0800 +++ new/src/share/classes/java/lang/Deprecated.java 2010-01-13 22:30:49.000000000 -0800 @@ -26,6 +26,7 @@ package java.lang; import java.lang.annotation.*; +import static java.lang.annotation.ElementType.*; /** * A program element annotated @Deprecated is one that programmers @@ -38,5 +39,6 @@ */ @Documented @Retention(RetentionPolicy.RUNTIME) + at Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, PARAMETER, TYPE}) public @interface Deprecated { } --- old/src/share/classes/java/lang/SuppressWarnings.java 2010-01-13 22:30:50.000000000 -0800 +++ new/src/share/classes/java/lang/SuppressWarnings.java 2010-01-13 22:30:49.000000000 -0800 @@ -26,7 +26,6 @@ package java.lang; import java.lang.annotation.*; -import java.lang.annotation.ElementType; import static java.lang.annotation.ElementType.*; /** @@ -45,7 +44,7 @@ * @since 1.5 * @author Josh Bloch */ - at Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) + at Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, TYPE_PARAMETER}) @Retention(RetentionPolicy.SOURCE) public @interface SuppressWarnings { /** For java.lang.Deprecated, the meta-annotation @Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, PARAMETER, TYPE}) includes all JDK 5/6 era locations annotations can be applied to. Therefore, with this list the locations @Deprecated can be applied will be unchanged from Java SE 6. JLSv3 mandates warnings be issued for the use of a deprecated "type, method, field, or constructor" (http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.6). Other permitted applications of an @Deprecated annotation must be ignored; "Use of the annotation @Deprecated on a local variable declaration or on a parameter declaration has no effect." Therefore, allowing @Deprecated on TYPE_PARAMETER or as a TYPE_USE would not be meaningful. Webrev at: http://cr.openjdk.java.net/~darcy/6908218.0/ Thanks, -Joe From brucechapman at paradise.net.nz Thu Jan 14 09:00:34 2010 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Thu, 14 Jan 2010 22:00:34 +1300 Subject: Code review request for 6908218 "java.lang.Deprecated should have explicit @Target meta-annotation" In-Reply-To: <4B4EBD38.10503@sun.com> References: <4B4EBD38.10503@sun.com> Message-ID: <4B4EDD32.7070206@paradise.net.nz> Joe, there is information about the rationale for the change in this email but that information isn't in the bug report, Will it be put in the commit message or bug report? Bruce Joseph D. Darcy wrote: > Hello. > > Please review my patch to fix 6908218 "java.lang.Deprecated should > have explicit @Target meta-annotation." > > For background, JSR 308 added two new enum constants to ElementType. > ElementType constants are used in java.lang.annotation.Target > meta-annotations to indicate what kind of elements an annotation is > applicable to. > > If an annotation type does not have a @Target meta-annotation, > annotations of the annotation type are allowed to be applied to all > elements. Therefore, after JSR 308 added new ElementTypes, > annotations without @Target meta-annotations can now be applied to > more kinds of things, perhaps inappropriately given the semantics of > the annotation. > > Conversely, annotations that do have a @Target meta-annotations might > want to be applicable to the new locations. > > Two adjustments should be done to platform annotations: @Deprecated > should get an explicit @Target meta-annotation and @SuppressWarnings > should be applicable to another ElementType: > > --- old/src/share/classes/java/lang/Deprecated.java 2010-01-13 > 22:30:49.000000000 -0800 > +++ new/src/share/classes/java/lang/Deprecated.java 2010-01-13 > 22:30:49.000000000 -0800 > @@ -26,6 +26,7 @@ > package java.lang; > > import java.lang.annotation.*; > +import static java.lang.annotation.ElementType.*; > > /** > * A program element annotated @Deprecated is one that programmers > @@ -38,5 +39,6 @@ > */ > @Documented > @Retention(RetentionPolicy.RUNTIME) > + at Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, > PARAMETER, TYPE}) > public @interface Deprecated { > } > --- old/src/share/classes/java/lang/SuppressWarnings.java > 2010-01-13 22:30:50.000000000 -0800 > +++ new/src/share/classes/java/lang/SuppressWarnings.java > 2010-01-13 22:30:49.000000000 -0800 > @@ -26,7 +26,6 @@ > package java.lang; > > import java.lang.annotation.*; > -import java.lang.annotation.ElementType; > import static java.lang.annotation.ElementType.*; > > /** > @@ -45,7 +44,7 @@ > * @since 1.5 > * @author Josh Bloch > */ > - at Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) > + at Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, > TYPE_PARAMETER}) > @Retention(RetentionPolicy.SOURCE) > public @interface SuppressWarnings { > /** > > > For java.lang.Deprecated, the meta-annotation > @Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, > PARAMETER, TYPE}) > includes all JDK 5/6 era locations annotations can be applied to. > Therefore, with this list the locations @Deprecated can be applied > will be unchanged from Java SE 6. > > JLSv3 mandates warnings be issued for the use of a deprecated "type, > method, field, or constructor" > (http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.6). > Other permitted applications of an @Deprecated annotation must be > ignored; "Use of the annotation @Deprecated on a local variable > declaration or on a parameter declaration has no effect." Therefore, > allowing @Deprecated on TYPE_PARAMETER or as a TYPE_USE would not be > meaningful. > > Webrev at: > http://cr.openjdk.java.net/~darcy/6908218.0/ > > Thanks, > > -Joe > From Joe.Darcy at Sun.COM Thu Jan 14 17:57:59 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 14 Jan 2010 09:57:59 -0800 Subject: Code review request for 6908218 "java.lang.Deprecated should have explicit @Target meta-annotation" In-Reply-To: <4B4EDD32.7070206@paradise.net.nz> References: <4B4EBD38.10503@sun.com> <4B4EDD32.7070206@paradise.net.nz> Message-ID: <4B4F5B27.7040607@sun.com> Bruce Chapman wrote: > Joe, > > there is information about the rationale for the change in this email > but that information isn't in the bug report, Will it be put in the > commit message or bug report? Hi Bruce. I'll at least add a link to the core-libs thread to the bug when I update the bug to fixed state. -Joe > > Bruce > > > Joseph D. Darcy wrote: >> Hello. >> >> Please review my patch to fix 6908218 "java.lang.Deprecated should >> have explicit @Target meta-annotation." >> >> For background, JSR 308 added two new enum constants to ElementType. >> ElementType constants are used in java.lang.annotation.Target >> meta-annotations to indicate what kind of elements an annotation is >> applicable to. >> >> If an annotation type does not have a @Target meta-annotation, >> annotations of the annotation type are allowed to be applied to all >> elements. Therefore, after JSR 308 added new ElementTypes, >> annotations without @Target meta-annotations can now be applied to >> more kinds of things, perhaps inappropriately given the semantics of >> the annotation. >> >> Conversely, annotations that do have a @Target meta-annotations might >> want to be applicable to the new locations. >> >> Two adjustments should be done to platform annotations: @Deprecated >> should get an explicit @Target meta-annotation and @SuppressWarnings >> should be applicable to another ElementType: >> >> --- old/src/share/classes/java/lang/Deprecated.java 2010-01-13 >> 22:30:49.000000000 -0800 >> +++ new/src/share/classes/java/lang/Deprecated.java 2010-01-13 >> 22:30:49.000000000 -0800 >> @@ -26,6 +26,7 @@ >> package java.lang; >> >> import java.lang.annotation.*; >> +import static java.lang.annotation.ElementType.*; >> >> /** >> * A program element annotated @Deprecated is one that programmers >> @@ -38,5 +39,6 @@ >> */ >> @Documented >> @Retention(RetentionPolicy.RUNTIME) >> + at Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, >> PARAMETER, TYPE}) >> public @interface Deprecated { >> } >> --- old/src/share/classes/java/lang/SuppressWarnings.java >> 2010-01-13 22:30:50.000000000 -0800 >> +++ new/src/share/classes/java/lang/SuppressWarnings.java >> 2010-01-13 22:30:49.000000000 -0800 >> @@ -26,7 +26,6 @@ >> package java.lang; >> >> import java.lang.annotation.*; >> -import java.lang.annotation.ElementType; >> import static java.lang.annotation.ElementType.*; >> >> /** >> @@ -45,7 +44,7 @@ >> * @since 1.5 >> * @author Josh Bloch >> */ >> - at Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE}) >> + at Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, >> LOCAL_VARIABLE, TYPE_PARAMETER}) >> @Retention(RetentionPolicy.SOURCE) >> public @interface SuppressWarnings { >> /** >> >> >> For java.lang.Deprecated, the meta-annotation >> @Target(value={CONSTRUCTOR, FIELD, LOCAL_VARIABLE, METHOD, PACKAGE, >> PARAMETER, TYPE}) >> includes all JDK 5/6 era locations annotations can be applied to. >> Therefore, with this list the locations @Deprecated can be applied >> will be unchanged from Java SE 6. >> >> JLSv3 mandates warnings be issued for the use of a deprecated "type, >> method, field, or constructor" >> (http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.6). >> Other permitted applications of an @Deprecated annotation must be >> ignored; "Use of the annotation @Deprecated on a local variable >> declaration or on a parameter declaration has no effect." Therefore, >> allowing @Deprecated on TYPE_PARAMETER or as a TYPE_USE would not be >> meaningful. >> >> Webrev at: >> http://cr.openjdk.java.net/~darcy/6908218.0/ >> >> Thanks, >> >> -Joe >> > From mernst at cs.washington.edu Thu Jan 14 21:23:22 2010 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 14 Jan 2010 13:23:22 -0800 (PST) Subject: Code review request for 6908218 "java.lang.Deprecated should have explicit @Target meta-annotation" In-Reply-To: <4B4EBD38.10503@sun.com> References: <4B4EBD38.10503@sun.com> Message-ID: <20100114.132322.84728237.mernst@cs.washington.edu> Joe- > Please review my patch to fix 6908218 "java.lang.Deprecated should have > explicit @Target meta-annotation." All this looks right to me. -Mike From jonathan.gibbons at sun.com Fri Jan 15 01:20:04 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 15 Jan 2010 01:20:04 +0000 Subject: hg: jdk7/tl/langtools: 6917122: provide utility method to find the inner most type of a type tree Message-ID: <20100115012007.9287B415EE@hg.openjdk.java.net> Changeset: b96ad32c004a Author: jjg Date: 2010-01-14 17:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b96ad32c004a 6917122: provide utility method to find the inner most type of a type tree Reviewed-by: darcy, jjg Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java From jonathan.gibbons at sun.com Fri Jan 15 01:24:41 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 15 Jan 2010 01:24:41 +0000 Subject: hg: jdk7/tl/langtools: 6916986: handle spaces in langtools launcher path Message-ID: <20100115012443.CFF61415F0@hg.openjdk.java.net> Changeset: 2d0f4e7b44b2 Author: jjg Date: 2010-01-14 17:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2d0f4e7b44b2 6916986: handle spaces in langtools launcher path Reviewed-by: darcy, jjg Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/bin/launcher.sh-template From joe.darcy at sun.com Fri Jan 15 04:05:52 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 15 Jan 2010 04:05:52 +0000 Subject: hg: jdk7/tl/jdk: 6908218: java.lang.Deprecated should have explicit @Target meta-annotation. Message-ID: <20100115040610.BB6484162B@hg.openjdk.java.net> Changeset: fa0cb25202d8 Author: darcy Date: 2010-01-14 20:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa0cb25202d8 6908218: java.lang.Deprecated should have explicit @Target meta-annotation. Reviewed-by: mernst ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/SuppressWarnings.java From sean.mullan at sun.com Fri Jan 15 15:05:56 2010 From: sean.mullan at sun.com (sean.mullan at sun.com) Date: Fri, 15 Jan 2010 15:05:56 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100115150635.0A79041705@hg.openjdk.java.net> Changeset: 51d62db10c93 Author: mullan Date: 2010-01-15 09:48 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51d62db10c93 6915939: Exception should be thrown if OCSP SingleResponses contain unresolved critical extensions Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 074f79397dda Author: mullan Date: 2010-01-15 09:58 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/074f79397dda Merge From christopher.hegarty at sun.com Fri Jan 15 16:31:49 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Fri, 15 Jan 2010 16:31:49 +0000 Subject: hg: jdk7/tl/jdk: 6916922: (sctp) SO_RCVBUF & SO_SNDBUF returns twice the value set Message-ID: <20100115163208.4D1864171E@hg.openjdk.java.net> Changeset: b019cdae32dd Author: chegar Date: 2010-01-15 16:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b019cdae32dd 6916922: (sctp) SO_RCVBUF & SO_SNDBUF returns twice the value set Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/SctpNet.c ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java From lana.steuck at sun.com Sat Jan 16 00:34:02 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:34:02 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b79 for changeset 20aeeb517139 Message-ID: <20100116003403.09BDC417AB@hg.openjdk.java.net> Changeset: b1952d19290d Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/b1952d19290d Added tag jdk7-b79 for changeset 20aeeb517139 ! .hgtags From lana.steuck at sun.com Sat Jan 16 00:34:09 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:34:09 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b79 for changeset ec0421b5703b Message-ID: <20100116003410.5CF59417AC@hg.openjdk.java.net> Changeset: fdbc85b2d15c Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/fdbc85b2d15c Added tag jdk7-b79 for changeset ec0421b5703b ! .hgtags From lana.steuck at sun.com Sat Jan 16 00:36:20 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:36:20 +0000 Subject: hg: jdk7/tl/hotspot: 74 new changesets Message-ID: <20100116004010.99A7F417B0@hg.openjdk.java.net> Changeset: f334aec453a1 Author: kvn Date: 2009-10-29 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f334aec453a1 6896084: VM does not reserve protected page below heap for compressed oops implicit null checks Summary: Set narrow_oop_base and narrow_oop_use_implicit_null_checks in Universe::preferred_heap_base(). Reviewed-by: twisti, jcoomes ! src/share/vm/memory/universe.cpp Changeset: 73a726751507 Author: cfang Date: 2009-10-30 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/73a726751507 6852078: HSX 14/16 in jdk 5.0: api/javax_management api/org_omg jck tests crashes or make tnameserv crash Summary: Disable SuperWord optimization for unsafe read/write Reviewed-by: kvn, phh ! src/share/vm/opto/superword.cpp + test/compiler/6852078/Test6852078.java Changeset: 389049f3f393 Author: jrose Date: 2009-10-30 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/389049f3f393 6858164: invokedynamic code needs some cleanup (post-6655638) Summary: Fix several crashers, remove needless paths for boxed-style bootstrap method call, refactor & simplify APIs for rewriter constantPoolOop, remove sun.dyn.CallSiteImpl Reviewed-by: kvn ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp Changeset: 323bd24c6520 Author: roland Date: 2009-11-02 11:17 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/323bd24c6520 6769124: various 64-bit fixes for c1 Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/runtime/arguments.cpp + test/compiler/6769124/TestArrayCopy6769124.java + test/compiler/6769124/TestDeoptInt6769124.java + test/compiler/6769124/TestUnalignedLoad6769124.java Changeset: 09572fede9d1 Author: kvn Date: 2009-11-04 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09572fede9d1 6896370: CTW fails share/vm/opto/matcher.cpp:1475 "duplicating node that's already been matched" Summary: Move DecodeN code outside the memory nodes only code. Reviewed-by: never ! src/share/vm/opto/matcher.cpp Changeset: dcdcc8c16e20 Author: kvn Date: 2009-11-04 14:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dcdcc8c16e20 6896352: CTW fails hotspot/src/share/vm/opto/escape.cpp:1155 Summary: Always call C->get_alias_index(phase->type(address)) during parsing. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/memnode.cpp Changeset: 2f1ec89b9995 Author: cfang Date: 2009-11-10 17:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2f1ec89b9995 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp Changeset: 473cce303f13 Author: phh Date: 2009-10-28 16:25 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/473cce303f13 6887571: Increase default heap config sizes Summary: Apply modification of existing server heap size ergo to all collectors except CMS. Reviewed-by: jmasa, ysr, xlu ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/services/management.cpp Changeset: c4ecde2f6b3c Author: xlu Date: 2009-10-30 17:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c4ecde2f6b3c Merge Changeset: 97b36138b494 Author: kamg Date: 2009-11-06 15:04 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/97b36138b494 Merge Changeset: ba7ea42fc66e Author: phh Date: 2009-11-04 16:49 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba7ea42fc66e 6898160: Need serviceability support for new vm argument type 'uint64_t' Summary: Add serviceability support for uint64_t. Flags of unknown type assert in debug builds and are ignored in product builds. Reviewed-by: never, xlu, mchung, dcubed ! src/share/vm/runtime/globals.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/management.cpp Changeset: db0d21039f34 Author: kamg Date: 2009-11-06 16:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/db0d21039f34 Merge Changeset: fb4c00faa9da Author: kamg Date: 2009-11-11 09:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fb4c00faa9da Merge ! src/share/vm/runtime/arguments.cpp Changeset: 87b2fdd4bf98 Author: never Date: 2009-11-11 23:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/87b2fdd4bf98 6892079: live value must not be garbage failure after fix for 6854812 Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: b18963243361 Author: twisti Date: 2009-11-19 03:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b18963243361 6902000: use ShouldNotReachHere() for btos/ctos/stos in TemplateInterpreterGenerator::set_short_entry_points Summary: set_entry_point is only ever used with the tos states of bytecode templates in templateTable.cpp and none of those use the subword tos states like btos, ctos and stos. Reviewed-by: kvn ! src/share/vm/interpreter/templateInterpreter.cpp Changeset: 7ef1d2e14917 Author: kvn Date: 2009-11-19 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7ef1d2e14917 6902036: WorldWind asserts on escape.cpp:1153: assert(addr->is_AddP(),"AddP required") Summary: Remove the assert. Reviewed-by: twisti ! src/share/vm/opto/escape.cpp Changeset: de44705e6b33 Author: cfang Date: 2009-11-24 11:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/de44705e6b33 Merge Changeset: 84cb6f20afb3 Author: phh Date: 2009-11-20 16:22 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/84cb6f20afb3 6900899: vm fails to start when -Xmx value is less than OldSize + NewSize Summary: Set minimum heap size to min(OldSize + NewSize, MaxHeapSize) in Arguments::set_heap_size(). Reviewed-by: kvn, ysr, tonyp ! src/share/vm/runtime/arguments.cpp Changeset: a75edfd400ea Author: acorn Date: 2009-11-11 15:49 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a75edfd400ea 6893504: LinkageError for bootstrap duplicate class definitions. Reviewed-by: kamg, xlu ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp Changeset: 1920bd911283 Author: acorn Date: 2009-11-23 16:24 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1920bd911283 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp Changeset: e1fb452ad949 Author: kamg Date: 2009-11-25 09:03 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e1fb452ad949 Merge Changeset: 8e7adf982378 Author: twisti Date: 2009-11-27 07:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8e7adf982378 6896043: first round of zero fixes Reviewed-by: kvn Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/runtime/os.hpp Changeset: 6400f475effe Author: iveresov Date: 2009-12-01 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6400f475effe Merge Changeset: 7c57aead6d3e Author: never Date: 2009-11-12 09:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c57aead6d3e 6892658: C2 should optimize some stringbuilder patterns Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/c2_globals.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/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.hpp + src/share/vm/opto/stringopts.cpp + src/share/vm/opto/stringopts.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: bd12fff78df5 Author: cfang Date: 2009-11-25 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bd12fff78df5 6904191: OptimizeStringConcat should be product instead of experimental Summary: Make OptimizeStringConcat a product VM option(contributed by never) Reviewed-by: never ! src/share/vm/opto/c2_globals.hpp Changeset: facbc74580c3 Author: iveresov Date: 2009-12-01 22:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/facbc74580c3 Merge ! src/share/vm/classfile/systemDictionary.hpp Changeset: 8b22f86d1740 Author: cfang Date: 2009-12-02 13:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b22f86d1740 6901572: JVM 1.6.16 crash on loops: assert(has_node(i),"") Summary: Skip the secondary induction variable handling if it is dead Reviewed-by: never, kvn ! src/share/vm/opto/loopnode.cpp + test/compiler/6901572/Test.java Changeset: 5f932a151fd4 Author: johnc Date: 2009-11-06 11:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5f932a151fd4 6895788: G1: SATB and update buffer allocation code allocates too much space Summary: The type in the NEW_C_HEAP_ARRRY and FREE_C_HEAP_ARRAY calls in the buffer allocation code was changed from void* to char as the size argument had already been mulitipled by the byte size of an object pointer. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp Changeset: 0e2d7ae2bc67 Author: jmasa Date: 2009-11-10 11:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e2d7ae2bc67 6898857: [Regression] -XX:NewRatio with -XX:+UseConcMarkSweepGC causes fatal error Summary: Use CollectorPolicy information instead of MaxNewSize Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 89f1b9ae8991 Author: ysr Date: 2009-11-13 11:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/89f1b9ae8991 6898948: G1: forensic instrumentation for out-of-bounds recent_avg_pause_time_ratio() Summary: Added instrumentation and (temporary) assert in non-product mode; clipped the value when found out-of-bounds in product mode. Fix of original issue will follow collection of data from this instrumentation. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp Changeset: 23b9a8d315fc Author: ysr Date: 2009-11-19 10:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/23b9a8d315fc 6902701: G1: protect debugging code related to 6898948 with a debug flag Summary: Protected stats dump with a new develop flag; other than for the dump, reconciled product and non-product behaviour in face of the error. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 3fc996d4edd2 Author: ysr Date: 2009-11-19 13:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3fc996d4edd2 6902303: G1: ScavengeALot should cause an incremental, rather than a full, collection Summary: ScavengeALot now causes an incremental (but possibly partially young, in the G1 sense) collection. Some such collections may be abandoned on account of MMU specs. Band-aided a native leak associated with abandoned pauses, as well as an MMU tracker overflow related to frequent scavenge events in the face of a large MMU denominator interval; the latter is protected by a product flag that defaults to false. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/memory/sharedHeap.hpp Changeset: db0d5eba9d20 Author: tonyp Date: 2009-11-20 14:47 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/db0d5eba9d20 6815790: G1: Missing MemoryPoolMXBeans with -XX:+UseG1GC Summary: It introduces the necessary memory pools for G1. Reviewed-by: mchung, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/includeDB_gc_g1 + src/share/vm/services/g1MemoryPool.cpp + src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp Changeset: fa357420e7d2 Author: johnc Date: 2009-11-24 15:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fa357420e7d2 6899058: G1: Internal error in ptrQueue.cpp:201 in nightly tests Summary: Fixes a race on the dirty card queue completed buffer list between worker thread(s) performing a flush of a deferred store barrier (enqueueing a newly completed buffer) and worker thread(s) in the RSet updating code claiming completed buffers. Removed the routine that removes elements from the completed update buffer queue using a CAS. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp Changeset: 6aa7255741f3 Author: ysr Date: 2009-12-03 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6aa7255741f3 6906727: UseCompressedOops: some card-marking fixes related to object arrays Summary: Introduced a new write_ref_array(HeapWords* start, size_t count) method that does the requisite MemRegion range calculation so (some of the) clients of the erstwhile write_ref_array(MemRegion mr) do not need to worry. This removed all external uses of array_size(), which was also simplified and made private. Asserts were added to catch other possible issues. Further, less essential, fixes stemming from this investigation are deferred to CR 6904516 (to follow shortly in hs17). Reviewed-by: kvn, coleenp, jmasa ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayOop.hpp Changeset: ed52bcc32739 Author: tonyp Date: 2009-12-04 07:44 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ed52bcc32739 6880903: G1: G1 reports incorrect Runtime.maxMemory() Summary: G1 reports committed memory instead of reserved memory from the Runtime.maxMemory() method Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: afc30fccf324 Author: tonyp Date: 2009-12-04 07:44 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/afc30fccf324 6906565: G1: deal with compilation warning in g1MemoryPool.hpp Summary: size_t max_size() hides size_t max_size() const. Reviewed-by: jmasa, ysr ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 9118860519b6 Author: tonyp Date: 2009-12-07 14:22 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9118860519b6 6904967: G1: some CollectionUsageThreshold tests fail Summary: ensure that max and committed are non-zero (currently: at least as large as the region size). Reviewed-by: iveresov, mchung ! src/share/vm/services/g1MemoryPool.cpp Changeset: 7bfd295ec074 Author: ysr Date: 2009-12-08 15:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7bfd295ec074 6908208: UseCompressedOops: array_size() returns incorrect size for MAX_INT object array following 6906727 Summary: In array_size() cast to an unsigned to avoid overflow of intermediate value. Reviewed-by: kvn, tonyp, jmasa, jcoomes, coleenp ! src/share/vm/oops/objArrayOop.hpp Changeset: 84a2da7f454c Author: jmasa Date: 2009-12-11 08:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/84a2da7f454c Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/includeDB_core Changeset: 74e00f62c726 Author: trims Date: 2009-12-11 16:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/74e00f62c726 Merge Changeset: 61b46f7853d4 Author: trims Date: 2009-12-22 16:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/61b46f7853d4 Merge Changeset: c5d3d979ae27 Author: never Date: 2009-12-08 16:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c5d3d979ae27 6908167: jbb2005, OptimizeStringConcat causes assert in EA Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp Changeset: f96a1a986f7b Author: kvn Date: 2009-12-09 16:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f96a1a986f7b 6895383: JCK test throws NPE for method compiled with Escape Analysis Summary: Add missing checks for MemBar nodes in EA. Reviewed-by: never ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse3.cpp + test/compiler/6895383/Test.java Changeset: 7fee0a6cc6d4 Author: kvn Date: 2009-12-09 19:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7fee0a6cc6d4 6896727: nsk/logging/LoggingPermission/LoggingPermission/logperm002 fails with G1, EscapeAnalisys Summary: Move instance store's memory users to corresponding memory slices when updating its memory edge. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp + test/compiler/6896727/Test.java Changeset: 6dc5471e0f66 Author: iveresov Date: 2009-12-15 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6dc5471e0f66 Merge Changeset: 9dc2adf2cbe0 Author: johnc Date: 2009-12-09 23:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9dc2adf2cbe0 6908215: G1: SEGV with G1PolicyVerbose=2 debug flag Summary: Change CollectionSetChooser::printSortedHeapRegions to handle null entries in _markedRegions growable array. Reviewed-by: jmasa, tonyp, iveresov ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp Changeset: 27f9477e879b Author: jmasa Date: 2009-12-11 09:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/27f9477e879b Merge Changeset: cf9a9a50e763 Author: jmasa Date: 2009-12-17 07:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cf9a9a50e763 Merge Changeset: 22e4972db0a6 Author: trims Date: 2009-12-22 16:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/22e4972db0a6 Merge Changeset: 920875ae1277 Author: trims Date: 2009-12-22 16:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/920875ae1277 6912782: Bump the HS17 build number to 06 Summary: Update the HS17 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 85f13cdfbc1d Author: twisti Date: 2009-12-16 12:48 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/85f13cdfbc1d 6829192: JSR 292 needs to support 64-bit x86 Summary: changes for method handles and invokedynamic Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/share/vm/classfile/classFileParser.cpp Changeset: 032260830071 Author: never Date: 2009-12-16 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/032260830071 5057818: codecache full and compiler disabled in bigapps fastdebug run Reviewed-by: kvn ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 1ea456c6f2b7 Author: iveresov Date: 2009-12-22 17:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1ea456c6f2b7 Merge Changeset: 44f61c24ddab Author: iveresov Date: 2009-12-16 15:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/44f61c24ddab 6862387: tune concurrent refinement further Summary: Reworked the concurrent refinement: threads activation, feedback-based threshold adjustment, other miscellaneous fixes. Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.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 ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: cc0ca4f00e89 Author: jmasa Date: 2009-12-22 22:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cc0ca4f00e89 Merge Changeset: 7ac7d558e895 Author: jmasa Date: 2009-12-23 00:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7ac7d558e895 Merge Changeset: 9749fbc4859b Author: trims Date: 2009-12-23 02:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9749fbc4859b Merge Changeset: 4b966d9946a3 Author: mchung Date: 2009-11-25 08:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4b966d9946a3 6888880: JKernel VM to inject the sun.jkernel.DownloadManager as a boot classloader hook Summary: Call sun.jkernel.DownloadManager.setBootClassLoaderHook during the kernel VM initialization Reviewed-by: alanb, coleenp, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: 0018cf203583 Author: coleenp Date: 2009-12-02 07:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0018cf203583 Merge Changeset: 95e9083cf4a7 Author: dholmes Date: 2009-12-01 22:29 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/95e9083cf4a7 6822370: ReentrantReadWriteLock: threads hung when there are no threads holding onto the lock (Netra x4450) Summary: This day one bug is caused by missing memory barriers in various Parker::park() paths that can result in lost wakeups and hangs. Reviewed-by: dice, acorn ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 3115100553b5 Author: dholmes Date: 2009-12-02 20:32 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3115100553b5 Merge Changeset: 547f81740344 Author: minqi Date: 2009-12-11 11:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/547f81740344 6361589: Print out stack trace for target thread of GC crash Summary: If GC crashed with java thread involved, print out the java stack trace in error report Reviewed-by: never, ysr, coleenp, dholmes ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 9127aa69352e Author: dcubed Date: 2009-12-14 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9127aa69352e 6648438: 4/4 src/share/vm/prims/jvmtiEnv.cpp:457 assert(phase == JVMTI_PHASE_LIVE,"sanity check") Summary: Return error on invalid JVMTI_PHASE instead of asserting. Reviewed-by: dholmes, ohair ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 98cd9901c161 Author: dcubed Date: 2009-12-14 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/98cd9901c161 6849968: 3/2 JVMTI tests fails on jdk5.0 with hs14 Summary: If a JVMTI agent asks for version 1.0, then it should get version 1.0 semantics. Reviewed-by: dholmes, ohair ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiHpp.xsl Changeset: dcb15a6f342d Author: dcubed Date: 2009-12-14 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dcb15a6f342d Merge ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp Changeset: 167c2986d91b Author: phh Date: 2009-12-16 12:54 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/167c2986d91b 6843629: Make current hotspot build part of jdk5 control build Summary: Source changes for older compilers plus makefile changes. Reviewed-by: xlu ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/runtime/os.hpp Changeset: 2e8bdfdd3ba2 Author: xlu Date: 2009-12-16 13:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2e8bdfdd3ba2 6899467: System property java.class.version out-of-sync with VM for jdk 5.0 with HS 16 in nightly build Reviewed-by: kvn, never, dholmes, ysr ! src/share/vm/classfile/classFileParser.cpp Changeset: d48983315b71 Author: xlu Date: 2009-12-16 13:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d48983315b71 Merge Changeset: 933a3e806ce6 Author: xlu Date: 2009-12-16 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/933a3e806ce6 6895168: JCK api/signaturetest/sigtest.basic.html#basic test fails for jdk 5.0 with HS 16 in nightly build Reviewed-by: dholmes, acorn, jrose ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp Changeset: ba60f0a5d714 Author: xlu Date: 2009-12-16 15:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba60f0a5d714 Merge Changeset: 6952ed8677bf Author: xlu Date: 2009-12-17 01:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6952ed8677bf Merge Changeset: a5a6adfca6ec Author: trims Date: 2009-12-23 03:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a5a6adfca6ec Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 1bc68593a110 Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1bc68593a110 Added tag jdk7-b79 for changeset a5a6adfca6ec ! .hgtags From lana.steuck at sun.com Sat Jan 16 00:42:16 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:42:16 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b79 for changeset b1005c504358 Message-ID: <20100116004216.A2E9B417B2@hg.openjdk.java.net> Changeset: 9219574db593 Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/9219574db593 Added tag jdk7-b79 for changeset b1005c504358 ! .hgtags From lana.steuck at sun.com Sat Jan 16 00:42:22 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:42:22 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b79 for changeset c08894f5b6e5 Message-ID: <20100116004222.80255417B3@hg.openjdk.java.net> Changeset: 447767dee56a Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/447767dee56a Added tag jdk7-b79 for changeset c08894f5b6e5 ! .hgtags From lana.steuck at sun.com Sat Jan 16 00:42:38 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:42:38 +0000 Subject: hg: jdk7/tl/jdk: 7 new changesets Message-ID: <20100116004451.ACEFC417B4@hg.openjdk.java.net> Changeset: 9c352f7ed4a3 Author: jrose Date: 2009-10-21 23:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c352f7ed4a3 6891770: JSR 292 API needs initial unit tests Summary: backport working mlvm regression test to M3 implementation of JSR 292; requires jtreg 4.1 Reviewed-by: twisti + test/java/dyn/MethodHandlesTest.java Changeset: fc3d21b50545 Author: jrose Date: 2010-01-06 16:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fc3d21b50545 Merge Changeset: dbcf6cafa65c Author: jrose Date: 2010-01-07 16:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbcf6cafa65c 6914665: update jdk code for JSR 292 (post 6858164) Summary: Fill in missing API implementations, fix numerous bugs, adjust APIs towards EG design. Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java + src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/empty/Empty.java + src/share/classes/sun/dyn/util/BytecodeDescriptor.java ! src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/BytecodeSignature.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! src/share/classes/sun/dyn/util/VerifyType.java ! src/share/classes/sun/dyn/util/Wrapper.java ! test/java/dyn/MethodHandlesTest.java Changeset: 918920710d65 Author: jcoomes Date: 2010-01-13 15:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/918920710d65 Merge - src/share/classes/sun/dyn/util/BytecodeSignature.java Changeset: 756ab2266ffb Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/756ab2266ffb Added tag jdk7-b79 for changeset 918920710d65 ! .hgtags Changeset: b428c8f80209 Author: jgodinez Date: 2010-01-15 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b428c8f80209 6915906: tests in closed/javax/print/ should not be calling System.exit() Reviewed-by: igor, prr ! test/ProblemList.txt + test/javax/print/DialogMargins.java + test/javax/print/StreamPrintingOrientation.java + test/javax/print/attribute/AttributeTest.java + test/javax/print/attribute/ServiceDialogTest.java ! test/javax/print/attribute/SidesPageRangesTest.java Changeset: 64f7b789aecc Author: lana Date: 2010-01-15 15:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/64f7b789aecc Merge - src/share/classes/sun/dyn/util/BytecodeSignature.java From lana.steuck at sun.com Sat Jan 16 00:49:29 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Sat, 16 Jan 2010 00:49:29 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20100116004934.E6A48417B6@hg.openjdk.java.net> Changeset: f0074aa48d4e Author: katleman Date: 2010-01-14 15:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f0074aa48d4e Added tag jdk7-b79 for changeset ac5b4c5644ce ! .hgtags Changeset: a84062774f0e Author: lana Date: 2010-01-15 15:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a84062774f0e Merge From ptisnovs at redhat.com Mon Jan 18 10:09:15 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Mon, 18 Jan 2010 11:09:15 +0100 Subject: Please review changes in regression test test/java/security/Provider/Turkish.java Message-ID: <4B54334B.7030305@redhat.com> Hi, please review changes in regression test jtest/java/security/Provider/Turkish.java. Webrev is available at http://cr.openjdk.java.net/~ptisnovs/Turkish/ We already discussed similar issue on jdk6-dev mailing list, concretely in this thread: http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-December/thread.html#1056 Thanks in advance Pavel Tisnovsky Red Hat QA From Alan.Bateman at Sun.COM Mon Jan 18 10:19:39 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 18 Jan 2010 10:19:39 +0000 Subject: Please review changes in regression test test/java/security/Provider/Turkish.java In-Reply-To: <4B54334B.7030305@redhat.com> References: <4B54334B.7030305@redhat.com> Message-ID: <4B5435BB.6080003@sun.com> Pavel Tisnovsky wrote: > Hi, > > please review changes in regression test > jtest/java/security/Provider/Turkish.java. > > Webrev is available at http://cr.openjdk.java.net/~ptisnovs/Turkish/ > > We already discussed similar issue on jdk6-dev mailing list, > concretely in this thread: > http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-December/thread.html#1056 > > > Thanks in advance > Pavel Tisnovsky > Red Hat QA > Looks good to me. I've cc'ed security-dev, as this test is "owned" by the security group. You'll need a bugID for this so I have created: 6917663: test/java/security/Provider/Turkish.java not samevm friendly Regards, -Alan. From Xuelei.Fan at Sun.COM Mon Jan 18 11:56:19 2010 From: Xuelei.Fan at Sun.COM (Xuelei Fan) Date: Mon, 18 Jan 2010 19:56:19 +0800 Subject: [security-dev 01527]: Re: Please review changes in regression test test/java/security/Provider/Turkish.java In-Reply-To: <4B5435BB.6080003@sun.com> References: <4B54334B.7030305@redhat.com> <4B5435BB.6080003@sun.com> Message-ID: <4B544C63.5030202@Sun.COM> Alan Bateman wrote: > Pavel Tisnovsky wrote: >> Hi, >> >> please review changes in regression test >> jtest/java/security/Provider/Turkish.java. >> >> Webrev is available at http://cr.openjdk.java.net/~ptisnovs/Turkish/ >> >> We already discussed similar issue on jdk6-dev mailing list, >> concretely in this thread: >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-December/thread.html#1056 >> >> >> Thanks in advance >> Pavel Tisnovsky >> Red Hat QA >> > Looks good to me. I've cc'ed security-dev, as this test is "owned" by > the security group. > Looks good to me, too. Regards, Xuelei > You'll need a bugID for this so I have created: > 6917663: test/java/security/Provider/Turkish.java not samevm friendly > > Regards, > > -Alan. From christopher.hegarty at sun.com Mon Jan 18 14:02:37 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 18 Jan 2010 14:02:37 +0000 Subject: hg: jdk7/tl/jdk: 6916890: (sctp) SctpChannel.send may cause IAE if given a heap buffer with an offset Message-ID: <20100118140339.1638341B9C@hg.openjdk.java.net> Changeset: 680d7d312a30 Author: chegar Date: 2010-01-18 14:01 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/680d7d312a30 6916890: (sctp) SctpChannel.send may cause IAE if given a heap buffer with an offset Reviewed-by: alanb ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! test/com/sun/nio/sctp/SctpChannel/Send.java ! test/com/sun/nio/sctp/SctpMultiChannel/Send.java From christopher.hegarty at sun.com Mon Jan 18 14:56:49 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 18 Jan 2010 14:56:49 +0000 Subject: hg: jdk7/tl/jdk: 6917317: (sctp) Remove dependency on handleSocketError Message-ID: <20100118145708.8291541BAE@hg.openjdk.java.net> Changeset: e0870a19b09e Author: chegar Date: 2010-01-18 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0870a19b09e 6917317: (sctp) Remove dependency on handleSocketError Reviewed-by: alanb ! src/solaris/native/sun/nio/ch/SctpNet.c ! test/com/sun/nio/sctp/SctpChannel/Connect.java From alan.bateman at sun.com Mon Jan 18 15:26:04 2010 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Mon, 18 Jan 2010 15:26:04 +0000 Subject: hg: jdk7/tl/jdk: 6917021: (file) copyTo/moveTo can overrwrite existing file when target associated with custom provider Message-ID: <20100118152623.49B9141BB8@hg.openjdk.java.net> Changeset: 42894ae6671c Author: alanb Date: 2010-01-18 15:21 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42894ae6671c 6917021: (file) copyTo/moveTo can overrwrite existing file when target associated with custom provider Reviewed-by: chegar ! src/share/classes/sun/nio/fs/AbstractPath.java ! test/java/nio/file/Path/CopyAndMove.java + test/java/nio/file/Path/PassThroughFileSystem.java ! test/java/nio/file/TestUtil.java From ptisnovs at redhat.com Mon Jan 18 16:54:07 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Mon, 18 Jan 2010 16:54:07 +0000 Subject: hg: jdk7/tl/jdk: 6917663: test/java/security/Provider/Turkish.java not samevm friendly Message-ID: <20100118165426.4B6B241BCF@hg.openjdk.java.net> Changeset: 7f2b99bd5123 Author: ptisnovs Date: 2010-01-18 17:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f2b99bd5123 6917663: test/java/security/Provider/Turkish.java not samevm friendly Summary: Added othervm flag to ensure that this test will run in isolation. Reviewed-by: alanb ! test/java/security/Provider/Turkish.java From gnu_andrew at member.fsf.org Mon Jan 18 17:13:10 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 18 Jan 2010 17:13:10 +0000 Subject: Please review changes in regression test test/java/security/Provider/Turkish.java In-Reply-To: <4B5435BB.6080003@sun.com> References: <4B54334B.7030305@redhat.com> <4B5435BB.6080003@sun.com> Message-ID: <17c6771e1001180913w6d3df03dy6aae4076d19d2e94@mail.gmail.com> 2010/1/18 Alan Bateman : > Pavel Tisnovsky wrote: >> >> Hi, >> >> please review changes in regression test >> jtest/java/security/Provider/Turkish.java. >> >> Webrev is available at http://cr.openjdk.java.net/~ptisnovs/Turkish/ >> >> We already discussed similar issue on jdk6-dev mailing list, concretely in >> this thread: >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-December/thread.html#1056 >> >> Thanks in advance >> Pavel Tisnovsky >> Red Hat QA >> > Looks good to me. I've cc'ed security-dev, as this test is "owned" by the > security group. > > You'll need a bugID for this so I have created: > ?6917663: test/java/security/Provider/Turkish.java not samevm friendly > > Regards, > > -Alan. > As mentioned by Joe (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-January/001135.html) patches for jdk6 should be sent to the jdk6-dev list before being pushed to the jdk6 tree. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Alan.Bateman at Sun.COM Mon Jan 18 17:32:15 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 18 Jan 2010 17:32:15 +0000 Subject: Please review changes in regression test test/java/security/Provider/Turkish.java In-Reply-To: <17c6771e1001180913w6d3df03dy6aae4076d19d2e94@mail.gmail.com> References: <4B54334B.7030305@redhat.com> <4B5435BB.6080003@sun.com> <17c6771e1001180913w6d3df03dy6aae4076d19d2e94@mail.gmail.com> Message-ID: <4B549B1F.7020402@sun.com> Andrew John Hughes wrote: > : > As mentioned by Joe > (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-January/001135.html) > patches for jdk6 should be sent to the jdk6-dev list before being > pushed to the jdk6 tree. > It might be good to also ping the mailing list for the area (as I don't think everyone is subscribed to jdk6-dev). -Alan. From gnu_andrew at member.fsf.org Mon Jan 18 18:45:02 2010 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 18 Jan 2010 18:45:02 +0000 Subject: Please review changes in regression test test/java/security/Provider/Turkish.java In-Reply-To: <4B549B1F.7020402@sun.com> References: <4B54334B.7030305@redhat.com> <4B5435BB.6080003@sun.com> <17c6771e1001180913w6d3df03dy6aae4076d19d2e94@mail.gmail.com> <4B549B1F.7020402@sun.com> Message-ID: <17c6771e1001181045o5691efbbu470ceea1d86adb84@mail.gmail.com> 2010/1/18 Alan Bateman : > Andrew John Hughes wrote: >> >> : >> As mentioned by Joe >> (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-January/001135.html) >> patches for jdk6 should be sent to the jdk6-dev list before being >> pushed to the jdk6 tree. >> > > It might be good to also ping the mailing list for the area (as I don't > think everyone is subscribed to jdk6-dev). > > -Alan. > > Yes, sorry, I meant that jdk6-dev should be in addition to the normal area list, if the patch is also intended for OpenJDK6. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From n-roeser at gmx.net Mon Jan 18 19:39:01 2010 From: n-roeser at gmx.net (Nico R.) Date: Mon, 18 Jan 2010 20:39:01 +0100 Subject: jdk6: LazyInitialization in java.io.File Message-ID: <4B54B8D5.3050309@gmx.net> Hello! In java.io.File.createTempFile(String,String,File) (see ), line 1797 says: String tmpDir = LazyInitialization.temporaryDirectory(); LazyInitialization, line 1683, has static final String temporaryDirectory = temporaryDirectory(); Shouldn?t the createTempFile method read from the /field/ in LazyInitialization instead of calling the /method/? If I got this correctly, the brackets in line 1797 should be removed. Regards -- Nico From Thomas.Hawtin at Sun.COM Mon Jan 18 20:07:27 2010 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 18 Jan 2010 20:07:27 +0000 Subject: jdk6: LazyInitialization in java.io.File In-Reply-To: <4B54B8D5.3050309@gmx.net> References: <4B54B8D5.3050309@gmx.net> Message-ID: <4B54BF7F.40906@sun.com> Nico R. wrote: > In java.io.File.createTempFile(String,String,File) (see > ), > line 1797 says: > > String tmpDir = LazyInitialization.temporaryDirectory(); > > LazyInitialization, line 1683, has > > static final String temporaryDirectory = temporaryDirectory(); > > > Shouldn?t the createTempFile method read from the /field/ in > LazyInitialization instead of calling the /method/? If I got this > correctly, the brackets in line 1797 should be removed. Well spotted. Prior to the CR 6721753[1] fix File.getTempDir hand-coded lazy initialisation of tmpdir. It shouldn't make an enormous amount of difference: updates to the system property currently change the temp directory used; the performance degredation should be trivial. I guess Alan will sort it. Tom [1] http://sunsolve.sun.com/search/document.do?assetkey=1-66-244986-1 From Alan.Bateman at Sun.COM Mon Jan 18 20:09:20 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 18 Jan 2010 20:09:20 +0000 Subject: jdk6: LazyInitialization in java.io.File In-Reply-To: <4B54B8D5.3050309@gmx.net> References: <4B54B8D5.3050309@gmx.net> Message-ID: <4B54BFF0.4070809@sun.com> Nico R. wrote: > Hello! > > In java.io.File.createTempFile(String,String,File) (see > ), > line 1797 says: > > String tmpDir = LazyInitialization.temporaryDirectory(); > > LazyInitialization, line 1683, has > > static final String temporaryDirectory = temporaryDirectory(); > > > Shouldn?t the createTempFile method read from the /field/ in > LazyInitialization instead of calling the /method/? If I got this > correctly, the brackets in line 1797 should be removed. > > Regards > Well spotted - that's what we get for having a field and method with the same name! That code has been replaced in jdk7 so it's not an issue there. For jdk6 code we should just initialize a field to the property value (like in jdk7) and the temporaryDirectory method return the value. -Alan. From mandy.chung at sun.com Mon Jan 18 23:24:16 2010 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Mon, 18 Jan 2010 23:24:16 +0000 Subject: hg: jdk7/tl/jdk: 6916217: make/modules/Makefile requires ALT_JDK_IMPORT_PATH Message-ID: <20100118232435.C6F1841C37@hg.openjdk.java.net> Changeset: 056d88d0f4d4 Author: mchung Date: 2010-01-18 15:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/056d88d0f4d4 6916217: make/modules/Makefile requires ALT_JDK_IMPORT_PATH Summary: build modules not depending on ALT_JDK_IMPORT_PATH being set Reviewed-by: alanb ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/modules/Makefile ! make/modules/optional.depconfig ! make/modules/tools/Makefile From weijun.wang at sun.com Tue Jan 19 03:45:27 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 19 Jan 2010 03:45:27 +0000 Subject: hg: jdk7/tl/jdk: 6917791: KeyTabEntry, when the byte value smaller then 16, the string drop '0' Message-ID: <20100119034546.1648241C7D@hg.openjdk.java.net> Changeset: 8339fd49bf6b Author: weijun Date: 2010-01-19 11:43 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8339fd49bf6b 6917791: KeyTabEntry, when the byte value smaller then 16, the string drop '0' Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java + test/sun/security/krb5/ktab/KeyString.java From jonathan.gibbons at sun.com Tue Jan 19 22:29:49 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 19 Jan 2010 22:29:49 +0000 Subject: hg: jdk7/tl/langtools: 6917067: refactor type annotations code from TransTypes into new TypeAnnotations class Message-ID: <20100119222957.6AB1341DBA@hg.openjdk.java.net> Changeset: f23b985beb78 Author: jjg Date: 2010-01-19 14:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f23b985beb78 6917067: refactor type annotations code from TransTypes into new TypeAnnotations class Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu + src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java From xuelei.fan at sun.com Wed Jan 20 13:44:32 2010 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Wed, 20 Jan 2010 13:44:32 +0000 Subject: hg: jdk7/tl/jdk: 6862064: incorrect implementation of PKIXParameters.clone() Message-ID: <20100120134513.2F5B541EB0@hg.openjdk.java.net> Changeset: dca3a251a001 Author: xuelei Date: 2010-01-20 21:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dca3a251a001 6862064: incorrect implementation of PKIXParameters.clone() Reviewed-by: weijun, mullan ! src/share/classes/java/security/cert/PKIXParameters.java From jeffhain at rocketmail.com Wed Jan 20 21:01:11 2010 From: jeffhain at rocketmail.com (Jeff Hain) Date: Wed, 20 Jan 2010 13:01:11 -0800 (PST) Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) Message-ID: <300042.18775.qm@web29205.mail.ird.yahoo.com> Hello. I happen to already have developped some pure Java version of ceil(double) and floor(double). It looks faster to me. But maybe is it incorrect ? (it's tested, but I'm never sure) Here it is : public class FloorCeil { ??? private static final double TWO_POW_26 = Double.longBitsToDouble(0x4190000000000000L); ??? private static final double TWO_POW_N26 = Double.longBitsToDouble(0x3E50000000000000L); ??? private static final double TWO_POW_52 = Double.longBitsToDouble(0x4330000000000000L); ??? public static double floor(double value) { ??????? // Faster than to work directly on bits. ??????? if (Math.abs(value) <= (double)Integer.MAX_VALUE) { ??????????? if (value > 0.0) { ??????????????? return (double)(int)value; ??????????? } else if (value < 0.0) { ??????????????? double anteComaDigits = (double)(int)value; ??????????????? if (value != anteComaDigits) { ??????????????????? return anteComaDigits - 1.0; ??????????????? } else { ??????????????????? return anteComaDigits; ??????????????? } ??????????? } else { // value is +-0.0 (not NaN due to test against Integer.MAX_VALUE) ??????????????? return value; ??????????? } ??????? } else if (Math.abs(value) < TWO_POW_52) { ??????????? // We split the value in two: ??????????? // high part, which is a mathematical integer, ??????????? // and the rest, for which we can get rid of the ??????????? // post coma digits by casting into an int. ??????????? double highPart = ((int)(value * TWO_POW_N26)) * TWO_POW_26; ??????????? if (value > 0.0) { ??????????????? return highPart + (double)((int)(value - highPart)); ??????????? } else { ??????????????? double anteComaDigits = highPart + (double)((int)(value - highPart)); ??????????????? if (value != anteComaDigits) { ??????????????????? return anteComaDigits - 1.0; ??????????????? } else { ??????????????????? return anteComaDigits; ??????????????? } ??????????? } ??????? } else { // abs(value) >= 2^52, or value is NaN ??????????? return value; ??????? } ??? } ??? public static double ceil(double value) { ??????? return -floor(-value); ??? } } Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at sun.com Wed Jan 20 23:19:50 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 20 Jan 2010 23:19:50 +0000 Subject: hg: jdk7/tl/jdk: 6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining Message-ID: <20100120232009.5BE3B41F53@hg.openjdk.java.net> Changeset: b19cd193245e Author: dcubed Date: 2010-01-20 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b19cd193245e 6580131: 3/4 CompiledMethodLoad events don't produce the expected extra notifications to describe inlining Summary: Add support for additional implementation specific info to the JVM/TI CompiledMethodLoad event via the compile_info parameter. Reviewed-by: never, ohair, tbell, tdeneau Contributed-by: Vasanth Venkatachalam ! make/common/shared/Sanity.gmk ! make/java/jvm/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/jvmti/README.txt + make/mkdemo/jvmti/compiledMethodLoad/Makefile + src/share/demo/jvmti/compiledMethodLoad/README.txt + src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c + src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/index.html + src/share/javavm/export/jvmticmlr.h + test/demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java ! test/demo/jvmti/heapTracker/HeapTrackerTest.java ! test/demo/jvmti/hprof/CpuTimesDefineClassTest.java ! test/demo/jvmti/hprof/CpuTimesTest.java ! test/demo/jvmti/minst/MinstTest.java ! test/demo/jvmti/mtrace/TraceJFrame.java From jonathan.gibbons at sun.com Thu Jan 21 00:13:27 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Thu, 21 Jan 2010 00:13:27 +0000 Subject: hg: jdk7/tl/langtools: 6918127: improve handling of TypeAnnotationPosition fields Message-ID: <20100121001329.CEC7541F61@hg.openjdk.java.net> Changeset: 0eaf89e08564 Author: jjg Date: 2010-01-20 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0eaf89e08564 6918127: improve handling of TypeAnnotationPosition fields Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java From Dmitry.Nadezhin at Sun.COM Thu Jan 21 06:27:05 2010 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Thu, 21 Jan 2010 09:27:05 +0300 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <300042.18775.qm@web29205.mail.ird.yahoo.com> References: <300042.18775.qm@web29205.mail.ird.yahoo.com> Message-ID: <4B57F3B9.6070602@sun.com> Jeff, Your"ceil" and "floor" seems correct for me. I benchmarked your code by attached benchmark program. It is faster on some test patterns and with some Jvm options and it is slower on some others. Joe, I'm curious how performance decisions are made in Jdk development process. Are there performance benchmarks in Jdk source tree ? Which platforms are considered and with which weight ? -Dima The benchmarks results on my OpenSolaris opteron computer (jdk7-b79): pattern1 is {+0.0, +0.5, +1.0, +1.5, +2.0, +2.5, +3.0, +3.5, +4.0}. pattern2 is {+0.0, -0.0, +1.5, -1.5, 1000.0, -1000.0, (1L << 40), -(1L << 40), Double.POSITIVE_INFINITY, Double.NEGATIVE_INFINITY}. *** pattern1 -d32 -client empty took 2,52 nsec Math.ceil took 24,23 nsec Math.floor took 23,56 nsec StrictMath.ceil took 24,59 nsec StrictMath.floor took 24,08 nsec FloorCeil.ceil took 13,91 nsec FloorCeil.floor took 11,31 nsec *** pattern1 -d32 -server empty took 1,67 nsec Math.ceil took 10,29 nsec Math.floor took 10,44 nsec StrictMath.ceil took 10,27 nsec StrictMath.floor took 10,44 nsec FloorCeil.ceil took 9,01 nsec FloorCeil.floor took 5,28 nsec *** pattern1 -d64 -client empty took 1,69 nsec Math.ceil took 6,92 nsec Math.floor took 6,18 nsec StrictMath.ceil took 6,90 nsec StrictMath.floor took 6,18 nsec FloorCeil.ceil took 8,31 nsec FloorCeil.floor took 5,35 nsec *** pattern1 -d64 -server empty took 1,67 nsec Math.ceil took 6,73 nsec Math.floor took 6,07 nsec StrictMath.ceil took 6,73 nsec StrictMath.floor took 6,07 nsec FloorCeil.ceil took 9,00 nsec FloorCeil.floor took 5,25 nsec *** pattern2 -d32 -client empty took 2,58 nsec Math.ceil took 24,24 nsec Math.floor took 23,99 nsec StrictMath.ceil took 24,25 nsec StrictMath.floor took 24,34 nsec FloorCeil.ceil took 15,94 nsec FloorCeil.floor took 16,45 nsec *** pattern2 -d32 -server empty took 1,67 nsec Math.ceil took 12,38 nsec Math.floor took 12,26 nsec StrictMath.ceil took 12,54 nsec StrictMath.floor took 12,31 nsec FloorCeil.ceil took 9,08 nsec FloorCeil.floor took 9,64 nsec *** pattern2 -d64 -client empty took 1,67 nsec Math.ceil took 6,07 nsec Math.floor took 6,33 nsec StrictMath.ceil took 6,00 nsec StrictMath.floor took 6,39 nsec FloorCeil.ceil took 9,81 nsec FloorCeil.floor took 7,39 nsec *** pattern2 -d64 -server empty took 1,67 nsec Math.ceil took 6,32 nsec Math.floor took 6,27 nsec StrictMath.ceil took 6,40 nsec StrictMath.floor took 6,37 nsec FloorCeil.ceil took 9,69 nsec FloorCeil.floor took 7,39 nsec ------------------------ The benchmark code package floorceilingtests; public class Main { public static void main(String[] args) { double[] a = new double[1000]; int pattern = 1; switch (pattern) { case 1: pattern1(a); break; case 2: pattern2(a); break; } new Main().test(a); } private static void pattern1(double[] a) { for (int i = 0; i < a.length; i += 10) { a[i+0] = +0.0; a[i+2] = +0.5; a[i+3] = +1.0; a[i+4] = +1.5; a[i+5] = +2.0; a[i+6] = +2.5; a[i+7] = +3.0; a[i+8] = +3.5; a[i+9] = +4.0; } } private static void pattern2(double[] a) { for (int i = 0; i < a.length; i += 10) { a[i+0] = +0.0; a[i+1] = -0.0; a[i+2] = +1.5; a[i+3] = -1.5; a[i+4] = 1000.0; a[i+5] = -1000.0; a[i+6] = (1L << 40); a[i+7] = -(1L << 40); a[i+8] = Double.POSITIVE_INFINITY; a[i+9] = Double.NEGATIVE_INFINITY; } } private void test (double[] args) { for (int i = 0; i < 5; i++) { System.out.println(); for (Benchmark b: benchmarks) { b.run(args, 100000); } } } private Benchmark[] benchmarks = { new Benchmark("empty") { double run(double[] args) { double s = 0; for (double d: args) { s += d; } return s; } }, new Benchmark("Math.ceil") { double run(double[] args) { double s = 0; for (double d: args) { s += Math.ceil(d); } return s; } }, new Benchmark("Math.floor") { double run(double[] args) { double s = 0; for (double d: args) { s += Math.floor(d); } return s; } }, new Benchmark("StrictMath.ceil") { double run(double[] args) { double s = 0; for (double d: args) { s += StrictMath.ceil(d); } return s; } }, new Benchmark("StrictMath.floor") { double run(double[] args) { double s = 0; for (double d: args) { s += StrictMath.floor(d); } return s; } }, new Benchmark("FloorCeil.ceil") { double run(double[] args) { double s = 0; for (double d: args) { s += FloorCeil.ceil(d); } return s; } }, new Benchmark("FloorCeil.floor") { double run(double[] args) { double s = 0; for (double d: args) { s += FloorCeil.floor(d); } return s; } } }; private abstract static class Benchmark { private final String name; private Benchmark(String name) { this.name = name; } abstract double run(double[] args); void run(double[] args, int repeatCount) { long startTime = System.nanoTime(); double s = 0; for (int i = 0; i < repeatCount; i++) { s += run(args); } long stopTime = System.nanoTime(); System.out.printf("%-20s took %10.2f nsec %s\n", name, (stopTime - startTime)/(double)repeatCount/args.length, s > 0 ? " " : ""); } } } ------------------------ Jeff Hain wrote: > Hello. > > I happen to already have developped some pure Java version of > ceil(double) and floor(double). > It looks faster to me. But maybe is it incorrect ? (it's tested, but > I'm never sure) > Here it is : > > public class FloorCeil { > private static final double TWO_POW_26 = > Double.longBitsToDouble(0x4190000000000000L); > private static final double TWO_POW_N26 = > Double.longBitsToDouble(0x3E50000000000000L); > private static final double TWO_POW_52 = > Double.longBitsToDouble(0x4330000000000000L); > public static double floor(double value) { > // Faster than to work directly on bits. > if (Math.abs(value) <= (double)Integer.MAX_VALUE) { > if (value > 0.0) { > return (double)(int)value; > } else if (value < 0.0) { > double anteComaDigits = (double)(int)value; > if (value != anteComaDigits) { > return anteComaDigits - 1.0; > } else { > return anteComaDigits; > } > } else { // value is +-0.0 (not NaN due to test against > Integer.MAX_VALUE) > return value; > } > } else if (Math.abs(value) < TWO_POW_52) { > // We split the value in two: > // high part, which is a mathematical integer, > // and the rest, for which we can get rid of the > // post coma digits by casting into an int. > double highPart = ((int)(value * TWO_POW_N26)) * TWO_POW_26; > if (value > 0.0) { > return highPart + (double)((int)(value - highPart)); > } else { > double anteComaDigits = highPart + > (double)((int)(value - highPart)); > if (value != anteComaDigits) { > return anteComaDigits - 1.0; > } else { > return anteComaDigits; > } > } > } else { // abs(value) >= 2^52, or value is NaN > return value; > } > } > public static double ceil(double value) { > return -floor(-value); > } > } > > Jeff > > > > From jeffhain at rocketmail.com Thu Jan 21 20:58:16 2010 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 21 Jan 2010 12:58:16 -0800 (PST) Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) Message-ID: <815589.7518.qm@web29207.mail.ird.yahoo.com> ? Dmitry, From your bench, I see FloorCeil methods get in trouble with 64 bits architecture, but I never ran anything on 64 bits yet. I ran your bench on my laptop: - DELL inspiron 9400, with (two) Genuine Intel T2300 @ 1.666GHz. - java.runtime.version=1.6.0_11-b03 - java.class.version=50.0 - os.name=Windows XP - os.arch=x86 - os.version=5.1 I added two patterns: - pattern3 ("common" case (for doubles) of non-integer values) { ??????????? 0.1, -0.1, ??????? 1e4+0.1, -1e4-0.1, ??????? 1e8+0.1, -1e8-0.1, ?????? 1e12+0.1, -1e12-0.1, ?? (1L<<52)/1.1, -(1L<<52)/1.1} - pattern4 (case of integer values) { ??????????? 0.0, -0.0, ??????????? 1e4, -1e4, ??????????? 1e8, -1e8, ?????? (1L<<52), -(1L<<52), ?????? (1L<<60), -(1L<<60)} I also added test of the?pure Java StrictMath class (which is the one you ran as "StrictMath" in your bench?) posted on this subject: "StrictMath_JD". Here is what I got: ? ----------------------------------------- - CLIENT ----------------------------------------- ? pattern 1: empty??????????????? took?????? 4,42 nsec? Math.ceil??????????? took????? 63,77 nsec? Math.floor?????????? took????? 67,55 nsec? StrictMath.ceil????? took????? 64,20 nsec? StrictMath.floor???? took????? 68,76 nsec? StrictMath_JD.ceil?? took????? 52,58 nsec? StrictMath_JD.floor? took????? 53,57 nsec? FloorCeil.ceil?????? took????? 24,31 nsec? FloorCeil.floor????? took????? 18,37 nsec? ? pattern 2: empty??????????????? took?????? 4,50 nsec Math.ceil??????????? took???? 110,95 nsec Math.floor?????????? took???? 110,42 nsec StrictMath.ceil????? took???? 111,38 nsec StrictMath.floor???? took???? 110,97 nsec StrictMath_JD.ceil?? took????? 48,95 nsec StrictMath_JD.floor? took????? 49,38 nsec FloorCeil.ceil?????? took????? 23,29 nsec FloorCeil.floor????? took????? 20,81 nsec ? pattern 3: empty??????????????? took?????? 4,39 nsec Math.ceil??????????? took???? 111,72 nsec Math.floor?????????? took???? 114,48 nsec StrictMath.ceil????? took???? 113,68 nsec StrictMath.floor???? took???? 114,32 nsec StrictMath_JD.ceil?? took????? 60,23 nsec StrictMath_JD..floor? took????? 60,13 nsec FloorCeil.ceil?????? took????? 27,11 nsec FloorCeil.floor????? took????? 23,77 nsec ? pattern 4: empty??????????????? took?????? 4,38 nsec Math.ceil??????????? took???? 113,49 nsec Math.floor?????????? took???? 113,34 nsec StrictMath.ceil????? took???? 110,35 nsec StrictMath.floor???? took???? 112,95 nsec StrictMath_JD.ceil?? took????? 43,69 nsec StrictMath_JD.floor? took????? 44,28 nsec FloorCeil.ceil?????? took????? 22,09 nsec FloorCeil.floor????? took????? 18,71 nsec ? ----------------------------------------- - SERVER ----------------------------------------- ? pattern 1: empty??????????????? took?????? 2,40 nsec? Math.ceil??????????? took????? 64,61 nsec? Math.floor?????????? took????? 65,14 nsec? StrictMath.ceil????? took????? 63,93 nsec? StrictMath.floor???? took????? 65,99 nsec? StrictMath_JD.ceil?? took????? 37,52 nsec? StrictMath_JD.floor? took????? 39,77 nsec? FloorCeil.ceil?????? took????? 21,36 nsec? FloorCeil.floor????? took????? 13,96 nsec? ? pattern 2: empty??????????????? took?????? 2,23 nsec Math.ceil??????????? took???? 112,42 nsec Math.floor?????????? took???? 110,88 nsec StrictMath.ceil????? took???? 112,05 nsec StrictMath.floor???? took???? 113,54 nsec StrictMath_JD.ceil?? took????? 33,98 nsec StrictMath_JD.floor? took????? 33,97 nsec FloorCeil.ceil?????? took????? 22,09 nsec FloorCeil.floor????? took????? 16,75 nsec ? pattern 3: empty??????????????? took?????? 2,19 nsec Math.ceil??????????? took???? 113,67 nsec Math.floor?????????? took???? 113,53 nsec StrictMath.ceil????? took???? 114,46 nsec StrictMath.floor???? took???? 115,02 nsec StrictMath_JD.ceil?? took????? 44,19 nsec StrictMath_JD.floor? took????? 43,57 nsec FloorCeil.ceil?????? took????? 25,57 nsec FloorCeil.floor????? took????? 20,95 nsec ? pattern 4: empty??????????????? took?????? 2,45 nsec Math.ceil??????????? took???? 108,56 nsec Math.floor?????????? took???? 112,96 nsec StrictMath.ceil????? took???? 109,43 nsec StrictMath.floor???? took???? 113,14 nsec StrictMath_JD.ceil?? took????? 30,18 nsec StrictMath_JD..floor? took????? 31,07 nsec FloorCeil.ceil?????? took????? 18,11 nsec FloorCeil.floor????? took????? 15,91 nsec ? ----------------------------------------- Jeff PS?: The ceil and floor I posted here are an extract of a FastMath class (I already ???? see some people in this mailing list invoking the gods against me while having ???? a heart attack at the hearing of this class name) I did, and put on source ???? forge (I already told about it in this list few months ago): maybe some of ???? you might want to take a look at it (it's called "FastMath", but not ALL of ???? its treatments are wrong...). -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Darcy at Sun.COM Thu Jan 21 22:38:49 2010 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Thu, 21 Jan 2010 14:38:49 -0800 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <815589.7518.qm@web29207.mail.ird.yahoo.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> Message-ID: <4B58D779.50004@sun.com> A few comments. First, part and parcel of doing numerical libraries work is developing tests; see, "Test where the failures are likely to be" (http://blogs.sun.com/darcy/entry/test_where_the_failures_are). An obvious set of tests to run are the regression tests I wrote as part of the fix for this bug (http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/ad1e30930c6c). Second, micro-benchmarking Java programs is a subtle art; see Cliff Click's various writeups for guidance, including http://www.azulsystems.com/events/javaone_2002/microbenchmarks.pdf http://blogs.azulsystems.com/cliff/2008/03/another-round-o.html http://www.azulsystems.com/events/javaone_2009/session/2009_J1_Benchmark.pdf Various benchmarks are examined by the performance team. You can assume benchmarks Sun publishes numbers on are included in the set of benchmarks of interest :-) -Joe Jeff Hain wrote: > > Dmitry, > > From your bench, I see FloorCeil methods get in trouble > with 64 bits architecture, but I never ran anything on 64 bits yet. > > I ran your bench on my laptop: > - DELL inspiron 9400, with (two) Genuine Intel T2300 @ 1.666GHz. > - java.runtime.version=1.6.0_11-b03 > - java.class.version=50.0 > - os.name=Windows XP > - os.arch=x86 > - os..version=5.1 > > I added two patterns: > - pattern3 ("common" case (for doubles) of non-integer values) { > 0.1, -0.1, > 1e4+0.1, -1e4-0.1, > 1e8+0.1, -1e8-0.1, > 1e12+0.1, -1e12-0.1, > (1L<<52)/1.1, -(1L<<52)/1.1} > - pattern4 (case of integer values) { > 0.0, -0.0, > 1e4, -1e4, > 1e8, -1e8, > (1L<<52), -(1L<<52), > (1L<<60), -(1L<<60)} > > I also added test of the pure Java StrictMath class (which is the one > you ran > as "StrictMath" in your bench?) posted on this subject: "StrictMath_JD". > > Here is what I got: > > ----------------------------------------- > - CLIENT > ----------------------------------------- > > pattern 1: > empty took 4,42 nsec > Math.ceil took 63,77 nsec > Math.floor took 67,55 nsec > StrictMath.ceil took 64,20 nsec > StrictMath.floor took 68,76 nsec > StrictMath_JD.ceil took 52,58 nsec > StrictMath_JD.floor took 53,57 nsec > FloorCeil.ceil took 24,31 nsec > FloorCeil.floor took 18,37 nsec > > pattern 2: > empty took 4,50 nsec > Math.ceil took 110,95 nsec > Math.floor took 110,42 nsec > StrictMath.ceil took 111,38 nsec > StrictMath.floor took 110,97 nsec > StrictMath_JD.ceil took 48,95 nsec > StrictMath_JD.floor took 49,38 nsec > FloorCeil.ceil took 23,29 nsec > FloorCeil.floor took 20,81 nsec > > pattern 3: > empty took 4,39 nsec > Math.ceil took 111,72 nsec > Math.floor took 114,48 nsec > StrictMath.ceil took 113,68 nsec > StrictMath.floor took 114,32 nsec > StrictMath_JD.ceil took 60,23 nsec > StrictMath_JD.floor took 60,13 nsec > FloorCeil.ceil took 27,11 nsec > FloorCeil.floor took 23,77 nsec > > pattern 4: > empty took 4,38 nsec > Math.ceil took 113,49 nsec > Math.floor took 113,34 nsec > StrictMath.ceil took 110,35 nsec > StrictMath.floor took 112,95 nsec > StrictMath_JD.ceil took 43,69 nsec > StrictMath_JD.floor took 44,28 nsec > FloorCeil.ceil took 22,09 nsec > FloorCeil.floor took 18,71 nsec > > ----------------------------------------- > - SERVER > ----------------------------------------- > > pattern 1: > empty took 2,40 nsec > Math.ceil took 64,61 nsec > Math.floor took 65,14 nsec > StrictMath.ceil took 63,93 nsec > StrictMath.floor took 65,99 nsec > StrictMath_JD.ceil took 37,52 nsec > StrictMath_JD.floor took 39,77 nsec > FloorCeil.ceil took 21,36 nsec > FloorCeil.floor took 13,96 nsec > > pattern 2: > empty took 2,23 nsec > Math.ceil took 112,42 nsec > Math.floor took 110,88 nsec > StrictMath.ceil took 112,05 nsec > StrictMath.floor took 113,54 nsec > StrictMath_JD.ceil took 33,98 nsec > StrictMath_JD.floor took 33,97 nsec > FloorCeil.ceil took 22,09 nsec > FloorCeil.floor took 16,75 nsec > > pattern 3: > empty took 2,19 nsec > Math.ceil took 113,67 nsec > Math.floor took 113,53 nsec > StrictMath.ceil took 114,46 nsec > StrictMath.floor took 115,02 nsec > StrictMath_JD.ceil took 44,19 nsec > StrictMath_JD.floor took 43,57 nsec > FloorCeil.ceil took 25,57 nsec > FloorCeil.floor took 20,95 nsec > > pattern 4: > empty took 2,45 nsec > Math.ceil took 108,56 nsec > Math.floor took 112,96 nsec > StrictMath.ceil took 109,43 nsec > StrictMath.floor took 113,14 nsec > StrictMath_JD.ceil took 30,18 nsec > StrictMath_JD.floor took 31,07 nsec > FloorCeil.ceil took 18,11 nsec > FloorCeil.floor took 15,91 nsec > > ----------------------------------------- > > Jeff > PS : The ceil and floor I posted here are an extract of a FastMath class > (I already > see some people in this mailing list invoking the gods against me > while having > a heart attack at the hearing of this class name) I did, and put on > source > forge (I already told about it in this list few months ago): maybe > some of > you might want to take a look at it (it's called "FastMath", but > not ALL of > its treatments are wrong...). > > From vincent.ryan at sun.com Fri Jan 22 00:01:21 2010 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Fri, 22 Jan 2010 00:01:21 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20100122000247.BA6A341483@hg.openjdk.java.net> Changeset: 117b245b5bb9 Author: vinnie Date: 2010-01-21 23:59 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/117b245b5bb9 6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1) Reviewed-by: andrew ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: c94ac5522d01 Author: vinnie Date: 2010-01-22 00:02 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c94ac5522d01 Merge From Dmitry.Nadezhin at Sun.COM Fri Jan 22 10:51:37 2010 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Fri, 22 Jan 2010 13:51:37 +0300 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <815589.7518.qm@web29207.mail.ird.yahoo.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> Message-ID: <4B598339.30004@sun.com> Jeff, I want to take a look at it, but I didn't find your post in this mailing list. Please give us a direct link to the FastMath sources. -Dima Jeff Hain wrote: > PS : The ceil and floor I posted here are an extract of a FastMath > class (I already > see some people in this mailing list invoking the gods against me > while having > a heart attack at the hearing of this class name) I did, and put > on source > forge (I already told about it in this list few months ago): > maybe some of > you might want to take a look at it (it's called "FastMath", but > not ALL of > its treatments are wrong...). From jeffhain at rocketmail.com Fri Jan 22 19:13:32 2010 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 22 Jan 2010 11:13:32 -0800 (PST) Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <4B598339.30004@sun.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> Message-ID: <671117.22865.qm@web29204.mail.ird.yahoo.com> Hi all. Dmitry, here is the link: http://sourceforge.net/projects/jafama/ The non-wrong treatments could be mainly: - round(double), floor(float), ceil(float), round(float), - maybe hypot(double,double) (Math.hypot delegates to StrictMath.hypot, ? which is very slow on my computer due to its use of StrictMath.sqrt ? I think (same slowness reason than?for Math.asin and Math.acos I think)), - maybe also remainder(double,double) (but it's not the IEEE algorithm). For Joe (or whoever wants to read it): ?? If benches get harder and harder as JVM's get smarter and smarter, maybe some tools could be developped to help developpers with that, instead of just having them warned about benches. ?? I know there is JConsole etc., but I think about something that could work for libraries, and rate them for different contexts of use. ?? After all, developping is developping implemented?algorithms, and algorithms are rated?according to?their?correctness (for which we have JUnit), and their performance (for which we have (?)). ?? Or maybe that's just not possible, or would be way too complicated... Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Darcy at Sun.COM Fri Jan 22 19:26:42 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 22 Jan 2010 11:26:42 -0800 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <671117.22865.qm@web29204.mail.ird.yahoo.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> Message-ID: <4B59FBF2.4080601@sun.com> Jeff Hain wrote: > > Hi all. > > Dmitry, here is the link: > http://sourceforge.net/projects/jafama/ > The non-wrong treatments could be mainly: > - round(double), floor(float), ceil(float), round(float), > - maybe hypot(double,double) (Math.hypot delegates to StrictMath.hypot, > which is very slow on my computer due to its use of StrictMath.sqrt Math and StrictMath sqrt are intrinsified to use the corresponding hardware instruction on any platform you're likely to have run your code on. -Joe From schlosna at gmail.com Sat Jan 23 00:07:40 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 22 Jan 2010 19:07:40 -0500 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <671117.22865.qm@web29204.mail.ird.yahoo.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> Message-ID: <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> On Fri, Jan 22, 2010 at 2:13 PM, Jeff Hain wrote: > > For Joe (or whoever wants to read it): > > If benches get harder and harder as JVM's get smarter and smarter, > maybe some tools could be developped to help developpers with that, > instead of just having them warned about benches. > I know there is JConsole etc., but I think about something that could > work for libraries, and rate them for different contexts of use. > After all, developping is developping implemented algorithms, and > algorithms are rated according to their correctness (for which we have > JUnit), and their performance (for which we have (?)). > Or maybe that's just not possible, or would be way too complicated... > > Jeff > > > You might be interested in a recent email to the Guava [1] mailing list introducing a new Google open source project called Caliper [2] that intends to serve as a micro-benchmarking framework for evaluating performance characteristics under various JVM configurations. [1]: http://groups.google.com/group/guava-discuss/msg/2061f22b90b3cde8?hl=en [2]: http://code.google.com/p/caliper/ - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdoubleya at gmail.com Sat Jan 23 07:59:11 2010 From: pdoubleya at gmail.com (Patrick Wright) Date: Sat, 23 Jan 2010 08:59:11 +0100 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> Message-ID: <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> > You might be interested in a recent email to the Guava [1] mailing list > introducing a new Google open source project called Caliper [2] that intends > to serve as a micro-benchmarking framework for evaluating performance > characteristics under various JVM configurations. > > [1]: http://groups.google.com/group/guava-discuss/msg/2061f22b90b3cde8?hl=en > [2]: http://code.google.com/p/caliper/ > > - Dave There is also Japex, a micro-benchmarking framework developed by a Sun group originally for testing XML parsing and Fast Infoset. https://japex.dev.java.net/ Patrick From Dmitry.Nadezhin at Sun.COM Sun Jan 24 14:04:22 2010 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Sun, 24 Jan 2010 17:04:22 +0300 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <671117.22865.qm@web29204.mail.ird.yahoo.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> Message-ID: <4B5C5366.4010509@sun.com> Jeff, This is a really interesting link. However, I have doubts with licensing. The owner of this project is "omaamo". He marked FastMath.java with LGPL v3 or later. It seems to me that LGPL v3 is not compatible with OpenJDK's GPL v2. OpenJDK can't include fragments of LGPL v3 code without permission of "omaamo", can it ? -Dima Jeff Hain wrote: > > Hi all. > > Dmitry, here is the link: > http://sourceforge.net/projects/jafama/ > The non-wrong treatments could be mainly: > - round(double), floor(float), ceil(float), round(float), > - maybe hypot(double,double) (Math.hypot delegates to StrictMath.hypot, > which is very slow on my computer due to its use of StrictMath.sqrt > I think (same slowness reason than for Math.asin and Math.acos I > think)), > - maybe also remainder(double,double) (but it's not the IEEE algorithm). > > For Joe (or whoever wants to read it): > > If benches get harder and harder as JVM's get smarter and smarter, > maybe some tools could be developped to help developpers with that, > instead of just having them warned about benches. > I know there is JConsole etc., but I think about something that could > work for libraries, and rate them for different contexts of use. > After all, developping is developping implemented algorithms, and > algorithms are rated according to their correctness (for which we have > JUnit), and their performance (for which we have (?)). > Or maybe that's just not possible, or would be way too complicated... > > Jeff > > From jeffhain at rocketmail.com Sun Jan 24 16:47:46 2010 From: jeffhain at rocketmail.com (Jeff Hain) Date: Sun, 24 Jan 2010 08:47:46 -0800 (PST) Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <4B5C5366.4010509@sun.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <4B5C5366.4010509@sun.com> Message-ID: <123697.60276.qm@web29219.mail.ird.yahoo.com> > It seems to me that LGPL v3 is not compatible with OpenJDK's GPL v2.. > OpenJDK can't include fragments of LGPL v3 code without > permission of "omaamo", can it ? Dmitry, "oma" is one of my multiple names (but I'll stick to Jeff now for my "developper incarnation", in case I would produce anything else, to make things simple). I didn't took care "omaamo" would appear as the owner of the project, or I would have chosen something less ugly. For licensing, I used LGPL because Source Forge requires you to pick up a license, but I could not care less for something in the world than for what is done with what I happen to produce. (As Krishna said : "Always act with detachment to the fruits of actions." (if you have enough money, you can live that way)) So, whoever can do whatever he wants with "Jafama", that's official! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Darcy at Sun.COM Mon Jan 25 06:25:09 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Sun, 24 Jan 2010 22:25:09 -0800 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <123697.60276.qm@web29219.mail.ird.yahoo.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <4B5C5366.4010509@sun.com> <123697.60276.qm@web29219.mail.ird.yahoo.com> Message-ID: <4B5D3945.8060709@sun.com> Jeff Hain wrote: > > > It seems to me that LGPL v3 is not compatible with OpenJDK's GPL v2. > > OpenJDK can't include fragments of LGPL v3 code without > > permission of "omaamo", can it ? > > > Dmitry, > > "oma" is one of my multiple names (but I'll stick to Jeff now > for my "developper incarnation", in case I would produce > anything else, to make things simple). > > I didn't took care "omaamo" would appear as the owner of > the project, or I would have chosen something less ugly. > > For licensing, I used LGPL because Source Forge requires you > to pick up a license, but I could not care less for something > in the world than for what is done with what I happen to produce. > (As Krishna said : "Always act with detachment to the fruits of > actions." (if you have enough money, you can live that way)) > > So, whoever can do whatever he wants with "Jafama", that's official! For externally developed code to be used in OpenJDK, it needs to be contributed by a party that has signed the Sun Contributor Agreement (SCA). See http://openjdk.java.net/contribute/ for more information. Regards, -Joe From Dmitry.Nadezhin at Sun.COM Mon Jan 25 06:04:48 2010 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Mon, 25 Jan 2010 09:04:48 +0300 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> Message-ID: <4B5D3480.8000106@sun.com> Joe, I'm interested in micro-benchmarking of math in OpenJDK . This includes a choice of proper framework, a choice of representative patterns (or testsuites). Will math micro-benchmarking be ever hosted by OpenJDK ? Or I should develop them elsewhere ? -Dima >> You might be interested in a recent email to the Guava [1] mailing list >> introducing a new Google open source project called Caliper [2] that intends >> to serve as a micro-benchmarking framework for evaluating performance >> characteristics under various JVM configurations. >> >> [1]: http://groups.google.com/group/guava-discuss/msg/2061f22b90b3cde8?hl=en >> [2]: http://code.google.com/p/caliper/ >> >> - Dave >> > > There is also Japex, a micro-benchmarking framework developed by a Sun > group originally for testing XML parsing and Fast Infoset. > https://japex.dev.java.net/ > > > Patrick > From christopher.hegarty at sun.com Mon Jan 25 15:43:28 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 25 Jan 2010 15:43:28 +0000 Subject: hg: jdk7/tl/jdk: 6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc Message-ID: <20100125154347.4C6CE41A8B@hg.openjdk.java.net> Changeset: e67bf9abc6a5 Author: chegar Date: 2010-01-25 15:41 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e67bf9abc6a5 6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc Reviewed-by: michaelm ! src/windows/native/java/net/NetworkInterface_winXP.c + test/java/net/InterfaceAddress/NetworkPrefixLength.java From weijun.wang at sun.com Tue Jan 26 09:05:00 2010 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 26 Jan 2010 09:05:00 +0000 Subject: hg: jdk7/tl/jdk: 6919610: KeyTabInputStream uses static field for per-instance value Message-ID: <20100126090519.87BF541BA7@hg.openjdk.java.net> Changeset: 558f2a424bfa Author: weijun Date: 2010-01-26 17:03 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/558f2a424bfa 6919610: KeyTabInputStream uses static field for per-instance value Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java + test/sun/security/krb5/ktab/KeyTabIndex.java From jean-christophe.collet at sun.com Tue Jan 26 10:44:29 2010 From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com) Date: Tue, 26 Jan 2010 10:44:29 +0000 Subject: hg: jdk7/tl/jdk: 6919185: test/closed/sun/net/ftp/FtpTests fails to compile Message-ID: <20100126104532.DBD6541BC2@hg.openjdk.java.net> Changeset: f544825d0976 Author: jccollet Date: 2010-01-26 11:39 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f544825d0976 6919185: test/closed/sun/net/ftp/FtpTests fails to compile Summary: Fixed a couple of regressions in FtpClient and updated the test. Reviewed-by: chegar ! src/share/classes/sun/net/ftp/impl/FtpClient.java From Joe.Darcy at Sun.COM Tue Jan 26 18:00:07 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 26 Jan 2010 10:00:07 -0800 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <4B5D3480.8000106@sun.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> <4B5D3480.8000106@sun.com> Message-ID: <4B5F2DA7.1000106@sun.com> Dmitry Nadezhin wrote: > Joe, > > I'm interested in micro-benchmarking of math in OpenJDK . > This includes a choice of proper framework, a choice of representative > patterns (or testsuites). > > Will math micro-benchmarking be ever hosted by OpenJDK ? > Or I should develop them elsewhere ? The site openjdk.java.net hosts various projects related to but separate from OpeJDK 6 and (Open) JDK 7 and there are procedures for proposing a new project: http://openjdk.java.net/projects/ -Joe From jonathan.gibbons at sun.com Tue Jan 26 19:16:57 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 26 Jan 2010 19:16:57 +0000 Subject: hg: jdk7/tl/langtools: 6919944: incorrect position given for duplicate annotation value error Message-ID: <20100126191701.B537541C4C@hg.openjdk.java.net> Changeset: da0e3e2dd3ef Author: jjg Date: 2010-01-26 11:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/da0e3e2dd3ef 6919944: incorrect position given for duplicate annotation value error Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrayclass/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java ! test/tools/javac/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out From jonathan.gibbons at sun.com Tue Jan 26 19:25:05 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Tue, 26 Jan 2010 19:25:05 +0000 Subject: hg: jdk7/tl/langtools: 6917130: should test that annotations that have been optimized away are not emitted to classfile Message-ID: <20100126192512.0E31841C51@hg.openjdk.java.net> Changeset: 59167312ed4e Author: jjg Date: 2010-01-26 11:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/59167312ed4e 6917130: should test that annotations that have been optimized away are not emitted to classfile Reviewed-by: jjg, darcy Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu + test/tools/javac/typeAnnotations/classfile/DeadCode.java From christopher.hegarty at sun.com Wed Jan 27 16:29:18 2010 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 27 Jan 2010 16:29:18 +0000 Subject: hg: jdk7/tl/jdk: 6905552: libnet/nio portability issues Message-ID: <20100127163008.0B6E041DB1@hg.openjdk.java.net> Changeset: 8df0ffac7f4d Author: chegar Date: 2010-01-27 16:11 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8df0ffac7f4d 6905552: libnet/nio portability issues Reviewed-by: alanb ! src/share/native/java/net/net_util.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/sun/net/spi/SdpProvider.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SctpNet.c From ptisnovs at redhat.com Wed Jan 27 16:48:35 2010 From: ptisnovs at redhat.com (ptisnovs at redhat.com) Date: Wed, 27 Jan 2010 16:48:35 +0000 Subject: hg: jdk7/tl/jdk: 6920143: test/java/awt/TestArea/UsingWithMouse.java needs realSync() Message-ID: <20100127164854.6255941DBA@hg.openjdk.java.net> Changeset: 4192f6edbbf4 Author: ptisnovs Date: 2010-01-27 17:47 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4192f6edbbf4 6920143: test/java/awt/TestArea/UsingWithMouse.java needs realSync() Summary: Added small delay to make sure that TextArea animation have finished Reviewed-by: anthony ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.java From lana.steuck at sun.com Thu Jan 28 02:48:34 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 02:48:34 +0000 Subject: hg: jdk7/tl: 3 new changesets Message-ID: <20100128024834.7ABE641E5A@hg.openjdk.java.net> Changeset: 432cbbdc44bc Author: andrew Date: 2010-01-07 23:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/rev/432cbbdc44bc 6914986: Make sure openjdk doc generation not turned off with JDK_UPDATE_VERSION Summary: Only turn off documentation for updates when not building OpenJDK Reviewed-by: ohair ! make/Defs-internal.gmk Changeset: a3242906c774 Author: mikejwre Date: 2010-01-20 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/a3242906c774 Merge Changeset: 8403096d1fe7 Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/8403096d1fe7 Added tag jdk7-b80 for changeset a3242906c774 ! .hgtags From lana.steuck at sun.com Thu Jan 28 02:48:42 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 02:48:42 +0000 Subject: hg: jdk7/tl/corba: 3 new changesets Message-ID: <20100128024847.A2F4141E5B@hg.openjdk.java.net> Changeset: d4c077d44a64 Author: andrew Date: 2010-01-16 01:04 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/d4c077d44a64 6917485: Corba doc warnings Summary: Fix warnings generated by javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/corba/se/idl/constExpr/Expression.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/SetOverrideType.java ! src/share/classes/org/omg/CORBA/TCKind.java ! src/share/classes/org/omg/CORBA/UnknownUserException.java ! src/share/classes/org/omg/CORBA/portable/ServantObject.java ! src/share/classes/org/omg/CosNaming/nameservice.idl ! src/share/classes/org/omg/PortableInterceptor/Interceptors.idl Changeset: 0336e70ca0ae Author: mikejwre Date: 2010-01-20 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0336e70ca0ae Merge Changeset: e08a42a2a94d Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e08a42a2a94d Added tag jdk7-b80 for changeset 0336e70ca0ae ! .hgtags From lana.steuck at sun.com Thu Jan 28 02:51:16 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 02:51:16 +0000 Subject: hg: jdk7/tl/hotspot: 34 new changesets Message-ID: <20100128025307.314BA41E5D@hg.openjdk.java.net> Changeset: 40e7c1d24e4a Author: twisti Date: 2010-01-04 00:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/40e7c1d24e4a 6909153: Fix broken options on Zero Summary: Smaller fixes to ensure that Zero still works with non-standard options. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 896da934748c Author: twisti Date: 2010-01-04 03:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/896da934748c 6913869: Zero assert fix Summary: Zero currently won't build on zSeries or PowerPC machines with assertions turned on. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/prims/jni.cpp Changeset: aa62b9388fce Author: twisti Date: 2010-01-04 15:52 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aa62b9388fce 6894206: JVM needs a way to traverse method handle structures Summary: We need a way to walk chained method handles in the JVM to call the right methods and to generate required bytecode adapters for the compilers. Reviewed-by: kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core + src/share/vm/prims/methodHandleWalk.cpp + src/share/vm/prims/methodHandleWalk.hpp Changeset: 0910903272e5 Author: twisti Date: 2010-01-04 07:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0910903272e5 Merge Changeset: e66fd840cb6b Author: twisti Date: 2010-01-04 18:38 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e66fd840cb6b 6893081: method handle & invokedynamic code needs additional cleanup (post 6815692, 6858164) Summary: During the work for 6829187 we have fixed a number of basic bugs which are logically grouped with 6815692 and 6858164 but which must be reviewed and pushed separately. Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 4b84186a8248 Author: kvn Date: 2010-01-04 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4b84186a8248 6913075: EA identifies escape state incorrectly after 6895383 fix Summary: EA incorrectly identifies escape state of an allocation passed as call argument. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 97125851f396 Author: twisti Date: 2010-01-05 13:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/97125851f396 6829187: compiler optimizations required for JSR 292 Summary: C2 implementation for invokedynamic support. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + src/share/vm/ci/ciCPCache.cpp + src/share/vm/ci/ciCPCache.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/type.cpp Changeset: dd57230ba8fe Author: twisti Date: 2010-01-05 15:21 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dd57230ba8fe 6893268: additional dynamic language related optimizations in C2 Summary: C2 needs some additional optimizations to be able to handle MethodHandle invokes and invokedynamic instructions at the best performance. Reviewed-by: kvn, never ! src/share/vm/ci/ciCPCache.cpp + src/share/vm/ci/ciCallSite.cpp + src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciExceptionHandler.cpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethod.hpp + src/share/vm/ci/ciMethodHandle.cpp + src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbolOop.cpp ! src/share/vm/oops/symbolOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/constantTag.hpp Changeset: b6f06e395428 Author: never Date: 2010-01-05 11:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b6f06e395428 6908267: Zero fails to unlock synchronized native methods on exception Reviewed-by: never Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: 1f6d42899c3a Author: never Date: 2010-01-05 11:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1f6d42899c3a Merge Changeset: b1f619d38249 Author: never Date: 2010-01-05 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b1f619d38249 6914002: unsigned compare problem after 5057818 Reviewed-by: kvn, twisti ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp Changeset: 4ce7240d622c Author: never Date: 2010-01-06 14:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4ce7240d622c 6914300: ciEnv should export all well known classes Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/serviceUtil.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: aad340e07bc4 Author: never Date: 2010-01-06 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aad340e07bc4 Merge Changeset: 9b9c1ee9b3f6 Author: iveresov Date: 2010-01-06 22:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9b9c1ee9b3f6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e018e6884bd8 Author: ysr Date: 2009-12-23 09:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e018e6884bd8 6631166: CMS: better heuristics when combatting fragmentation Summary: Autonomic per-worker free block cache sizing, tunable coalition policies, fixes to per-size block statistics, retuned gain and bandwidth of some feedback loop filters to allow quicker reactivity to abrupt changes in ambient demand, and other heuristics to reduce fragmentation of the CMS old gen. Also tightened some assertions, including those related to locking. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsLockVerifier.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsLockVerifier.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/includeDB_gc_parallel ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/classLoadingService.cpp Changeset: 504830073409 Author: jmasa Date: 2010-01-04 07:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/504830073409 Merge ! src/share/vm/runtime/globals.hpp Changeset: 75bd253e25dd Author: ysr Date: 2010-01-04 14:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75bd253e25dd 6637203: Classunloading messages go to stdout rather than Xloggc file, causing hangs when stdout is closed Summary: Decoupled TraceClassUnloading from verbose:gc, JVMTI_VERBOSE_GC and PrintGC[Details], making it settable in a manner identical to TraceClassLoading. Reverted an inadvertent change of TraceClassUnloading output in a previous changeset from gclog back to tty. Reviewed-by: coleenp, dholmes, jmasa, poonam ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: 05b775309e59 Author: jmasa Date: 2010-01-07 08:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/05b775309e59 6912018: CMS: guarantee(head() != 0,"The head of the list cannot be NULL") Summary: Block too small to split was not correctly putback to free lists. Reviewed-by: ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 0579c695832f Author: ysr Date: 2010-01-09 09:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0579c695832f Merge ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/arguments.cpp Changeset: f62a22282a47 Author: kvn Date: 2010-01-07 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f62a22282a47 6914622: Print values of all flags for product VM Summary: Change the flag -XX:+PrintFlagsFinal to product and add new product flag -XX:+PrintFlagsInitial. Reviewed-by: phh, ysr Contributed-by: gbenson at redhat.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1271af4ec18c Author: kvn Date: 2010-01-07 16:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1271af4ec18c 6912517: JIT bug compiles out (and stops running) code that needs to be run. Causes NPE. Summary: Add missing check that value is used in memory expression in instructions with embedded load. Reviewed-by: never, jrose ! src/share/vm/opto/lcm.cpp + test/compiler/6912517/Test.java Changeset: cd37471eaecc Author: twisti Date: 2010-01-08 11:09 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd37471eaecc 6914206: change way of permission checking for generated MethodHandle adapters Summary: Put generated MH adapter in InvokeDynamic/MethodHandle classes to be able to indentify them easily in the compiler. Reviewed-by: kvn, never, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vframe.cpp Changeset: bea7a22a6f79 Author: kvn Date: 2010-01-08 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bea7a22a6f79 6915110: IfNode::up_one_dom moves beyond RootNode bug in src/share/vm/opto/ifnode.cpp Summary: Check RootNode before check Loop in IfNode::up_one_dom(). Reviewed-by: never Contributed-by: kevin.brown at sun.com ! src/share/vm/opto/ifnode.cpp Changeset: 174ade00803b Author: kvn Date: 2010-01-08 09:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/174ade00803b 6910484: incorrect integer optimization (loosing and op-r in a given example) Summary: Remove AND operation only if mask is equal to shift. Reviewed-by: never ! src/share/vm/opto/divnode.cpp + test/compiler/6910484/Test.java Changeset: 4e6abf09f540 Author: jrose Date: 2010-01-08 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4e6abf09f540 6912062: disassembler plugin needs to produce symbolic information in product mode Summary: More informative disassembly in product mode. Also, a more consistent CompileCommand syntax. Reviewed-by: never ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/arrayKlassKlass.hpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassKlass.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodDataKlass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodKlass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/symbolKlass.cpp ! src/share/vm/oops/symbolKlass.hpp ! src/share/vm/oops/typeArrayKlassKlass.cpp ! src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 136ac23d6ded Author: jrose Date: 2010-01-08 15:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/136ac23d6ded Merge Changeset: c3b315a0d58a Author: jrose Date: 2010-01-08 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c3b315a0d58a 6912063: inlining parameters need to be adjusted for some uses of the JVM Summary: Put all inline-related switches into product mode, to allow tuning by dynamic language implementors. Reviewed-by: twisti, kvn ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/runtime/globals.hpp Changeset: f2e64cfc2020 Author: jrose Date: 2010-01-08 18:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f2e64cfc2020 Merge Changeset: 5b06c5db3e89 Author: jrose Date: 2010-01-08 22:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5b06c5db3e89 Merge Changeset: f24201449cac Author: never Date: 2010-01-09 00:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f24201449cac 6909839: missing unsigned compare cases for some cmoves in sparc.ad Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/sparc.ad + test/compiler/6909839/Test6909839.java Changeset: 1fc01a2425ce Author: iveresov Date: 2010-01-12 13:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1fc01a2425ce Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: d749b1813f40 Author: trims Date: 2010-01-15 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d749b1813f40 Merge Changeset: 3003ddd1d433 Author: trims Date: 2010-01-15 14:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3003ddd1d433 6917463: Bump the HS17 build number to 07 Summary: Update the HS17 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 359445e739ac Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/359445e739ac Added tag jdk7-b80 for changeset 3003ddd1d433 ! .hgtags From lana.steuck at sun.com Thu Jan 28 02:57:05 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 02:57:05 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b80 for changeset 9219574db593 Message-ID: <20100128025705.A71E641E5F@hg.openjdk.java.net> Changeset: 204e59d488cd Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/204e59d488cd Added tag jdk7-b80 for changeset 9219574db593 ! .hgtags From lana.steuck at sun.com Thu Jan 28 02:57:11 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 02:57:11 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b80 for changeset 447767dee56a Message-ID: <20100128025711.E524941E60@hg.openjdk.java.net> Changeset: f051045fe94a Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/f051045fe94a Added tag jdk7-b80 for changeset 447767dee56a ! .hgtags From lana.steuck at sun.com Thu Jan 28 02:58:56 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 02:58:56 +0000 Subject: hg: jdk7/tl/jdk: 28 new changesets Message-ID: <20100128030831.22EE741E65@hg.openjdk.java.net> Changeset: 9956e8d71e06 Author: tbell Date: 2009-12-18 09:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9956e8d71e06 6899737: JDK build fails in make/java/jli because of _vsnprintf macro redefinition Summary: Use stdio.h instead when building with Visual Studio 2008 or later Reviewed-by: art, ohair ! src/share/native/java/util/zip/zlib-1.2.3/zutil.h Changeset: 39b9564ff01c Author: ohair Date: 2010-01-05 15:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39b9564ff01c Merge Changeset: 447c9e535234 Author: ohair Date: 2010-01-13 15:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/447c9e535234 Merge Changeset: e0905e36766a Author: yhuang Date: 2009-12-06 22:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0905e36766a 6868106: Ukrainian currency has wrong format Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_uk.java ! src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties ! test/sun/text/resources/LocaleData Changeset: d9080b33ba74 Author: yhuang Date: 2009-12-08 21:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d9080b33ba74 6610748: Dateformat - AM-PM indicator in Finnish appears to be from English Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_fi.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ac9e284db030 Author: yhuang Date: 2009-12-08 21:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ac9e284db030 6645271: Wrong date format for Croatian (hr) locale Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_hr_HR.java Changeset: 3ab178316aa0 Author: yhuang Date: 2009-12-08 21:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3ab178316aa0 6609737: DateFormat incorrect for German locale Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java Changeset: 4910b580a725 Author: yhuang Date: 2009-12-08 21:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4910b580a725 6507067: TimeZone country/area message error Reviewed-by: peytoia ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 06df47459ecf Author: yhuang Date: 2009-12-10 17:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/06df47459ecf 6873931: New Turkish currency since 2009 Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ddc4a80f25f4 Author: yhuang Date: 2009-12-17 02:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ddc4a80f25f4 6450945: The week day for Saturday and the first week day in Romania locale are incorrect Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_ro.java ! src/share/classes/sun/util/resources/CalendarData_ro.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cd5d46887546 Author: yhuang Date: 2009-12-17 02:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd5d46887546 6645268: Country/language names with locale fi_FI are incorrect for FRANCE/FRENCH Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/LocaleNames_fi.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java ! test/sun/util/resources/Locale/Bug4429024.java Changeset: 946a0a09a477 Author: yhuang Date: 2009-12-17 02:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/946a0a09a477 6646611: Incorrect spelling of month name in locale for Belarusian language ("be", "BY") Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_be.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e8fa2b2cb1e8 Author: yhuang Date: 2009-12-17 22:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e8fa2b2cb1e8 6650730: Lithuanian locale date and number formats mismatch. Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_lt.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e9b09f76d281 Author: yhuang Date: 2009-12-17 22:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e9b09f76d281 6645405: Errors in Hungarian local-specific formatting. (L10N part of 6609703) Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_hu_HU.java Changeset: 3b78f3769688 Author: yhuang Date: 2009-12-20 19:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b78f3769688 6910489: Slovenia Locale, wrong firstDayOfWeek number Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CalendarData_sl.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: b09e582d09bd Author: yhuang Date: 2009-12-20 19:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b09e582d09bd 6573250: Java.util.Currency.getSymbol(Locale) returns wrong value when locale is not US. Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 7bf839e2e9ce Author: yhuang Date: 2009-12-24 15:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7bf839e2e9ce 6870908: reopen bug 4244752: month names in Estonian should be lowercase Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_et.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 1397ae8dc558 Author: yhuang Date: 2009-12-24 16:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1397ae8dc558 6541350: TimeZone display names localization Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: 2886607f8bc3 Author: yhuang Date: 2009-12-28 14:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2886607f8bc3 6585666: Spanish language names not compliant with CLDR Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/LocaleNames_es.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 5ec5337c0298 Author: yhuang Date: 2010-01-05 18:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5ec5337c0298 6716626: Integrate contributed language and country names for NL Reviewed-by: yhuang, peytoia ! src/share/classes/sun/util/resources/LocaleNames_nl.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 8bf6b2173e9f Author: yhuang Date: 2010-01-06 17:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8bf6b2173e9f 6914413: abbreviation name for November is not correct in be_BY Reviewed-by: yhuang, peytoia ! src/share/classes/sun/text/resources/FormatData_be.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: eea1cc096889 Author: yhuang Date: 2010-01-06 19:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eea1cc096889 6821191: Timezone display name localization Reviewed-by: yhuang, ogino ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: eff93f451501 Author: yhuang Date: 2010-01-11 23:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eff93f451501 Merge - make/tools/CharsetMapping/DoubleByte-X.java - make/tools/CharsetMapping/SingleByte-X.java - src/share/classes/javax/swing/plaf/synth/DefaultMenuLayout.java - src/share/classes/sun/awt/ComponentAccessor.java - src/share/classes/sun/awt/WindowAccessor.java - src/share/classes/sun/security/provider/IdentityDatabase.java - src/share/classes/sun/security/provider/SystemIdentity.java - src/share/classes/sun/security/provider/SystemSigner.java - src/share/classes/sun/security/x509/X500Signer.java - src/share/classes/sun/security/x509/X509Cert.java - src/share/classes/sun/swing/plaf/synth/SynthUI.java - src/share/classes/sun/tools/jar/JarVerifierStream.java - src/share/classes/sun/util/CoreResourceBundleControl-XLocales.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java - test/java/util/Formatter/Basic-X.java - test/sun/tools/native2ascii/test2 - test/tools/launcher/SolarisDataModel.sh - test/tools/launcher/SolarisRunpath.sh - test/tools/launcher/libraryCaller.c - test/tools/launcher/libraryCaller.h - test/tools/launcher/libraryCaller.java Changeset: d91c6bdcc852 Author: yhuang Date: 2010-01-17 18:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d91c6bdcc852 Merge Changeset: 049cfaaa9a73 Author: mikejwre Date: 2010-01-20 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/049cfaaa9a73 Merge Changeset: 15815a54d930 Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15815a54d930 Added tag jdk7-b80 for changeset 049cfaaa9a73 ! .hgtags Changeset: 10b993d417fc Author: lana Date: 2010-01-22 09:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/10b993d417fc Merge - make/java/redist/FILES.gmk - make/sun/nio/FILES_java.gmk - src/solaris/classes/sun/nio/ch/SctpSocketDispatcher.java Changeset: 0126effcc249 Author: lana Date: 2010-01-27 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0126effcc249 Merge From lana.steuck at sun.com Thu Jan 28 03:19:32 2010 From: lana.steuck at sun.com (lana.steuck at sun.com) Date: Thu, 28 Jan 2010 03:19:32 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20100128031943.B5BF041E6D@hg.openjdk.java.net> Changeset: 250a580ab046 Author: mikejwre Date: 2010-01-21 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/250a580ab046 Added tag jdk7-b80 for changeset f0074aa48d4e ! .hgtags Changeset: cfabfcf9f110 Author: lana Date: 2010-01-22 09:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cfabfcf9f110 Merge Changeset: ff7a01f9eff3 Author: lana Date: 2010-01-27 14:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ff7a01f9eff3 Merge From xueming.shen at sun.com Thu Jan 28 03:43:24 2010 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 28 Jan 2010 03:43:24 +0000 Subject: hg: jdk7/tl/jdk: 6920732: opensource test/java/nio/charset Message-ID: <20100128034343.4671241E77@hg.openjdk.java.net> Changeset: 946b30073247 Author: sherman Date: 2010-01-27 19:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/946b30073247 6920732: opensource test/java/nio/charset Summary: move the test cases to openjdk Reviewed-by: martin + test/java/nio/charset/Charset/AvailableCharsetNames.java + test/java/nio/charset/Charset/CharsetContainmentTest.java + test/java/nio/charset/Charset/Contains.java + test/java/nio/charset/Charset/Default.java + test/java/nio/charset/Charset/EmptyCharsetName.java + test/java/nio/charset/Charset/EncDec.java + test/java/nio/charset/Charset/IllegalCharsetName.java + test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java + test/java/nio/charset/Charset/NullCharsetName.java + test/java/nio/charset/Charset/RegisteredCharsets.java + test/java/nio/charset/Charset/default.sh + test/java/nio/charset/CharsetDecoder/AverageMax.java + test/java/nio/charset/CharsetDecoder/EmptyInput.java + test/java/nio/charset/CharsetEncoder/CanEncode.java + test/java/nio/charset/CharsetEncoder/Flush.java + test/java/nio/charset/RemovingSunIO/SunioAlias.java + test/java/nio/charset/RemovingSunIO/TestCOMP.java + test/java/nio/charset/RemovingSunIO/TestUnmappableForLength.java + test/java/nio/charset/coders/BashCache.java + test/java/nio/charset/coders/BashStreams.java + test/java/nio/charset/coders/Check.java + test/java/nio/charset/coders/CheckSJISMappingProp.sh + test/java/nio/charset/coders/Errors.java + test/java/nio/charset/coders/FullRead.java + test/java/nio/charset/coders/IOCoders.java + test/java/nio/charset/coders/IsLegalReplacement.java + test/java/nio/charset/coders/ResetISO2022JP.java + test/java/nio/charset/coders/SJISPropTest.java + test/java/nio/charset/coders/StreamTimeout.java + test/java/nio/charset/coders/Surrogate.java + test/java/nio/charset/coders/Surrogates.java + test/java/nio/charset/coders/Util.java + test/java/nio/charset/coders/ref.shift_jis + test/java/nio/charset/coders/ref.windows-31j + test/java/nio/charset/spi/FooCharset.java + test/java/nio/charset/spi/FooProvider.java + test/java/nio/charset/spi/Test.java + test/java/nio/charset/spi/basic.sh + test/java/nio/charset/spi/charsetProvider.sp + test/java/nio/charset/spi/default-pol From martinrb at google.com Fri Jan 29 05:13:50 2010 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 Jan 2010 21:13:50 -0800 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <4B5D3480.8000106@sun.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> <4B5D3480.8000106@sun.com> Message-ID: <1ccfd1c11001282113n3f8a03c7vac1c93f93c4e0cad@mail.gmail.com> I think it's reasonable to have small microbenchmarks of JDK functionality in the openjdk code base. I've done that occasionally myself in the jdk/test directory. More serious implementation-independent benchmarking efforts should probably have their own project, as with e.g. DaCapo. Maybe there's already a Java community benchmarking project that would be interested in math-related things? Martin On Sun, Jan 24, 2010 at 22:04, Dmitry Nadezhin wrote: > Joe, > > I'm interested in micro-benchmarking of math in OpenJDK . > This includes a choice of proper framework, a choice of representative > patterns (or testsuites). > > Will math micro-benchmarking be ever hosted by OpenJDK ? > Or I should develop them elsewhere ? From Dmitry.Nadezhin at Sun.COM Fri Jan 29 08:59:25 2010 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Fri, 29 Jan 2010 11:59:25 +0300 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <1ccfd1c11001282113n3f8a03c7vac1c93f93c4e0cad@mail.gmail.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> <4B5D3480.8000106@sun.com> <1ccfd1c11001282113n3f8a03c7vac1c93f93c4e0cad@mail.gmail.com> Message-ID: <4B62A36D.5090607@sun.com> Martin, Thank you for the answer. I found your benchmark in "jdk/test/java/util/ArrayList". Also I see an example of microbenchmark included in the post to core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003226.html . Its nice to keep such microbenchmarks in jdk/tests. When there are variants of method implementation, the choice of fastest method is not forever. The choice can change later after optimizations in HotSpot. For example, floor and ceil results on pattern3 = { 0.1, -0.1, 1e4+0.1, -1e4-0.1, 1e8+0.1, -1e8-0.1, 1e12+0.1, -1e12-0.1, (1L<<52)/1.1, -(1L<<52)/1.1}; jdk1.5.0_21/bin/java -d32 -server empty took 1,67 nsec Math.ceil took 65,53 nsec Math.floor took 66,62 nsec StrictMath.ceil took 67,21 nsec StrictMath.floor took 66,04 nsec FloorCeilDarcy.ceil took 24,22 nsec FloorCeilDarcy.floor took 23,36 nsec FloorCeilHain.ceil took 97,61 nsec FloorCeilHain.floor took 100,56 nsec jdk1.5.0_21/bin/java -d64 -server empty took 1,67 nsec Math.ceil took 33,53 nsec Math.floor took 33,54 nsec StrictMath.ceil took 33,53 nsec StrictMath.floor took 33,54 nsec FloorCeilDarcy.ceil took 8,18 nsec FloorCeilDarcy.floor took 16,96 nsec FloorCeilHain.ceil took 20,39 nsec FloorCeilHain.floor took 19,92 nsec jdk1.7.0_b79/bin/java -d32 -server empty took 1,67 nsec Math.ceil took 15,74 nsec Math.floor took 14,70 nsec StrictMath.ceil took 15,76 nsec StrictMath.floor took 14,70 nsec FloorCeilDarcy.ceil took 15,88 nsec FloorCeilDarcy.floor took 14,98 nsec FloorCeilHain.ceil took 12,27 nsec FloorCeilHain.floor took 10,38 nsec jdk1.7.0_b79/bin/java -d64 -server empty took 1,67 nsec Math.ceil took 7,66 nsec Math.floor took 7,81 nsec StrictMath.ceil took 7,65 nsec StrictMath.floor took 7,80 nsec FloorCeilDarcy.ceil took 7,62 nsec FloorCeilDarcy.floor took 7,80 nsec FloorCeilHain.ceil took 12,65 nsec FloorCeilHain.floor took 11,15 nsec On JDK-1.5, Darcy's implementation was much faster than Hain's. On JDK-1.7 -d32 -server, Hain's implementation is faster than Darcy's. Perhaps implementation which are not the best choice now may become the best choice later. Perhaps alternative implementation should be stored somewhere too. This maybe a project in OpenJdk or a subproject of other project. I shall write something about it in the next message with a new subject. -Dima From Dmitry.Nadezhin at Sun.COM Fri Jan 29 09:02:29 2010 From: Dmitry.Nadezhin at Sun.COM (Dmitry Nadezhin) Date: Fri, 29 Jan 2010 12:02:29 +0300 Subject: Math project or subproject Message-ID: <4B62A425.7040506@sun.com> In my previous post I discussed choice criteria for performance enhancements in math libraries. I guess that in production projects Jdk 1.6 and Jdk 1.7 the main choice criteria is stability. This explains why changes to math stuff in Java are almost impossible. Here is a pair of examples: 1) The Karatsuba multiplication in BigInteger http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-January/000225.html (contribution proposals) http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000229.html (proposals approved) http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000236.html (patch submitted) This patch is still not in OpenJdk tree. 2) Double.parseDouble(String s) loops infinitely on some inputs http://bugs.sun.com/view_bug.do?bug_id=4421494 (one-line fix was suggested in bug database comment in 2004) http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003153.html (fix was submitted again together with tests) http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003182.html (fix was scheduled for verification) This patch is still not in OpenJdk tree. I respect our "Java Floating-Point Czar" for keeping stability of mainstream Java. However, I suspect that some OpenJdk users prefer enhancements and bug fixes of old bugs in math libraries in exchange for a small risk of new bugs. Perhaps some new languages may need enhancements in OpenJdk math (scala, fortress, frink, fantom). http://www.scala-lang.org/ http://projectfortress.sun.com/Projects/Community/ http://futureboy.homeip.net/frinkdocs/ http://fantom.org/ What about more rapid enhancement of OpenJdk math in some project related to but separate from OpenJDK 6 and (Open) JDK 7 ? This may be a new Math project or a subproject of the Da Vinci Machine Project. I see such works which can be done in such a project. I) Jdk changes 1) bug fixing of known math bugs from bug database; 2) creating microbenchmarks for performance enhancements request Keeping a collection of alternative implementations and picking currently fastest implementation 3) Static methods which performs arithmetic operations on doubles with RoundingMode.FLOOR and RoundingMode.CEILING for use in interval computations. 4) Arbitrary-precision classes: Rational - rational numbers together with infinities and signed zero Binary - floating-point binary numbers 5) Classes for some particular floating-point binary formats: BINARY128, BINARY80. 6) Universal Comparator to compare values of different subclasses of Number with each other. Different quiet and signalling relational operators mentioned in IEEE 754r standard. 7) Implementation of forthcoming P1788 Interval Arithmetic standard http://grouper.ieee.org/groups/1788/ II) HotSpot changes. I consider useful to intrinsify some methods from above (3),(4),(5),(7)., III) Quality Perhaps the math libraries are a proper subject for Formal Verification. Operation on numbers are easy to specify by formal tools. It is easy to make long-live bugs in math libraries which can be detected by attempt to prove. There are already tools to assist formal proofs. http://coq.inria.fr/ http://lipforge.ens-lyon.fr/www/pff/ http://gappa.gforge.inria.fr/ http://why.lri.fr/ http://krakatoa.lri.fr/ What do people think about a Math project or subproject ? -Dima From kevinb at google.com Fri Jan 29 17:07:44 2010 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 29 Jan 2010 09:07:44 -0800 Subject: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) &StrictMath.ceil(double) In-Reply-To: <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> References: <815589.7518.qm@web29207.mail.ird.yahoo.com> <4B598339.30004@sun.com> <671117.22865.qm@web29204.mail.ird.yahoo.com> <9146341c1001221607mf99112er4bb6080beb566ddf@mail.gmail.com> <64efa1ba1001222359o5c5dc63cl7cb4a16006d8ee9c@mail.gmail.com> Message-ID: <108fcdeb1001290907s69820a98i6c85038bf9c0565c@mail.gmail.com> Caliper was born partially out of frustration with Japex. It's still early in development. We are currently reviewing every aspect of its methodology with Doug/Josh/Cliff/Brian/et al. With luck, in a few months it will become something very useful for the kinds of microbenchmarks you need to write and run for core-libs work. If you're someone who lives and breathes Java microbenchmarks, I'd very much like to hear your ideas, off-list. On Fri, Jan 22, 2010 at 11:59 PM, Patrick Wright wrote: > > You might be interested in a recent email to the Guava [1] mailing list > > introducing a new Google open source project called Caliper [2] that > intends > > to serve as a micro-benchmarking framework for evaluating performance > > characteristics under various JVM configurations. > > > > [1]: > http://groups.google.com/group/guava-discuss/msg/2061f22b90b3cde8?hl=en > > [2]: http://code.google.com/p/caliper/ > > > > - Dave > > There is also Japex, a micro-benchmarking framework developed by a Sun > group originally for testing XML parsing and Fast Infoset. > https://japex.dev.java.net/ > > > Patrick > -- Kevin Bourrillion @ Google internal: http://go/javalibraries external: guava-libraries.googlecode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliasen at mindspring.com Fri Jan 29 22:14:36 2010 From: eliasen at mindspring.com (Alan Eliasen) Date: Fri, 29 Jan 2010 15:14:36 -0700 Subject: Math project or subproject In-Reply-To: <4B62A425.7040506@sun.com> References: <4B62A425.7040506@sun.com> Message-ID: <4B635DCC.9010207@mindspring.com> On 01/29/2010 02:02 AM, Dmitry Nadezhin wrote: > In my previous post I discussed choice criteria for performance > enhancements in math libraries. > > I guess that in production projects Jdk 1.6 and Jdk 1.7 the main choice > criteria is stability. > This explains why changes to math stuff in Java are almost impossible. > Here is a pair of examples: > 1) The Karatsuba multiplication in BigInteger > http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-January/000225.html I'm the submitter of these patches which are almost two years old in a couple of weeks, with still no approval. And these multiplication patches are only a small part of the work that needs to be done on BigInteger. I also have orders-of-magnitude improvements for pow() and toString(), both of which use extremely slow algorithms. I was asked to make patches as small as possible so they could be reviewed quickly, so my submitted patches have just been for multiplication. Joe Darcy, what is your current status on reviewing these patches? Can you delegate this to Dmitry or Xiaobin if you don't appear to have time to do it? > I respect our "Java Floating-Point Czar" for keeping stability of > mainstream Java. > However, I suspect that some OpenJdk users prefer enhancements and bug > fixes of old bugs in math libraries in exchange for a small risk of > new bugs. I think OpenJDK *contributors* need some evidence that their contributions are being looked at, or they'll stop contributing, and/or move to other platforms with better numerics. Some of us have spent literally weeks of unpaid work improving performance, getting world-class outside reviewers to look over them and reduce Sun's workload, etc. It's very depressing to wait over two years for approval of a well-known algorithm that is usually assigned as a homework assignment in undergrad courses. > What about more rapid enhancement of OpenJdk math in some project > related to but separate from OpenJDK 6 and (Open) JDK 7 ? > This may be a new Math project or a subproject of the Da Vinci Machine > Project. I'm all for improving Java's numerics. Please keep me informed. I've already implemented a lot of missing algorithms. -- Alan Eliasen eliasen at mindspring.com http://futureboy.us/ From jonathan.gibbons at sun.com Sat Jan 30 00:07:56 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Sat, 30 Jan 2010 00:07:56 +0000 Subject: hg: jdk7/tl/langtools: 6919889: assorted position errors in compiler syntax trees Message-ID: <20100130000759.E314C4152E@hg.openjdk.java.net> Changeset: 699ecefbdd4e Author: jjg Date: 2010-01-29 16:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/699ecefbdd4e 6919889: assorted position errors in compiler syntax trees Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T6654037.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out + test/tools/javac/treepostests/TreePosTest.java From jonathan.gibbons at sun.com Sat Jan 30 00:55:59 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Sat, 30 Jan 2010 00:55:59 +0000 Subject: hg: jdk7/tl/langtools: 6499119: Created package-info class file modeled improperly; ... Message-ID: <20100130005605.A81D141542@hg.openjdk.java.net> Changeset: 8e638442522a Author: jjg Date: 2010-01-29 16:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8e638442522a 6499119: Created package-info class file modeled improperly 6920317: package-info.java file has to be specified on the javac cmdline, else it will not be avail. Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/6499119/ClassProcessor.java + test/tools/javac/processing/6499119/package-info.java + test/tools/javac/processing/T6920317.java From scolebourne at joda.org Sun Jan 31 00:44:14 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 31 Jan 2010 00:44:14 +0000 Subject: Serialization problem Message-ID: <4B64D25E.5030709@joda.org> I thought I'd raise an issue with serialization that I've had a problem with more than once. Perhaps there is an obvious easy solution, but I can't see it (I can see hard workarounds...) In JSR-310 we have lots of immutable classes. One of these stores four fields: private final String name private final Duration duration private final List periods private final int hashCode For serialization, I only need to store the name, duration and element zero from the periods list. (The rest of the period list is a cache derived from the first element. Similarly, I want to cache the hash code in the constructor as this could be performance critical.). Storing just these fields can be done easily using writeObject() But, when you implement readObject(), you cannot store the read values into the fields because they are final. Nor can I stash them somewhere ready for readResolve(). From my perspective, what I need is a combined readObject() and readResolve(): private Object readObjectAndResolve() I could then read the stream, and call the constructor to properly initialise the object state (including the full period list and hash code caches). This seems to be a general problem with deserializing immutable classes. Workarounds include lazily creating the caches in transient fields, bloating the serialzed data, using reflection or creating a dummy inner class to act as the serialized form. All are rubbish solutions. Any suggestions? And if not, what about adding the suggested method to the JDK? Stephen From gokdogan at gmail.com Sun Jan 31 04:04:45 2010 From: gokdogan at gmail.com (Goktug Gokdogan) Date: Sat, 30 Jan 2010 23:04:45 -0500 Subject: Serialization problem In-Reply-To: <4B64D25E.5030709@joda.org> References: <4B64D25E.5030709@joda.org> Message-ID: I would put the first element to a different field, make periods field transient and implement a readResolve method that calls a constructor. So, something like this should solve your problem easily, right? private final String name private final Duration duration private final PeriodField firstPeriod private final transient List periods private final transient int hashCode private Object readResolve() throws java.io.ObjectStreamException { return new MyImmutableClass(name, duration, firstPeriod); //you can define a private constructor if required } On Sat, Jan 30, 2010 at 7:44 PM, Stephen Colebourne wrote: > I thought I'd raise an issue with serialization that I've had a problem > with more than once. Perhaps there is an obvious easy solution, but I can't > see it (I can see hard workarounds...) > > In JSR-310 we have lots of immutable classes. One of these stores four > fields: > > private final String name > private final Duration duration > private final List periods > private final int hashCode > > For serialization, I only need to store the name, duration and element zero > from the periods list. (The rest of the period list is a cache derived from > the first element. Similarly, I want to cache the hash code in the > constructor as this could be performance critical.). Storing just these > fields can be done easily using writeObject() > > But, when you implement readObject(), you cannot store the read values into > the fields because they are final. Nor can I stash them somewhere ready for > readResolve(). > > From my perspective, what I need is a combined readObject() and > readResolve(): > > private Object readObjectAndResolve() > > I could then read the stream, and call the constructor to properly > initialise the object state (including the full period list and hash code > caches). This seems to be a general problem with deserializing immutable > classes. > > Workarounds include lazily creating the caches in transient fields, > bloating the serialzed data, using reflection or creating a dummy inner > class to act as the serialized form. All are rubbish solutions. > > Any suggestions? And if not, what about adding the suggested method to the > JDK? > > Stephen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scolebourne at joda.org Sun Jan 31 09:31:31 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 31 Jan 2010 09:31:31 +0000 Subject: Serialization problem In-Reply-To: References: <4B64D25E.5030709@joda.org> Message-ID: <4b4f45e01001310131x57a81a5bi441e26a71a9abb56@mail.gmail.com> Agreed, the solution below works in the use case I gave (and thats what I'm using as a workaround). However, its not optimal, which is why I raised the (broader) question here. (This solution doesn't allow me to use readObject/writeObject to actually control the wire bits, such as to flatten the Duration and PeriodField to their constituent parts. Thats part of the broader problem of controlling the serialized form of an immutable class, without needing an inner proxy class.) On 31 January 2010 04:04, Goktug Gokdogan wrote: > I would put the first element to a different field, make periods field > transient and implement a readResolve method that calls a constructor. > > So, something like this should solve your problem easily, right? > > ?private final String name > ?private final Duration duration > ?private final?PeriodField firstPeriod > ?private final transient List periods > ?private final transient int hashCode > ?private Object readResolve() throws java.io.ObjectStreamException { > ?? ?return new MyImmutableClass(name, duration, firstPeriod); //you can > define a private constructor if required > ?} > On Sat, Jan 30, 2010 at 7:44 PM, Stephen Colebourne > wrote: >> >> I thought I'd raise an issue with serialization that I've had a problem >> with more than once. Perhaps there is an obvious easy solution, but I can't >> see it (I can see hard workarounds...) >> >> In JSR-310 we have lots of immutable classes. One of these stores four >> fields: >> >> ?private final String name >> ?private final Duration duration >> ?private final List periods >> ?private final int hashCode >> >> For serialization, I only need to store the name, duration and element >> zero from the periods list. (The rest of the period list is a cache derived >> from the first element. Similarly, I want to cache the hash code in the >> constructor as this could be performance critical.). Storing just these >> fields can be done easily using writeObject() >> >> But, when you implement readObject(), you cannot store the read values >> into the fields because they are final. Nor can I stash them somewhere ready >> for readResolve(). >> >> From my perspective, what I need is a combined readObject() and >> readResolve(): >> >> ?private Object readObjectAndResolve() >> >> I could then read the stream, and call the constructor to properly >> initialise the object state (including the full period list and hash code >> caches). This seems to be a general problem with deserializing immutable >> classes. >> >> Workarounds include lazily creating the caches in transient fields, >> bloating the serialzed data, using reflection or creating a dummy inner >> class to act as the serialized form. All are rubbish solutions. >> >> Any suggestions? And if not, what about adding the suggested method to the >> JDK? >> >> Stephen >> > > From Alan.Bateman at Sun.COM Sun Jan 31 13:35:58 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 31 Jan 2010 13:35:58 +0000 Subject: Serialization problem In-Reply-To: <4B64D25E.5030709@joda.org> References: <4B64D25E.5030709@joda.org> Message-ID: <4B65873E.1070006@sun.com> Stephen Colebourne wrote: > I thought I'd raise an issue with serialization that I've had a > problem with more than once. Perhaps there is an obvious easy > solution, but I can't see it (I can see hard workarounds...) > > In JSR-310 we have lots of immutable classes. One of these stores four > fields: > > private final String name > private final Duration duration > private final List periods > private final int hashCode > > For serialization, I only need to store the name, duration and element > zero from the periods list. (The rest of the period list is a cache > derived from the first element. Similarly, I want to cache the hash > code in the constructor as this could be performance critical.). > Storing just these fields can be done easily using writeObject() In the JDK there are places that use unsafe's putObjectVolatile to workaround this. It's also possible to use reflection hacks in some cases. There is more discussion here: http://bugs.sun.com/view_bug.do?bug_id=6379948 Doug Lea and the concurrency group were working on a Fences API that included a method for safe publication so that one can get the same effects as final for cases where it's not possible to declare a field as field. For the hashCode case above then perhaps it doesn't necessary to compute the hash code in the constructor or when reconstituting the object. Instead perhaps the hashCode method could compute and set the hashCode field when it sees the value is 0 (no need to be volatile and shouldn't matter if more than one thread computes it). -Alan. From pdoubleya at gmail.com Sun Jan 31 17:02:27 2010 From: pdoubleya at gmail.com (Patrick Wright) Date: Sun, 31 Jan 2010 18:02:27 +0100 Subject: Math project or subproject In-Reply-To: <4B62A425.7040506@sun.com> References: <4B62A425.7040506@sun.com> Message-ID: <64efa1ba1001310902s6324599fqcd5a38e510bff696@mail.gmail.com> Hi Dima I think a goal for such a Math subproject would be to engage in active, constructive discussion with a wider community interested in high-performance math libs on the JVM. The folks behind Apache Commons Math and COLT are two obvious examples. I'm sure there has been communication back and forth over the years between the JDK developers and external groups on math libs, but I don't know of any public repository for those discussions. This is not to say that there isn't room for math libraries outside of the JDK, or that top priority shouldn't be on backwards compatibility, but it seems more open dialogue (especially public dialog on mailing lists) would be welcome. In particular, in those cases where it's decided that a certain "optimization" will not be added to the JDK, the reasons will be recorded publicly and for posterity; and if the factors influencing those decisions change over time, as the JVMs improve and new CPUs come to market, then the decisions can be re-reviewed later, again, based on open, public discussion. In addition, I think that having an open-source micro-benchmarking library for this purpose would be very helpful. It might not be perfect or all-encompassing, but it would allow researchers and tinkerers a base on which to test their own code, and on which to base arguments of "improvements" to the current libs. In essence, it would be like saying that the OpenJDK is written as it is because it works well in these standard benchmarks, and if someone thinks they have improvements, they have to prove it against the same benchmarks that Sun/Oracle has used for their own decision-making. There is/was a Sun project I mentioned on another JDK thread, Japex (search online) which is a test harness for micro-benchmarking. Perhaps something like this could provide a standard benchmarking, with records of historical results, into which different tests could be plugged. I don't have any reason to prefer Japex over Caliper or another framework; in general I think that a framework that could take care (at least) of isolating the warm-up phase, taking and recording measurements, etc. would be better than people starting from scratch in main() each time they write a benchmark. Best of luck with your effort. Regards Patrick On Fri, Jan 29, 2010 at 10:02 AM, Dmitry Nadezhin wrote: > In my previous post I discussed choice criteria for performance enhancements > in math libraries. > > I guess that in production projects Jdk 1.6 and Jdk 1.7 the main choice > criteria is stability. > This explains why changes to math stuff in Java are almost impossible. > Here is a pair of examples: > 1) The Karatsuba multiplication in BigInteger > http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-January/000225.html > (contribution proposals) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000229.html > (proposals approved) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000236.html > (patch submitted) > This patch is still not in OpenJdk tree. > 2) Double.parseDouble(String s) loops infinitely on some inputs > http://bugs.sun.com/view_bug.do?bug_id=4421494 > (one-line fix was suggested in bug database comment in 2004) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003153.html > (fix was submitted again together with tests) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003182.html > (fix was scheduled for verification) > This patch is still not in OpenJdk tree. > > I respect our "Java Floating-Point Czar" for keeping stability of mainstream > Java. > However, I suspect that some OpenJdk users prefer enhancements and bug fixes > of old bugs in math libraries > in exchange for a small risk of new bugs. Perhaps some new languages may > need enhancements in OpenJdk math > (scala, fortress, frink, fantom). > http://www.scala-lang.org/ > http://projectfortress.sun.com/Projects/Community/ > http://futureboy.homeip.net/frinkdocs/ > http://fantom.org/ > > What about more rapid enhancement of OpenJdk math in some project related to > but separate from OpenJDK 6 and (Open) JDK 7 ? > This may be a new Math project or a subproject of the Da Vinci Machine > Project. > > I see such works which can be done in such a project. > > I) Jdk changes > 1) bug fixing of known math bugs from bug database; > 2) creating microbenchmarks for performance enhancements request > ? Keeping a collection of alternative implementations and picking currently > fastest implementation > 3) Static methods which performs arithmetic operations on doubles with > RoundingMode.FLOOR and > RoundingMode.CEILING for use in interval computations. > 4) Arbitrary-precision classes: > ?Rational - rational numbers together with infinities and signed zero > ?Binary - floating-point binary numbers > 5) Classes for some particular floating-point binary formats: > ?BINARY128, BINARY80. > 6) Universal Comparator to compare values of different subclasses > ? of Number with each other. Different quiet and signalling relational > operators > ?mentioned in IEEE 754r standard. > 7) Implementation of forthcoming P1788 Interval Arithmetic standard > http://grouper.ieee.org/groups/1788/ > > II) HotSpot changes. > I consider useful to intrinsify some methods from above (3),(4),(5),(7)., > > III) Quality > ?Perhaps the math libraries are a proper subject for Formal Verification. > ?Operation on numbers are easy to specify by formal tools. > ?It is easy to make long-live bugs in math libraries which can be detected > by attempt to prove. > ?There are already tools to assist formal proofs. > http://coq.inria.fr/ > http://lipforge.ens-lyon.fr/www/pff/ > http://gappa.gforge.inria.fr/ > http://why.lri.fr/ > http://krakatoa.lri.fr/ > > What do people think about a Math project or subproject ? > > ?-Dima > > From opinali at gmail.com Sun Jan 31 17:42:30 2010 From: opinali at gmail.com (Osvaldo Doederlein) Date: Sun, 31 Jan 2010 15:42:30 -0200 Subject: Serialization problem In-Reply-To: <4B65873E.1070006@sun.com> References: <4B64D25E.5030709@joda.org> <4B65873E.1070006@sun.com> Message-ID: It's sad to see this issue of serialization vs. final resurface so many times. I have complained about this myself a number of times. The 'final' modifier is counter-intuitive as it doesn't really prohibit modification (most developers don't know that even a 'private static final' field can be updated by reflection or JNI, as explicitly allowed by the JLS). On top of that, Serialization was introduced without enough care for final fields, so we are effectively forced to drop 'final' for fields that require custom desserialization. Now these problems will bite us much more often because the immutable-object technique is being increasingly adopted, sometimes by whole libraries, or even more radically by newer languages-for-the-JVM like Clojure (and I guess these languages would love to translate their semantically-immutable types into immutable JVM-level classes whenever possible, e.g. when mutable state is not introduced by the compiler as optimization around extra allocations). My suggestion (big one I know, perhaps an idea for Java 8...) - add some mechanism (annotation, type modifier, etc.) that allows to fix/strengthen the semantics of final and serialization (and more? some suggestions below...), as follows: 1) Final fields are guaranteed immutable, forever, after construction. They cannot be changed by magic reflection calls from trusted classes, or even by JNI calls. (If it's too expensive to write-protect against arbitrary JNI code, spec the result as 'undefined behavior', and perform the very expensive check only with -Xcheck:jni.) 2) readObject() and other desserialization helpers can update final fields. The "final freeze" is defined to happen only after desserialization is complete. (If readObject() is invokes some helper methods, even if these methods are in the same class and only used by desserialization, they cannot assign to final fields; no need to make this check complex.) 3) In final fields of array type, the array elements are also immutable after the final-freeze. (I know this creates some challenges. Within the same class, maybe we can do enough effort to make sure that array field is not assigned/aliased/reflected in a way that would allow modification to elements. Then we can just decree that the array cannot be escape its class; so if one wants a getter for the array, it's mandatory to return a copy of it. This technique - defensive copying - is already a best-practice, so it's not really extra cost. And the JIT can always eliminate copying in cases covered by Escape Analysis, e.g. in println(obj.getStuff()[5]), it's trivial to see that the array copy performed by getStuff() can be avoided at this particular callsite.) 4) If the class is Serializable, providing serialVersionUID is mandatory. 5) If the class overloads hashCode(), it must overload equals() and vice-versa. 6) If the class (or some of its superclasses except Object) doesn't overload hashCode(), a call to hashCode() throws an exception; that is, relying on Object.hashCode() is banned. 7) Some interaction with JSR-305 (enforcing the semantics of its annotations further - a real pluggable typesystem)? 8..) More? The general idea is enforcing as much "Modern POJO Best-Practices" as possible (without requiring extra code, so I don't propose things such as mandating hashCode/equals to be overridden). This enforcement should be hard-line, with detection of uncompliance at both runtime and (when possible) compile-time. It should be robust enough (no possible circumvention) so the security system could rely on it to enforce security concerns without extra runtime checks, and the JIT optimizer could rely on it to enable aggressive optimizations. A+ Osvaldo 2010/1/31 Alan Bateman > Stephen Colebourne wrote: > >> I thought I'd raise an issue with serialization that I've had a problem >> with more than once. Perhaps there is an obvious easy solution, but I can't >> see it (I can see hard workarounds...) >> >> In JSR-310 we have lots of immutable classes. One of these stores four >> fields: >> >> private final String name >> private final Duration duration >> private final List periods >> private final int hashCode >> >> For serialization, I only need to store the name, duration and element >> zero from the periods list. (The rest of the period list is a cache derived >> from the first element. Similarly, I want to cache the hash code in the >> constructor as this could be performance critical.). Storing just these >> fields can be done easily using writeObject() >> > In the JDK there are places that use unsafe's putObjectVolatile to > workaround this. It's also possible to use reflection hacks in some cases. > There is more discussion here: > http://bugs.sun.com/view_bug.do?bug_id=6379948 > > Doug Lea and the concurrency group were working on a Fences API that > included a method for safe publication so that one can get the same effects > as final for cases where it's not possible to declare a field as field. > > For the hashCode case above then perhaps it doesn't necessary to compute > the hash code in the constructor or when reconstituting the object. Instead > perhaps the hashCode method could compute and set the hashCode field when it > sees the value is 0 (no need to be volatile and shouldn't matter if more > than one thread computes it). > > -Alan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scolebourne at joda.org Sun Jan 31 20:50:42 2010 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 31 Jan 2010 20:50:42 +0000 Subject: Serialization problem In-Reply-To: <4B65873E.1070006@sun.com> References: <4B64D25E.5030709@joda.org> <4B65873E.1070006@sun.com> Message-ID: <4b4f45e01001311250r3f83cdal8b314aafb5d7b735@mail.gmail.com> Thanks for the info. Unfortunately, JSR-310 cannot use unsafe, as it needs to be usable outside the JDK. For info, I compared the sizes of a neatly trimmed output (using a Serialization proxy class) with the best achievable without one. 277 bytes without, 99 bytes with a proxy. So, this isn't an esoteric problem. What would you think of using a ThreadLocal to cache the result value between readObject() and readResolve() ? (making everything transient and using a dedicated format) What do you think of the general idea of readObjectAndResolve() ? (for JDK 7+) Stephen On 31 January 2010 13:35, Alan Bateman wrote: > Stephen Colebourne wrote: >> >> I thought I'd raise an issue with serialization that I've had a problem >> with more than once. Perhaps there is an obvious easy solution, but I can't >> see it (I can see hard workarounds...) >> >> In JSR-310 we have lots of immutable classes. One of these stores four >> fields: >> >> ?private final String name >> ?private final Duration duration >> ?private final List periods >> ?private final int hashCode >> >> For serialization, I only need to store the name, duration and element >> zero from the periods list. (The rest of the period list is a cache derived >> from the first element. Similarly, I want to cache the hash code in the >> constructor as this could be performance critical.). Storing just these >> fields can be done easily using writeObject() > > In the JDK there are places that use unsafe's putObjectVolatile to > workaround this. It's also possible to use reflection hacks in some cases. > There is more discussion here: > ?http://bugs.sun.com/view_bug.do?bug_id=6379948 > > Doug Lea and the concurrency group were working on a Fences API that > included a method for safe publication so that one can get the same effects > as final for cases where it's not possible to declare a field as field. > > For the hashCode case above then perhaps it doesn't necessary to compute the > hash code in the constructor or when reconstituting the object. Instead > perhaps the hashCode method could compute and set the hashCode field when it > sees the value is 0 (no need to be volatile and shouldn't matter if more > than one thread computes it). > > -Alan. > > >