From coleen.phillimore at oracle.com Thu Dec 1 15:58:33 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 01 Dec 2011 23:58:33 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111201235840.C6C09474F7@hg.openjdk.java.net> Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/242b4e0e6f73 7116189: Export JVM_SetNativeThreadName from Hotspot Summary: Added JVM_SetNativeThreadName to linker mapfiles on Solaris and Linux. Reviewed-by: dcubed, dholmes Contributed-by: michael.x.mcmahon at oracle.com ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers Changeset: 763f01599ff4 Author: phh Date: 2011-11-29 17:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/763f01599ff4 7116481: Commercial features in Hotspot must be gated by a switch Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. Reviewed-by: jwilhelm, kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 358eca91be48 Author: phh Date: 2011-11-30 12:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/358eca91be48 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch Summary: Revert 7116481 to current hsx/hotspot-main Reviewed-by: kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 81a08cd7f6a1 Author: coleenp Date: 2011-12-01 13:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81a08cd7f6a1 Merge From john.coomes at oracle.com Thu Dec 1 20:35:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:35:39 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b15 for changeset a4f28069d44a Message-ID: <20111202043539.D46E0474FA@hg.openjdk.java.net> Changeset: 4e06ae613e99 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4e06ae613e99 Added tag jdk8-b15 for changeset a4f28069d44a ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:35:45 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:35:45 +0000 Subject: hg: hsx/hotspot-main/corba: 3 new changesets Message-ID: <20111202043549.1DFC1474FB@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/44c269731425 7091388: Regular unexplained npe's from corba libs after system has been running for days Reviewed-by: alanb ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java Changeset: 7da69e7175a7 Author: lana Date: 2011-11-18 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/7da69e7175a7 Merge Changeset: 82dc033975bb Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/82dc033975bb Added tag jdk8-b15 for changeset 7da69e7175a7 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:35:54 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:35:54 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b15 for changeset 804f666d6d44 Message-ID: <20111202043554.A24AB474FC@hg.openjdk.java.net> Changeset: 8181f7634e4a Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/8181f7634e4a Added tag jdk8-b15 for changeset 804f666d6d44 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:36:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:36:00 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b15 for changeset c9ab96ff23d5 Message-ID: <20111202043600.46CBA474FD@hg.openjdk.java.net> Changeset: 76e37e606354 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/76e37e606354 Added tag jdk8-b15 for changeset c9ab96ff23d5 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:36:54 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:36:54 +0000 Subject: hg: hsx/hotspot-main/jdk: 34 new changesets Message-ID: <20111202044259.18B5747502@hg.openjdk.java.net> Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89952dc5be8e 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h Reviewed-by: prr, bae Contributed-by: littlee at linux.vnet.ibm.com ! src/share/native/sun/awt/medialib/mlib_types.h Changeset: 60331bbcf4ad Author: lana Date: 2011-11-18 16:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60331bbcf4ad Merge Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f410b91caf45 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java Changeset: 52be75d060f9 Author: weijun Date: 2011-11-09 15:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52be75d060f9 7109096: keytool -genkeypair needn't call -selfcert Reviewed-by: xuelei ! src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java Changeset: d6a5da5f6ba0 Author: dl Date: 2011-11-10 12:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6a5da5f6ba0 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Reviewed-by: chegar, mduigou, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: 0ccfb35cce26 Author: michaelm Date: 2011-11-10 15:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ccfb35cce26 7110484: HttpServer.stop() not closing selector Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: e5d65a583c15 Author: michaelm Date: 2011-11-10 15:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e5d65a583c15 Merge Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/830d2e46023a 7110111: Minor Java SE javadoc & Constructor clean up Reviewed-by: alanb, darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/util/jar/Attributes.java Changeset: 9dd994f319ee Author: coffeys Date: 2011-11-11 10:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9dd994f319ee 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/solaris/classes/java/io/FileDescriptor.java ! src/windows/classes/java/io/FileDescriptor.java - test/java/io/FileDescriptor/FileChannelFDTest.java + test/java/io/FileDescriptor/Sharing.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 5c7c83a6ee24 Author: xuelei Date: 2011-11-14 01:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5c7c83a6ee24 7111548: unexpected debug log message Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 68fc55d12ae6 Author: chegar Date: 2011-11-14 10:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/68fc55d12ae6 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/classes/java/net/PlainSocketImpl.java Changeset: c740519fe83a Author: weijun Date: 2011-11-16 11:53 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c740519fe83a 7111579: klist starttime, renewtill, ticket etype Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: cd6d236e863b Author: okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author: okutsu Date: 2011-11-16 13:17 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1266e72f7896 Merge Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/398442b00b2b 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Reviewed-by: ohair, katleman ! make/docs/Makefile Changeset: 3cd7dcf4a302 Author: mchung Date: 2011-11-17 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3cd7dcf4a302 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung Contributed-by: gary.adams at oracle.com ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java Changeset: 5bfff9616b86 Author: weijun Date: 2011-11-18 16:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bfff9616b86 7077172: KerberosTime does not take into account system clock adjustement Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/KerberosTime.java Changeset: cd37d8066437 Author: lana Date: 2011-11-18 11:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd37d8066437 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: c98235762b30 Author: alanb Date: 2011-11-19 19:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c98235762b30 6818464: TEST_BUG: java/util/Timer/KillThread.java failing intermittently Reviewed-by: dholmes, alanb, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 8be37eae9598 Author: alanb Date: 2011-11-19 19:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8be37eae9598 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf Reviewed-by: dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/Args.java Changeset: 450c17e4808d Author: alanb Date: 2011-11-19 20:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/450c17e4808d 6860309: TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java Reviewed-by: alanb, dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java Changeset: 184578f3e8b9 Author: alanb Date: 2011-11-21 12:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/184578f3e8b9 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Reviewed-by: forax, chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/Stop.java Changeset: 2db942c7eb9c Author: alanb Date: 2011-11-21 12:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2db942c7eb9c 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Reviewed-by: dholmes, alanb Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 81987765cb81 Author: ngmr Date: 2011-11-11 14:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/81987765cb81 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Reviewed-by: chegar, alanb, mduigou, ngmr Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h Changeset: ee2fa62fb09f Author: ngmr Date: 2011-11-22 09:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ee2fa62fb09f 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Reviewed-by: chegar Contributed-by: Neil Richards ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 1945abeb82a0 Author: mullan Date: 2011-11-22 08:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1945abeb82a0 7093090: Reduce synchronization in java.security.Policy.getPolicyNoCheck Reviewed-by: valeriep ! src/share/classes/java/security/Policy.java Changeset: bb8f19b80557 Author: mullan Date: 2011-11-22 09:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb8f19b80557 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: b4d7020c2a40 Author: mullan Date: 2011-11-22 09:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4d7020c2a40 Merge Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/82151e860a64 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Summary: also reviewed by Dennis.Gu at oracle.com Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java Changeset: 7eb0debca9b3 Author: chegar Date: 2011-11-23 12:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7eb0debca9b3 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX Reviewed-by: chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/NullThreadName.java Changeset: d27f0b2f1476 Author: coffeys Date: 2011-11-23 14:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d27f0b2f1476 7102369: remove java.rmi.server.codebase property parsing from registyimpl 7094468: rmiregistry clean up Reviewed-by: smarks ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java + test/java/rmi/registry/readTest/readTest.java + test/java/rmi/registry/readTest/readTest.sh + test/java/rmi/registry/readTest/testPkg/Client.java + test/java/rmi/registry/readTest/testPkg/Hello.java + test/java/rmi/registry/readTest/testPkg/Server.java Changeset: 855675a4235b Author: lana Date: 2011-11-23 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/855675a4235b Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 3c248d0e2c48 Author: lana Date: 2011-11-28 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c248d0e2c48 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 929597c6e777 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/929597c6e777 Added tag jdk8-b15 for changeset 3c248d0e2c48 ! .hgtags From david.holmes at oracle.com Thu Dec 1 21:32:17 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 02 Dec 2011 15:32:17 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4ED50287.3070102@oracle.com> References: <4ED50287.3070102@oracle.com> Message-ID: <4ED862E1.6040903@oracle.com> Hi Mikael, On 30/11/2011 2:04 AM, Mikael Gerdin wrote: > I've been working on a white box testing API for HotSpot in order to > allow for improved precision in vm testing. > > The basic idea is to open up the possibility for tests written in Java > to call native methods which query or poke the vm in some way. > > The API is accessible by using the class sun/hotspot/WhiteBox which is > not intended to be available in public builds. Where "public" means non-developer builds - right? But what if someone simply puts wb.jar in their classpath? > In order to allow the WhiteBox class access to the VM the > registerNatives function is linked to JVM_RegisterWhiteBoxMethods. That > function then links all the implementation functions using normal JNI > RegisterNatives. > > The API is not meant to be used by end users for any intent or purpose > and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions > -XX:+EnableWhiteboxAPI" and the fact that the class files will not be > present in an end user build of a JDK. I'm a little confused as to where wb.jar ends up when I build hotspot. I see this in a makefile: 26 WB = wb 27 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src 29 30 WB_JAR = $(GENERATED)/$(WB).jar 31 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) Why JAVA_HOME? That's normally a binary installation of a JDK used for building, not somewhere I expect my build to try and put something. Plus the above will expand to: $(JAVA_HOME)/lib/$(GENERATED)/wb.jar which doesn't seem right either. And if I build a full JDK, where does wb.jar end up then? I also see in make/Makefile: 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar 371 $(install-file) Why the endorsed subdirectory? This is nothing to do with an "endorsed standard": http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ ??? Thanks, David ----- > If the VM crashes after this API has been accessed a note will be > written in the hs_err file to signal that the API has been used. > > Webrev: > http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ > (thanks to stefank for hosting my webrev :) > > CR: > I'll file a CR tomorrow. > > Change comments: > > make/jprt.properties > > Add a test target to make sure that the API is available on all > supported platforms > > make/** > > Makefile changes to build the class sun/hotspot/WhiteBox, put it in a > JAR file and copy it to the jre/lib/endorsed directory in the export > targets. > The BSD makefile changes are not tested since I don't have access to any > BSD/OSX machine to test them on. > > src/share/vm/prims/nativeLookup.cpp > > Special-case the method sun/hotspot/WhiteBox/registerNatives and link it > to JVM_RegisterWhiteBoxMethods > > src/share/vm/prims/whitebox.* > > The implementation of the white box API. The actual API functions are > only examples of what we want to be able to do using the API. > > src/share/vm/runtime/globals.hpp > > Add the command line flag > > src/share/vm/utilities/vmError.cpp > > Print a message in hs_err files when white box API has been used. > > test/Makefile > > Add a makefile test target for the white box API test > > test/sanity/wbapi.java > > JTreg test to ensure that the API works. > > > Thanks > /Mikael Gerdin From mikael.gerdin at oracle.com Fri Dec 2 02:46:16 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 02 Dec 2011 11:46:16 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4ED862E1.6040903@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> Message-ID: <4ED8AC78.5000508@oracle.com> On 2011-12-02 06:32, David Holmes wrote: > Hi Mikael, > > On 30/11/2011 2:04 AM, Mikael Gerdin wrote: >> I've been working on a white box testing API for HotSpot in order to >> allow for improved precision in vm testing. >> >> The basic idea is to open up the possibility for tests written in Java >> to call native methods which query or poke the vm in some way. >> >> The API is accessible by using the class sun/hotspot/WhiteBox which is >> not intended to be available in public builds. > > Where "public" means non-developer builds - right? Yes. > > But what if someone simply puts wb.jar in their classpath? It won't work. They need to put it in the boot class path in order to get it to work. Additinally they'll need to add "-XX:+UnlockDiagnosticVMOptions -XX:+EnableWhiteboxAPI" to their command line. But yes, it is not impossible to use from a "non-developer" build. > >> In order to allow the WhiteBox class access to the VM the >> registerNatives function is linked to JVM_RegisterWhiteBoxMethods. That >> function then links all the implementation functions using normal JNI >> RegisterNatives. >> >> The API is not meant to be used by end users for any intent or purpose >> and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions >> -XX:+EnableWhiteboxAPI" and the fact that the class files will not be >> present in an end user build of a JDK. > > I'm a little confused as to where wb.jar ends up when I build hotspot. I > see this in a makefile: There are a couple of issues in these make files. > > 26 WB = wb > 27 > 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src > 29 > 30 WB_JAR = $(GENERATED)/$(WB).jar > 31 > 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) > > Why JAVA_HOME? That's normally a binary installation of a JDK used for > building, not somewhere I expect my build to try and put something. Plus > the above will expand to: For example, look in jsig.make. It has a target that copies libjsig to JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior with the "install"-targets in the make files. > > $(JAVA_HOME)/lib/$(GENERATED)/wb.jar > > which doesn't seem right either. Agreed, that's incorrect. > > And if I build a full JDK, where does wb.jar end up then? $ find . -name wb.jar ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar The JDK makefiles that build the j2{sdk,re}-image directories do not pick up the wb.jar file. > > I also see in make/Makefile: > > 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar > 371 $(install-file) > > Why the endorsed subdirectory? This is nothing to do with an "endorsed > standard": > > http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ Because of security requirements and implementation details the Whitebox class must be available on the boot class path. Putting the wb.jar file in the endorsed directory is a quick and easy way to achieve that. Does this clarify your concerns? /Mikael Gerdin > > ??? > > Thanks, > David > ----- > >> If the VM crashes after this API has been accessed a note will be >> written in the hs_err file to signal that the API has been used. >> >> Webrev: >> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >> (thanks to stefank for hosting my webrev :) >> >> CR: >> I'll file a CR tomorrow. >> >> Change comments: >> >> make/jprt.properties >> >> Add a test target to make sure that the API is available on all >> supported platforms >> >> make/** >> >> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >> JAR file and copy it to the jre/lib/endorsed directory in the export >> targets. >> The BSD makefile changes are not tested since I don't have access to any >> BSD/OSX machine to test them on. >> >> src/share/vm/prims/nativeLookup.cpp >> >> Special-case the method sun/hotspot/WhiteBox/registerNatives and link it >> to JVM_RegisterWhiteBoxMethods >> >> src/share/vm/prims/whitebox.* >> >> The implementation of the white box API. The actual API functions are >> only examples of what we want to be able to do using the API. >> >> src/share/vm/runtime/globals.hpp >> >> Add the command line flag >> >> src/share/vm/utilities/vmError.cpp >> >> Print a message in hs_err files when white box API has been used. >> >> test/Makefile >> >> Add a makefile test target for the white box API test >> >> test/sanity/wbapi.java >> >> JTreg test to ensure that the API works. >> >> >> Thanks >> /Mikael Gerdin From mikael.vidstedt at oracle.com Fri Dec 2 05:59:14 2011 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 02 Dec 2011 14:59:14 +0100 Subject: Improving the documention of the JVM implementation interface In-Reply-To: <1322577043.6819.5.camel@jazzette> References: <1322058589.13674.7.camel@jazzette> <1322577043.6819.5.camel@jazzette> Message-ID: <4ED8D9B2.9060500@oracle.com> As Steve says, improving and clarifying the the dependencies and interaction points between the JVM and the libraries is something I'm happy to support. The JVM_* functions already have some documentation, but even there I'm sure there are things that can be clarified, and I fully agree that things like Attach functionality could use some documentation work. One thing I'd like to stress is that the goal of this project should not be to lock down the interface between the JVM and the JDK. Even though we should for a number of different reasons try to keep the interfaces changes to a minimum, we need to preserve the right to change them without having to go through lengthy standardization processes etc. I don't think that contradicts the goal of this project though. I'm sure there are people who have been involved in projects where documentation like this would have been very helpful. If at all possible I'd like to encourage you to share your thoughts on this and if possible help us out going forward. Thanks, Mikael On 2011-11-29 15:30, Steve Poole wrote: > On Thu, 2011-11-24 at 11:26 +0800, Krystal Mok wrote: >> Hi Steve, >> >> >> There's been some efforts in this area before. There's an OpenJDK >> project called "Common VM Interface" [1], ran by Dr Andrew John >> Hughes. One of the earlier notes can be found at [2]. The aims of this >> project seems to be in the same direction as what you're looking for. > Hi Krystal - sorry for the delay in responding: been somewhat email > server challenged. Its possible the cmvi project could be used to do > this work but it seems very quiet at the moment. Besides, this proposal > is about documenting what exists today, so I'd rather have the > conversation on a mailing list that the people who know frequent :-) >> >> Xi Yang has been working on integrating OpenJDK class libraries into >> Jikes RVM this year. This work also needed a definition of the VM >> interface in OpenJDK. He's made quite a lot of progress already, so he >> might be able to help out with this documentation proposal. I'm cc'ing >> this mail to him. >> >> >> - Kris >> >> >> [1]: http://openjdk.java.net/projects/cvmi/ >> [2]: http://mail.openjdk.java.net/pipermail/cvmi-dev/2008-July/000006.html >> >> On Wed, Nov 23, 2011 at 10:29 PM, Steve Poole >> wrote: >> Hi all, I've been talking to Mikael Vidstedt and a few other >> Oracle >> luminaries about improving the documentation of the interface >> between >> the JVM and the rest of the SDK. >> >> We wanted to make that discussion public hence this post. >> I'll start >> and Mikael can jump in. >> >> What I'm trying to do is simply gain some agreement on what >> code is JVM >> implementation specific and what isn't. Then, where this JVM >> implementation specific code interacts with the SDK, improve >> the >> documentation. >> >> A few examples to consider... >> >> JVM_* entry points in the VM that are there for the class >> library code >> to call: these are not part of the public JNI spec - I'd like >> to get >> them documented in more detail. >> >> These extra entry points can blur the line between the JVM and >> the class >> libraries: sometimes making it's difficult to work out if the >> "real" >> API is the C entry point or the calling Java class. To put it >> another >> way - there is Java code that is intentionally JVM >> implementation >> specific. I'd like to get that status documented. >> >> Another similar example is where Hotspot code leaks out of the >> JVM into >> the class libs and tools. The Late Attach API is a good (or >> is that >> bad) example. Sometimes it's difficult to work out if that >> leakage is >> intentional or inadvertent. I'd like to get that status >> documented too. >> >> So to recap: what I'd like to do is discover and document the >> API >> between the JVM implementation specific code and everything >> else. >> Hopefully in the process improving everyone's awareness and >> getting some >> common agreement over actual behaviour or design versus >> intention. This >> work might discover areas that could benefit from improved >> interface >> design and some form of refactoring but that would be for >> later. >> >> >> Thanks >> >> Steve >> >> >> >> > From paul.hohensee at oracle.com Fri Dec 2 07:54:23 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 02 Dec 2011 10:54:23 -0500 Subject: Pls review (S) 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot Message-ID: <4ED8F4AF.8070107@oracle.com> Webrev here: http://cr.openjdk.java.net/~phh/7117389/ This webrev defines and uses, but does not implement, a switch extension interface. I've added a new file, globals_ext.hpp, that contains hooks for vendor-specific additions to the set of Hotspot command line switches and added their use to globals.hpp, globals.cpp and globals_extension.hpp. I chose "_ext" as a generic suffix for files containing extension hooks. In effect, such files are interface definitions. A vendor supplies a file, perhaps of the same name in another source base (as can be seen in the Hotspot makefiles), that implements the extension hooks. Thanks, Paul From tony.printezis at oracle.com Fri Dec 2 08:06:33 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 02 Dec 2011 16:06:33 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20111202160655.6DC104751D@hg.openjdk.java.net> Changeset: a88de71c4e3a Author: tonyp Date: 2011-11-18 12:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a88de71c4e3a 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class Summary: Major cleanup of the G1CollectorPolicy class. It removes a lot of unused fields and methods and also consolidates replicated information (mainly various ways of counting the number of CSet regions) into one copy. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d06a2d7fcd5b Author: brutisso Date: 2011-11-21 07:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d06a2d7fcd5b 7110718: -XX:MarkSweepAlwaysCompactCount=0 crashes the JVM Summary: Interpret MarkSweepAlwaysCompactCount < 1 as never do full compaction Reviewed-by: ysr, tonyp, jmasa, johnc ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/memory/space.hpp Changeset: b5a5f30c483d Author: johnc Date: 2011-11-21 09:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5a5f30c483d 7110173: GCNotifier::pushNotification publishes stale data. Summary: GCNotifier::pushNotification() references GCMemoryManager::_last_gc_stat but is called from GCMemoryManager::gc_end() before GCMemoryManager::_last_gc_stat is set up using the values in GCMemoryManager::_current_gc_stat. As a result the GC notification code accesses unitialized or stale data. Move the notification call after GCMemoryManager::_las_gc_stat is set, but inside the same if-block. Reviewed-by: poonam, dholmes, fparain, mchung ! src/share/vm/services/memoryManager.cpp Changeset: 6071e0581859 Author: johnc Date: 2011-11-18 12:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6071e0581859 7111795: G1: Various cleanups identified during walk through of changes for 6484965 Summary: Various cleanups and formatting changes identified during a code walk through of the changes for 6484965 ("G1: piggy-back liveness accounting phase on marking"). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 3a298e04d914 Author: tonyp Date: 2011-11-22 04:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a298e04d914 Merge Changeset: bca17e38de00 Author: jmasa Date: 2011-08-09 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bca17e38de00 6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads Summary: Select number of GC threads dynamically based on heap usage and number of Java threads Reviewed-by: johnc, ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 00dd86e542eb Author: johnc Date: 2011-11-28 09:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/00dd86e542eb 7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise Summary: Race between the VM thread reading G1CollectedHeap::_mark_in_progress and it being set by the concurrent mark thread when concurrent marking is aborted by a full GC. Have the concurrent mark thread join the SuspendibleThreadSet before changing the marking state. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: dc467e8b2c5e Author: johnc Date: 2011-11-17 12:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc467e8b2c5e 7112743: G1: Reduce overhead of marking closure during evacuation pauses Summary: Parallelize the serial code that was used to mark objects reachable from survivor objects in the collection set. Some minor improvments in the timers used to track the freeing of the collection set along with some tweaks to PrintGCDetails. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/oops/objArrayOop.hpp Changeset: ea640b5e949a Author: jmasa Date: 2011-11-22 14:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea640b5e949a 7106024: CMS: Removed unused code for precleaning in remark phase Summary: Remove dead code. Reviewed-by: stefank, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7913e93dca52 Author: jmasa Date: 2011-11-22 14:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7913e93dca52 7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure Summary: Remove obsolete code. Reviewed-by: brutisso, ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp Changeset: 1bbf5b6fb7b0 Author: tonyp Date: 2011-12-02 08:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1bbf5b6fb7b0 Merge ! src/share/vm/runtime/globals.hpp From john.coomes at oracle.com Fri Dec 2 12:53:21 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 20:53:21 +0000 Subject: hg: hsx/hotspot-main/langtools: 7 new changesets Message-ID: <20111202205338.6563C47522@hg.openjdk.java.net> Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/36553cb94345 7108668: allow Log to be initialized and used earlier Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: ae361e7f435a Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ae361e7f435a 7108669: cleanup Log methods for direct printing to streams Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: c1238fcc9515 Author: ksrini Date: 2011-11-14 08:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c1238fcc9515 7110974: (javac) add coding conventions and style checkers for langtools Reviewed-by: jjg ! make/build.properties ! make/build.xml + make/conf/checkstyle-emacs.xsl + make/conf/checkstyle-langtools.xml Changeset: 7375d4979bd3 Author: ksrini Date: 2011-11-14 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7375d4979bd3 7106166: (javac) re-factor EndPos parser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/EndPosTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/TreePosTest.java Changeset: f07d6f55d39a Author: lana Date: 2011-11-18 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f07d6f55d39a Merge Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/07599bd780ca 7110611: compiler message file broken for javac -fullversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: ec2c0973cc31 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ec2c0973cc31 Added tag jdk8-b15 for changeset 07599bd780ca ! .hgtags From john.coomes at oracle.com Fri Dec 2 19:51:07 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 03 Dec 2011 03:51:07 +0000 Subject: hg: hsx/hsx23/hotspot: 23 new changesets Message-ID: <20111203035157.A66FB4754E@hg.openjdk.java.net> Changeset: d1f29d4e0bc6 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d1f29d4e0bc6 Added tag jdk8-b15 for changeset fde2a39ed7f3 ! .hgtags Changeset: da4182086289 Author: jcoomes Date: 2011-11-18 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/da4182086289 7113503: Bump the hs23 build number to 07 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 36b057451829 Author: dholmes Date: 2011-11-16 20:38 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/36b057451829 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Reviewed-by: dholmes, dsamersoff Contributed-by: Chris Hegarty ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 002cb3fc8256 Author: coleenp Date: 2011-11-18 17:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/002cb3fc8256 Merge Changeset: c17bc65648de Author: brutisso Date: 2011-11-21 08:02 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c17bc65648de 7112308: Fix Visual Studio build for precompiled header Summary: Add the new path to precompiled.hpp in the project make file Reviewed-by: coleenp, dholmes, brutisso Contributed-by: rbackman ! make/windows/makefiles/projectcreator.make Changeset: 1d090cf33da6 Author: coleenp Date: 2011-11-21 10:22 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1d090cf33da6 Merge Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/242b4e0e6f73 7116189: Export JVM_SetNativeThreadName from Hotspot Summary: Added JVM_SetNativeThreadName to linker mapfiles on Solaris and Linux. Reviewed-by: dcubed, dholmes Contributed-by: michael.x.mcmahon at oracle.com ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers Changeset: 763f01599ff4 Author: phh Date: 2011-11-29 17:00 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/763f01599ff4 7116481: Commercial features in Hotspot must be gated by a switch Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. Reviewed-by: jwilhelm, kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 358eca91be48 Author: phh Date: 2011-11-30 12:48 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/358eca91be48 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch Summary: Revert 7116481 to current hsx/hotspot-main Reviewed-by: kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 81a08cd7f6a1 Author: coleenp Date: 2011-12-01 13:42 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/81a08cd7f6a1 Merge Changeset: a88de71c4e3a Author: tonyp Date: 2011-11-18 12:52 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a88de71c4e3a 7097002: G1: remove a lot of unused / redundant code from the G1CollectorPolicy class Summary: Major cleanup of the G1CollectorPolicy class. It removes a lot of unused fields and methods and also consolidates replicated information (mainly various ways of counting the number of CSet regions) into one copy. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d06a2d7fcd5b Author: brutisso Date: 2011-11-21 07:47 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d06a2d7fcd5b 7110718: -XX:MarkSweepAlwaysCompactCount=0 crashes the JVM Summary: Interpret MarkSweepAlwaysCompactCount < 1 as never do full compaction Reviewed-by: ysr, tonyp, jmasa, johnc ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/memory/space.hpp Changeset: b5a5f30c483d Author: johnc Date: 2011-11-21 09:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b5a5f30c483d 7110173: GCNotifier::pushNotification publishes stale data. Summary: GCNotifier::pushNotification() references GCMemoryManager::_last_gc_stat but is called from GCMemoryManager::gc_end() before GCMemoryManager::_last_gc_stat is set up using the values in GCMemoryManager::_current_gc_stat. As a result the GC notification code accesses unitialized or stale data. Move the notification call after GCMemoryManager::_las_gc_stat is set, but inside the same if-block. Reviewed-by: poonam, dholmes, fparain, mchung ! src/share/vm/services/memoryManager.cpp Changeset: 6071e0581859 Author: johnc Date: 2011-11-18 12:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6071e0581859 7111795: G1: Various cleanups identified during walk through of changes for 6484965 Summary: Various cleanups and formatting changes identified during a code walk through of the changes for 6484965 ("G1: piggy-back liveness accounting phase on marking"). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 3a298e04d914 Author: tonyp Date: 2011-11-22 04:47 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3a298e04d914 Merge Changeset: bca17e38de00 Author: jmasa Date: 2011-08-09 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/bca17e38de00 6593758: RFE: Enhance GC ergonomics to dynamically choose ParallelGCThreads Summary: Select number of GC threads dynamically based on heap usage and number of Java threads Reviewed-by: johnc, ysr, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 00dd86e542eb Author: johnc Date: 2011-11-28 09:49 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/00dd86e542eb 7114303: G1: assert(_g1->mark_in_progress()) failed: shouldn't be here otherwise Summary: Race between the VM thread reading G1CollectedHeap::_mark_in_progress and it being set by the concurrent mark thread when concurrent marking is aborted by a full GC. Have the concurrent mark thread join the SuspendibleThreadSet before changing the marking state. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: dc467e8b2c5e Author: johnc Date: 2011-11-17 12:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/dc467e8b2c5e 7112743: G1: Reduce overhead of marking closure during evacuation pauses Summary: Parallelize the serial code that was used to mark objects reachable from survivor objects in the collection set. Some minor improvments in the timers used to track the freeing of the collection set along with some tweaks to PrintGCDetails. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/oops/objArrayOop.hpp Changeset: ea640b5e949a Author: jmasa Date: 2011-11-22 14:18 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ea640b5e949a 7106024: CMS: Removed unused code for precleaning in remark phase Summary: Remove dead code. Reviewed-by: stefank, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7913e93dca52 Author: jmasa Date: 2011-11-22 14:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/7913e93dca52 7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure Summary: Remove obsolete code. Reviewed-by: brutisso, ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp Changeset: 1bbf5b6fb7b0 Author: tonyp Date: 2011-12-02 08:52 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1bbf5b6fb7b0 Merge ! src/share/vm/runtime/globals.hpp Changeset: 6de8c9ba5907 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/aed8bf036ce2 Added tag hs23-b07 for changeset 6de8c9ba5907 ! .hgtags From john.coomes at oracle.com Fri Dec 2 23:24:58 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 03 Dec 2011 07:24:58 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111203072507.B73954754F@hg.openjdk.java.net> Changeset: d1f29d4e0bc6 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d1f29d4e0bc6 Added tag jdk8-b15 for changeset fde2a39ed7f3 ! .hgtags Changeset: 6de8c9ba5907 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aed8bf036ce2 Added tag hs23-b07 for changeset 6de8c9ba5907 ! .hgtags Changeset: cf4dd13bbcd3 Author: jcoomes Date: 2011-12-02 21:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cf4dd13bbcd3 7117536: new hotspot build - hs23-b08 Reviewed-by: johnc ! make/hotspot_version From kirk at kodewerk.com Sat Dec 3 05:01:25 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Sat, 3 Dec 2011 14:01:25 +0100 Subject: Pls review (S) 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot In-Reply-To: <4ED8F4AF.8070107@oracle.com> References: <4ED8F4AF.8070107@oracle.com> Message-ID: <0F9EC0C0-2F22-42E6-A843-B7C8E26B55AB@kodewerk.com> Hi Paul, Does this imply that if I wanted to add a command line switch for my commercial product that was "embedded" into the JVM I would have to do this in a special build? I'm trying to sort out how this would work? Regards, Kirk On Dec 2, 2011, at 4:54 PM, Paul Hohensee wrote: > Webrev here: > > http://cr.openjdk.java.net/~phh/7117389/ > > This webrev defines and uses, but does not implement, a switch extension interface. > > I've added a new file, globals_ext.hpp, that contains hooks for vendor-specific additions > to the set of Hotspot command line switches and added their use to globals.hpp, > globals.cpp and globals_extension.hpp. I chose "_ext" as a generic suffix for files > containing extension hooks. In effect, such files are interface definitions. A vendor > supplies a file, perhaps of the same name in another source base (as can be seen in > the Hotspot makefiles), that implements the extension hooks. > > Thanks, > > Paul > From david.holmes at oracle.com Sun Dec 4 18:08:58 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Dec 2011 12:08:58 +1000 Subject: Pls review (S) 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot In-Reply-To: <4ED8F4AF.8070107@oracle.com> References: <4ED8F4AF.8070107@oracle.com> Message-ID: <4EDC27BA.7020600@oracle.com> Hi Paul, This looks okay to me, but I agree that an example of how to use it would help set the context for the review. David On 3/12/2011 1:54 AM, Paul Hohensee wrote: > Webrev here: > > http://cr.openjdk.java.net/~phh/7117389/ > > This webrev defines and uses, but does not implement, a switch extension > interface. > > I've added a new file, globals_ext.hpp, that contains hooks for > vendor-specific additions > to the set of Hotspot command line switches and added their use to > globals.hpp, > globals.cpp and globals_extension.hpp. I chose "_ext" as a generic > suffix for files > containing extension hooks. In effect, such files are interface > definitions. A vendor > supplies a file, perhaps of the same name in another source base (as can > be seen in > the Hotspot makefiles), that implements the extension hooks. > > Thanks, > > Paul > From david.holmes at oracle.com Sun Dec 4 22:18:30 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Dec 2011 16:18:30 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4ED8AC78.5000508@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> Message-ID: <4EDC6236.5070106@oracle.com> Hi Mikael, On 2/12/2011 8:46 PM, Mikael Gerdin wrote: > On 2011-12-02 06:32, David Holmes wrote: >> I'm a little confused as to where wb.jar ends up when I build hotspot. I >> see this in a makefile: > > There are a couple of issues in these make files. >> >> 26 WB = wb >> 27 >> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >> 29 >> 30 WB_JAR = $(GENERATED)/$(WB).jar >> 31 >> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >> >> Why JAVA_HOME? That's normally a binary installation of a JDK used for >> building, not somewhere I expect my build to try and put something. Plus >> the above will expand to: > > For example, look in jsig.make. It has a target that copies libjsig to > JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to > JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior > with the "install"-targets in the make files. Our build system is somewhat confusing. The top-level Defs.make will set JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which can be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are all places where the build expects to find an executable JDK for performing build actions like javac compiles, javah etc. As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and that is used by the install_* targets, which are dependencies of the vm.make install target. The vm.make install target is itself invoked from top.make's install target. So when do these install targets actually get used? Other than by a developer on the command-line I don't see these targets actually getting used - and they can't be specified as targets for the top-level Makefile. I suspect these may be relics from a time when you would do something like: JAVA_HOME=/my/local/jdk/to/test/ make product1 install >> And if I build a full JDK, where does wb.jar end up then? > > $ find . -name wb.jar > ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar > ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar > > > The JDK makefiles that build the j2{sdk,re}-image directories do not > pick up the wb.jar file. Ok. So what is the expected build process here such that wb is available for use? Are you expecting the developer to do some kind of "make install"? >> I also see in make/Makefile: >> >> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >> 371 $(install-file) >> >> Why the endorsed subdirectory? This is nothing to do with an "endorsed >> standard": >> >> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ > > Because of security requirements and implementation details the Whitebox > class must be available on the boot class path. > Putting the wb.jar file in the endorsed directory is a quick and easy > way to achieve that. Why not just in lib? Or perhaps lib/ext? endorsed just seems to be the least appropriate choice here. And now your usage model has confused me because the above export is done for JPRT builds - right? So you want this to be available in a JPRT bundle, but not in a full JDK build? > Does this clarify your concerns? Not yet :) Thanks, David > /Mikael Gerdin > >> >> ??? >> >> Thanks, >> David >> ----- >> >>> If the VM crashes after this API has been accessed a note will be >>> written in the hs_err file to signal that the API has been used. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>> (thanks to stefank for hosting my webrev :) >>> >>> CR: >>> I'll file a CR tomorrow. >>> >>> Change comments: >>> >>> make/jprt.properties >>> >>> Add a test target to make sure that the API is available on all >>> supported platforms >>> >>> make/** >>> >>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >>> JAR file and copy it to the jre/lib/endorsed directory in the export >>> targets. >>> The BSD makefile changes are not tested since I don't have access to any >>> BSD/OSX machine to test them on. >>> >>> src/share/vm/prims/nativeLookup.cpp >>> >>> Special-case the method sun/hotspot/WhiteBox/registerNatives and link it >>> to JVM_RegisterWhiteBoxMethods >>> >>> src/share/vm/prims/whitebox.* >>> >>> The implementation of the white box API. The actual API functions are >>> only examples of what we want to be able to do using the API. >>> >>> src/share/vm/runtime/globals.hpp >>> >>> Add the command line flag >>> >>> src/share/vm/utilities/vmError.cpp >>> >>> Print a message in hs_err files when white box API has been used. >>> >>> test/Makefile >>> >>> Add a makefile test target for the white box API test >>> >>> test/sanity/wbapi.java >>> >>> JTreg test to ensure that the API works. >>> >>> >>> Thanks >>> /Mikael Gerdin From paul.hohensee at oracle.com Mon Dec 5 06:44:03 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 05 Dec 2011 09:44:03 -0500 Subject: Pls review (S) 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot In-Reply-To: <0F9EC0C0-2F22-42E6-A843-B7C8E26B55AB@kodewerk.com> References: <4ED8F4AF.8070107@oracle.com> <0F9EC0C0-2F22-42E6-A843-B7C8E26B55AB@kodewerk.com> Message-ID: <4EDCD8B3.4050506@oracle.com> Yes, you'd have to have your own build. Oracle does this now. OpenJDK builds are slightly different from OracleJDK ones right now and we expect that to continue going forward. Paul On 12/3/11 8:01 AM, Charles K Pepperdine wrote: > Hi Paul, > > Does this imply that if I wanted to add a command line switch for my commercial product that was "embedded" into the JVM I would have to do this in a special build? I'm trying to sort out how this would work? > > Regards, > Kirk > > On Dec 2, 2011, at 4:54 PM, Paul Hohensee wrote: > >> Webrev here: >> >> http://cr.openjdk.java.net/~phh/7117389/ >> >> This webrev defines and uses, but does not implement, a switch extension interface. >> >> I've added a new file, globals_ext.hpp, that contains hooks for vendor-specific additions >> to the set of Hotspot command line switches and added their use to globals.hpp, >> globals.cpp and globals_extension.hpp. I chose "_ext" as a generic suffix for files >> containing extension hooks. In effect, such files are interface definitions. A vendor >> supplies a file, perhaps of the same name in another source base (as can be seen in >> the Hotspot makefiles), that implements the extension hooks. >> >> Thanks, >> >> Paul >> From paul.hohensee at oracle.com Mon Dec 5 07:06:02 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 05 Dec 2011 10:06:02 -0500 Subject: Pls review (S) 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot In-Reply-To: <4EDC27BA.7020600@oracle.com> References: <4ED8F4AF.8070107@oracle.com> <4EDC27BA.7020600@oracle.com> Message-ID: <4EDCDDDA.5020906@oracle.com> Here's an example vendor-specific globals_ext.hpp that defines a single vendor-specific flag. I have no idea whether it will even compile, but it gives the flavor of what's needed. Paul ---- #ifndef SHARE_VM_RUNTIME_GLOBALS_EXT_HPP #define SHARE_VM_RUNTIME_GLOBALS_EXT_HPP // globals.hpp extension #define VENDOR_FLAGS(develop, product) \ \ product(bool, VendorFlag, false, "A vendor-specific flag") VENDOR_FLAGS(DECLARE_DEVELOPER_FLAG, DECLARE_PRODUCT_FLAG) // globals_extension.hpp extension // Additional CommandLineFlags enum values #define COMMANDLINEFLAG_EXT \ VENDOR_FLAGS(RUNTIME_DEVELOP_FLAG_MEMBER, RUNTIME_PRODUCT_FLAG_MEMBER) // Additional CommandLineFlagsWithType enum values #define COMMANDLINEFLAGWITHTYPE_EXT \ VENDOR_FLAGS(RUNTIME_DEVELOP_FLAG_MEMBER_WITH_TYPE, \ RUNTIME_PRODUCT_FLAG_MEMBER_WITH_TYPE) // globals.cpp extension // Additional flag definitions #define MATERIALIZE_FLAGS_EXT \ VENDOR_FLAGS(MATERIALIZE_DEVELOPER_FLAG, MATERIALIZE_PRODUCT_FLAG) // Additional flag descriptors: see flagTable definition #define FLAGTABLE_EXT \ VENDOR_FLAGS(RUNTIME_DEVELOP_FLAG_STRUCT, RUNTIME_PRODUCT_FLAG_STRUCT) // Extended method definitions inline bool Flag::is_unlocker_ext() const { return false; } inline bool Flag::is_unlocked_ext() const { return true; } #endif // SHARE_VM_RUNTIME_GLOBALS_EXT_HPP David Holmes wrote: > Hi Paul, > > This looks okay to me, but I agree that an example of how to use it > would help set the context for the review. > > David > > On 3/12/2011 1:54 AM, Paul Hohensee wrote: >> Webrev here: >> >> http://cr.openjdk.java.net/~phh/7117389/ >> >> This webrev defines and uses, but does not implement, a switch extension >> interface. >> >> I've added a new file, globals_ext.hpp, that contains hooks for >> vendor-specific additions >> to the set of Hotspot command line switches and added their use to >> globals.hpp, >> globals.cpp and globals_extension.hpp. I chose "_ext" as a generic >> suffix for files >> containing extension hooks. In effect, such files are interface >> definitions. A vendor >> supplies a file, perhaps of the same name in another source base (as can >> be seen in >> the Hotspot makefiles), that implements the extension hooks. >> >> Thanks, >> >> Paul >> From dalibor.topic at oracle.com Mon Dec 5 07:53:58 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 05 Dec 2011 16:53:58 +0100 Subject: Pls review (S) 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot In-Reply-To: <4EDCD8B3.4050506@oracle.com> References: <4ED8F4AF.8070107@oracle.com> <0F9EC0C0-2F22-42E6-A843-B7C8E26B55AB@kodewerk.com> <4EDCD8B3.4050506@oracle.com> Message-ID: <4EDCE916.5010008@oracle.com> On 12/5/11 3:44 PM, Paul Hohensee wrote: > Yes, you'd have to have your own build. Side note: Given that OpenJDK in general only provides source code, this condition is trivially satisfied for someone looking to add command line switches on top of HotSpot in OpenJDK, whether they are academic research projects, experimental ports to new CPU architectures, or something else, to give a few examples where I believe this functionality could come in handy in the future. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From spoole at linux.vnet.ibm.com Tue Dec 6 06:22:20 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 06 Dec 2011 14:22:20 +0000 Subject: Improving the documention of the JVM implementation interface In-Reply-To: <4ED8D9B2.9060500@oracle.com> References: <1322058589.13674.7.camel@jazzette> <1322577043.6819.5.camel@jazzette> <4ED8D9B2.9060500@oracle.com> Message-ID: <1323181340.15452.7.camel@jazzette> On Fri, 2011-12-02 at 14:59 +0100, Mikael Vidstedt wrote: > As Steve says, improving and clarifying the the dependencies and > interaction points between the JVM and the libraries is something I'm > happy to support. The JVM_* functions already have some documentation, > but even there I'm sure there are things that can be clarified, and I > fully agree that things like Attach functionality could use some > documentation work. > One thing I'd like to stress is that the goal of this project should not > be to lock down the interface between the JVM and the JDK. Even though > we should for a number of different reasons try to keep the interfaces > changes to a minimum, we need to preserve the right to change them > without having to go through lengthy standardization processes etc. I > don't think that contradicts the goal of this project though. > > I'm sure there are people who have been involved in projects where > documentation like this would have been very helpful. If at all possible > I'd like to encourage you to share your thoughts on this and if possible > help us out going forward. Thanks Mikael. The JVM_* functions would be a great place to start improving the doc since it's already a known, shared, interface. I'd also like to use a doc tool to create nice readable doc - what do people think about updating jvm.h with doxygen style comments and then using doxygen to create the docs? > > Thanks, > Mikael > > > > On 2011-11-29 15:30, Steve Poole wrote: > > On Thu, 2011-11-24 at 11:26 +0800, Krystal Mok wrote: > >> Hi Steve, > >> > >> > >> There's been some efforts in this area before. There's an OpenJDK > >> project called "Common VM Interface" [1], ran by Dr Andrew John > >> Hughes. One of the earlier notes can be found at [2]. The aims of this > >> project seems to be in the same direction as what you're looking for. > > Hi Krystal - sorry for the delay in responding: been somewhat email > > server challenged. Its possible the cmvi project could be used to do > > this work but it seems very quiet at the moment. Besides, this proposal > > is about documenting what exists today, so I'd rather have the > > conversation on a mailing list that the people who know frequent :-) > >> > >> Xi Yang has been working on integrating OpenJDK class libraries into > >> Jikes RVM this year. This work also needed a definition of the VM > >> interface in OpenJDK. He's made quite a lot of progress already, so he > >> might be able to help out with this documentation proposal. I'm cc'ing > >> this mail to him. > >> > >> > >> - Kris > >> > >> > >> [1]: http://openjdk.java.net/projects/cvmi/ > >> [2]: http://mail.openjdk.java.net/pipermail/cvmi-dev/2008-July/000006.html > >> > >> On Wed, Nov 23, 2011 at 10:29 PM, Steve Poole > >> wrote: > >> Hi all, I've been talking to Mikael Vidstedt and a few other > >> Oracle > >> luminaries about improving the documentation of the interface > >> between > >> the JVM and the rest of the SDK. > >> > >> We wanted to make that discussion public hence this post. > >> I'll start > >> and Mikael can jump in. > >> > >> What I'm trying to do is simply gain some agreement on what > >> code is JVM > >> implementation specific and what isn't. Then, where this JVM > >> implementation specific code interacts with the SDK, improve > >> the > >> documentation. > >> > >> A few examples to consider... > >> > >> JVM_* entry points in the VM that are there for the class > >> library code > >> to call: these are not part of the public JNI spec - I'd like > >> to get > >> them documented in more detail. > >> > >> These extra entry points can blur the line between the JVM and > >> the class > >> libraries: sometimes making it's difficult to work out if the > >> "real" > >> API is the C entry point or the calling Java class. To put it > >> another > >> way - there is Java code that is intentionally JVM > >> implementation > >> specific. I'd like to get that status documented. > >> > >> Another similar example is where Hotspot code leaks out of the > >> JVM into > >> the class libs and tools. The Late Attach API is a good (or > >> is that > >> bad) example. Sometimes it's difficult to work out if that > >> leakage is > >> intentional or inadvertent. I'd like to get that status > >> documented too. > >> > >> So to recap: what I'd like to do is discover and document the > >> API > >> between the JVM implementation specific code and everything > >> else. > >> Hopefully in the process improving everyone's awareness and > >> getting some > >> common agreement over actual behaviour or design versus > >> intention. This > >> work might discover areas that could benefit from improved > >> interface > >> design and some form of refactoring but that would be for > >> later. > >> > >> > >> Thanks > >> > >> Steve > >> > >> > >> > >> > > > From stefan.karlsson at oracle.com Wed Dec 7 04:52:22 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 07 Dec 2011 13:52:22 +0100 Subject: Review request (M): 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Message-ID: <4EDF6186.7050704@oracle.com> Please review this REF. http://cr.openjdk.java.net/~stefank/7118863/webrev/ The main motivation for this patch is to make it easier to merge with the permgen project. But, IMHO, they also help the code by not having different ways to go from a klass field offset to an offset against the klassOopDesc. Two things to note about this patch. 1) There's one place in the code where we don't add sizeof(klassOopDesc). I maintain this oddity and will leave the correct fix for a later change. src/share/vm/opto/compile.cpp 2) I have no way to verify the shark changes. src/share/vm/shark/sharkIntrinsics.cpp src/share/vm/shark/sharkTopLevelBlock.cpp From the RFE: The *Klass::*_offset_in_bytes() functions are used to get the offset to a field in a Klass. All places where they are used, we add something like sizeof(klassOopDesc) to make the offset against the klassOopDesc instead. For example in opto/memnode.cpp: if (tkls->offset() == Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc)) { There's a couple of variants to this: instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc) Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc) Klass::secondary_supers_offset_in_bytes() + klassOopDesc::header_size() * HeapWordSize Klass::java_mirror_offset_in_bytes() klassOopDesc::klass_part_offset_in_bytes() The proposal is to move all these size adjustments into the *Klass:*_offset_in_bytes() functions. From bertrand.delsart at oracle.com Wed Dec 7 05:25:31 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 07 Dec 2011 14:25:31 +0100 Subject: Review request (M): 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions In-Reply-To: <4EDF6186.7050704@oracle.com> References: <4EDF6186.7050704@oracle.com> Message-ID: <4EDF694B.90009@oracle.com> Would it be possible to change the name of the offset functions ? By using the same name, but with a different semantic, you silently break all the ports for which the change has not yet been applied. These ports will compile correctly but will fail at execution time because they will be adding sizeof(klassOopDesc) twice. Fixing them will require to double check the changeset and identity all the functions for which the semantic has changed. Similar issues might happens if someone backports some code which includes your changes to a previous hotspot version which uses the old semantic. By changing the names, it will be trivial to detect at build time which calls have not been yet been correctly fixed. This also simplifies the review since we will be sure all calls have been dealt with :-) Bertrand. On 12/ 7/11 01:52 PM, Stefan Karlsson wrote: > Please review this REF. > > http://cr.openjdk.java.net/~stefank/7118863/webrev/ > > The main motivation for this patch is to make it easier to merge with > the permgen project. But, IMHO, they also help the code by not having > different ways to go from a klass field offset to an offset against the > klassOopDesc. > > Two things to note about this patch. > 1) There's one place in the code where we don't add > sizeof(klassOopDesc). I maintain this oddity and will leave the correct > fix for a later change. > src/share/vm/opto/compile.cpp > > 2) I have no way to verify the shark changes. > src/share/vm/shark/sharkIntrinsics.cpp > src/share/vm/shark/sharkTopLevelBlock.cpp > > From the RFE: > The *Klass::*_offset_in_bytes() functions are used to get the offset to > a field in a Klass. All places where they are used, we add something > like sizeof(klassOopDesc) to make the offset against the klassOopDesc > instead. > > For example in opto/memnode.cpp: > if (tkls->offset() == Klass::access_flags_offset_in_bytes() + > (int)sizeof(oopDesc)) { > > There's a couple of variants to this: > instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc) > Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc) > Klass::secondary_supers_offset_in_bytes() + klassOopDesc::header_size() > * HeapWordSize > Klass::java_mirror_offset_in_bytes() > klassOopDesc::klass_part_offset_in_bytes() > > The proposal is to move all these size adjustments into the > *Klass:*_offset_in_bytes() functions. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From stefan.karlsson at oracle.com Wed Dec 7 05:35:42 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 07 Dec 2011 14:35:42 +0100 Subject: Review request (M): 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions In-Reply-To: <4EDF694B.90009@oracle.com> References: <4EDF6186.7050704@oracle.com> <4EDF694B.90009@oracle.com> Message-ID: <4EDF6BAE.7080104@oracle.com> On 2011-12-07 14:25, Bertrand Delsart wrote: > Would it be possible to change the name of the offset functions ? > > By using the same name, but with a different semantic, you silently > break all the ports for which the change has not yet been applied. > These ports will compile correctly but will fail at execution time > because they will be adding sizeof(klassOopDesc) twice. Fixing them > will require to double check the changeset and identity all the > functions for which the semantic has changed. Similar issues might > happens if someone backports some code which includes your changes to > a previous hotspot version which uses the old semantic. Good suggestion. Thanks. StefanK > > By changing the names, it will be trivial to detect at build time > which calls have not been yet been correctly fixed. This also > simplifies the review since we will be sure all calls have been dealt > with :-) > > Bertrand. > > On 12/ 7/11 01:52 PM, Stefan Karlsson wrote: >> Please review this REF. >> >> http://cr.openjdk.java.net/~stefank/7118863/webrev/ >> >> The main motivation for this patch is to make it easier to merge with >> the permgen project. But, IMHO, they also help the code by not having >> different ways to go from a klass field offset to an offset against the >> klassOopDesc. >> >> Two things to note about this patch. >> 1) There's one place in the code where we don't add >> sizeof(klassOopDesc). I maintain this oddity and will leave the correct >> fix for a later change. >> src/share/vm/opto/compile.cpp >> >> 2) I have no way to verify the shark changes. >> src/share/vm/shark/sharkIntrinsics.cpp >> src/share/vm/shark/sharkTopLevelBlock.cpp >> >> From the RFE: >> The *Klass::*_offset_in_bytes() functions are used to get the offset to >> a field in a Klass. All places where they are used, we add something >> like sizeof(klassOopDesc) to make the offset against the klassOopDesc >> instead. >> >> For example in opto/memnode.cpp: >> if (tkls->offset() == Klass::access_flags_offset_in_bytes() + >> (int)sizeof(oopDesc)) { >> >> There's a couple of variants to this: >> instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc) >> Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc) >> Klass::secondary_supers_offset_in_bytes() + klassOopDesc::header_size() >> * HeapWordSize >> Klass::java_mirror_offset_in_bytes() >> klassOopDesc::klass_part_offset_in_bytes() >> >> The proposal is to move all these size adjustments into the >> *Klass:*_offset_in_bytes() functions. > > From tom.rodriguez at oracle.com Wed Dec 7 09:59:30 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 7 Dec 2011 09:59:30 -0800 Subject: Review request (M): 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions In-Reply-To: <4EDF6BAE.7080104@oracle.com> References: <4EDF6186.7050704@oracle.com> <4EDF694B.90009@oracle.com> <4EDF6BAE.7080104@oracle.com> Message-ID: <3B49228A-1C43-4C7F-8ED3-45128C4067D2@oracle.com> On Dec 7, 2011, at 5:35 AM, Stefan Karlsson wrote: > On 2011-12-07 14:25, Bertrand Delsart wrote: >> Would it be possible to change the name of the offset functions ? >> >> By using the same name, but with a different semantic, you silently break all the ports for which the change has not yet been applied. These ports will compile correctly but will fail at execution time because they will be adding sizeof(klassOopDesc) twice. Fixing them will require to double check the changeset and identity all the functions for which the semantic has changed. Similar issues might happens if someone backports some code which includes your changes to a previous hotspot version which uses the old semantic. > > Good suggestion. Thanks. The current names are simple and clear. What can you replace them with? The Klass:: ones could be moved into klassOopDesc but that would still create a delete relative to the perm repo since klassOopDesc is going away. tom > > StefanK > >> >> By changing the names, it will be trivial to detect at build time which calls have not been yet been correctly fixed. This also simplifies the review since we will be sure all calls have been dealt with :-) >> >> Bertrand. >> >> On 12/ 7/11 01:52 PM, Stefan Karlsson wrote: >>> Please review this REF. >>> >>> http://cr.openjdk.java.net/~stefank/7118863/webrev/ >>> >>> The main motivation for this patch is to make it easier to merge with >>> the permgen project. But, IMHO, they also help the code by not having >>> different ways to go from a klass field offset to an offset against the >>> klassOopDesc. >>> >>> Two things to note about this patch. >>> 1) There's one place in the code where we don't add >>> sizeof(klassOopDesc). I maintain this oddity and will leave the correct >>> fix for a later change. >>> src/share/vm/opto/compile.cpp >>> >>> 2) I have no way to verify the shark changes. >>> src/share/vm/shark/sharkIntrinsics.cpp >>> src/share/vm/shark/sharkTopLevelBlock.cpp >>> >>> From the RFE: >>> The *Klass::*_offset_in_bytes() functions are used to get the offset to >>> a field in a Klass. All places where they are used, we add something >>> like sizeof(klassOopDesc) to make the offset against the klassOopDesc >>> instead. >>> >>> For example in opto/memnode.cpp: >>> if (tkls->offset() == Klass::access_flags_offset_in_bytes() + >>> (int)sizeof(oopDesc)) { >>> >>> There's a couple of variants to this: >>> instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc) >>> Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc) >>> Klass::secondary_supers_offset_in_bytes() + klassOopDesc::header_size() >>> * HeapWordSize >>> Klass::java_mirror_offset_in_bytes() >>> klassOopDesc::klass_part_offset_in_bytes() >>> >>> The proposal is to move all these size adjustments into the >>> *Klass:*_offset_in_bytes() functions. >> >> > From manojo10386 at gmail.com Wed Dec 7 15:56:00 2011 From: manojo10386 at gmail.com (Manohar Jonnalagedda) Date: Thu, 8 Dec 2011 00:56:00 +0100 Subject: Understanding PrintAssembly output Message-ID: Hello all, I was just wondering whether you would have some pointers on how to understand the x86 assembly code output by the PrintAssembly flag? My question is specifically oriented towards understanding of loops and branching instructions. In the output that I get, I have many instructions as follows: B14 : # info about B14 cmpl R10, R10 jg,s B24 I understand that the above will never go to B24, as the test will always be equal. However, by doing such an analysis, I find that there the CFG for a given method is much smaller than the overall size of the compiled method. Also, some of the branches in this "non-reachable" portion of the assembler code contains *inner main loops* whose *pre loops* are in the reachable portion. How do I actually go about understanding such output? Thanks a lot, Manohar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111208/65515354/attachment.html From Dmitry.Samersoff at oracle.com Wed Dec 7 21:41:01 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 08 Dec 2011 09:41:01 +0400 Subject: Understanding PrintAssembly output In-Reply-To: References: Message-ID: <4EE04DED.4050305@oracle.com> Manohar, C2 compiler use various methods of optimization of generated code, particularity - it unrolls loops when possible. -Dmitry On 2011-12-08 03:56, Manohar Jonnalagedda wrote: > Hello all, > > I was just wondering whether you would have some pointers on how to > understand the x86 assembly code output by the PrintAssembly flag? My > question is specifically oriented towards understanding of loops and > branching instructions. In the output that I get, I have many > instructions as follows: > > B14 : # info about B14 > > cmpl R10, R10 > jg,s B24 > > I understand that the above will never go to B24, as the test will > always be equal. However, by doing such an analysis, I find that there > the CFG for a given method is much smaller than the overall size of the > compiled method. Also, some of the branches in this "non-reachable" > portion of the assembler code contains /inner main loops/ whose /pre > loops/ are in the reachable portion. How do I actually go about > understanding such output? > > Thanks a lot, > Manohar -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From mikael.gerdin at oracle.com Thu Dec 8 07:11:35 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 08 Dec 2011 16:11:35 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EDC6236.5070106@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> Message-ID: <4EE0D3A7.3010109@oracle.com> Hi David, Sorry for the delayed response. On 2011-12-05 07:18, David Holmes wrote: > Hi Mikael, > > On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >> On 2011-12-02 06:32, David Holmes wrote: >>> I'm a little confused as to where wb.jar ends up when I build hotspot. I >>> see this in a makefile: >> >> There are a couple of issues in these make files. >>> >>> 26 WB = wb >>> 27 >>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >>> 29 >>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>> 31 >>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>> >>> Why JAVA_HOME? That's normally a binary installation of a JDK used for >>> building, not somewhere I expect my build to try and put something. Plus >>> the above will expand to: >> >> For example, look in jsig.make. It has a target that copies libjsig to >> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior >> with the "install"-targets in the make files. > > Our build system is somewhat confusing. The top-level Defs.make will set > JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which can > be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are all > places where the build expects to find an executable JDK for performing > build actions like javac compiles, javah etc. > > As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and > that is used by the install_* targets, which are dependencies of the > vm.make install target. The vm.make install target is itself invoked > from top.make's install target. > > So when do these install targets actually get used? Other than by a > developer on the command-line I don't see these targets actually getting > used - and they can't be specified as targets for the top-level > Makefile. I suspect these may be relics from a time when you would do > something like: > > JAVA_HOME=/my/local/jdk/to/test/ make product1 install You are probably correct. Do you want me to modify the make file to more closely mimic the behavior of the other make files and let the legacy "install" target stay or do you want me to just not add an install target? > >>> And if I build a full JDK, where does wb.jar end up then? >> >> $ find . -name wb.jar >> ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar >> ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar >> >> >> >> The JDK makefiles that build the j2{sdk,re}-image directories do not >> pick up the wb.jar file. > > Ok. So what is the expected build process here such that wb is available > for use? Are you expecting the developer to do some kind of "make install"? This is primarily intended for use together with our internal test infrastructure (nightly testing etc.). When running these tests there is already a requirement for a JDK to go together with a VM that we are testing. The same goes for jtreg and the HotSpot tests in the test/ subdirectory of the HotSpot repository. So if you want to run tests on your own VM wouldn't you need to use something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do automatically copy your libjvm to a working JDK? > >>> I also see in make/Makefile: >>> >>> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >>> 371 $(install-file) >>> >>> Why the endorsed subdirectory? This is nothing to do with an "endorsed >>> standard": >>> >>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ >> >> Because of security requirements and implementation details the Whitebox >> class must be available on the boot class path. >> Putting the wb.jar file in the endorsed directory is a quick and easy >> way to achieve that. > > Why not just in lib? Or perhaps lib/ext? endorsed just seems to be the > least appropriate choice here. Because jars in lib/endorsed are automatically added to the _boot_ class path. We could put the jar in jre/lib/ext or jre/lib/ or just lib/ but then all tests using the API would need -Xbootclasspath as an additional command line flag. > > And now your usage model has confused me because the above export is > done for JPRT builds - right? So you want this to be available in a JPRT > bundle, but not in a full JDK build? Nightly testing runs on bundles generated by JPRT, by having the API available in those bundles we can have tests that use this API in our nighly testing. If we want to have this API available when doing a full JDK build we can revisit that particular point in the future since that would need to be synchronized with RE as well. > >> Does this clarify your concerns? > > Not yet :) I'll keep trying then :) /Mikael > > Thanks, > David > >> /Mikael Gerdin >> >>> >>> ??? >>> >>> Thanks, >>> David >>> ----- >>> >>>> If the VM crashes after this API has been accessed a note will be >>>> written in the hs_err file to signal that the API has been used. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>> (thanks to stefank for hosting my webrev :) >>>> >>>> CR: >>>> I'll file a CR tomorrow. >>>> >>>> Change comments: >>>> >>>> make/jprt.properties >>>> >>>> Add a test target to make sure that the API is available on all >>>> supported platforms >>>> >>>> make/** >>>> >>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >>>> JAR file and copy it to the jre/lib/endorsed directory in the export >>>> targets. >>>> The BSD makefile changes are not tested since I don't have access to >>>> any >>>> BSD/OSX machine to test them on. >>>> >>>> src/share/vm/prims/nativeLookup.cpp >>>> >>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>> link it >>>> to JVM_RegisterWhiteBoxMethods >>>> >>>> src/share/vm/prims/whitebox.* >>>> >>>> The implementation of the white box API. The actual API functions are >>>> only examples of what we want to be able to do using the API. >>>> >>>> src/share/vm/runtime/globals.hpp >>>> >>>> Add the command line flag >>>> >>>> src/share/vm/utilities/vmError.cpp >>>> >>>> Print a message in hs_err files when white box API has been used. >>>> >>>> test/Makefile >>>> >>>> Add a makefile test target for the white box API test >>>> >>>> test/sanity/wbapi.java >>>> >>>> JTreg test to ensure that the API works. >>>> >>>> >>>> Thanks >>>> /Mikael Gerdin From paul.hohensee at oracle.com Thu Dec 8 10:59:55 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 08 Dec 2011 13:59:55 -0500 Subject: Optimizing arithmetic operations on processors with AVX2 support In-Reply-To: References: , <5dfbcef2-6eee-4541-b129-155a386575a9@shankar-win1> Message-ID: <4EE1092B.2050408@oracle.com> cc'ing hotspot-dev. Paul On 12/8/11 1:41 PM, John Platts wrote: > I actually do agree with what Shankar said regarding the current Java memory model. However, the point that I was trying to illustrate is that the JIT compiler of a JVM can use the AVX2, SSE2, SSE3, and SSE4.1 instructions instead of the ordinary arithmetic instructions to optimize the performance of integer arithmetic operations on x86 processors with the AVX2 instruction set. I was also intending to show an example of how arithmetic operations can be re-ordered by a JVM implementation without violating the Java Memory Model. > > ---------------------------------------- >> Date: Thu, 8 Dec 2011 10:08:12 -0800 >> From: shankar at vmware.com >> To: john_platts at hotmail.com >> CC: jdk8-dev at openjdk.java.net >> Subject: Re: Optimizing arithmetic operations on processors with AVX2 support >> >> Such an assumption (in-order execution of statements) would be invalid even with the current memory model. There's nothing to stop the compilers from re-ordering the adds and multiplies so that they fill each other's pipeline delays. >> >> So I don't think AVX2 brings anything new to the table in terms of perturbing the memory model. >> >> ----- Original Message ----- >> From: "John Platts" >> To: jdk8-dev at openjdk.java.net >> Sent: Thursday, December 8, 2011 9:25:41 AM >> Subject: Optimizing arithmetic operations on processors with AVX2 support >> >> >> Here is an example of a class with an operation that can be optimized on a processor with AVX2 support:class ExampleClass { public void ExampleOperation(ExampleClass y) { a += y.a; b *= y.b; c += y.c; d += y.d; e += y.e; f *= y.f; g *= y.g; h *= y.h; } >> private int a; private int b; private int c; private int d; private int e; private int f; private int g; private int h;} >> The AVX2 instruction set includes gather instructions that can be used to read from primitive fields that are not contiguous to each other. The AVX2 instruction set will be implemented on the Intel Haswell microarchitecture processors. >> In the example above, a JVM running on a processor with the AVX2 instruction set can optimize the ExampleOperation method as follows:- Reading the a, c, d, and e fields of both this and y using the VPGATHERDD instruction.- Performing the 4 addition operations simultaneously using the PADDD instruction.- Store the result of the addition operations in a, c, d, and e using the PEXTRD instruction.- Reading the b, f, g, and h fields of both this and y using the VPGATHERDD instruction.- Performing the 4 multiplication operations simultaneously using the PMULLD instruction.- Store the result of the multiplication operations in b, f, g, and h using the PEXTRD instruction. >> This optimization is perfectly legal under the Java Memory Model, since there are no volatile reads or volatile writes. However, this optimization would be illegal if a, b, c, d, e, f, g, or h were declared as volatile fields. This optimization must also respect constraints imposed by synchronized blocks, volatile reads, volatile writes, method calls, data dependencies, and strictfp semantics. This optimization would also need to be disabled if the method is being debugged by a Java debugger, as the Java debugger can step through each operation individually. >> The point I am trying to illustrate is that Java programmers should not assume that the arithmetic operations performed by the ExampleOperation method are not guaranteed to execute in the sequence shown in the source code. This example also illustrates the importance of properly synchronization. Will this optimization get implemented in the Hotspot VM in the future? > From vladimir.danushevsky at oracle.com Thu Dec 8 11:44:43 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 08 Dec 2011 19:44:43 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20111208194453.6967247642@hg.openjdk.java.net> Changeset: cd00eaeebef6 Author: phh Date: 2011-12-05 12:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd00eaeebef6 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot Summary: Add a file, globals_ext.hpp, containing a null interface, to be replaced by a vendor in altsrc as needed. Reviewed-by: coleenp, kamg, dholmes, johnc, jrose ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/runtime/globals_ext.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 8657ec177a14 Author: dcubed Date: 2011-12-05 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8657ec177a14 7117748: SA_APPLE_BOOT_JAVA and ALWAYS_PASS_TEST_GAMMA settings should not be required on MacOS X Summary: Replace SA_APPLE_BOOT_JAVA with logic that checks the boot JDK for the location of JDI classes. ALWAYS_PASS_TEST_GAMMA is true by default on Darwin. Reviewed-by: kvn, swingler ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/sa.make Changeset: 41cce03b29a8 Author: dcubed Date: 2011-12-06 05:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41cce03b29a8 Merge Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/03865c41c4f3 Merge ! src/share/vm/runtime/globals.hpp Changeset: 55d777c0860a Author: dcubed Date: 2011-12-07 07:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/55d777c0860a 7118648: disable compressed oops by default on MacOS X until 7118647 is fixed Summary: UseCompressedOops is false by default on MacOS X; can still be set manually Reviewed-by: jmelvin, kvn, dholmes ! src/share/vm/runtime/arguments.cpp From tom.rodriguez at oracle.com Thu Dec 8 12:53:43 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 8 Dec 2011 12:53:43 -0800 Subject: Understanding PrintAssembly output In-Reply-To: References: Message-ID: On Dec 7, 2011, at 3:56 PM, Manohar Jonnalagedda wrote: > Hello all, > > I was just wondering whether you would have some pointers on how to understand the x86 assembly code output by the PrintAssembly flag? My question is specifically oriented towards understanding of loops and branching instructions. In the output that I get, I have many instructions as follows: > > B14 : # info about B14 > > cmpl R10, R10 > jg,s B24 That looks like a missed optimization. The compiler should have eliminated that. > > I understand that the above will never go to B24, as the test will always be equal. However, by doing such an analysis, I find that there the CFG for a given method is much smaller than the overall size of the compiled method. Also, some of the branches in this "non-reachable" portion of the assembler code contains inner main loops whose pre loops are in the reachable portion. How do I actually go about understanding such output? The optimizer may sometimes do surprising things as well. OSR compiles also have very odd structures, particular when the backedge in inside nested loops. If you think something is actually wrong, you should send along the full output for the code in question. tom > > Thanks a lot, > Manohar From manojo10386 at gmail.com Thu Dec 8 13:41:56 2011 From: manojo10386 at gmail.com (Manohar Jonnalagedda) Date: Thu, 8 Dec 2011 22:41:56 +0100 Subject: Understanding PrintAssembly output In-Reply-To: References: Message-ID: Thanks for your responses. > > > cmpl R10, R10 > > jg,s B24 > > That looks like a missed optimization. The compiler should have > eliminated that. > It seems to me that I misread some of the instructions, and also misunderstood them. What I have is actually test R10, R10 which I misunderstood for a comparison, while it actually is a zero-check. Things are a bit more clear as a result of understanding this. Sorry for the trouble, Manohar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111208/6bea7f5a/attachment.html From vladimir.kozlov at oracle.com Thu Dec 8 15:48:10 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 08 Dec 2011 23:48:10 +0000 Subject: hg: hsx/hotspot-main/hotspot: 14 new changesets Message-ID: <20111208234839.AE42947645@hg.openjdk.java.net> Changeset: e8fdaf4a66cb Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e8fdaf4a66cb 7110586: C2 generates incorrect results Summary: Exact limit of empty loop calculated incorrectly. Reviewed-by: iveresov, never ! src/share/vm/opto/loopnode.cpp + test/compiler/7110586/Test7110586.java Changeset: 8c57262447d3 Author: kvn Date: 2011-11-14 18:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c57262447d3 7105605: Use EA info to optimize pointers compare Summary: optimize pointers compare using EA information. Reviewed-by: never, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 6729bbc1fcd6 Author: twisti Date: 2011-11-16 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6729bbc1fcd6 7003454: order constants in constant table by number of references in code Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.hpp Changeset: 1bd45abaa507 Author: kvn Date: 2011-11-16 09:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1bd45abaa507 6890673: Eliminate allocations immediately after EA Summary: Try to eliminate allocations and related locks immediately after escape analysis. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 973293defacd Author: iveresov Date: 2011-11-16 19:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/973293defacd 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks Summary: Move the inlinee invoke notification callback into inlinee preamble Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! test/compiler/6792161/Test6792161.java Changeset: a04a201f0f5a Author: twisti Date: 2011-11-17 04:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a04a201f0f5a 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Reviewed-by: kvn, never ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: 59bc0d4d9ea3 Author: never Date: 2011-11-18 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59bc0d4d9ea3 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Reviewed-by: kvn, iveresov, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 7793051af7d6 Author: twisti Date: 2011-11-21 00:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7793051af7d6 7110058: change default for ScavengeRootsInCode to 2 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp Changeset: f03a3c8bd5e5 Author: roland Date: 2011-09-14 09:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f03a3c8bd5e5 7077312: Provide a CALL effect for instruct declaration in the ad file Summary: abstracted way to declare that the MachNode has the effect of a call (kills caller save registers, preserves callee save registers) Reviewed-by: twisti, never ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp Changeset: db2e64ca2d5a Author: roland Date: 2011-11-22 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db2e64ca2d5a 7090968: Allow adlc register class to depend on runtime conditions Summary: allow reg_class definition as a function. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/matcher.hpp Changeset: cc81b9c09bbb Author: kvn Date: 2011-11-28 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cc81b9c09bbb 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 97825a4f7369 Author: iveresov Date: 2011-11-30 17:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/97825a4f7369 7116795: Tiered: enable by default for server Summary: Enable tiered compilation on server VM by default Reviewed-by: kvn, never ! make/jprt.properties ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: f745b2be3737 Author: kvn Date: 2011-12-02 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f745b2be3737 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Summary: Delay memory node transformation until the memory is processed. Reviewed-by: iveresov, never ! src/share/vm/opto/memnode.cpp Changeset: 81f7362f7bed Author: kvn Date: 2011-12-08 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81f7362f7bed Merge ! make/jprt.properties ! src/share/vm/runtime/globals.hpp From david.holmes at oracle.com Thu Dec 8 20:25:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Dec 2011 14:25:14 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE0D3A7.3010109@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> Message-ID: <4EE18DAA.5010105@oracle.com> Hi Mikael, I'll top-post for convenience :) Two points: 1. I think it may be simpler to drop the install target - "install" seems to be somewhat of a historical relic 2. lib/ext jars have the same permissions as bootclasspath, so it should work to place it there. Thanks, David On 9/12/2011 1:11 AM, Mikael Gerdin wrote: > Hi David, > Sorry for the delayed response. > > On 2011-12-05 07:18, David Holmes wrote: >> Hi Mikael, >> >> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>> On 2011-12-02 06:32, David Holmes wrote: >>>> I'm a little confused as to where wb.jar ends up when I build >>>> hotspot. I >>>> see this in a makefile: >>> >>> There are a couple of issues in these make files. >>>> >>>> 26 WB = wb >>>> 27 >>>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >>>> 29 >>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>> 31 >>>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>>> >>>> Why JAVA_HOME? That's normally a binary installation of a JDK used for >>>> building, not somewhere I expect my build to try and put something. >>>> Plus >>>> the above will expand to: >>> >>> For example, look in jsig.make. It has a target that copies libjsig to >>> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >>> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior >>> with the "install"-targets in the make files. >> >> Our build system is somewhat confusing. The top-level Defs.make will set >> JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which can >> be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are all >> places where the build expects to find an executable JDK for performing >> build actions like javac compiles, javah etc. >> >> As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and >> that is used by the install_* targets, which are dependencies of the >> vm.make install target. The vm.make install target is itself invoked >> from top.make's install target. >> >> So when do these install targets actually get used? Other than by a >> developer on the command-line I don't see these targets actually getting >> used - and they can't be specified as targets for the top-level >> Makefile. I suspect these may be relics from a time when you would do >> something like: >> >> JAVA_HOME=/my/local/jdk/to/test/ make product1 install > > You are probably correct. > Do you want me to modify the make file to more closely mimic the > behavior of the other make files and let the legacy "install" target > stay or do you want me to just not add an install target? > >> >>>> And if I build a full JDK, where does wb.jar end up then? >>> >>> $ find . -name wb.jar >>> ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar >>> ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar >>> >>> >>> >>> >>> The JDK makefiles that build the j2{sdk,re}-image directories do not >>> pick up the wb.jar file. >> >> Ok. So what is the expected build process here such that wb is available >> for use? Are you expecting the developer to do some kind of "make >> install"? > > This is primarily intended for use together with our internal test > infrastructure (nightly testing etc.). When running these tests there is > already a requirement for a JDK to go together with a VM that we are > testing. The same goes for jtreg and the HotSpot tests in the test/ > subdirectory of the HotSpot repository. > So if you want to run tests on your own VM wouldn't you need to use > something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do > automatically copy your libjvm to a working JDK? > > >> >>>> I also see in make/Makefile: >>>> >>>> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >>>> 371 $(install-file) >>>> >>>> Why the endorsed subdirectory? This is nothing to do with an "endorsed >>>> standard": >>>> >>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ >>> >>> Because of security requirements and implementation details the Whitebox >>> class must be available on the boot class path. >>> Putting the wb.jar file in the endorsed directory is a quick and easy >>> way to achieve that. >> >> Why not just in lib? Or perhaps lib/ext? endorsed just seems to be the >> least appropriate choice here. > > Because jars in lib/endorsed are automatically added to the _boot_ class > path. > We could put the jar in jre/lib/ext or jre/lib/ or just lib/ > but then all tests using the API would need -Xbootclasspath as an > additional command line flag. > >> >> And now your usage model has confused me because the above export is >> done for JPRT builds - right? So you want this to be available in a JPRT >> bundle, but not in a full JDK build? > > Nightly testing runs on bundles generated by JPRT, by having the API > available in those bundles we can have tests that use this API in our > nighly testing. > If we want to have this API available when doing a full JDK build we can > revisit that particular point in the future since that would need to be > synchronized with RE as well. > >> >>> Does this clarify your concerns? >> >> Not yet :) > > I'll keep trying then :) > > /Mikael > >> >> Thanks, >> David >> >>> /Mikael Gerdin >>> >>>> >>>> ??? >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> If the VM crashes after this API has been accessed a note will be >>>>> written in the hs_err file to signal that the API has been used. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>> (thanks to stefank for hosting my webrev :) >>>>> >>>>> CR: >>>>> I'll file a CR tomorrow. >>>>> >>>>> Change comments: >>>>> >>>>> make/jprt.properties >>>>> >>>>> Add a test target to make sure that the API is available on all >>>>> supported platforms >>>>> >>>>> make/** >>>>> >>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >>>>> JAR file and copy it to the jre/lib/endorsed directory in the export >>>>> targets. >>>>> The BSD makefile changes are not tested since I don't have access to >>>>> any >>>>> BSD/OSX machine to test them on. >>>>> >>>>> src/share/vm/prims/nativeLookup.cpp >>>>> >>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>> link it >>>>> to JVM_RegisterWhiteBoxMethods >>>>> >>>>> src/share/vm/prims/whitebox.* >>>>> >>>>> The implementation of the white box API. The actual API functions are >>>>> only examples of what we want to be able to do using the API. >>>>> >>>>> src/share/vm/runtime/globals.hpp >>>>> >>>>> Add the command line flag >>>>> >>>>> src/share/vm/utilities/vmError.cpp >>>>> >>>>> Print a message in hs_err files when white box API has been used. >>>>> >>>>> test/Makefile >>>>> >>>>> Add a makefile test target for the white box API test >>>>> >>>>> test/sanity/wbapi.java >>>>> >>>>> JTreg test to ensure that the API works. >>>>> >>>>> >>>>> Thanks >>>>> /Mikael Gerdin From mikael.gerdin at oracle.com Fri Dec 9 05:42:38 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 09 Dec 2011 14:42:38 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE18DAA.5010105@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> Message-ID: <4EE2104E.2040304@oracle.com> Hi David, On 2011-12-09 05:25, David Holmes wrote: > Hi Mikael, > > I'll top-post for convenience :) > > Two points: > > 1. I think it may be simpler to drop the install target - "install" > seems to be somewhat of a historical relic Ok > > 2. lib/ext jars have the same permissions as bootclasspath, so it should > work to place it there. I tried that first (before even discovering the existence of the "endorsed" directory) but when I tried it the Whitebox class didn't get have null as its classloader. Looking at the code in src/share/vm/runtime/arguments.cpp, the class SysClassPath claims to be responsible for handling the boot class path. I don't see any reference to lib/ext there but I'm not very familiar with how the class loading code actually works. /Mikael > > Thanks, > David > > On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >> Hi David, >> Sorry for the delayed response. >> >> On 2011-12-05 07:18, David Holmes wrote: >>> Hi Mikael, >>> >>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>> On 2011-12-02 06:32, David Holmes wrote: >>>>> I'm a little confused as to where wb.jar ends up when I build >>>>> hotspot. I >>>>> see this in a makefile: >>>> >>>> There are a couple of issues in these make files. >>>>> >>>>> 26 WB = wb >>>>> 27 >>>>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >>>>> 29 >>>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>>> 31 >>>>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>>>> >>>>> Why JAVA_HOME? That's normally a binary installation of a JDK used for >>>>> building, not somewhere I expect my build to try and put something. >>>>> Plus >>>>> the above will expand to: >>>> >>>> For example, look in jsig.make. It has a target that copies libjsig to >>>> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >>>> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior >>>> with the "install"-targets in the make files. >>> >>> Our build system is somewhat confusing. The top-level Defs.make will set >>> JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which can >>> be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are all >>> places where the build expects to find an executable JDK for performing >>> build actions like javac compiles, javah etc. >>> >>> As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and >>> that is used by the install_* targets, which are dependencies of the >>> vm.make install target. The vm.make install target is itself invoked >>> from top.make's install target. >>> >>> So when do these install targets actually get used? Other than by a >>> developer on the command-line I don't see these targets actually getting >>> used - and they can't be specified as targets for the top-level >>> Makefile. I suspect these may be relics from a time when you would do >>> something like: >>> >>> JAVA_HOME=/my/local/jdk/to/test/ make product1 install >> >> You are probably correct. >> Do you want me to modify the make file to more closely mimic the >> behavior of the other make files and let the legacy "install" target >> stay or do you want me to just not add an install target? >> >>> >>>>> And if I build a full JDK, where does wb.jar end up then? >>>> >>>> $ find . -name wb.jar >>>> ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar >>>> ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar >>>> >>>> >>>> >>>> >>>> >>>> The JDK makefiles that build the j2{sdk,re}-image directories do not >>>> pick up the wb.jar file. >>> >>> Ok. So what is the expected build process here such that wb is available >>> for use? Are you expecting the developer to do some kind of "make >>> install"? >> >> This is primarily intended for use together with our internal test >> infrastructure (nightly testing etc.). When running these tests there is >> already a requirement for a JDK to go together with a VM that we are >> testing. The same goes for jtreg and the HotSpot tests in the test/ >> subdirectory of the HotSpot repository. >> So if you want to run tests on your own VM wouldn't you need to use >> something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do >> automatically copy your libjvm to a working JDK? >> >> >>> >>>>> I also see in make/Makefile: >>>>> >>>>> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >>>>> 371 $(install-file) >>>>> >>>>> Why the endorsed subdirectory? This is nothing to do with an "endorsed >>>>> standard": >>>>> >>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ >>>> >>>> Because of security requirements and implementation details the >>>> Whitebox >>>> class must be available on the boot class path. >>>> Putting the wb.jar file in the endorsed directory is a quick and easy >>>> way to achieve that. >>> >>> Why not just in lib? Or perhaps lib/ext? endorsed just seems to be the >>> least appropriate choice here. >> >> Because jars in lib/endorsed are automatically added to the _boot_ class >> path. >> We could put the jar in jre/lib/ext or jre/lib/ or just lib/ >> but then all tests using the API would need -Xbootclasspath as an >> additional command line flag. >> >>> >>> And now your usage model has confused me because the above export is >>> done for JPRT builds - right? So you want this to be available in a JPRT >>> bundle, but not in a full JDK build? >> >> Nightly testing runs on bundles generated by JPRT, by having the API >> available in those bundles we can have tests that use this API in our >> nighly testing. >> If we want to have this API available when doing a full JDK build we can >> revisit that particular point in the future since that would need to be >> synchronized with RE as well. >> >>> >>>> Does this clarify your concerns? >>> >>> Not yet :) >> >> I'll keep trying then :) >> >> /Mikael >> >>> >>> Thanks, >>> David >>> >>>> /Mikael Gerdin >>>> >>>>> >>>>> ??? >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> If the VM crashes after this API has been accessed a note will be >>>>>> written in the hs_err file to signal that the API has been used. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>> (thanks to stefank for hosting my webrev :) >>>>>> >>>>>> CR: >>>>>> I'll file a CR tomorrow. >>>>>> >>>>>> Change comments: >>>>>> >>>>>> make/jprt.properties >>>>>> >>>>>> Add a test target to make sure that the API is available on all >>>>>> supported platforms >>>>>> >>>>>> make/** >>>>>> >>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >>>>>> JAR file and copy it to the jre/lib/endorsed directory in the export >>>>>> targets. >>>>>> The BSD makefile changes are not tested since I don't have access to >>>>>> any >>>>>> BSD/OSX machine to test them on. >>>>>> >>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>> >>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>> link it >>>>>> to JVM_RegisterWhiteBoxMethods >>>>>> >>>>>> src/share/vm/prims/whitebox.* >>>>>> >>>>>> The implementation of the white box API. The actual API functions are >>>>>> only examples of what we want to be able to do using the API. >>>>>> >>>>>> src/share/vm/runtime/globals.hpp >>>>>> >>>>>> Add the command line flag >>>>>> >>>>>> src/share/vm/utilities/vmError.cpp >>>>>> >>>>>> Print a message in hs_err files when white box API has been used. >>>>>> >>>>>> test/Makefile >>>>>> >>>>>> Add a makefile test target for the white box API test >>>>>> >>>>>> test/sanity/wbapi.java >>>>>> >>>>>> JTreg test to ensure that the API works. >>>>>> >>>>>> >>>>>> Thanks >>>>>> /Mikael Gerdin From jon.masamitsu at oracle.com Fri Dec 9 09:11:18 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 09 Dec 2011 17:11:18 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20111209171131.BFFB247650@hg.openjdk.java.net> Changeset: 4406629aa157 Author: johnc Date: 2011-12-02 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4406629aa157 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj Summary: As a result of the changes for 4965777, the G1 reference field scanning closure could be applied to the discovered field of a reference object twice. The failing assert is too strong if the result of the first application of the closure is stolen, and the referenced object, evacuated by another worker thread. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: e37aedaedccd Author: tonyp Date: 2011-12-05 12:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e37aedaedccd Merge Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1391adc6681 7112034: Parallel CMS fails to properly mark reference objects Summary: Enabled reference processing when work stealing during concurrent marking Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f4414323345f Author: stefank Date: 2011-11-28 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f4414323345f 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM Summary: Changed the conditional to see if the precompiled header has been specified. Also, removed the unused PrecompiledOption. Reviewed-by: dholmes, brutisso ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/gcc.make Changeset: d23d2b18183e Author: tonyp Date: 2011-12-07 12:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d23d2b18183e 7118202: G1: eden size unnecessarily drops to a minimum Summary: An integer underflow can cause the RSet lengths to be massively overpredicted which forces the eden size to the minimum. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e9b91fd07263 Author: jmasa Date: 2011-12-09 06:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e9b91fd07263 Merge From david.holmes at oracle.com Sun Dec 11 03:10:40 2011 From: david.holmes at oracle.com (David Holmes) Date: Sun, 11 Dec 2011 21:10:40 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE2104E.2040304@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> Message-ID: <4EE48FB0.1000503@oracle.com> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: > On 2011-12-09 05:25, David Holmes wrote: >> 2. lib/ext jars have the same permissions as bootclasspath, so it should >> work to place it there. > > I tried that first (before even discovering the existence of the > "endorsed" directory) but when I tried it the Whitebox class didn't get > have null as its classloader. Right - lib/ext is loaded by the extensions classloader not the bootstraploader. But this is supposed to have as many privileges as the bootstrap loader: "By default, installed optional packages in this standard directory are trusted. That is, they are granted the same privileges as if they were core platform classes (those in rt.jar). This default privilege is specified in the system policy file (in /jre/lib/security/java.policy), but can be overridden for a particular optional package by adding the appropriate policy file entry (see Permissions in the JDK). http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html What is it that requires that wb.jar actually be on the bootclasspath? Cheers, David > Looking at the code in src/share/vm/runtime/arguments.cpp, the class > SysClassPath claims to be responsible for handling the boot class path. > I don't see any reference to lib/ext there but I'm not very familiar > with how the class loading code actually works. > > /Mikael > >> >> Thanks, >> David >> >> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>> Hi David, >>> Sorry for the delayed response. >>> >>> On 2011-12-05 07:18, David Holmes wrote: >>>> Hi Mikael, >>>> >>>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>>> On 2011-12-02 06:32, David Holmes wrote: >>>>>> I'm a little confused as to where wb.jar ends up when I build >>>>>> hotspot. I >>>>>> see this in a makefile: >>>>> >>>>> There are a couple of issues in these make files. >>>>>> >>>>>> 26 WB = wb >>>>>> 27 >>>>>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >>>>>> 29 >>>>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>>>> 31 >>>>>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>>>>> >>>>>> Why JAVA_HOME? That's normally a binary installation of a JDK used >>>>>> for >>>>>> building, not somewhere I expect my build to try and put something. >>>>>> Plus >>>>>> the above will expand to: >>>>> >>>>> For example, look in jsig.make. It has a target that copies libjsig to >>>>> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >>>>> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing behavior >>>>> with the "install"-targets in the make files. >>>> >>>> Our build system is somewhat confusing. The top-level Defs.make will >>>> set >>>> JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which >>>> can >>>> be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are >>>> all >>>> places where the build expects to find an executable JDK for performing >>>> build actions like javac compiles, javah etc. >>>> >>>> As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and >>>> that is used by the install_* targets, which are dependencies of the >>>> vm.make install target. The vm.make install target is itself invoked >>>> from top.make's install target. >>>> >>>> So when do these install targets actually get used? Other than by a >>>> developer on the command-line I don't see these targets actually >>>> getting >>>> used - and they can't be specified as targets for the top-level >>>> Makefile. I suspect these may be relics from a time when you would do >>>> something like: >>>> >>>> JAVA_HOME=/my/local/jdk/to/test/ make product1 install >>> >>> You are probably correct. >>> Do you want me to modify the make file to more closely mimic the >>> behavior of the other make files and let the legacy "install" target >>> stay or do you want me to just not add an install target? >>> >>>> >>>>>> And if I build a full JDK, where does wb.jar end up then? >>>>> >>>>> $ find . -name wb.jar >>>>> ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar >>>>> ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The JDK makefiles that build the j2{sdk,re}-image directories do not >>>>> pick up the wb.jar file. >>>> >>>> Ok. So what is the expected build process here such that wb is >>>> available >>>> for use? Are you expecting the developer to do some kind of "make >>>> install"? >>> >>> This is primarily intended for use together with our internal test >>> infrastructure (nightly testing etc.). When running these tests there is >>> already a requirement for a JDK to go together with a VM that we are >>> testing. The same goes for jtreg and the HotSpot tests in the test/ >>> subdirectory of the HotSpot repository. >>> So if you want to run tests on your own VM wouldn't you need to use >>> something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do >>> automatically copy your libjvm to a working JDK? >>> >>> >>>> >>>>>> I also see in make/Makefile: >>>>>> >>>>>> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >>>>>> 371 $(install-file) >>>>>> >>>>>> Why the endorsed subdirectory? This is nothing to do with an >>>>>> "endorsed >>>>>> standard": >>>>>> >>>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ >>>>> >>>>> Because of security requirements and implementation details the >>>>> Whitebox >>>>> class must be available on the boot class path. >>>>> Putting the wb.jar file in the endorsed directory is a quick and easy >>>>> way to achieve that. >>>> >>>> Why not just in lib? Or perhaps lib/ext? endorsed just seems to be the >>>> least appropriate choice here. >>> >>> Because jars in lib/endorsed are automatically added to the _boot_ class >>> path. >>> We could put the jar in jre/lib/ext or jre/lib/ or just lib/ >>> but then all tests using the API would need -Xbootclasspath as an >>> additional command line flag. >>> >>>> >>>> And now your usage model has confused me because the above export is >>>> done for JPRT builds - right? So you want this to be available in a >>>> JPRT >>>> bundle, but not in a full JDK build? >>> >>> Nightly testing runs on bundles generated by JPRT, by having the API >>> available in those bundles we can have tests that use this API in our >>> nighly testing. >>> If we want to have this API available when doing a full JDK build we can >>> revisit that particular point in the future since that would need to be >>> synchronized with RE as well. >>> >>>> >>>>> Does this clarify your concerns? >>>> >>>> Not yet :) >>> >>> I'll keep trying then :) >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> /Mikael Gerdin >>>>> >>>>>> >>>>>> ??? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>> >>>>>>> CR: >>>>>>> I'll file a CR tomorrow. >>>>>>> >>>>>>> Change comments: >>>>>>> >>>>>>> make/jprt.properties >>>>>>> >>>>>>> Add a test target to make sure that the API is available on all >>>>>>> supported platforms >>>>>>> >>>>>>> make/** >>>>>>> >>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it >>>>>>> in a >>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the export >>>>>>> targets. >>>>>>> The BSD makefile changes are not tested since I don't have access to >>>>>>> any >>>>>>> BSD/OSX machine to test them on. >>>>>>> >>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>> >>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>> link it >>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>> >>>>>>> src/share/vm/prims/whitebox.* >>>>>>> >>>>>>> The implementation of the white box API. The actual API functions >>>>>>> are >>>>>>> only examples of what we want to be able to do using the API. >>>>>>> >>>>>>> src/share/vm/runtime/globals.hpp >>>>>>> >>>>>>> Add the command line flag >>>>>>> >>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>> >>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>> >>>>>>> test/Makefile >>>>>>> >>>>>>> Add a makefile test target for the white box API test >>>>>>> >>>>>>> test/sanity/wbapi.java >>>>>>> >>>>>>> JTreg test to ensure that the API works. >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> /Mikael Gerdin From mark at klomp.org Sun Dec 11 05:06:50 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 11 Dec 2011 14:06:50 +0100 Subject: Call for participation: Free Java @ FOSDEM 2012 Message-ID: <20111211130650.GD7625@toonder.wildebeest.org> We are pleased to announce the Call for Participation in the FOSDEM 2012 Free Java DevRoom! This marks the 9th year that the Free Java DevRoom has been a part of FOSDEM. http://fosdem.org/2012/ Saturday 4th and Sunday 5th of February 2012 Brussels, Belgium The Free Java DevRoom has become unique in that it has attracted upstream, downstream, distrbutors and and Free Software hackers together in one venue. Topics range from the "deep technical" to "deep community". Join us for this year's theme: "Free Java Momentum" Check out our wiki for more details on the conference: http://wiki.debian.org/Java/DevJam/2012/Fosdem And join the freejava-devroom at lists.fosdem.org https://lists.fosdem.org/mailman/listinfo/freejava-devroom Please submit one (or more) 30 minute talk proposal(s) by the 30th of December 2011 to fosdem at developer.classpath.org. A template for submitting a talk can be found at: http://wiki.debian.org/Java/DevJam/2012/Fosdem/CallForParticipation Please join us! --The Free Java DevRoom Organizing Committee Andrew Haley, Red Hat Dalibor Topic, Oracle Dr Andrew John Hughes, Red Hat Mark Wielaard, IcedTea Sylvestre Ledru, Debian Tom Marble, Informatique p.s. We had some nice media coverage last year... FLOSS Weekly 152: FOSDEM http://twit.tv/floss152 Linux Outlaws 191 - Special: FOSDEM Coverage http://old.linuxoutlaws.com/podcast/191 From mikael.gerdin at oracle.com Mon Dec 12 05:13:43 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 12 Dec 2011 14:13:43 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE48FB0.1000503@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> Message-ID: <4EE5FE07.40503@oracle.com> David, On 2011-12-11 12:10, David Holmes wrote: > On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >> On 2011-12-09 05:25, David Holmes wrote: >>> 2. lib/ext jars have the same permissions as bootclasspath, so it should >>> work to place it there. >> >> I tried that first (before even discovering the existence of the >> "endorsed" directory) but when I tried it the Whitebox class didn't get >> have null as its classloader. > > Right - lib/ext is loaded by the extensions classloader not the > bootstraploader. But this is supposed to have as many privileges as the > bootstrap loader: Yes, but does the VM know anything about the ext class loader? Is there any way to check from inside the privilege level of a class? (I suppose I can do some sort of upcall to the JDK to check that but is there a shorter way?) Also, there is one more detail about the boot class loader, see below. > > "By default, installed optional packages in this standard directory are > trusted. That is, they are granted the same privileges as if they were > core platform classes (those in rt.jar). This default privilege is > specified in the system policy file (in > /jre/lib/security/java.policy), but can be overridden for a > particular optional package by adding the appropriate policy file entry > (see Permissions in the JDK). > > http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html > > What is it that requires that wb.jar actually be on the bootclasspath? In order to avoid adding more changes to nativeLookup.cpp i just added the JVM_RegisterWhiteboxMethods to the array of methods explicitly menttioned in this file. The current code checks for the null class loader explicitly here: 156 Handle loader(THREAD, 157 instanceKlass::cast(method->method_holder())->class_loader()); 158 if (loader.is_null()) { 159 entry = lookup_special_native(jni_name); I could add another JNINativeMethod array and check for "WhiteBox_registerNatives" on all class loaders. If we go down this way I would have to verify with my security contact that he's okay with dropping the boot class loader requirement. /Mikael > > Cheers, > David > >> Looking at the code in src/share/vm/runtime/arguments.cpp, the class >> SysClassPath claims to be responsible for handling the boot class path. >> I don't see any reference to lib/ext there but I'm not very familiar >> with how the class loading code actually works. >> >> /Mikael >> >>> >>> Thanks, >>> David >>> >>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>>> Hi David, >>>> Sorry for the delayed response. >>>> >>>> On 2011-12-05 07:18, David Holmes wrote: >>>>> Hi Mikael, >>>>> >>>>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>>>> On 2011-12-02 06:32, David Holmes wrote: >>>>>>> I'm a little confused as to where wb.jar ends up when I build >>>>>>> hotspot. I >>>>>>> see this in a makefile: >>>>>> >>>>>> There are a couple of issues in these make files. >>>>>>> >>>>>>> 26 WB = wb >>>>>>> 27 >>>>>>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >>>>>>> 29 >>>>>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>>>>> 31 >>>>>>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>>>>>> >>>>>>> Why JAVA_HOME? That's normally a binary installation of a JDK used >>>>>>> for >>>>>>> building, not somewhere I expect my build to try and put something. >>>>>>> Plus >>>>>>> the above will expand to: >>>>>> >>>>>> For example, look in jsig.make. It has a target that copies >>>>>> libjsig to >>>>>> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >>>>>> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing >>>>>> behavior >>>>>> with the "install"-targets in the make files. >>>>> >>>>> Our build system is somewhat confusing. The top-level Defs.make will >>>>> set >>>>> JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which >>>>> can >>>>> be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are >>>>> all >>>>> places where the build expects to find an executable JDK for >>>>> performing >>>>> build actions like javac compiles, javah etc. >>>>> >>>>> As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and >>>>> that is used by the install_* targets, which are dependencies of the >>>>> vm.make install target. The vm.make install target is itself invoked >>>>> from top.make's install target. >>>>> >>>>> So when do these install targets actually get used? Other than by a >>>>> developer on the command-line I don't see these targets actually >>>>> getting >>>>> used - and they can't be specified as targets for the top-level >>>>> Makefile. I suspect these may be relics from a time when you would do >>>>> something like: >>>>> >>>>> JAVA_HOME=/my/local/jdk/to/test/ make product1 install >>>> >>>> You are probably correct. >>>> Do you want me to modify the make file to more closely mimic the >>>> behavior of the other make files and let the legacy "install" target >>>> stay or do you want me to just not add an install target? >>>> >>>>> >>>>>>> And if I build a full JDK, where does wb.jar end up then? >>>>>> >>>>>> $ find . -name wb.jar >>>>>> ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar >>>>>> ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The JDK makefiles that build the j2{sdk,re}-image directories do not >>>>>> pick up the wb.jar file. >>>>> >>>>> Ok. So what is the expected build process here such that wb is >>>>> available >>>>> for use? Are you expecting the developer to do some kind of "make >>>>> install"? >>>> >>>> This is primarily intended for use together with our internal test >>>> infrastructure (nightly testing etc.). When running these tests >>>> there is >>>> already a requirement for a JDK to go together with a VM that we are >>>> testing. The same goes for jtreg and the HotSpot tests in the test/ >>>> subdirectory of the HotSpot repository. >>>> So if you want to run tests on your own VM wouldn't you need to use >>>> something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do >>>> automatically copy your libjvm to a working JDK? >>>> >>>> >>>>> >>>>>>> I also see in make/Makefile: >>>>>>> >>>>>>> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >>>>>>> 371 $(install-file) >>>>>>> >>>>>>> Why the endorsed subdirectory? This is nothing to do with an >>>>>>> "endorsed >>>>>>> standard": >>>>>>> >>>>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ >>>>>> >>>>>> Because of security requirements and implementation details the >>>>>> Whitebox >>>>>> class must be available on the boot class path. >>>>>> Putting the wb.jar file in the endorsed directory is a quick and easy >>>>>> way to achieve that. >>>>> >>>>> Why not just in lib? Or perhaps lib/ext? endorsed just seems to be the >>>>> least appropriate choice here. >>>> >>>> Because jars in lib/endorsed are automatically added to the _boot_ >>>> class >>>> path. >>>> We could put the jar in jre/lib/ext or jre/lib/ or just lib/ >>>> but then all tests using the API would need -Xbootclasspath as an >>>> additional command line flag. >>>> >>>>> >>>>> And now your usage model has confused me because the above export is >>>>> done for JPRT builds - right? So you want this to be available in a >>>>> JPRT >>>>> bundle, but not in a full JDK build? >>>> >>>> Nightly testing runs on bundles generated by JPRT, by having the API >>>> available in those bundles we can have tests that use this API in our >>>> nighly testing. >>>> If we want to have this API available when doing a full JDK build we >>>> can >>>> revisit that particular point in the future since that would need to be >>>> synchronized with RE as well. >>>> >>>>> >>>>>> Does this clarify your concerns? >>>>> >>>>> Not yet :) >>>> >>>> I'll keep trying then :) >>>> >>>> /Mikael >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> /Mikael Gerdin >>>>>> >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>> >>>>>>>> CR: >>>>>>>> I'll file a CR tomorrow. >>>>>>>> >>>>>>>> Change comments: >>>>>>>> >>>>>>>> make/jprt.properties >>>>>>>> >>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>> supported platforms >>>>>>>> >>>>>>>> make/** >>>>>>>> >>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it >>>>>>>> in a >>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>> export >>>>>>>> targets. >>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>> access to >>>>>>>> any >>>>>>>> BSD/OSX machine to test them on. >>>>>>>> >>>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>>> >>>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>>> link it >>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>> >>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>> >>>>>>>> The implementation of the white box API. The actual API functions >>>>>>>> are >>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>> >>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>> >>>>>>>> Add the command line flag >>>>>>>> >>>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>>> >>>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>>> >>>>>>>> test/Makefile >>>>>>>> >>>>>>>> Add a makefile test target for the white box API test >>>>>>>> >>>>>>>> test/sanity/wbapi.java >>>>>>>> >>>>>>>> JTreg test to ensure that the API works. >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> /Mikael Gerdin From rednaxelafx at gmail.com Mon Dec 12 06:54:39 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 12 Dec 2011 22:54:39 +0800 Subject: outputStream's position not updated by disassembler In-Reply-To: References: Message-ID: Hi all, Got around to look at this issue again today, and it turns out the fix was fairly simple: In VMError, a staticBufferStream was used to write out the contents of the crash log. staticBufferStream never updates its own _position, probably because it was thought to be redundant, that the underlying _outer_stream should have updated position correctly. hsdis relies on positional info to be correct to write the newlines (with st->bol() ), but since staticBufferStream doesn't update its own position, bol() never calls cr() in this case. The simplest fix would be to call update_position() in staticBufferStream::write(), albeit redundant. outputStream::position() isn't virtual, so it can't be overridden by staticBufferStream to use its underlying _outer_stream's position. An updated, but still quick-n-dirty patch to disassemble instructions in HotSpot's crash log is at [1]. The patch is only meant for my debugging purposes, though. I'm not purposing an RFE here, just answering my own question. - Kris [1]: https://gist.github.com/1467547 On Fri, Sep 9, 2011 at 3:11 PM, Krystal Mok wrote: > Hi all, > > I tried to add disassembly support in VM error reporting, but had a couple > of issues. > The result I'm looking for is something like this: > > Instructions: (pc=0x00002b148974ddf2) > 0x00002b148974ddd2: 48 8b 05 17 0d 42 00 41 c7 85 48 02 00 00 06 00 > 0x00002b148974dde2: 00 00 8b 38 e8 ed 3f 9a ff c6 80 6c 02 00 00 01 > 0x00002b148974ddf2: 45 89 26 c6 80 6c 02 00 00 00 48 8b 5b 48 48 8b > 0x00002b148974de02: 7b 10 4c 8b 63 08 48 83 3f 00 74 09 e8 cd 6f a3 > > [Disassembling for mach='i386:x86-64'] > 0x00002b148974ddf2: mov %r12d,(%r14) > 0x00002b148974ddf5: movb $0x0,0x26c(%rax) > 0x00002b148974ddfc: mov 0x48(%rbx),%rbx > 0x00002b148974de00: mov 0x10(%rbx),%rdi > ... > > I'm working on Linux/x64, HS20-b11. If I made this change to reuse > the disassembler plugin (if available): > > diff -r f0f676c5a2c6 src/os_cpu/linux_x86/vm/os_linux_x86.cpp > --- a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Tue Mar 15 19:30:16 2011 > -0700 > +++ b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Fri Sep 09 14:50:16 2011 > +0800 > @@ -29,6 +29,7 @@ > #include "classfile/vmSymbols.hpp" > #include "code/icBuffer.hpp" > #include "code/vtableStubs.hpp" > +#include "compiler/disassembler.hpp" > #include "interpreter/interpreter.hpp" > #include "jvm_linux.h" > #include "memory/allocation.inline.hpp" > @@ -808,6 +809,11 @@ > address pc = os::Linux::ucontext_get_pc(uc); > st->print_cr("Instructions: (pc=" PTR_FORMAT ")", pc); > print_hex_dump(st, pc - 32, pc + 32, sizeof(char)); > + > + // dump disassembly near pc > + st->cr(); > + Disassembler::decode(pc, pc + 32, st); > + st->cr(); > } > > void os::print_register_info(outputStream *st, void *context) { > > > Then the disassembly output I'm getting misses all newlines at the end of > each instruction, like this: > > [Disassembling for mach='i386:x86-64'] > 0x00002b148974ddf2: mov %r12d,(%r14) 0x00002b148974ddf5: movb > $0x0,0x26c(%rax) ... > > Tracing down, the newlines are requested by the disassembler plugin (hsdis > in this case), handled by printf_to_env(void* env_pv, const char* format, > ...), which in turn calls outputStream::bol(). > bol() decides whether or not to write a newline depending on the current > position. By instrumenting printf_to_env, I found that the position was > always 0 during disassembling, which caused the problem of missing newlines. > > But the same plugin, when used in situations like PrintInterpreter, works > fine; the position gets updated correctly, and no newlines are lost. > > Does anyone have any idea what might have caused the difference? The > outputStream instances are different, sure, but staticBufferStream used > in error reporting look pretty innocent to me. > > P.S. I could just work around this by changing the bol() call to a cr()call. But that feels hackish, and I'm looking for a cleaner solution. > > Regards, > Kris Mok > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111212/e602d7b5/attachment.html From david.holmes at oracle.com Mon Dec 12 19:16:22 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 13:16:22 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE5FE07.40503@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> Message-ID: <4EE6C386.3010207@oracle.com> Hi Mikael, I see why you are dependent on being loaded by the boot loader, but I think using the endorsed mechanism for that is somewhat of a hack - this isn't anything to do with being endorsed it is just a way to get on the bootclasspath without modifying the bootclasspath. I'd like to hear what others think of this. David On 12/12/2011 11:13 PM, Mikael Gerdin wrote: > David, > > On 2011-12-11 12:10, David Holmes wrote: >> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>> On 2011-12-09 05:25, David Holmes wrote: >>>> 2. lib/ext jars have the same permissions as bootclasspath, so it >>>> should >>>> work to place it there. >>> >>> I tried that first (before even discovering the existence of the >>> "endorsed" directory) but when I tried it the Whitebox class didn't get >>> have null as its classloader. >> >> Right - lib/ext is loaded by the extensions classloader not the >> bootstraploader. But this is supposed to have as many privileges as the >> bootstrap loader: > > Yes, but does the VM know anything about the ext class loader? > Is there any way to check from inside the privilege level of a class? (I > suppose I can do some sort of upcall to the JDK to check that but is > there a shorter way?) > > Also, there is one more detail about the boot class loader, see below. > >> >> "By default, installed optional packages in this standard directory are >> trusted. That is, they are granted the same privileges as if they were >> core platform classes (those in rt.jar). This default privilege is >> specified in the system policy file (in >> /jre/lib/security/java.policy), but can be overridden for a >> particular optional package by adding the appropriate policy file entry >> (see Permissions in the JDK). >> >> http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/spec.html >> >> >> What is it that requires that wb.jar actually be on the bootclasspath? > > In order to avoid adding more changes to nativeLookup.cpp i just added > the JVM_RegisterWhiteboxMethods to the array of methods explicitly > menttioned in this file. > > The current code checks for the null class loader explicitly here: > 156 Handle loader(THREAD, > 157 instanceKlass::cast(method->method_holder())->class_loader()); > 158 if (loader.is_null()) { > 159 entry = lookup_special_native(jni_name); > > I could add another JNINativeMethod array and check for > "WhiteBox_registerNatives" on all class loaders. > If we go down this way I would have to verify with my security contact > that he's okay with dropping the boot class loader requirement. > > /Mikael > >> >> Cheers, >> David >> >>> Looking at the code in src/share/vm/runtime/arguments.cpp, the class >>> SysClassPath claims to be responsible for handling the boot class path. >>> I don't see any reference to lib/ext there but I'm not very familiar >>> with how the class loading code actually works. >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>>>> Hi David, >>>>> Sorry for the delayed response. >>>>> >>>>> On 2011-12-05 07:18, David Holmes wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>>>>> On 2011-12-02 06:32, David Holmes wrote: >>>>>>>> I'm a little confused as to where wb.jar ends up when I build >>>>>>>> hotspot. I >>>>>>>> see this in a makefile: >>>>>>> >>>>>>> There are a couple of issues in these make files. >>>>>>>> >>>>>>>> 26 WB = wb >>>>>>>> 27 >>>>>>>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/whitebox/src >>>>>>>> 29 >>>>>>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>>>>>> 31 >>>>>>>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>>>>>>> >>>>>>>> Why JAVA_HOME? That's normally a binary installation of a JDK used >>>>>>>> for >>>>>>>> building, not somewhere I expect my build to try and put something. >>>>>>>> Plus >>>>>>>> the above will expand to: >>>>>>> >>>>>>> For example, look in jsig.make. It has a target that copies >>>>>>> libjsig to >>>>>>> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >>>>>>> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing >>>>>>> behavior >>>>>>> with the "install"-targets in the make files. >>>>>> >>>>>> Our build system is somewhat confusing. The top-level Defs.make will >>>>>> set >>>>>> JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which >>>>>> can >>>>>> be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are >>>>>> all >>>>>> places where the build expects to find an executable JDK for >>>>>> performing >>>>>> build actions like javac compiles, javah etc. >>>>>> >>>>>> As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and >>>>>> that is used by the install_* targets, which are dependencies of the >>>>>> vm.make install target. The vm.make install target is itself invoked >>>>>> from top.make's install target. >>>>>> >>>>>> So when do these install targets actually get used? Other than by a >>>>>> developer on the command-line I don't see these targets actually >>>>>> getting >>>>>> used - and they can't be specified as targets for the top-level >>>>>> Makefile. I suspect these may be relics from a time when you would do >>>>>> something like: >>>>>> >>>>>> JAVA_HOME=/my/local/jdk/to/test/ make product1 install >>>>> >>>>> You are probably correct. >>>>> Do you want me to modify the make file to more closely mimic the >>>>> behavior of the other make files and let the legacy "install" target >>>>> stay or do you want me to just not add an install target? >>>>> >>>>>> >>>>>>>> And if I build a full JDK, where does wb.jar end up then? >>>>>>> >>>>>>> $ find . -name wb.jar >>>>>>> ./build/linux-amd64/hotspot/import/jre/lib/endorsed/wb.jar >>>>>>> ./build/linux-amd64/hotspot/outputdir/linux_amd64_compiler2/generated/wb.jar >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The JDK makefiles that build the j2{sdk,re}-image directories do not >>>>>>> pick up the wb.jar file. >>>>>> >>>>>> Ok. So what is the expected build process here such that wb is >>>>>> available >>>>>> for use? Are you expecting the developer to do some kind of "make >>>>>> install"? >>>>> >>>>> This is primarily intended for use together with our internal test >>>>> infrastructure (nightly testing etc.). When running these tests >>>>> there is >>>>> already a requirement for a JDK to go together with a VM that we are >>>>> testing. The same goes for jtreg and the HotSpot tests in the test/ >>>>> subdirectory of the HotSpot repository. >>>>> So if you want to run tests on your own VM wouldn't you need to use >>>>> something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do >>>>> automatically copy your libjvm to a working JDK? >>>>> >>>>> >>>>>> >>>>>>>> I also see in make/Makefile: >>>>>>>> >>>>>>>> 370 $(EXPORT_JRE_LIB_DIR)/endorsed/%.jar: $(GEN_DIR)/%.jar >>>>>>>> 371 $(install-file) >>>>>>>> >>>>>>>> Why the endorsed subdirectory? This is nothing to do with an >>>>>>>> "endorsed >>>>>>>> standard": >>>>>>>> >>>>>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/ >>>>>>> >>>>>>> Because of security requirements and implementation details the >>>>>>> Whitebox >>>>>>> class must be available on the boot class path. >>>>>>> Putting the wb.jar file in the endorsed directory is a quick and >>>>>>> easy >>>>>>> way to achieve that. >>>>>> >>>>>> Why not just in lib? Or perhaps lib/ext? endorsed just seems to be >>>>>> the >>>>>> least appropriate choice here. >>>>> >>>>> Because jars in lib/endorsed are automatically added to the _boot_ >>>>> class >>>>> path. >>>>> We could put the jar in jre/lib/ext or jre/lib/ or just lib/ >>>>> but then all tests using the API would need -Xbootclasspath as an >>>>> additional command line flag. >>>>> >>>>>> >>>>>> And now your usage model has confused me because the above export is >>>>>> done for JPRT builds - right? So you want this to be available in a >>>>>> JPRT >>>>>> bundle, but not in a full JDK build? >>>>> >>>>> Nightly testing runs on bundles generated by JPRT, by having the API >>>>> available in those bundles we can have tests that use this API in our >>>>> nighly testing. >>>>> If we want to have this API available when doing a full JDK build we >>>>> can >>>>> revisit that particular point in the future since that would need >>>>> to be >>>>> synchronized with RE as well. >>>>> >>>>>> >>>>>>> Does this clarify your concerns? >>>>>> >>>>>> Not yet :) >>>>> >>>>> I'll keep trying then :) >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> /Mikael Gerdin >>>>>>> >>>>>>>> >>>>>>>> ??? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>>> >>>>>>>>> CR: >>>>>>>>> I'll file a CR tomorrow. >>>>>>>>> >>>>>>>>> Change comments: >>>>>>>>> >>>>>>>>> make/jprt.properties >>>>>>>>> >>>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>>> supported platforms >>>>>>>>> >>>>>>>>> make/** >>>>>>>>> >>>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it >>>>>>>>> in a >>>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>>> export >>>>>>>>> targets. >>>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>>> access to >>>>>>>>> any >>>>>>>>> BSD/OSX machine to test them on. >>>>>>>>> >>>>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>>>> >>>>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>>>> link it >>>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>>> >>>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>>> >>>>>>>>> The implementation of the white box API. The actual API functions >>>>>>>>> are >>>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>>> >>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>> >>>>>>>>> Add the command line flag >>>>>>>>> >>>>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>>>> >>>>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>>>> >>>>>>>>> test/Makefile >>>>>>>>> >>>>>>>>> Add a makefile test target for the white box API test >>>>>>>>> >>>>>>>>> test/sanity/wbapi.java >>>>>>>>> >>>>>>>>> JTreg test to ensure that the API works. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /Mikael Gerdin From rednaxelafx at gmail.com Mon Dec 12 22:48:39 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 13 Dec 2011 14:48:39 +0800 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE6C386.3010207@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> Message-ID: Hi Mikael and David, As an alternative, how about inserting wb.jar into the bootclasspath in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is enabled, just like the way alt-rt.jar is inserted when -XX:+AggressiveOpts is given, in the product JDK 6 and 7? - Kris On Tue, Dec 13, 2011 at 11:16 AM, David Holmes wrote: > Hi Mikael, > > I see why you are dependent on being loaded by the boot loader, but I > think using the endorsed mechanism for that is somewhat of a hack - this > isn't anything to do with being endorsed it is just a way to get on the > bootclasspath without modifying the bootclasspath. > > I'd like to hear what others think of this. > > David > > > On 12/12/2011 11:13 PM, Mikael Gerdin wrote: > >> David, >> >> On 2011-12-11 12:10, David Holmes wrote: >> >>> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>> >>>> On 2011-12-09 05:25, David Holmes wrote: >>>> >>>>> 2. lib/ext jars have the same permissions as bootclasspath, so it >>>>> should >>>>> work to place it there. >>>>> >>>> >>>> I tried that first (before even discovering the existence of the >>>> "endorsed" directory) but when I tried it the Whitebox class didn't get >>>> have null as its classloader. >>>> >>> >>> Right - lib/ext is loaded by the extensions classloader not the >>> bootstraploader. But this is supposed to have as many privileges as the >>> bootstrap loader: >>> >> >> Yes, but does the VM know anything about the ext class loader? >> Is there any way to check from inside the privilege level of a class? (I >> suppose I can do some sort of upcall to the JDK to check that but is >> there a shorter way?) >> >> Also, there is one more detail about the boot class loader, see below. >> >> >>> "By default, installed optional packages in this standard directory are >>> trusted. That is, they are granted the same privileges as if they were >>> core platform classes (those in rt.jar). This default privilege is >>> specified in the system policy file (in >>> /jre/lib/security/**java.policy), but can be overridden for a >>> particular optional package by adding the appropriate policy file entry >>> (see Permissions in the JDK). >>> >>> http://docs.oracle.com/javase/**7/docs/technotes/guides/** >>> extensions/spec.html >>> >>> >>> What is it that requires that wb.jar actually be on the bootclasspath? >>> >> >> In order to avoid adding more changes to nativeLookup.cpp i just added >> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >> menttioned in this file. >> >> The current code checks for the null class loader explicitly here: >> 156 Handle loader(THREAD, >> 157 instanceKlass::cast(method->**method_holder())->class_**loader()); >> 158 if (loader.is_null()) { >> 159 entry = lookup_special_native(jni_**name); >> >> I could add another JNINativeMethod array and check for >> "WhiteBox_registerNatives" on all class loaders. >> If we go down this way I would have to verify with my security contact >> that he's okay with dropping the boot class loader requirement. >> >> /Mikael >> >> >>> Cheers, >>> David >>> >>> Looking at the code in src/share/vm/runtime/**arguments.cpp, the class >>>> SysClassPath claims to be responsible for handling the boot class path. >>>> I don't see any reference to lib/ext there but I'm not very familiar >>>> with how the class loading code actually works. >>>> >>>> /Mikael >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>>>> >>>>>> Hi David, >>>>>> Sorry for the delayed response. >>>>>> >>>>>> On 2011-12-05 07:18, David Holmes wrote: >>>>>> >>>>>>> Hi Mikael, >>>>>>> >>>>>>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>>>>> >>>>>>>> On 2011-12-02 06:32, David Holmes wrote: >>>>>>>> >>>>>>>>> I'm a little confused as to where wb.jar ends up when I build >>>>>>>>> hotspot. I >>>>>>>>> see this in a makefile: >>>>>>>>> >>>>>>>> >>>>>>>> There are a couple of issues in these make files. >>>>>>>> >>>>>>>>> >>>>>>>>> 26 WB = wb >>>>>>>>> 27 >>>>>>>>> 28 WBSRCDIR = $(GAMMADIR)/src/share/tools/**whitebox/src >>>>>>>>> 29 >>>>>>>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>>>>>>> 31 >>>>>>>>> 32 DEST_WB_JAR = $(JAVA_HOME)/lib/$(WB_JAR) >>>>>>>>> >>>>>>>>> Why JAVA_HOME? That's normally a binary installation of a JDK used >>>>>>>>> for >>>>>>>>> building, not somewhere I expect my build to try and put something. >>>>>>>>> Plus >>>>>>>>> the above will expand to: >>>>>>>>> >>>>>>>> >>>>>>>> For example, look in jsig.make. It has a target that copies >>>>>>>> libjsig to >>>>>>>> JDK_LIBDIR. JDK_LIBDIR is set up in vm.make to point to >>>>>>>> JAVA_HOME/jre/lib/[arch]. I was only trying to mimic existing >>>>>>>> behavior >>>>>>>> with the "install"-targets in the make files. >>>>>>>> >>>>>>> >>>>>>> Our build system is somewhat confusing. The top-level Defs.make will >>>>>>> set >>>>>>> JAVA_HOME based on ABS_BOOTDIR which in turn is set by BOOTDIR which >>>>>>> can >>>>>>> be overridden by ALT_BOOTDIR. BOOTDIR, ALT_BOOTDIR and JAVA_HOME are >>>>>>> all >>>>>>> places where the build expects to find an executable JDK for >>>>>>> performing >>>>>>> build actions like javac compiles, javah etc. >>>>>>> >>>>>>> As you point out vm.make then sets JDK_LIBDIR based on JAVA_HOME and >>>>>>> that is used by the install_* targets, which are dependencies of the >>>>>>> vm.make install target. The vm.make install target is itself invoked >>>>>>> from top.make's install target. >>>>>>> >>>>>>> So when do these install targets actually get used? Other than by a >>>>>>> developer on the command-line I don't see these targets actually >>>>>>> getting >>>>>>> used - and they can't be specified as targets for the top-level >>>>>>> Makefile. I suspect these may be relics from a time when you would do >>>>>>> something like: >>>>>>> >>>>>>> JAVA_HOME=/my/local/jdk/to/**test/ make product1 install >>>>>>> >>>>>> >>>>>> You are probably correct. >>>>>> Do you want me to modify the make file to more closely mimic the >>>>>> behavior of the other make files and let the legacy "install" target >>>>>> stay or do you want me to just not add an install target? >>>>>> >>>>>> >>>>>>> And if I build a full JDK, where does wb.jar end up then? >>>>>>>>> >>>>>>>> >>>>>>>> $ find . -name wb.jar >>>>>>>> ./build/linux-amd64/hotspot/**import/jre/lib/endorsed/wb.jar >>>>>>>> ./build/linux-amd64/hotspot/**outputdir/linux_amd64_** >>>>>>>> compiler2/generated/wb.jar >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The JDK makefiles that build the j2{sdk,re}-image directories do not >>>>>>>> pick up the wb.jar file. >>>>>>>> >>>>>>> >>>>>>> Ok. So what is the expected build process here such that wb is >>>>>>> available >>>>>>> for use? Are you expecting the developer to do some kind of "make >>>>>>> install"? >>>>>>> >>>>>> >>>>>> This is primarily intended for use together with our internal test >>>>>> infrastructure (nightly testing etc.). When running these tests >>>>>> there is >>>>>> already a requirement for a JDK to go together with a VM that we are >>>>>> testing. The same goes for jtreg and the HotSpot tests in the test/ >>>>>> subdirectory of the HotSpot repository. >>>>>> So if you want to run tests on your own VM wouldn't you need to use >>>>>> something like "make ALT_EXPORT_PATH=/some/jdk all_fastdebug" do >>>>>> automatically copy your libjvm to a working JDK? >>>>>> >>>>>> >>>>>> >>>>>>> I also see in make/Makefile: >>>>>>>>> >>>>>>>>> 370 $(EXPORT_JRE_LIB_DIR)/**endorsed/%.jar: $(GEN_DIR)/%.jar >>>>>>>>> 371 $(install-file) >>>>>>>>> >>>>>>>>> Why the endorsed subdirectory? This is nothing to do with an >>>>>>>>> "endorsed >>>>>>>>> standard": >>>>>>>>> >>>>>>>>> http://docs.oracle.com/javase/**6/docs/technotes/guides/** >>>>>>>>> standards/ >>>>>>>>> >>>>>>>> >>>>>>>> Because of security requirements and implementation details the >>>>>>>> Whitebox >>>>>>>> class must be available on the boot class path. >>>>>>>> Putting the wb.jar file in the endorsed directory is a quick and >>>>>>>> easy >>>>>>>> way to achieve that. >>>>>>>> >>>>>>> >>>>>>> Why not just in lib? Or perhaps lib/ext? endorsed just seems to be >>>>>>> the >>>>>>> least appropriate choice here. >>>>>>> >>>>>> >>>>>> Because jars in lib/endorsed are automatically added to the _boot_ >>>>>> class >>>>>> path. >>>>>> We could put the jar in jre/lib/ext or jre/lib/ or just lib/ >>>>>> but then all tests using the API would need -Xbootclasspath as an >>>>>> additional command line flag. >>>>>> >>>>>> >>>>>>> And now your usage model has confused me because the above export is >>>>>>> done for JPRT builds - right? So you want this to be available in a >>>>>>> JPRT >>>>>>> bundle, but not in a full JDK build? >>>>>>> >>>>>> >>>>>> Nightly testing runs on bundles generated by JPRT, by having the API >>>>>> available in those bundles we can have tests that use this API in our >>>>>> nighly testing. >>>>>> If we want to have this API available when doing a full JDK build we >>>>>> can >>>>>> revisit that particular point in the future since that would need >>>>>> to be >>>>>> synchronized with RE as well. >>>>>> >>>>>> >>>>>>> Does this clarify your concerns? >>>>>>>> >>>>>>> >>>>>>> Not yet :) >>>>>>> >>>>>> >>>>>> I'll keep trying then :) >>>>>> >>>>>> /Mikael >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> /Mikael Gerdin >>>>>>>> >>>>>>>> >>>>>>>>> ??? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~**stefank/mgerdin/wbapi.0/**webrev/ >>>>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>>>> >>>>>>>>>> CR: >>>>>>>>>> I'll file a CR tomorrow. >>>>>>>>>> >>>>>>>>>> Change comments: >>>>>>>>>> >>>>>>>>>> make/jprt.properties >>>>>>>>>> >>>>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>>>> supported platforms >>>>>>>>>> >>>>>>>>>> make/** >>>>>>>>>> >>>>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it >>>>>>>>>> in a >>>>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>>>> export >>>>>>>>>> targets. >>>>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>>>> access to >>>>>>>>>> any >>>>>>>>>> BSD/OSX machine to test them on. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/**nativeLookup.cpp >>>>>>>>>> >>>>>>>>>> Special-case the method sun/hotspot/WhiteBox/**registerNatives >>>>>>>>>> and >>>>>>>>>> link it >>>>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>>>> >>>>>>>>>> The implementation of the white box API. The actual API functions >>>>>>>>>> are >>>>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/globals.**hpp >>>>>>>>>> >>>>>>>>>> Add the command line flag >>>>>>>>>> >>>>>>>>>> src/share/vm/utilities/**vmError.cpp >>>>>>>>>> >>>>>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>>>>> >>>>>>>>>> test/Makefile >>>>>>>>>> >>>>>>>>>> Add a makefile test target for the white box API test >>>>>>>>>> >>>>>>>>>> test/sanity/wbapi.java >>>>>>>>>> >>>>>>>>>> JTreg test to ensure that the API works. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /Mikael Gerdin >>>>>>>>>> >>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111213/fe5b9427/attachment-0001.html From david.holmes at oracle.com Mon Dec 12 23:04:53 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 17:04:53 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> Message-ID: <4EE6F915.7060602@oracle.com> On 13/12/2011 4:48 PM, Krystal Mok wrote: > Hi Mikael and David, > > As an alternative, how about inserting wb.jar into the bootclasspath > in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is > enabled, just like the way alt-rt.jar is inserted when > -XX:+AggressiveOpts is given, in the product JDK 6 and 7? And presumably place wb.jar in jre/lib the way alt-rt.jar is. That seems like a good suggestion - thanks Kris. David > - Kris > > On Tue, Dec 13, 2011 at 11:16 AM, David Holmes > wrote: > > Hi Mikael, > > I see why you are dependent on being loaded by the boot loader, but > I think using the endorsed mechanism for that is somewhat of a hack > - this isn't anything to do with being endorsed it is just a way to > get on the bootclasspath without modifying the bootclasspath. > > I'd like to hear what others think of this. > > David > > > On 12/12/2011 11:13 PM, Mikael Gerdin wrote: > > David, > > On 2011-12-11 12:10, David Holmes wrote: > > On 9/12/2011 11:42 PM, Mikael Gerdin wrote: > > On 2011-12-09 05:25, David Holmes wrote: > > 2. lib/ext jars have the same permissions as > bootclasspath, so it > should > work to place it there. > > > I tried that first (before even discovering the > existence of the > "endorsed" directory) but when I tried it the Whitebox > class didn't get > have null as its classloader. > > > Right - lib/ext is loaded by the extensions classloader not the > bootstraploader. But this is supposed to have as many > privileges as the > bootstrap loader: > > > Yes, but does the VM know anything about the ext class loader? > Is there any way to check from inside the privilege level of a > class? (I > suppose I can do some sort of upcall to the JDK to check that but is > there a shorter way?) > > Also, there is one more detail about the boot class loader, see > below. > > > "By default, installed optional packages in this standard > directory are > trusted. That is, they are granted the same privileges as if > they were > core platform classes (those in rt.jar). This default > privilege is > specified in the system policy file (in > /jre/lib/security/__java.policy), but can be > overridden for a > particular optional package by adding the appropriate policy > file entry > (see Permissions in the JDK). > > http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html > > > > What is it that requires that wb.jar actually be on the > bootclasspath? > > > In order to avoid adding more changes to nativeLookup.cpp i just > added > the JVM_RegisterWhiteboxMethods to the array of methods explicitly > menttioned in this file. > > The current code checks for the null class loader explicitly here: > 156 Handle loader(THREAD, > 157 > instanceKlass::cast(method->__method_holder())->class___loader()); > 158 if (loader.is_null()) { > 159 entry = lookup_special_native(jni___name); > > I could add another JNINativeMethod array and check for > "WhiteBox_registerNatives" on all class loaders. > If we go down this way I would have to verify with my security > contact > that he's okay with dropping the boot class loader requirement. > > /Mikael > > > Cheers, > David > > Looking at the code in > src/share/vm/runtime/__arguments.cpp, the class > SysClassPath claims to be responsible for handling the > boot class path. > I don't see any reference to lib/ext there but I'm not > very familiar > with how the class loading code actually works. > > /Mikael > > > Thanks, > David > > On 9/12/2011 1:11 AM, Mikael Gerdin wrote: > > Hi David, > Sorry for the delayed response. > > On 2011-12-05 07:18, David Holmes wrote: > > Hi Mikael, > > On 2/12/2011 8:46 PM, Mikael Gerdin wrote: > > On 2011-12-02 06:32, David Holmes wrote: > > I'm a little confused as to where > wb.jar ends up when I build > hotspot. I > see this in a makefile: > > > There are a couple of issues in these > make files. > > > 26 WB = wb > 27 > 28 WBSRCDIR = > $(GAMMADIR)/src/share/tools/__whitebox/src > 29 > 30 WB_JAR = $(GENERATED)/$(WB).jar > 31 > 32 DEST_WB_JAR = > $(JAVA_HOME)/lib/$(WB_JAR) > > Why JAVA_HOME? That's normally a > binary installation of a JDK used > for > building, not somewhere I expect my > build to try and put something. > Plus > the above will expand to: > > > For example, look in jsig.make. It has a > target that copies > libjsig to > JDK_LIBDIR. JDK_LIBDIR is set up in > vm.make to point to > JAVA_HOME/jre/lib/[arch]. I was only > trying to mimic existing > behavior > with the "install"-targets in the make > files. > > > Our build system is somewhat confusing. The > top-level Defs.make will > set > JAVA_HOME based on ABS_BOOTDIR which in turn > is set by BOOTDIR which > can > be overridden by ALT_BOOTDIR. BOOTDIR, > ALT_BOOTDIR and JAVA_HOME are > all > places where the build expects to find an > executable JDK for > performing > build actions like javac compiles, javah etc. > > As you point out vm.make then sets > JDK_LIBDIR based on JAVA_HOME and > that is used by the install_* targets, which > are dependencies of the > vm.make install target. The vm.make install > target is itself invoked > from top.make's install target. > > So when do these install targets actually > get used? Other than by a > developer on the command-line I don't see > these targets actually > getting > used - and they can't be specified as > targets for the top-level > Makefile. I suspect these may be relics from > a time when you would do > something like: > > JAVA_HOME=/my/local/jdk/to/__test/ make > product1 install > > > You are probably correct. > Do you want me to modify the make file to more > closely mimic the > behavior of the other make files and let the > legacy "install" target > stay or do you want me to just not add an > install target? > > > And if I build a full JDK, where > does wb.jar end up then? > > > $ find . -name wb.jar > ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar > ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar > > > > > > > > > The JDK makefiles that build the > j2{sdk,re}-image directories do not > pick up the wb.jar file. > > > Ok. So what is the expected build process > here such that wb is > available > for use? Are you expecting the developer to > do some kind of "make > install"? > > > This is primarily intended for use together with > our internal test > infrastructure (nightly testing etc.). When > running these tests > there is > already a requirement for a JDK to go together > with a VM that we are > testing. The same goes for jtreg and the HotSpot > tests in the test/ > subdirectory of the HotSpot repository. > So if you want to run tests on your own VM > wouldn't you need to use > something like "make ALT_EXPORT_PATH=/some/jdk > all_fastdebug" do > automatically copy your libjvm to a working JDK? > > > > I also see in make/Makefile: > > 370 > $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: > $(GEN_DIR)/%.jar > 371 $(install-file) > > Why the endorsed subdirectory? This > is nothing to do with an > "endorsed > standard": > > http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ > > > > Because of security requirements and > implementation details the > Whitebox > class must be available on the boot > class path. > Putting the wb.jar file in the endorsed > directory is a quick and > easy > way to achieve that. > > > Why not just in lib? Or perhaps lib/ext? > endorsed just seems to be > the > least appropriate choice here. > > > Because jars in lib/endorsed are automatically > added to the _boot_ > class > path. > We could put the jar in jre/lib/ext or jre/lib/ > or just lib/ > but then all tests using the API would need > -Xbootclasspath as an > additional command line flag. > > > And now your usage model has confused me > because the above export is > done for JPRT builds - right? So you want > this to be available in a > JPRT > bundle, but not in a full JDK build? > > > Nightly testing runs on bundles generated by > JPRT, by having the API > available in those bundles we can have tests > that use this API in our > nighly testing. > If we want to have this API available when doing > a full JDK build we > can > revisit that particular point in the future > since that would need > to be > synchronized with RE as well. > > > Does this clarify your concerns? > > > Not yet :) > > > I'll keep trying then :) > > /Mikael > > > Thanks, > David > > /Mikael Gerdin > > > ??? > > Thanks, > David > ----- > > If the VM crashes after this API > has been accessed a note will be > written in the hs_err file to > signal that the API has been used. > > Webrev: > http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ > > (thanks to stefank for hosting > my webrev :) > > CR: > I'll file a CR tomorrow. > > Change comments: > > make/jprt.properties > > Add a test target to make sure > that the API is available on all > supported platforms > > make/** > > Makefile changes to build the > class sun/hotspot/WhiteBox, put it > in a > JAR file and copy it to the > jre/lib/endorsed directory in the > export > targets. > The BSD makefile changes are not > tested since I don't have > access to > any > BSD/OSX machine to test them on. > > src/share/vm/prims/__nativeLookup.cpp > > Special-case the method > sun/hotspot/WhiteBox/__registerNatives > and > link it > to JVM_RegisterWhiteBoxMethods > > src/share/vm/prims/whitebox.* > > The implementation of the white > box API. The actual API functions > are > only examples of what we want to > be able to do using the API. > > src/share/vm/runtime/globals.__hpp > > Add the command line flag > > src/share/vm/utilities/__vmError.cpp > > Print a message in hs_err files > when white box API has been used. > > test/Makefile > > Add a makefile test target for > the white box API test > > test/sanity/wbapi.java > > JTreg test to ensure that the > API works. > > > Thanks > /Mikael Gerdin > > From mikael.gerdin at oracle.com Tue Dec 13 05:48:19 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 13 Dec 2011 14:48:19 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE6F915.7060602@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> Message-ID: <4EE757A3.90803@oracle.com> Thanks Kris and David for the idea! I ran into a small issue with this solution: when compiling the testcase javac can't find wb.jar. If I put wb.jar in jre/lib/ext javac finds it and the test works but I'm not sure if it's Ok to put a jar file in ext on the boot class path behind the back of the extension class loader. Any ideas? /Mikael On 2011-12-13 08:04, David Holmes wrote: > On 13/12/2011 4:48 PM, Krystal Mok wrote: >> Hi Mikael and David, >> >> As an alternative, how about inserting wb.jar into the bootclasspath >> in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is >> enabled, just like the way alt-rt.jar is inserted when >> -XX:+AggressiveOpts is given, in the product JDK 6 and 7? > > And presumably place wb.jar in jre/lib the way alt-rt.jar is. > > That seems like a good suggestion - thanks Kris. > > David > >> - Kris >> >> On Tue, Dec 13, 2011 at 11:16 AM, David Holmes > > wrote: >> >> Hi Mikael, >> >> I see why you are dependent on being loaded by the boot loader, but >> I think using the endorsed mechanism for that is somewhat of a hack >> - this isn't anything to do with being endorsed it is just a way to >> get on the bootclasspath without modifying the bootclasspath. >> >> I'd like to hear what others think of this. >> >> David >> >> >> On 12/12/2011 11:13 PM, Mikael Gerdin wrote: >> >> David, >> >> On 2011-12-11 12:10, David Holmes wrote: >> >> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >> >> On 2011-12-09 05:25, David Holmes wrote: >> >> 2. lib/ext jars have the same permissions as >> bootclasspath, so it >> should >> work to place it there. >> >> >> I tried that first (before even discovering the >> existence of the >> "endorsed" directory) but when I tried it the Whitebox >> class didn't get >> have null as its classloader. >> >> >> Right - lib/ext is loaded by the extensions classloader not the >> bootstraploader. But this is supposed to have as many >> privileges as the >> bootstrap loader: >> >> >> Yes, but does the VM know anything about the ext class loader? >> Is there any way to check from inside the privilege level of a >> class? (I >> suppose I can do some sort of upcall to the JDK to check that but is >> there a shorter way?) >> >> Also, there is one more detail about the boot class loader, see >> below. >> >> >> "By default, installed optional packages in this standard >> directory are >> trusted. That is, they are granted the same privileges as if >> they were >> core platform classes (those in rt.jar). This default >> privilege is >> specified in the system policy file (in >> /jre/lib/security/__java.policy), but can be >> overridden for a >> particular optional package by adding the appropriate policy >> file entry >> (see Permissions in the JDK). >> >> http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html >> >> >> >> >> >> What is it that requires that wb.jar actually be on the >> bootclasspath? >> >> >> In order to avoid adding more changes to nativeLookup.cpp i just >> added >> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >> menttioned in this file. >> >> The current code checks for the null class loader explicitly here: >> 156 Handle loader(THREAD, >> 157 >> instanceKlass::cast(method->__method_holder())->class___loader()); >> 158 if (loader.is_null()) { >> 159 entry = lookup_special_native(jni___name); >> >> I could add another JNINativeMethod array and check for >> "WhiteBox_registerNatives" on all class loaders. >> If we go down this way I would have to verify with my security >> contact >> that he's okay with dropping the boot class loader requirement. >> >> /Mikael >> >> >> Cheers, >> David >> >> Looking at the code in >> src/share/vm/runtime/__arguments.cpp, the class >> SysClassPath claims to be responsible for handling the >> boot class path. >> I don't see any reference to lib/ext there but I'm not >> very familiar >> with how the class loading code actually works. >> >> /Mikael >> >> >> Thanks, >> David >> >> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >> >> Hi David, >> Sorry for the delayed response. >> >> On 2011-12-05 07:18, David Holmes wrote: >> >> Hi Mikael, >> >> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >> >> On 2011-12-02 06:32, David Holmes wrote: >> >> I'm a little confused as to where >> wb.jar ends up when I build >> hotspot. I >> see this in a makefile: >> >> >> There are a couple of issues in these >> make files. >> >> >> 26 WB = wb >> 27 >> 28 WBSRCDIR = >> $(GAMMADIR)/src/share/tools/__whitebox/src >> 29 >> 30 WB_JAR = $(GENERATED)/$(WB).jar >> 31 >> 32 DEST_WB_JAR = >> $(JAVA_HOME)/lib/$(WB_JAR) >> >> Why JAVA_HOME? That's normally a >> binary installation of a JDK used >> for >> building, not somewhere I expect my >> build to try and put something. >> Plus >> the above will expand to: >> >> >> For example, look in jsig.make. It has a >> target that copies >> libjsig to >> JDK_LIBDIR. JDK_LIBDIR is set up in >> vm.make to point to >> JAVA_HOME/jre/lib/[arch]. I was only >> trying to mimic existing >> behavior >> with the "install"-targets in the make >> files. >> >> >> Our build system is somewhat confusing. The >> top-level Defs.make will >> set >> JAVA_HOME based on ABS_BOOTDIR which in turn >> is set by BOOTDIR which >> can >> be overridden by ALT_BOOTDIR. BOOTDIR, >> ALT_BOOTDIR and JAVA_HOME are >> all >> places where the build expects to find an >> executable JDK for >> performing >> build actions like javac compiles, javah etc. >> >> As you point out vm.make then sets >> JDK_LIBDIR based on JAVA_HOME and >> that is used by the install_* targets, which >> are dependencies of the >> vm.make install target. The vm.make install >> target is itself invoked >> from top.make's install target. >> >> So when do these install targets actually >> get used? Other than by a >> developer on the command-line I don't see >> these targets actually >> getting >> used - and they can't be specified as >> targets for the top-level >> Makefile. I suspect these may be relics from >> a time when you would do >> something like: >> >> JAVA_HOME=/my/local/jdk/to/__test/ make >> product1 install >> >> >> You are probably correct. >> Do you want me to modify the make file to more >> closely mimic the >> behavior of the other make files and let the >> legacy "install" target >> stay or do you want me to just not add an >> install target? >> >> >> And if I build a full JDK, where >> does wb.jar end up then? >> >> >> $ find . -name wb.jar >> ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar >> ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar >> >> >> >> >> >> >> >> >> >> The JDK makefiles that build the >> j2{sdk,re}-image directories do not >> pick up the wb.jar file. >> >> >> Ok. So what is the expected build process >> here such that wb is >> available >> for use? Are you expecting the developer to >> do some kind of "make >> install"? >> >> >> This is primarily intended for use together with >> our internal test >> infrastructure (nightly testing etc.). When >> running these tests >> there is >> already a requirement for a JDK to go together >> with a VM that we are >> testing. The same goes for jtreg and the HotSpot >> tests in the test/ >> subdirectory of the HotSpot repository. >> So if you want to run tests on your own VM >> wouldn't you need to use >> something like "make ALT_EXPORT_PATH=/some/jdk >> all_fastdebug" do >> automatically copy your libjvm to a working JDK? >> >> >> >> I also see in make/Makefile: >> >> 370 >> $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: >> $(GEN_DIR)/%.jar >> 371 $(install-file) >> >> Why the endorsed subdirectory? This >> is nothing to do with an >> "endorsed >> standard": >> >> http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ >> >> >> >> Because of security requirements and >> implementation details the >> Whitebox >> class must be available on the boot >> class path. >> Putting the wb.jar file in the endorsed >> directory is a quick and >> easy >> way to achieve that. >> >> >> Why not just in lib? Or perhaps lib/ext? >> endorsed just seems to be >> the >> least appropriate choice here. >> >> >> Because jars in lib/endorsed are automatically >> added to the _boot_ >> class >> path. >> We could put the jar in jre/lib/ext or jre/lib/ >> or just lib/ >> but then all tests using the API would need >> -Xbootclasspath as an >> additional command line flag. >> >> >> And now your usage model has confused me >> because the above export is >> done for JPRT builds - right? So you want >> this to be available in a >> JPRT >> bundle, but not in a full JDK build? >> >> >> Nightly testing runs on bundles generated by >> JPRT, by having the API >> available in those bundles we can have tests >> that use this API in our >> nighly testing. >> If we want to have this API available when doing >> a full JDK build we >> can >> revisit that particular point in the future >> since that would need >> to be >> synchronized with RE as well. >> >> >> Does this clarify your concerns? >> >> >> Not yet :) >> >> >> I'll keep trying then :) >> >> /Mikael >> >> >> Thanks, >> David >> >> /Mikael Gerdin >> >> >> ??? >> >> Thanks, >> David >> ----- >> >> If the VM crashes after this API >> has been accessed a note will be >> written in the hs_err file to >> signal that the API has been used. >> >> Webrev: >> http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ >> >> (thanks to stefank for hosting >> my webrev :) >> >> CR: >> I'll file a CR tomorrow. >> >> Change comments: >> >> make/jprt.properties >> >> Add a test target to make sure >> that the API is available on all >> supported platforms >> >> make/** >> >> Makefile changes to build the >> class sun/hotspot/WhiteBox, put it >> in a >> JAR file and copy it to the >> jre/lib/endorsed directory in the >> export >> targets. >> The BSD makefile changes are not >> tested since I don't have >> access to >> any >> BSD/OSX machine to test them on. >> >> src/share/vm/prims/__nativeLookup.cpp >> >> Special-case the method >> sun/hotspot/WhiteBox/__registerNatives >> and >> link it >> to JVM_RegisterWhiteBoxMethods >> >> src/share/vm/prims/whitebox.* >> >> The implementation of the white >> box API. The actual API functions >> are >> only examples of what we want to >> be able to do using the API. >> >> src/share/vm/runtime/globals.__hpp >> >> Add the command line flag >> >> src/share/vm/utilities/__vmError.cpp >> >> Print a message in hs_err files >> when white box API has been used. >> >> test/Makefile >> >> Add a makefile test target for >> the white box API test >> >> test/sanity/wbapi.java >> >> JTreg test to ensure that the >> API works. >> >> >> Thanks >> /Mikael Gerdin >> >> From stefan.karlsson at oracle.com Tue Dec 13 13:10:50 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 13 Dec 2011 22:10:50 +0100 Subject: Review request (M): 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions In-Reply-To: <4EDF6186.7050704@oracle.com> References: <4EDF6186.7050704@oracle.com> Message-ID: <4EE7BF5A.6030107@oracle.com> Updated patch: http://cr.openjdk.java.net/~stefank/7118863/webrev.02/ The function names and the return types have been changed, to prevent this change from silently breaking ports of HotSpot. The compile.cpp oddity will be fixed before this is pushed. StefanK On 2011-12-07 13:52, Stefan Karlsson wrote: > Please review this REF. > > http://cr.openjdk.java.net/~stefank/7118863/webrev/ > > The main motivation for this patch is to make it easier to merge with > the permgen project. But, IMHO, they also help the code by not having > different ways to go from a klass field offset to an offset against > the klassOopDesc. > > Two things to note about this patch. > 1) There's one place in the code where we don't add > sizeof(klassOopDesc). I maintain this oddity and will leave the > correct fix for a later change. > src/share/vm/opto/compile.cpp > > 2) I have no way to verify the shark changes. > src/share/vm/shark/sharkIntrinsics.cpp > src/share/vm/shark/sharkTopLevelBlock.cpp > > From the RFE: > The *Klass::*_offset_in_bytes() functions are used to get the offset > to a field in a Klass. All places where they are used, we add > something like sizeof(klassOopDesc) to make the offset against the > klassOopDesc instead. > > For example in opto/memnode.cpp: > if (tkls->offset() == Klass::access_flags_offset_in_bytes() + > (int)sizeof(oopDesc)) { > > There's a couple of variants to this: > instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc) > Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc) > Klass::secondary_supers_offset_in_bytes() + > klassOopDesc::header_size() * HeapWordSize > Klass::java_mirror_offset_in_bytes() > klassOopDesc::klass_part_offset_in_bytes() > > The proposal is to move all these size adjustments into the > *Klass:*_offset_in_bytes() functions. From david.holmes at oracle.com Tue Dec 13 16:48:17 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2011 10:48:17 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE757A3.90803@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE757A3.90803@oracle.com> Message-ID: <4EE7F251.7030003@oracle.com> On 13/12/2011 11:48 PM, Mikael Gerdin wrote: > Thanks Kris and David for the idea! > > I ran into a small issue with this solution: > when compiling the testcase javac can't find wb.jar. I think you will need to add wb.jar explicitly to the classpath for javac. Or perhaps use the javac from your VM under test with wb enabled? > If I put wb.jar in jre/lib/ext javac finds it and the test works but I'm > not sure if it's Ok to put a jar file in ext on the boot class path > behind the back of the extension class loader. No I would not do that. David ----- > > Any ideas? > > /Mikael > > On 2011-12-13 08:04, David Holmes wrote: >> On 13/12/2011 4:48 PM, Krystal Mok wrote: >>> Hi Mikael and David, >>> >>> As an alternative, how about inserting wb.jar into the bootclasspath >>> in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is >>> enabled, just like the way alt-rt.jar is inserted when >>> -XX:+AggressiveOpts is given, in the product JDK 6 and 7? >> >> And presumably place wb.jar in jre/lib the way alt-rt.jar is. >> >> That seems like a good suggestion - thanks Kris. >> >> David >> >>> - Kris >>> >>> On Tue, Dec 13, 2011 at 11:16 AM, David Holmes >> > wrote: >>> >>> Hi Mikael, >>> >>> I see why you are dependent on being loaded by the boot loader, but >>> I think using the endorsed mechanism for that is somewhat of a hack >>> - this isn't anything to do with being endorsed it is just a way to >>> get on the bootclasspath without modifying the bootclasspath. >>> >>> I'd like to hear what others think of this. >>> >>> David >>> >>> >>> On 12/12/2011 11:13 PM, Mikael Gerdin wrote: >>> >>> David, >>> >>> On 2011-12-11 12:10, David Holmes wrote: >>> >>> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>> >>> On 2011-12-09 05:25, David Holmes wrote: >>> >>> 2. lib/ext jars have the same permissions as >>> bootclasspath, so it >>> should >>> work to place it there. >>> >>> >>> I tried that first (before even discovering the >>> existence of the >>> "endorsed" directory) but when I tried it the Whitebox >>> class didn't get >>> have null as its classloader. >>> >>> >>> Right - lib/ext is loaded by the extensions classloader not the >>> bootstraploader. But this is supposed to have as many >>> privileges as the >>> bootstrap loader: >>> >>> >>> Yes, but does the VM know anything about the ext class loader? >>> Is there any way to check from inside the privilege level of a >>> class? (I >>> suppose I can do some sort of upcall to the JDK to check that but is >>> there a shorter way?) >>> >>> Also, there is one more detail about the boot class loader, see >>> below. >>> >>> >>> "By default, installed optional packages in this standard >>> directory are >>> trusted. That is, they are granted the same privileges as if >>> they were >>> core platform classes (those in rt.jar). This default >>> privilege is >>> specified in the system policy file (in >>> /jre/lib/security/__java.policy), but can be >>> overridden for a >>> particular optional package by adding the appropriate policy >>> file entry >>> (see Permissions in the JDK). >>> >>> http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html >>> >>> >>> >>> >>> >>> >>> >>> What is it that requires that wb.jar actually be on the >>> bootclasspath? >>> >>> >>> In order to avoid adding more changes to nativeLookup.cpp i just >>> added >>> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >>> menttioned in this file. >>> >>> The current code checks for the null class loader explicitly here: >>> 156 Handle loader(THREAD, >>> 157 >>> instanceKlass::cast(method->__method_holder())->class___loader()); >>> 158 if (loader.is_null()) { >>> 159 entry = lookup_special_native(jni___name); >>> >>> I could add another JNINativeMethod array and check for >>> "WhiteBox_registerNatives" on all class loaders. >>> If we go down this way I would have to verify with my security >>> contact >>> that he's okay with dropping the boot class loader requirement. >>> >>> /Mikael >>> >>> >>> Cheers, >>> David >>> >>> Looking at the code in >>> src/share/vm/runtime/__arguments.cpp, the class >>> SysClassPath claims to be responsible for handling the >>> boot class path. >>> I don't see any reference to lib/ext there but I'm not >>> very familiar >>> with how the class loading code actually works. >>> >>> /Mikael >>> >>> >>> Thanks, >>> David >>> >>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>> >>> Hi David, >>> Sorry for the delayed response. >>> >>> On 2011-12-05 07:18, David Holmes wrote: >>> >>> Hi Mikael, >>> >>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>> >>> On 2011-12-02 06:32, David Holmes wrote: >>> >>> I'm a little confused as to where >>> wb.jar ends up when I build >>> hotspot. I >>> see this in a makefile: >>> >>> >>> There are a couple of issues in these >>> make files. >>> >>> >>> 26 WB = wb >>> 27 >>> 28 WBSRCDIR = >>> $(GAMMADIR)/src/share/tools/__whitebox/src >>> 29 >>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>> 31 >>> 32 DEST_WB_JAR = >>> $(JAVA_HOME)/lib/$(WB_JAR) >>> >>> Why JAVA_HOME? That's normally a >>> binary installation of a JDK used >>> for >>> building, not somewhere I expect my >>> build to try and put something. >>> Plus >>> the above will expand to: >>> >>> >>> For example, look in jsig.make. It has a >>> target that copies >>> libjsig to >>> JDK_LIBDIR. JDK_LIBDIR is set up in >>> vm.make to point to >>> JAVA_HOME/jre/lib/[arch]. I was only >>> trying to mimic existing >>> behavior >>> with the "install"-targets in the make >>> files. >>> >>> >>> Our build system is somewhat confusing. The >>> top-level Defs.make will >>> set >>> JAVA_HOME based on ABS_BOOTDIR which in turn >>> is set by BOOTDIR which >>> can >>> be overridden by ALT_BOOTDIR. BOOTDIR, >>> ALT_BOOTDIR and JAVA_HOME are >>> all >>> places where the build expects to find an >>> executable JDK for >>> performing >>> build actions like javac compiles, javah etc. >>> >>> As you point out vm.make then sets >>> JDK_LIBDIR based on JAVA_HOME and >>> that is used by the install_* targets, which >>> are dependencies of the >>> vm.make install target. The vm.make install >>> target is itself invoked >>> from top.make's install target. >>> >>> So when do these install targets actually >>> get used? Other than by a >>> developer on the command-line I don't see >>> these targets actually >>> getting >>> used - and they can't be specified as >>> targets for the top-level >>> Makefile. I suspect these may be relics from >>> a time when you would do >>> something like: >>> >>> JAVA_HOME=/my/local/jdk/to/__test/ make >>> product1 install >>> >>> >>> You are probably correct. >>> Do you want me to modify the make file to more >>> closely mimic the >>> behavior of the other make files and let the >>> legacy "install" target >>> stay or do you want me to just not add an >>> install target? >>> >>> >>> And if I build a full JDK, where >>> does wb.jar end up then? >>> >>> >>> $ find . -name wb.jar >>> ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar >>> ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The JDK makefiles that build the >>> j2{sdk,re}-image directories do not >>> pick up the wb.jar file. >>> >>> >>> Ok. So what is the expected build process >>> here such that wb is >>> available >>> for use? Are you expecting the developer to >>> do some kind of "make >>> install"? >>> >>> >>> This is primarily intended for use together with >>> our internal test >>> infrastructure (nightly testing etc.). When >>> running these tests >>> there is >>> already a requirement for a JDK to go together >>> with a VM that we are >>> testing. The same goes for jtreg and the HotSpot >>> tests in the test/ >>> subdirectory of the HotSpot repository. >>> So if you want to run tests on your own VM >>> wouldn't you need to use >>> something like "make ALT_EXPORT_PATH=/some/jdk >>> all_fastdebug" do >>> automatically copy your libjvm to a working JDK? >>> >>> >>> >>> I also see in make/Makefile: >>> >>> 370 >>> $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: >>> $(GEN_DIR)/%.jar >>> 371 $(install-file) >>> >>> Why the endorsed subdirectory? This >>> is nothing to do with an >>> "endorsed >>> standard": >>> >>> http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ >>> >>> >>> >>> Because of security requirements and >>> implementation details the >>> Whitebox >>> class must be available on the boot >>> class path. >>> Putting the wb.jar file in the endorsed >>> directory is a quick and >>> easy >>> way to achieve that. >>> >>> >>> Why not just in lib? Or perhaps lib/ext? >>> endorsed just seems to be >>> the >>> least appropriate choice here. >>> >>> >>> Because jars in lib/endorsed are automatically >>> added to the _boot_ >>> class >>> path. >>> We could put the jar in jre/lib/ext or jre/lib/ >>> or just lib/ >>> but then all tests using the API would need >>> -Xbootclasspath as an >>> additional command line flag. >>> >>> >>> And now your usage model has confused me >>> because the above export is >>> done for JPRT builds - right? So you want >>> this to be available in a >>> JPRT >>> bundle, but not in a full JDK build? >>> >>> >>> Nightly testing runs on bundles generated by >>> JPRT, by having the API >>> available in those bundles we can have tests >>> that use this API in our >>> nighly testing. >>> If we want to have this API available when doing >>> a full JDK build we >>> can >>> revisit that particular point in the future >>> since that would need >>> to be >>> synchronized with RE as well. >>> >>> >>> Does this clarify your concerns? >>> >>> >>> Not yet :) >>> >>> >>> I'll keep trying then :) >>> >>> /Mikael >>> >>> >>> Thanks, >>> David >>> >>> /Mikael Gerdin >>> >>> >>> ??? >>> >>> Thanks, >>> David >>> ----- >>> >>> If the VM crashes after this API >>> has been accessed a note will be >>> written in the hs_err file to >>> signal that the API has been used. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ >>> >>> (thanks to stefank for hosting >>> my webrev :) >>> >>> CR: >>> I'll file a CR tomorrow. >>> >>> Change comments: >>> >>> make/jprt.properties >>> >>> Add a test target to make sure >>> that the API is available on all >>> supported platforms >>> >>> make/** >>> >>> Makefile changes to build the >>> class sun/hotspot/WhiteBox, put it >>> in a >>> JAR file and copy it to the >>> jre/lib/endorsed directory in the >>> export >>> targets. >>> The BSD makefile changes are not >>> tested since I don't have >>> access to >>> any >>> BSD/OSX machine to test them on. >>> >>> src/share/vm/prims/__nativeLookup.cpp >>> >>> Special-case the method >>> sun/hotspot/WhiteBox/__registerNatives >>> and >>> link it >>> to JVM_RegisterWhiteBoxMethods >>> >>> src/share/vm/prims/whitebox.* >>> >>> The implementation of the white >>> box API. The actual API functions >>> are >>> only examples of what we want to >>> be able to do using the API. >>> >>> src/share/vm/runtime/globals.__hpp >>> >>> Add the command line flag >>> >>> src/share/vm/utilities/__vmError.cpp >>> >>> Print a message in hs_err files >>> when white box API has been used. >>> >>> test/Makefile >>> >>> Add a makefile test target for >>> the white box API test >>> >>> test/sanity/wbapi.java >>> >>> JTreg test to ensure that the >>> API works. >>> >>> >>> Thanks >>> /Mikael Gerdin >>> >>> From john.pampuch at oracle.com Tue Dec 13 17:42:46 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Tue, 13 Dec 2011 17:42:46 -0800 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE6F915.7060602@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> Message-ID: <4EE7FF16.9030107@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111213/d5c24f4e/attachment-0001.html From jon.masamitsu at oracle.com Tue Dec 13 19:36:34 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 14 Dec 2011 03:36:34 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7119584: UseParallelGC barrier task can be overwritten. Message-ID: <20111214033640.630E8476A4@hg.openjdk.java.net> Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d7d0790074d 7119584: UseParallelGC barrier task can be overwritten. Summary: Provoke a GC for a metadata allocation failure. Reviewed-by: johnc, iveresov ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp From joe.darcy at oracle.com Tue Dec 13 20:25:49 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 13 Dec 2011 20:25:49 -0800 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE757A3.90803@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE757A3.90803@oracle.com> Message-ID: <4EE8254D.6090206@oracle.com> Hello, On 12/13/2011 5:48 AM, Mikael Gerdin wrote: > Thanks Kris and David for the idea! > > I ran into a small issue with this solution: > when compiling the testcase javac can't find wb.jar. > > If I put wb.jar in jre/lib/ext javac finds it and the test works but > I'm not sure if it's Ok to put a jar file in ext on the boot class > path behind the back of the extension class loader. > > Any ideas? I believe this effort would be simplified if the new types were unconditionally available in the JDK and not available depending on build variations. The endorsed standards mechanism is meant for other, very specific purposes [1]. For a more general discussion about how the full logical classpath is constructed in different settings see [2] and [3]. -Joe [1] http://docs.oracle.com/javase/7/docs/technotes/guides/standards/index.html [2] http://blogs.oracle.com/darcy/entry/pick_a_path_any_path1 [3] http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html > > /Mikael > > On 2011-12-13 08:04, David Holmes wrote: >> On 13/12/2011 4:48 PM, Krystal Mok wrote: >>> Hi Mikael and David, >>> >>> As an alternative, how about inserting wb.jar into the bootclasspath >>> in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is >>> enabled, just like the way alt-rt.jar is inserted when >>> -XX:+AggressiveOpts is given, in the product JDK 6 and 7? >> >> And presumably place wb.jar in jre/lib the way alt-rt.jar is. >> >> That seems like a good suggestion - thanks Kris. >> >> David >> >>> - Kris >>> >>> On Tue, Dec 13, 2011 at 11:16 AM, David Holmes >> > wrote: >>> >>> Hi Mikael, >>> >>> I see why you are dependent on being loaded by the boot loader, but >>> I think using the endorsed mechanism for that is somewhat of a hack >>> - this isn't anything to do with being endorsed it is just a way to >>> get on the bootclasspath without modifying the bootclasspath. >>> >>> I'd like to hear what others think of this. >>> >>> David >>> >>> >>> On 12/12/2011 11:13 PM, Mikael Gerdin wrote: >>> >>> David, >>> >>> On 2011-12-11 12:10, David Holmes wrote: >>> >>> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>> >>> On 2011-12-09 05:25, David Holmes wrote: >>> >>> 2. lib/ext jars have the same permissions as >>> bootclasspath, so it >>> should >>> work to place it there. >>> >>> >>> I tried that first (before even discovering the >>> existence of the >>> "endorsed" directory) but when I tried it the Whitebox >>> class didn't get >>> have null as its classloader. >>> >>> >>> Right - lib/ext is loaded by the extensions classloader not the >>> bootstraploader. But this is supposed to have as many >>> privileges as the >>> bootstrap loader: >>> >>> >>> Yes, but does the VM know anything about the ext class loader? >>> Is there any way to check from inside the privilege level of a >>> class? (I >>> suppose I can do some sort of upcall to the JDK to check that but is >>> there a shorter way?) >>> >>> Also, there is one more detail about the boot class loader, see >>> below. >>> >>> >>> "By default, installed optional packages in this standard >>> directory are >>> trusted. That is, they are granted the same privileges as if >>> they were >>> core platform classes (those in rt.jar). This default >>> privilege is >>> specified in the system policy file (in >>> /jre/lib/security/__java.policy), but can be >>> overridden for a >>> particular optional package by adding the appropriate policy >>> file entry >>> (see Permissions in the JDK). >>> >>> http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html >>> >>> >>> >>> >>> >>> >>> >>> What is it that requires that wb.jar actually be on the >>> bootclasspath? >>> >>> >>> In order to avoid adding more changes to nativeLookup.cpp i just >>> added >>> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >>> menttioned in this file. >>> >>> The current code checks for the null class loader explicitly here: >>> 156 Handle loader(THREAD, >>> 157 >>> instanceKlass::cast(method->__method_holder())->class___loader()); >>> 158 if (loader.is_null()) { >>> 159 entry = lookup_special_native(jni___name); >>> >>> I could add another JNINativeMethod array and check for >>> "WhiteBox_registerNatives" on all class loaders. >>> If we go down this way I would have to verify with my security >>> contact >>> that he's okay with dropping the boot class loader requirement. >>> >>> /Mikael >>> >>> >>> Cheers, >>> David >>> >>> Looking at the code in >>> src/share/vm/runtime/__arguments.cpp, the class >>> SysClassPath claims to be responsible for handling the >>> boot class path. >>> I don't see any reference to lib/ext there but I'm not >>> very familiar >>> with how the class loading code actually works. >>> >>> /Mikael >>> >>> >>> Thanks, >>> David >>> >>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>> >>> Hi David, >>> Sorry for the delayed response. >>> >>> On 2011-12-05 07:18, David Holmes wrote: >>> >>> Hi Mikael, >>> >>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>> >>> On 2011-12-02 06:32, David Holmes wrote: >>> >>> I'm a little confused as to where >>> wb.jar ends up when I build >>> hotspot. I >>> see this in a makefile: >>> >>> >>> There are a couple of issues in these >>> make files. >>> >>> >>> 26 WB = wb >>> 27 >>> 28 WBSRCDIR = >>> $(GAMMADIR)/src/share/tools/__whitebox/src >>> 29 >>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>> 31 >>> 32 DEST_WB_JAR = >>> $(JAVA_HOME)/lib/$(WB_JAR) >>> >>> Why JAVA_HOME? That's normally a >>> binary installation of a JDK used >>> for >>> building, not somewhere I expect my >>> build to try and put something. >>> Plus >>> the above will expand to: >>> >>> >>> For example, look in jsig.make. It has a >>> target that copies >>> libjsig to >>> JDK_LIBDIR. JDK_LIBDIR is set up in >>> vm.make to point to >>> JAVA_HOME/jre/lib/[arch]. I was only >>> trying to mimic existing >>> behavior >>> with the "install"-targets in the make >>> files. >>> >>> >>> Our build system is somewhat confusing. The >>> top-level Defs.make will >>> set >>> JAVA_HOME based on ABS_BOOTDIR which in turn >>> is set by BOOTDIR which >>> can >>> be overridden by ALT_BOOTDIR. BOOTDIR, >>> ALT_BOOTDIR and JAVA_HOME are >>> all >>> places where the build expects to find an >>> executable JDK for >>> performing >>> build actions like javac compiles, javah etc. >>> >>> As you point out vm.make then sets >>> JDK_LIBDIR based on JAVA_HOME and >>> that is used by the install_* targets, which >>> are dependencies of the >>> vm.make install target. The vm.make install >>> target is itself invoked >>> from top.make's install target. >>> >>> So when do these install targets actually >>> get used? Other than by a >>> developer on the command-line I don't see >>> these targets actually >>> getting >>> used - and they can't be specified as >>> targets for the top-level >>> Makefile. I suspect these may be relics from >>> a time when you would do >>> something like: >>> >>> JAVA_HOME=/my/local/jdk/to/__test/ make >>> product1 install >>> >>> >>> You are probably correct. >>> Do you want me to modify the make file to more >>> closely mimic the >>> behavior of the other make files and let the >>> legacy "install" target >>> stay or do you want me to just not add an >>> install target? >>> >>> >>> And if I build a full JDK, where >>> does wb.jar end up then? >>> >>> >>> $ find . -name wb.jar >>> ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar >>> ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The JDK makefiles that build the >>> j2{sdk,re}-image directories do not >>> pick up the wb.jar file. >>> >>> >>> Ok. So what is the expected build process >>> here such that wb is >>> available >>> for use? Are you expecting the developer to >>> do some kind of "make >>> install"? >>> >>> >>> This is primarily intended for use together with >>> our internal test >>> infrastructure (nightly testing etc.). When >>> running these tests >>> there is >>> already a requirement for a JDK to go together >>> with a VM that we are >>> testing. The same goes for jtreg and the HotSpot >>> tests in the test/ >>> subdirectory of the HotSpot repository. >>> So if you want to run tests on your own VM >>> wouldn't you need to use >>> something like "make ALT_EXPORT_PATH=/some/jdk >>> all_fastdebug" do >>> automatically copy your libjvm to a working JDK? >>> >>> >>> >>> I also see in make/Makefile: >>> >>> 370 >>> $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: >>> $(GEN_DIR)/%.jar >>> 371 $(install-file) >>> >>> Why the endorsed subdirectory? This >>> is nothing to do with an >>> "endorsed >>> standard": >>> >>> http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ >>> >>> >>> >>> Because of security requirements and >>> implementation details the >>> Whitebox >>> class must be available on the boot >>> class path. >>> Putting the wb.jar file in the endorsed >>> directory is a quick and >>> easy >>> way to achieve that. >>> >>> >>> Why not just in lib? Or perhaps lib/ext? >>> endorsed just seems to be >>> the >>> least appropriate choice here. >>> >>> >>> Because jars in lib/endorsed are automatically >>> added to the _boot_ >>> class >>> path. >>> We could put the jar in jre/lib/ext or jre/lib/ >>> or just lib/ >>> but then all tests using the API would need >>> -Xbootclasspath as an >>> additional command line flag. >>> >>> >>> And now your usage model has confused me >>> because the above export is >>> done for JPRT builds - right? So you want >>> this to be available in a >>> JPRT >>> bundle, but not in a full JDK build? >>> >>> >>> Nightly testing runs on bundles generated by >>> JPRT, by having the API >>> available in those bundles we can have tests >>> that use this API in our >>> nighly testing. >>> If we want to have this API available when doing >>> a full JDK build we >>> can >>> revisit that particular point in the future >>> since that would need >>> to be >>> synchronized with RE as well. >>> >>> >>> Does this clarify your concerns? >>> >>> >>> Not yet :) >>> >>> >>> I'll keep trying then :) >>> >>> /Mikael >>> >>> >>> Thanks, >>> David >>> >>> /Mikael Gerdin >>> >>> >>> ??? >>> >>> Thanks, >>> David >>> ----- >>> >>> If the VM crashes after this API >>> has been accessed a note will be >>> written in the hs_err file to >>> signal that the API has been used. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ >>> >>> (thanks to stefank for hosting >>> my webrev :) >>> >>> CR: >>> I'll file a CR tomorrow. >>> >>> Change comments: >>> >>> make/jprt.properties >>> >>> Add a test target to make sure >>> that the API is available on all >>> supported platforms >>> >>> make/** >>> >>> Makefile changes to build the >>> class sun/hotspot/WhiteBox, put it >>> in a >>> JAR file and copy it to the >>> jre/lib/endorsed directory in the >>> export >>> targets. >>> The BSD makefile changes are not >>> tested since I don't have >>> access to >>> any >>> BSD/OSX machine to test them on. >>> >>> src/share/vm/prims/__nativeLookup.cpp >>> >>> Special-case the method >>> sun/hotspot/WhiteBox/__registerNatives >>> and >>> link it >>> to JVM_RegisterWhiteBoxMethods >>> >>> src/share/vm/prims/whitebox.* >>> >>> The implementation of the white >>> box API. The actual API functions >>> are >>> only examples of what we want to >>> be able to do using the API. >>> >>> src/share/vm/runtime/globals.__hpp >>> >>> Add the command line flag >>> >>> src/share/vm/utilities/__vmError.cpp >>> >>> Print a message in hs_err files >>> when white box API has been used. >>> >>> test/Makefile >>> >>> Add a makefile test target for >>> the white box API test >>> >>> test/sanity/wbapi.java >>> >>> JTreg test to ensure that the >>> API works. >>> >>> >>> Thanks >>> /Mikael Gerdin >>> >>> From mikael.gerdin at oracle.com Wed Dec 14 00:46:38 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 14 Dec 2011 09:46:38 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE7FF16.9030107@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE7FF16.9030107@oracle.com> Message-ID: <4EE8626E.2020507@oracle.com> I think they will, hopefully they will make this easier. /Mikael On 2011-12-14 02:42, John Pampuch wrote: > Will the modularity changes coming in JDK 8 affect this? > > -John > > On 12/12/11 11:04 PM, David Holmes wrote: >> On 13/12/2011 4:48 PM, Krystal Mok wrote: >>> Hi Mikael and David, >>> >>> As an alternative, how about inserting wb.jar into the bootclasspath >>> in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is >>> enabled, just like the way alt-rt.jar is inserted when >>> -XX:+AggressiveOpts is given, in the product JDK 6 and 7? >> >> And presumably place wb.jar in jre/lib the way alt-rt.jar is. >> >> That seems like a good suggestion - thanks Kris. >> >> David >> >>> - Kris >>> >>> On Tue, Dec 13, 2011 at 11:16 AM, David Holmes >> > wrote: >>> >>> Hi Mikael, >>> >>> I see why you are dependent on being loaded by the boot loader, but >>> I think using the endorsed mechanism for that is somewhat of a hack >>> - this isn't anything to do with being endorsed it is just a way to >>> get on the bootclasspath without modifying the bootclasspath. >>> >>> I'd like to hear what others think of this. >>> >>> David >>> >>> >>> On 12/12/2011 11:13 PM, Mikael Gerdin wrote: >>> >>> David, >>> >>> On 2011-12-11 12:10, David Holmes wrote: >>> >>> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>> >>> On 2011-12-09 05:25, David Holmes wrote: >>> >>> 2. lib/ext jars have the same permissions as >>> bootclasspath, so it >>> should >>> work to place it there. >>> >>> >>> I tried that first (before even discovering the >>> existence of the >>> "endorsed" directory) but when I tried it the Whitebox >>> class didn't get >>> have null as its classloader. >>> >>> >>> Right - lib/ext is loaded by the extensions classloader not the >>> bootstraploader. But this is supposed to have as many >>> privileges as the >>> bootstrap loader: >>> >>> >>> Yes, but does the VM know anything about the ext class loader? >>> Is there any way to check from inside the privilege level of a >>> class? (I >>> suppose I can do some sort of upcall to the JDK to check that but is >>> there a shorter way?) >>> >>> Also, there is one more detail about the boot class loader, see >>> below. >>> >>> >>> "By default, installed optional packages in this standard >>> directory are >>> trusted. That is, they are granted the same privileges as if >>> they were >>> core platform classes (those in rt.jar). This default >>> privilege is >>> specified in the system policy file (in >>> /jre/lib/security/__java.policy), but can be >>> overridden for a >>> particular optional package by adding the appropriate policy >>> file entry >>> (see Permissions in the JDK). >>> >>> http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html >>> >>> >>> >>> What is it that requires that wb.jar actually be on the >>> bootclasspath? >>> >>> >>> In order to avoid adding more changes to nativeLookup.cpp i just >>> added >>> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >>> menttioned in this file. >>> >>> The current code checks for the null class loader explicitly here: >>> 156 Handle loader(THREAD, >>> 157 >>> instanceKlass::cast(method->__method_holder())->class___loader()); >>> 158 if (loader.is_null()) { >>> 159 entry = lookup_special_native(jni___name); >>> >>> I could add another JNINativeMethod array and check for >>> "WhiteBox_registerNatives" on all class loaders. >>> If we go down this way I would have to verify with my security >>> contact >>> that he's okay with dropping the boot class loader requirement. >>> >>> /Mikael >>> >>> >>> Cheers, >>> David >>> >>> Looking at the code in >>> src/share/vm/runtime/__arguments.cpp, the class >>> SysClassPath claims to be responsible for handling the >>> boot class path. >>> I don't see any reference to lib/ext there but I'm not >>> very familiar >>> with how the class loading code actually works. >>> >>> /Mikael >>> >>> >>> Thanks, >>> David >>> >>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>> >>> Hi David, >>> Sorry for the delayed response. >>> >>> On 2011-12-05 07:18, David Holmes wrote: >>> >>> Hi Mikael, >>> >>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>> >>> On 2011-12-02 06:32, David Holmes wrote: >>> >>> I'm a little confused as to where >>> wb.jar ends up when I build >>> hotspot. I >>> see this in a makefile: >>> >>> >>> There are a couple of issues in these >>> make files. >>> >>> >>> 26 WB = wb >>> 27 >>> 28 WBSRCDIR = >>> $(GAMMADIR)/src/share/tools/__whitebox/src >>> 29 >>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>> 31 >>> 32 DEST_WB_JAR = >>> $(JAVA_HOME)/lib/$(WB_JAR) >>> >>> Why JAVA_HOME? That's normally a >>> binary installation of a JDK used >>> for >>> building, not somewhere I expect my >>> build to try and put something. >>> Plus >>> the above will expand to: >>> >>> >>> For example, look in jsig.make. It has a >>> target that copies >>> libjsig to >>> JDK_LIBDIR. JDK_LIBDIR is set up in >>> vm.make to point to >>> JAVA_HOME/jre/lib/[arch]. I was only >>> trying to mimic existing >>> behavior >>> with the "install"-targets in the make >>> files. >>> >>> >>> Our build system is somewhat confusing. The >>> top-level Defs.make will >>> set >>> JAVA_HOME based on ABS_BOOTDIR which in turn >>> is set by BOOTDIR which >>> can >>> be overridden by ALT_BOOTDIR. BOOTDIR, >>> ALT_BOOTDIR and JAVA_HOME are >>> all >>> places where the build expects to find an >>> executable JDK for >>> performing >>> build actions like javac compiles, javah etc. >>> >>> As you point out vm.make then sets >>> JDK_LIBDIR based on JAVA_HOME and >>> that is used by the install_* targets, which >>> are dependencies of the >>> vm.make install target. The vm.make install >>> target is itself invoked >>> from top.make's install target. >>> >>> So when do these install targets actually >>> get used? Other than by a >>> developer on the command-line I don't see >>> these targets actually >>> getting >>> used - and they can't be specified as >>> targets for the top-level >>> Makefile. I suspect these may be relics from >>> a time when you would do >>> something like: >>> >>> JAVA_HOME=/my/local/jdk/to/__test/ make >>> product1 install >>> >>> >>> You are probably correct. >>> Do you want me to modify the make file to more >>> closely mimic the >>> behavior of the other make files and let the >>> legacy "install" target >>> stay or do you want me to just not add an >>> install target? >>> >>> >>> And if I build a full JDK, where >>> does wb.jar end up then? >>> >>> >>> $ find . -name wb.jar >>> ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar >>> ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar >>> >>> >>> >>> >>> >>> >>> >>> >>> The JDK makefiles that build the >>> j2{sdk,re}-image directories do not >>> pick up the wb.jar file. >>> >>> >>> Ok. So what is the expected build process >>> here such that wb is >>> available >>> for use? Are you expecting the developer to >>> do some kind of "make >>> install"? >>> >>> >>> This is primarily intended for use together with >>> our internal test >>> infrastructure (nightly testing etc.). When >>> running these tests >>> there is >>> already a requirement for a JDK to go together >>> with a VM that we are >>> testing. The same goes for jtreg and the HotSpot >>> tests in the test/ >>> subdirectory of the HotSpot repository. >>> So if you want to run tests on your own VM >>> wouldn't you need to use >>> something like "make ALT_EXPORT_PATH=/some/jdk >>> all_fastdebug" do >>> automatically copy your libjvm to a working JDK? >>> >>> >>> >>> I also see in make/Makefile: >>> >>> 370 >>> $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: >>> $(GEN_DIR)/%.jar >>> 371 $(install-file) >>> >>> Why the endorsed subdirectory? This >>> is nothing to do with an >>> "endorsed >>> standard": >>> >>> http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ >>> >>> >>> >>> Because of security requirements and >>> implementation details the >>> Whitebox >>> class must be available on the boot >>> class path. >>> Putting the wb.jar file in the endorsed >>> directory is a quick and >>> easy >>> way to achieve that. >>> >>> >>> Why not just in lib? Or perhaps lib/ext? >>> endorsed just seems to be >>> the >>> least appropriate choice here. >>> >>> >>> Because jars in lib/endorsed are automatically >>> added to the _boot_ >>> class >>> path. >>> We could put the jar in jre/lib/ext or jre/lib/ >>> or just lib/ >>> but then all tests using the API would need >>> -Xbootclasspath as an >>> additional command line flag. >>> >>> >>> And now your usage model has confused me >>> because the above export is >>> done for JPRT builds - right? So you want >>> this to be available in a >>> JPRT >>> bundle, but not in a full JDK build? >>> >>> >>> Nightly testing runs on bundles generated by >>> JPRT, by having the API >>> available in those bundles we can have tests >>> that use this API in our >>> nighly testing. >>> If we want to have this API available when doing >>> a full JDK build we >>> can >>> revisit that particular point in the future >>> since that would need >>> to be >>> synchronized with RE as well. >>> >>> >>> Does this clarify your concerns? >>> >>> >>> Not yet :) >>> >>> >>> I'll keep trying then :) >>> >>> /Mikael >>> >>> >>> Thanks, >>> David >>> >>> /Mikael Gerdin >>> >>> >>> ??? >>> >>> Thanks, >>> David >>> ----- >>> >>> If the VM crashes after this API >>> has been accessed a note will be >>> written in the hs_err file to >>> signal that the API has been used. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ >>> >>> (thanks to stefank for hosting >>> my webrev :) >>> >>> CR: >>> I'll file a CR tomorrow. >>> >>> Change comments: >>> >>> make/jprt.properties >>> >>> Add a test target to make sure >>> that the API is available on all >>> supported platforms >>> >>> make/** >>> >>> Makefile changes to build the >>> class sun/hotspot/WhiteBox, put it >>> in a >>> JAR file and copy it to the >>> jre/lib/endorsed directory in the >>> export >>> targets. >>> The BSD makefile changes are not >>> tested since I don't have >>> access to >>> any >>> BSD/OSX machine to test them on. >>> >>> src/share/vm/prims/__nativeLookup.cpp >>> >>> Special-case the method >>> sun/hotspot/WhiteBox/__registerNatives >>> and >>> link it >>> to JVM_RegisterWhiteBoxMethods >>> >>> src/share/vm/prims/whitebox.* >>> >>> The implementation of the white >>> box API. The actual API functions >>> are >>> only examples of what we want to >>> be able to do using the API. >>> >>> src/share/vm/runtime/globals.__hpp >>> >>> Add the command line flag >>> >>> src/share/vm/utilities/__vmError.cpp >>> >>> Print a message in hs_err files >>> when white box API has been used. >>> >>> test/Makefile >>> >>> Add a makefile test target for >>> the white box API test >>> >>> test/sanity/wbapi.java >>> >>> JTreg test to ensure that the >>> API works. >>> >>> >>> Thanks >>> /Mikael Gerdin >>> >>> From mikael.gerdin at oracle.com Wed Dec 14 04:18:01 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 14 Dec 2011 13:18:01 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE7F251.7030003@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE757A3.90803@oracle.com> <4EE7F251.7030003@oracle.com> Message-ID: <4EE893F9.8010205@oracle.com> On 2011-12-14 01:48, David Holmes wrote: > On 13/12/2011 11:48 PM, Mikael Gerdin wrote: >> Thanks Kris and David for the idea! >> >> I ran into a small issue with this solution: >> when compiling the testcase javac can't find wb.jar. > > I think you will need to add wb.jar explicitly to the classpath for > javac. Or perhaps use the javac from your VM under test with wb enabled? Yes. What I meant was that javac won't _automatically_ find the WhiteBox class as it does if I put the jar file in ext/ or endorsed/ I changed the jtreg test to use: * @run compile -J-XX:+UnlockDiagnosticVMOptions -J-XX:+WhiteBoxAPI wbapi.java * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI wbapi but it's a bit ugly imo. I'd rather have it work automatically but since there doesn't seem to be a good way to do that I'll have to settle with this. /Mikael > >> If I put wb.jar in jre/lib/ext javac finds it and the test works but I'm >> not sure if it's Ok to put a jar file in ext on the boot class path >> behind the back of the extension class loader. > > No I would not do that. > > David > ----- >> >> Any ideas? >> >> /Mikael >> >> On 2011-12-13 08:04, David Holmes wrote: >>> On 13/12/2011 4:48 PM, Krystal Mok wrote: >>>> Hi Mikael and David, >>>> >>>> As an alternative, how about inserting wb.jar into the bootclasspath >>>> in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is >>>> enabled, just like the way alt-rt.jar is inserted when >>>> -XX:+AggressiveOpts is given, in the product JDK 6 and 7? >>> >>> And presumably place wb.jar in jre/lib the way alt-rt.jar is. >>> >>> That seems like a good suggestion - thanks Kris. >>> >>> David >>> >>>> - Kris >>>> >>>> On Tue, Dec 13, 2011 at 11:16 AM, David Holmes >>> > wrote: >>>> >>>> Hi Mikael, >>>> >>>> I see why you are dependent on being loaded by the boot loader, but >>>> I think using the endorsed mechanism for that is somewhat of a hack >>>> - this isn't anything to do with being endorsed it is just a way to >>>> get on the bootclasspath without modifying the bootclasspath. >>>> >>>> I'd like to hear what others think of this. >>>> >>>> David >>>> >>>> >>>> On 12/12/2011 11:13 PM, Mikael Gerdin wrote: >>>> >>>> David, >>>> >>>> On 2011-12-11 12:10, David Holmes wrote: >>>> >>>> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>>> >>>> On 2011-12-09 05:25, David Holmes wrote: >>>> >>>> 2. lib/ext jars have the same permissions as >>>> bootclasspath, so it >>>> should >>>> work to place it there. >>>> >>>> >>>> I tried that first (before even discovering the >>>> existence of the >>>> "endorsed" directory) but when I tried it the Whitebox >>>> class didn't get >>>> have null as its classloader. >>>> >>>> >>>> Right - lib/ext is loaded by the extensions classloader not the >>>> bootstraploader. But this is supposed to have as many >>>> privileges as the >>>> bootstrap loader: >>>> >>>> >>>> Yes, but does the VM know anything about the ext class loader? >>>> Is there any way to check from inside the privilege level of a >>>> class? (I >>>> suppose I can do some sort of upcall to the JDK to check that but is >>>> there a shorter way?) >>>> >>>> Also, there is one more detail about the boot class loader, see >>>> below. >>>> >>>> >>>> "By default, installed optional packages in this standard >>>> directory are >>>> trusted. That is, they are granted the same privileges as if >>>> they were >>>> core platform classes (those in rt.jar). This default >>>> privilege is >>>> specified in the system policy file (in >>>> /jre/lib/security/__java.policy), but can be >>>> overridden for a >>>> particular optional package by adding the appropriate policy >>>> file entry >>>> (see Permissions in the JDK). >>>> >>>> http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> What is it that requires that wb.jar actually be on the >>>> bootclasspath? >>>> >>>> >>>> In order to avoid adding more changes to nativeLookup.cpp i just >>>> added >>>> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >>>> menttioned in this file. >>>> >>>> The current code checks for the null class loader explicitly here: >>>> 156 Handle loader(THREAD, >>>> 157 >>>> instanceKlass::cast(method->__method_holder())->class___loader()); >>>> 158 if (loader.is_null()) { >>>> 159 entry = lookup_special_native(jni___name); >>>> >>>> I could add another JNINativeMethod array and check for >>>> "WhiteBox_registerNatives" on all class loaders. >>>> If we go down this way I would have to verify with my security >>>> contact >>>> that he's okay with dropping the boot class loader requirement. >>>> >>>> /Mikael >>>> >>>> >>>> Cheers, >>>> David >>>> >>>> Looking at the code in >>>> src/share/vm/runtime/__arguments.cpp, the class >>>> SysClassPath claims to be responsible for handling the >>>> boot class path. >>>> I don't see any reference to lib/ext there but I'm not >>>> very familiar >>>> with how the class loading code actually works. >>>> >>>> /Mikael >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>>> >>>> Hi David, >>>> Sorry for the delayed response. >>>> >>>> On 2011-12-05 07:18, David Holmes wrote: >>>> >>>> Hi Mikael, >>>> >>>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>> >>>> On 2011-12-02 06:32, David Holmes wrote: >>>> >>>> I'm a little confused as to where >>>> wb.jar ends up when I build >>>> hotspot. I >>>> see this in a makefile: >>>> >>>> >>>> There are a couple of issues in these >>>> make files. >>>> >>>> >>>> 26 WB = wb >>>> 27 >>>> 28 WBSRCDIR = >>>> $(GAMMADIR)/src/share/tools/__whitebox/src >>>> 29 >>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>> 31 >>>> 32 DEST_WB_JAR = >>>> $(JAVA_HOME)/lib/$(WB_JAR) >>>> >>>> Why JAVA_HOME? That's normally a >>>> binary installation of a JDK used >>>> for >>>> building, not somewhere I expect my >>>> build to try and put something. >>>> Plus >>>> the above will expand to: >>>> >>>> >>>> For example, look in jsig.make. It has a >>>> target that copies >>>> libjsig to >>>> JDK_LIBDIR. JDK_LIBDIR is set up in >>>> vm.make to point to >>>> JAVA_HOME/jre/lib/[arch]. I was only >>>> trying to mimic existing >>>> behavior >>>> with the "install"-targets in the make >>>> files. >>>> >>>> >>>> Our build system is somewhat confusing. The >>>> top-level Defs.make will >>>> set >>>> JAVA_HOME based on ABS_BOOTDIR which in turn >>>> is set by BOOTDIR which >>>> can >>>> be overridden by ALT_BOOTDIR. BOOTDIR, >>>> ALT_BOOTDIR and JAVA_HOME are >>>> all >>>> places where the build expects to find an >>>> executable JDK for >>>> performing >>>> build actions like javac compiles, javah etc. >>>> >>>> As you point out vm.make then sets >>>> JDK_LIBDIR based on JAVA_HOME and >>>> that is used by the install_* targets, which >>>> are dependencies of the >>>> vm.make install target. The vm.make install >>>> target is itself invoked >>>> from top.make's install target. >>>> >>>> So when do these install targets actually >>>> get used? Other than by a >>>> developer on the command-line I don't see >>>> these targets actually >>>> getting >>>> used - and they can't be specified as >>>> targets for the top-level >>>> Makefile. I suspect these may be relics from >>>> a time when you would do >>>> something like: >>>> >>>> JAVA_HOME=/my/local/jdk/to/__test/ make >>>> product1 install >>>> >>>> >>>> You are probably correct. >>>> Do you want me to modify the make file to more >>>> closely mimic the >>>> behavior of the other make files and let the >>>> legacy "install" target >>>> stay or do you want me to just not add an >>>> install target? >>>> >>>> >>>> And if I build a full JDK, where >>>> does wb.jar end up then? >>>> >>>> >>>> $ find . -name wb.jar >>>> ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar >>>> ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The JDK makefiles that build the >>>> j2{sdk,re}-image directories do not >>>> pick up the wb.jar file. >>>> >>>> >>>> Ok. So what is the expected build process >>>> here such that wb is >>>> available >>>> for use? Are you expecting the developer to >>>> do some kind of "make >>>> install"? >>>> >>>> >>>> This is primarily intended for use together with >>>> our internal test >>>> infrastructure (nightly testing etc.). When >>>> running these tests >>>> there is >>>> already a requirement for a JDK to go together >>>> with a VM that we are >>>> testing. The same goes for jtreg and the HotSpot >>>> tests in the test/ >>>> subdirectory of the HotSpot repository. >>>> So if you want to run tests on your own VM >>>> wouldn't you need to use >>>> something like "make ALT_EXPORT_PATH=/some/jdk >>>> all_fastdebug" do >>>> automatically copy your libjvm to a working JDK? >>>> >>>> >>>> >>>> I also see in make/Makefile: >>>> >>>> 370 >>>> $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: >>>> $(GEN_DIR)/%.jar >>>> 371 $(install-file) >>>> >>>> Why the endorsed subdirectory? This >>>> is nothing to do with an >>>> "endorsed >>>> standard": >>>> >>>> http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ >>>> >>>> >>>> >>>> Because of security requirements and >>>> implementation details the >>>> Whitebox >>>> class must be available on the boot >>>> class path. >>>> Putting the wb.jar file in the endorsed >>>> directory is a quick and >>>> easy >>>> way to achieve that. >>>> >>>> >>>> Why not just in lib? Or perhaps lib/ext? >>>> endorsed just seems to be >>>> the >>>> least appropriate choice here. >>>> >>>> >>>> Because jars in lib/endorsed are automatically >>>> added to the _boot_ >>>> class >>>> path. >>>> We could put the jar in jre/lib/ext or jre/lib/ >>>> or just lib/ >>>> but then all tests using the API would need >>>> -Xbootclasspath as an >>>> additional command line flag. >>>> >>>> >>>> And now your usage model has confused me >>>> because the above export is >>>> done for JPRT builds - right? So you want >>>> this to be available in a >>>> JPRT >>>> bundle, but not in a full JDK build? >>>> >>>> >>>> Nightly testing runs on bundles generated by >>>> JPRT, by having the API >>>> available in those bundles we can have tests >>>> that use this API in our >>>> nighly testing. >>>> If we want to have this API available when doing >>>> a full JDK build we >>>> can >>>> revisit that particular point in the future >>>> since that would need >>>> to be >>>> synchronized with RE as well. >>>> >>>> >>>> Does this clarify your concerns? >>>> >>>> >>>> Not yet :) >>>> >>>> >>>> I'll keep trying then :) >>>> >>>> /Mikael >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> /Mikael Gerdin >>>> >>>> >>>> ??? >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> If the VM crashes after this API >>>> has been accessed a note will be >>>> written in the hs_err file to >>>> signal that the API has been used. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ >>>> >>>> (thanks to stefank for hosting >>>> my webrev :) >>>> >>>> CR: >>>> I'll file a CR tomorrow. >>>> >>>> Change comments: >>>> >>>> make/jprt.properties >>>> >>>> Add a test target to make sure >>>> that the API is available on all >>>> supported platforms >>>> >>>> make/** >>>> >>>> Makefile changes to build the >>>> class sun/hotspot/WhiteBox, put it >>>> in a >>>> JAR file and copy it to the >>>> jre/lib/endorsed directory in the >>>> export >>>> targets. >>>> The BSD makefile changes are not >>>> tested since I don't have >>>> access to >>>> any >>>> BSD/OSX machine to test them on. >>>> >>>> src/share/vm/prims/__nativeLookup.cpp >>>> >>>> Special-case the method >>>> sun/hotspot/WhiteBox/__registerNatives >>>> and >>>> link it >>>> to JVM_RegisterWhiteBoxMethods >>>> >>>> src/share/vm/prims/whitebox.* >>>> >>>> The implementation of the white >>>> box API. The actual API functions >>>> are >>>> only examples of what we want to >>>> be able to do using the API. >>>> >>>> src/share/vm/runtime/globals.__hpp >>>> >>>> Add the command line flag >>>> >>>> src/share/vm/utilities/__vmError.cpp >>>> >>>> Print a message in hs_err files >>>> when white box API has been used. >>>> >>>> test/Makefile >>>> >>>> Add a makefile test target for >>>> the white box API test >>>> >>>> test/sanity/wbapi.java >>>> >>>> JTreg test to ensure that the >>>> API works. >>>> >>>> >>>> Thanks >>>> /Mikael Gerdin >>>> >>>> From mikael.gerdin at oracle.com Wed Dec 14 04:25:55 2011 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 14 Dec 2011 13:25:55 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE8254D.6090206@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE757A3.90803@oracle.com> <4EE8254D.6090206@oracle.com> Message-ID: <4EE895D3.20906@oracle.com> Hi Joe, On 2011-12-14 05:25, Joe Darcy wrote: > Hello, > > On 12/13/2011 5:48 AM, Mikael Gerdin wrote: >> Thanks Kris and David for the idea! >> >> I ran into a small issue with this solution: >> when compiling the testcase javac can't find wb.jar. >> >> If I put wb.jar in jre/lib/ext javac finds it and the test works but >> I'm not sure if it's Ok to put a jar file in ext on the boot class >> path behind the back of the extension class loader. >> >> Any ideas? > > I believe this effort would be simplified if the new types were > unconditionally available in the JDK and not available depending on > build variations. In principle I agree with you, but with our current processes that would cause a dependency on JDK changes for HotSpot tests. Say that I want to write a regression test and that I create a WhiteBox API function that the test uses, when we do a nightly build of HotSpot we only build HotSpot and copy the libjvm into a "stable" JDK. If this class came from the JDK I'd have to wait for a full promotion cycle before I could use that class in the HotSpot test. > > The endorsed standards mechanism is meant for other, very specific > purposes [1]. > > For a more general discussion about how the full logical classpath is > constructed in different settings see [2] and [3]. > > -Joe > > [1] > http://docs.oracle.com/javase/7/docs/technotes/guides/standards/index.html > > [2] http://blogs.oracle.com/darcy/entry/pick_a_path_any_path1 > Nice table! It has all the information I spent time reverse-engineering out of the HotSpot sources because I could not find any good and concise documentation :) /Mikael > [3] > http://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html > > >> >> /Mikael >> >> On 2011-12-13 08:04, David Holmes wrote: >>> On 13/12/2011 4:48 PM, Krystal Mok wrote: >>>> Hi Mikael and David, >>>> >>>> As an alternative, how about inserting wb.jar into the bootclasspath >>>> in Arguments::parse_vm_init_args() when -XX:+EnableWhiteboxAPI is >>>> enabled, just like the way alt-rt.jar is inserted when >>>> -XX:+AggressiveOpts is given, in the product JDK 6 and 7? >>> >>> And presumably place wb.jar in jre/lib the way alt-rt.jar is. >>> >>> That seems like a good suggestion - thanks Kris. >>> >>> David >>> >>>> - Kris >>>> >>>> On Tue, Dec 13, 2011 at 11:16 AM, David Holmes >>> > wrote: >>>> >>>> Hi Mikael, >>>> >>>> I see why you are dependent on being loaded by the boot loader, but >>>> I think using the endorsed mechanism for that is somewhat of a hack >>>> - this isn't anything to do with being endorsed it is just a way to >>>> get on the bootclasspath without modifying the bootclasspath. >>>> >>>> I'd like to hear what others think of this. >>>> >>>> David >>>> >>>> >>>> On 12/12/2011 11:13 PM, Mikael Gerdin wrote: >>>> >>>> David, >>>> >>>> On 2011-12-11 12:10, David Holmes wrote: >>>> >>>> On 9/12/2011 11:42 PM, Mikael Gerdin wrote: >>>> >>>> On 2011-12-09 05:25, David Holmes wrote: >>>> >>>> 2. lib/ext jars have the same permissions as >>>> bootclasspath, so it >>>> should >>>> work to place it there. >>>> >>>> >>>> I tried that first (before even discovering the >>>> existence of the >>>> "endorsed" directory) but when I tried it the Whitebox >>>> class didn't get >>>> have null as its classloader. >>>> >>>> >>>> Right - lib/ext is loaded by the extensions classloader not the >>>> bootstraploader. But this is supposed to have as many >>>> privileges as the >>>> bootstrap loader: >>>> >>>> >>>> Yes, but does the VM know anything about the ext class loader? >>>> Is there any way to check from inside the privilege level of a >>>> class? (I >>>> suppose I can do some sort of upcall to the JDK to check that but is >>>> there a shorter way?) >>>> >>>> Also, there is one more detail about the boot class loader, see >>>> below. >>>> >>>> >>>> "By default, installed optional packages in this standard >>>> directory are >>>> trusted. That is, they are granted the same privileges as if >>>> they were >>>> core platform classes (those in rt.jar). This default >>>> privilege is >>>> specified in the system policy file (in >>>> /jre/lib/security/__java.policy), but can be >>>> overridden for a >>>> particular optional package by adding the appropriate policy >>>> file entry >>>> (see Permissions in the JDK). >>>> >>>> http://docs.oracle.com/javase/__7/docs/technotes/guides/__extensions/spec.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> What is it that requires that wb.jar actually be on the >>>> bootclasspath? >>>> >>>> >>>> In order to avoid adding more changes to nativeLookup.cpp i just >>>> added >>>> the JVM_RegisterWhiteboxMethods to the array of methods explicitly >>>> menttioned in this file. >>>> >>>> The current code checks for the null class loader explicitly here: >>>> 156 Handle loader(THREAD, >>>> 157 >>>> instanceKlass::cast(method->__method_holder())->class___loader()); >>>> 158 if (loader.is_null()) { >>>> 159 entry = lookup_special_native(jni___name); >>>> >>>> I could add another JNINativeMethod array and check for >>>> "WhiteBox_registerNatives" on all class loaders. >>>> If we go down this way I would have to verify with my security >>>> contact >>>> that he's okay with dropping the boot class loader requirement. >>>> >>>> /Mikael >>>> >>>> >>>> Cheers, >>>> David >>>> >>>> Looking at the code in >>>> src/share/vm/runtime/__arguments.cpp, the class >>>> SysClassPath claims to be responsible for handling the >>>> boot class path. >>>> I don't see any reference to lib/ext there but I'm not >>>> very familiar >>>> with how the class loading code actually works. >>>> >>>> /Mikael >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/12/2011 1:11 AM, Mikael Gerdin wrote: >>>> >>>> Hi David, >>>> Sorry for the delayed response. >>>> >>>> On 2011-12-05 07:18, David Holmes wrote: >>>> >>>> Hi Mikael, >>>> >>>> On 2/12/2011 8:46 PM, Mikael Gerdin wrote: >>>> >>>> On 2011-12-02 06:32, David Holmes wrote: >>>> >>>> I'm a little confused as to where >>>> wb.jar ends up when I build >>>> hotspot. I >>>> see this in a makefile: >>>> >>>> >>>> There are a couple of issues in these >>>> make files. >>>> >>>> >>>> 26 WB = wb >>>> 27 >>>> 28 WBSRCDIR = >>>> $(GAMMADIR)/src/share/tools/__whitebox/src >>>> 29 >>>> 30 WB_JAR = $(GENERATED)/$(WB).jar >>>> 31 >>>> 32 DEST_WB_JAR = >>>> $(JAVA_HOME)/lib/$(WB_JAR) >>>> >>>> Why JAVA_HOME? That's normally a >>>> binary installation of a JDK used >>>> for >>>> building, not somewhere I expect my >>>> build to try and put something. >>>> Plus >>>> the above will expand to: >>>> >>>> >>>> For example, look in jsig.make. It has a >>>> target that copies >>>> libjsig to >>>> JDK_LIBDIR. JDK_LIBDIR is set up in >>>> vm.make to point to >>>> JAVA_HOME/jre/lib/[arch]. I was only >>>> trying to mimic existing >>>> behavior >>>> with the "install"-targets in the make >>>> files. >>>> >>>> >>>> Our build system is somewhat confusing. The >>>> top-level Defs.make will >>>> set >>>> JAVA_HOME based on ABS_BOOTDIR which in turn >>>> is set by BOOTDIR which >>>> can >>>> be overridden by ALT_BOOTDIR. BOOTDIR, >>>> ALT_BOOTDIR and JAVA_HOME are >>>> all >>>> places where the build expects to find an >>>> executable JDK for >>>> performing >>>> build actions like javac compiles, javah etc. >>>> >>>> As you point out vm.make then sets >>>> JDK_LIBDIR based on JAVA_HOME and >>>> that is used by the install_* targets, which >>>> are dependencies of the >>>> vm.make install target. The vm.make install >>>> target is itself invoked >>>> from top.make's install target. >>>> >>>> So when do these install targets actually >>>> get used? Other than by a >>>> developer on the command-line I don't see >>>> these targets actually >>>> getting >>>> used - and they can't be specified as >>>> targets for the top-level >>>> Makefile. I suspect these may be relics from >>>> a time when you would do >>>> something like: >>>> >>>> JAVA_HOME=/my/local/jdk/to/__test/ make >>>> product1 install >>>> >>>> >>>> You are probably correct. >>>> Do you want me to modify the make file to more >>>> closely mimic the >>>> behavior of the other make files and let the >>>> legacy "install" target >>>> stay or do you want me to just not add an >>>> install target? >>>> >>>> >>>> And if I build a full JDK, where >>>> does wb.jar end up then? >>>> >>>> >>>> $ find . -name wb.jar >>>> ./build/linux-amd64/hotspot/__import/jre/lib/endorsed/wb.jar >>>> ./build/linux-amd64/hotspot/__outputdir/linux_amd64___compiler2/generated/wb.jar >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The JDK makefiles that build the >>>> j2{sdk,re}-image directories do not >>>> pick up the wb.jar file. >>>> >>>> >>>> Ok. So what is the expected build process >>>> here such that wb is >>>> available >>>> for use? Are you expecting the developer to >>>> do some kind of "make >>>> install"? >>>> >>>> >>>> This is primarily intended for use together with >>>> our internal test >>>> infrastructure (nightly testing etc.). When >>>> running these tests >>>> there is >>>> already a requirement for a JDK to go together >>>> with a VM that we are >>>> testing. The same goes for jtreg and the HotSpot >>>> tests in the test/ >>>> subdirectory of the HotSpot repository. >>>> So if you want to run tests on your own VM >>>> wouldn't you need to use >>>> something like "make ALT_EXPORT_PATH=/some/jdk >>>> all_fastdebug" do >>>> automatically copy your libjvm to a working JDK? >>>> >>>> >>>> >>>> I also see in make/Makefile: >>>> >>>> 370 >>>> $(EXPORT_JRE_LIB_DIR)/__endorsed/%.jar: >>>> $(GEN_DIR)/%.jar >>>> 371 $(install-file) >>>> >>>> Why the endorsed subdirectory? This >>>> is nothing to do with an >>>> "endorsed >>>> standard": >>>> >>>> http://docs.oracle.com/javase/__6/docs/technotes/guides/__standards/ >>>> >>>> >>>> >>>> Because of security requirements and >>>> implementation details the >>>> Whitebox >>>> class must be available on the boot >>>> class path. >>>> Putting the wb.jar file in the endorsed >>>> directory is a quick and >>>> easy >>>> way to achieve that. >>>> >>>> >>>> Why not just in lib? Or perhaps lib/ext? >>>> endorsed just seems to be >>>> the >>>> least appropriate choice here. >>>> >>>> >>>> Because jars in lib/endorsed are automatically >>>> added to the _boot_ >>>> class >>>> path. >>>> We could put the jar in jre/lib/ext or jre/lib/ >>>> or just lib/ >>>> but then all tests using the API would need >>>> -Xbootclasspath as an >>>> additional command line flag. >>>> >>>> >>>> And now your usage model has confused me >>>> because the above export is >>>> done for JPRT builds - right? So you want >>>> this to be available in a >>>> JPRT >>>> bundle, but not in a full JDK build? >>>> >>>> >>>> Nightly testing runs on bundles generated by >>>> JPRT, by having the API >>>> available in those bundles we can have tests >>>> that use this API in our >>>> nighly testing. >>>> If we want to have this API available when doing >>>> a full JDK build we >>>> can >>>> revisit that particular point in the future >>>> since that would need >>>> to be >>>> synchronized with RE as well. >>>> >>>> >>>> Does this clarify your concerns? >>>> >>>> >>>> Not yet :) >>>> >>>> >>>> I'll keep trying then :) >>>> >>>> /Mikael >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> /Mikael Gerdin >>>> >>>> >>>> ??? >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> If the VM crashes after this API >>>> has been accessed a note will be >>>> written in the hs_err file to >>>> signal that the API has been used. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~__stefank/mgerdin/wbapi.0/__webrev/ >>>> >>>> (thanks to stefank for hosting >>>> my webrev :) >>>> >>>> CR: >>>> I'll file a CR tomorrow. >>>> >>>> Change comments: >>>> >>>> make/jprt.properties >>>> >>>> Add a test target to make sure >>>> that the API is available on all >>>> supported platforms >>>> >>>> make/** >>>> >>>> Makefile changes to build the >>>> class sun/hotspot/WhiteBox, put it >>>> in a >>>> JAR file and copy it to the >>>> jre/lib/endorsed directory in the >>>> export >>>> targets. >>>> The BSD makefile changes are not >>>> tested since I don't have >>>> access to >>>> any >>>> BSD/OSX machine to test them on. >>>> >>>> src/share/vm/prims/__nativeLookup.cpp >>>> >>>> Special-case the method >>>> sun/hotspot/WhiteBox/__registerNatives >>>> and >>>> link it >>>> to JVM_RegisterWhiteBoxMethods >>>> >>>> src/share/vm/prims/whitebox.* >>>> >>>> The implementation of the white >>>> box API. The actual API functions >>>> are >>>> only examples of what we want to >>>> be able to do using the API. >>>> >>>> src/share/vm/runtime/globals.__hpp >>>> >>>> Add the command line flag >>>> >>>> src/share/vm/utilities/__vmError.cpp >>>> >>>> Print a message in hs_err files >>>> when white box API has been used. >>>> >>>> test/Makefile >>>> >>>> Add a makefile test target for >>>> the white box API test >>>> >>>> test/sanity/wbapi.java >>>> >>>> JTreg test to ensure that the >>>> API works. >>>> >>>> >>>> Thanks >>>> /Mikael Gerdin >>>> >>>> From Alan.Bateman at oracle.com Wed Dec 14 07:56:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Dec 2011 15:56:06 +0000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE7FF16.9030107@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE7FF16.9030107@oracle.com> Message-ID: <4EE8C716.7010405@oracle.com> On 14/12/2011 01:42, John Pampuch wrote: > Will the modularity changes coming in JDK 8 affect this? Yes as the class path, boot class path etc. should go away in modules mode. The likely approach would be to have the wb API installed as a module where it could be used in both legacy/classic mode and when running in modules mode. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111214/fa5955b5/attachment.html From tom.rodriguez at oracle.com Wed Dec 14 11:49:50 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Dec 2011 11:49:50 -0800 Subject: Review request (M): 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions In-Reply-To: <4EE7BF5A.6030107@oracle.com> References: <4EDF6186.7050704@oracle.com> <4EE7BF5A.6030107@oracle.com> Message-ID: <30B047DE-9F2C-4FE6-BB98-AF0D57DF2A5E@oracle.com> Looks good. tom On Dec 13, 2011, at 1:10 PM, Stefan Karlsson wrote: > Updated patch: > http://cr.openjdk.java.net/~stefank/7118863/webrev.02/ > > The function names and the return types have been changed, to prevent this change from silently breaking ports of HotSpot. > > The compile.cpp oddity will be fixed before this is pushed. > > StefanK > > On 2011-12-07 13:52, Stefan Karlsson wrote: >> Please review this REF. >> >> http://cr.openjdk.java.net/~stefank/7118863/webrev/ >> >> The main motivation for this patch is to make it easier to merge with the permgen project. But, IMHO, they also help the code by not having different ways to go from a klass field offset to an offset against the klassOopDesc. >> >> Two things to note about this patch. >> 1) There's one place in the code where we don't add sizeof(klassOopDesc). I maintain this oddity and will leave the correct fix for a later change. >> src/share/vm/opto/compile.cpp >> >> 2) I have no way to verify the shark changes. >> src/share/vm/shark/sharkIntrinsics.cpp >> src/share/vm/shark/sharkTopLevelBlock.cpp >> >> From the RFE: >> The *Klass::*_offset_in_bytes() functions are used to get the offset to a field in a Klass. All places where they are used, we add something like sizeof(klassOopDesc) to make the offset against the klassOopDesc instead. >> >> For example in opto/memnode.cpp: >> if (tkls->offset() == Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc)) { >> >> There's a couple of variants to this: >> instanceKlass::init_thread_offset_in_bytes() + sizeof(klassOopDesc) >> Klass::access_flags_offset_in_bytes() + (int)sizeof(oopDesc) >> Klass::secondary_supers_offset_in_bytes() + klassOopDesc::header_size() * HeapWordSize >> Klass::java_mirror_offset_in_bytes() klassOopDesc::klass_part_offset_in_bytes() >> >> The proposal is to move all these size adjustments into the *Klass:*_offset_in_bytes() functions. > From david.holmes at oracle.com Wed Dec 14 22:34:28 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2011 16:34:28 +1000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE8C716.7010405@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE7FF16.9030107@oracle.com> <4EE8C716.7010405@oracle.com> Message-ID: <4EE994F4.90103@oracle.com> On 15/12/2011 1:56 AM, Alan Bateman wrote: > On 14/12/2011 01:42, John Pampuch wrote: >> Will the modularity changes coming in JDK 8 affect this? > Yes as the class path, boot class path etc. should go away in modules > mode. The likely approach would be to have the wb API installed as a > module where it could be used in both legacy/classic mode and when > running in modules mode. But in that case there is no bootclasspath and so the current validity check of being "on the boot classpath" becomes invalid. So what would replace that? Does the concept of the boot loader disappear? David > -Alan. From joe.darcy at oracle.com Wed Dec 14 22:59:20 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 Dec 2011 22:59:20 -0800 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE895D3.20906@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE757A3.90803@oracle.com> <4EE8254D.6090206@oracle.com> <4EE895D3.20906@oracle.com> Message-ID: <4EE99AC8.1090807@oracle.com> Hi Mikael, On 12/14/2011 4:25 AM, Mikael Gerdin wrote: > Hi Joe, > > On 2011-12-14 05:25, Joe Darcy wrote: >> Hello, >> >> On 12/13/2011 5:48 AM, Mikael Gerdin wrote: >>> Thanks Kris and David for the idea! >>> >>> I ran into a small issue with this solution: >>> when compiling the testcase javac can't find wb.jar. >>> >>> If I put wb.jar in jre/lib/ext javac finds it and the test works but >>> I'm not sure if it's Ok to put a jar file in ext on the boot class >>> path behind the back of the extension class loader. >>> >>> Any ideas? >> >> I believe this effort would be simplified if the new types were >> unconditionally available in the JDK and not available depending on >> build variations. > > In principle I agree with you, but with our current processes that > would cause a dependency on JDK changes for HotSpot tests. > Say that I want to write a regression test and that I create a > WhiteBox API function that the test uses, when we do a nightly build > of HotSpot we only build HotSpot and copy the libjvm into a "stable" JDK. > If this class came from the JDK I'd have to wait for a full promotion > cycle before I could use that class in the HotSpot test. Well, there are a few other solutions that problem :-) * Change the build so that selected files from the HotSpot repo can go into the bootclasspath * Update integration procedures so that HotSpot uses a newer "stable" JDK * Arrange for HotSpot integration to also be able to push some changes to the jdk repo -Joe From vladimir.danushevsky at oracle.com Thu Dec 15 01:02:51 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 15 Dec 2011 09:02:51 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20111215090255.CD65C476CC@hg.openjdk.java.net> Changeset: 3b688d6ff3d0 Author: fparain Date: 2011-12-14 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b688d6ff3d0 7104647: Adding a diagnostic command framework Reviewed-by: phh, dcubed ! src/share/vm/services/attachListener.cpp + src/share/vm/services/diagnosticArgument.cpp + src/share/vm/services/diagnosticArgument.hpp + src/share/vm/services/diagnosticCommand.cpp + src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticFramework.cpp + src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: 31f6f10e4379 Author: vladidan Date: 2011-12-14 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/31f6f10e4379 Merge From Alan.Bateman at oracle.com Thu Dec 15 02:14:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Dec 2011 10:14:49 +0000 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4EE994F4.90103@oracle.com> References: <4ED50287.3070102@oracle.com> <4ED862E1.6040903@oracle.com> <4ED8AC78.5000508@oracle.com> <4EDC6236.5070106@oracle.com> <4EE0D3A7.3010109@oracle.com> <4EE18DAA.5010105@oracle.com> <4EE2104E.2040304@oracle.com> <4EE48FB0.1000503@oracle.com> <4EE5FE07.40503@oracle.com> <4EE6C386.3010207@oracle.com> <4EE6F915.7060602@oracle.com> <4EE7FF16.9030107@oracle.com> <4EE8C716.7010405@oracle.com> <4EE994F4.90103@oracle.com> Message-ID: <4EE9C899.1050002@oracle.com> On 15/12/2011 06:34, David Holmes wrote: > On 15/12/2011 1:56 AM, Alan Bateman wrote: >> On 14/12/2011 01:42, John Pampuch wrote: >>> Will the modularity changes coming in JDK 8 affect this? >> Yes as the class path, boot class path etc. should go away in modules >> mode. The likely approach would be to have the wb API installed as a >> module where it could be used in both legacy/classic mode and when >> running in modules mode. > > But in that case there is no bootclasspath and so the current validity > check of being "on the boot classpath" becomes invalid. So what would > replace that? Does the concept of the boot loader disappear? Yes, this should go away but code in the platform modules that except the the class loader to be null will have to continue to see null and a new method introduced to return the module class loader. More generally for white box testing is there will need need to be a mechanism to allow tests to access types and internals aren't exported by modules. -Alan From jon.masamitsu at oracle.com Thu Dec 15 09:39:11 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 15 Dec 2011 09:39:11 -0800 Subject: hg: hsx/hotspot-main/hotspot: 7119584: UseParallelGC barrier task can be overwritten. In-Reply-To: <20111214033640.630E8476A4@hg.openjdk.java.net> References: <20111214033640.630E8476A4@hg.openjdk.java.net> Message-ID: <4EEA30BF.70303@oracle.com> The "Summary" comment below is just wrong. Sorry for the misinformation. On 12/13/11 19:36, jon.masamitsu at oracle.com wrote: > Changeset: 6d7d0790074d > Author: jmasa > Date: 2011-12-09 19:28 -0800 > URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6d7d0790074d > > 7119584: UseParallelGC barrier task can be overwritten. > Summary: Provoke a GC for a metadata allocation failure. > Reviewed-by: johnc, iveresov > > ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp > ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp > From kelly.ohair at oracle.com Thu Dec 15 12:02:24 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Dec 2011 12:02:24 -0800 Subject: VM warning: Performance bug Message-ID: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> Anyone seen this message before: OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 Maybe from jdk7u2? -kto From tom.rodriguez at oracle.com Thu Dec 15 12:38:39 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 12:38:39 -0800 Subject: VM warning: Performance bug In-Reply-To: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> Message-ID: <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: > > Anyone seen this message before: > > OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 > > Maybe from jdk7u2? I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. tom > > -kto > From karen.kinnear at oracle.com Thu Dec 15 13:05:40 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 15 Dec 2011 16:05:40 -0500 Subject: VM warning: Performance bug In-Reply-To: <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> Message-ID: <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> Actually I am working on a fix for it - see 7105270. It is "benign" in the sense of correct operation. However, we have an internal customer who has seen measurable performance loss when they get this warning. So I am working on resizing the system dictionary if the lookups take "too long". If you have a way to duplicate it that doesn't require a database - that would make it easier for me to debug. thanks, Karen On Dec 15, 2011, at 3:38 PM, Tom Rodriguez wrote: > > On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: > >> >> Anyone seen this message before: >> >> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >> >> Maybe from jdk7u2? > > I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. > > tom > >> >> -kto >> > From tom.rodriguez at oracle.com Thu Dec 15 13:10:04 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 13:10:04 -0800 Subject: VM warning: Performance bug In-Reply-To: <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> Message-ID: <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> On Dec 15, 2011, at 1:05 PM, Karen Kinnear wrote: > Actually I am working on a fix for it - see 7105270. Great. Will this be something that other subclasses of BasicHashtable can take advantage of? The interned string table has similar issues that we've papered over. Having more general support for rehashing would help. tom > > It is "benign" in the sense of correct operation. However, we have an internal customer who has > seen measurable performance loss when they get this warning. So I am working on resizing the > system dictionary if the lookups take "too long". > > If you have a way to duplicate it that doesn't require a database - that would make it easier for > me to debug. > > thanks, > Karen > > On Dec 15, 2011, at 3:38 PM, Tom Rodriguez wrote: > >> >> On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: >> >>> >>> Anyone seen this message before: >>> >>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>> >>> Maybe from jdk7u2? >> >> I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. >> >> tom >> >>> >>> -kto >>> >> > From tom.rodriguez at oracle.com Thu Dec 15 13:47:28 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 13:47:28 -0800 Subject: VM warning: Performance bug In-Reply-To: <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> Message-ID: <78D5CAAE-10BC-4AA6-B3B2-E80AA8736F9A@oracle.com> On Dec 15, 2011, at 1:10 PM, Tom Rodriguez wrote: > > On Dec 15, 2011, at 1:05 PM, Karen Kinnear wrote: > >> Actually I am working on a fix for it - see 7105270. > > Great. Will this be something that other subclasses of BasicHashtable can take advantage of? The interned string table has similar issues that we've papered over. Having more general support for rehashing would help. > > tom > >> >> It is "benign" in the sense of correct operation. However, we have an internal customer who has >> seen measurable performance loss when they get this warning. So I am working on resizing the >> system dictionary if the lookups take "too long". Also I didn't mean to imply that it was always benign. The message itself doesn't provide enough information to conclude anything since lots of different patterns could give you lookup statistics like that. It would need to report some structural statistics around occupancy and chain length to make sense of those numbers. Those particular numbers seem pretty benign though. tom >> >> If you have a way to duplicate it that doesn't require a database - that would make it easier for >> me to debug. >> >> thanks, >> Karen >> >> On Dec 15, 2011, at 3:38 PM, Tom Rodriguez wrote: >> >>> >>> On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: >>> >>>> >>>> Anyone seen this message before: >>>> >>>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>>> >>>> Maybe from jdk7u2? >>> >>> I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. >>> >>> tom >>> >>>> >>>> -kto >>>> >>> >> > From kelly.ohair at oracle.com Thu Dec 15 14:15:27 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 15 Dec 2011 14:15:27 -0800 Subject: VM warning: Performance bug In-Reply-To: <78D5CAAE-10BC-4AA6-B3B2-E80AA8736F9A@oracle.com> References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> <78D5CAAE-10BC-4AA6-B3B2-E80AA8736F9A@oracle.com> Message-ID: Maurizio ran into it with a jprt boot cycle job like so: jprt submit -boot jdk7 -control 'corba hotspot jaxp jaxws jdk langtools' -et '.*windows_i586.*' -buildenv SKIP_BOOT_CYCLE=false -buildenv SKIP_MSIVAL2=true -buildenv SKIP_COMPARE_IMAGES=true -buildsonly -noqa http://prt-web.us.oracle.com//archive/2011/12/2011-12-14-182027.maurizio.tl Probably adding -ot 'linux_x64_2.6-fastdebug' would be good, it only happens with linux 64bit fastdebug. The -boot jdk7 effectively uses the latest jdk7 being worked on (7u2 or 7u4) instead of the first jdk7 (jdk7fcs). It appears as if it has caused the javac.jar file to fail. Like maybe spitting out messages to stdout/stderr isn't a good idea? >>>>> /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/bootjdk/../linux-amd64-fastdebug/j2sdk-image/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/tmp/jprt/P1/182027.maurizio/source/build/linux-amd64-fastdebug/langtools/dist/bootstrap/lib/javac.jar -jar /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64-fastdebug/langtools/dist/bootstrap/lib/javac.jar -g -Xlint:all -Xlint:-path -source 7 -target 7 -encoding ascii -Xbootclasspath:/tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/classes -sourcepath /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/gensrc:../../../src/solaris/classes:../../../src/share/classes -d /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/classes @/tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/tmp/java >>>>> /java.lang >>>>> /java/.cla >>>>> sses.list.filtered >>>>> /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/gensrc/java/nio/charset/CharsetEncoder.java:973: error: class, interface, or enum expected >>>>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>>>> ^ >>>>> 1 error >>>>> # javac finished -kto On Dec 15, 2011, at 1:47 PM, Tom Rodriguez wrote: > > On Dec 15, 2011, at 1:10 PM, Tom Rodriguez wrote: > >> >> On Dec 15, 2011, at 1:05 PM, Karen Kinnear wrote: >> >>> Actually I am working on a fix for it - see 7105270. >> >> Great. Will this be something that other subclasses of BasicHashtable can take advantage of? The interned string table has similar issues that we've papered over. Having more general support for rehashing would help. >> >> tom >> >>> >>> It is "benign" in the sense of correct operation. However, we have an internal customer who has >>> seen measurable performance loss when they get this warning. So I am working on resizing the >>> system dictionary if the lookups take "too long". > > Also I didn't mean to imply that it was always benign. The message itself doesn't provide enough information to conclude anything since lots of different patterns could give you lookup statistics like that. It would need to report some structural statistics around occupancy and chain length to make sense of those numbers. Those particular numbers seem pretty benign though. > > tom > >>> >>> If you have a way to duplicate it that doesn't require a database - that would make it easier for >>> me to debug. >>> >>> thanks, >>> Karen >>> >>> On Dec 15, 2011, at 3:38 PM, Tom Rodriguez wrote: >>> >>>> >>>> On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: >>>> >>>>> >>>>> Anyone seen this message before: >>>>> >>>>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>>>> >>>>> Maybe from jdk7u2? >>>> >>>> I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. >>>> >>>> tom >>>> >>>>> >>>>> -kto >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111215/a1673808/attachment-0001.html From karen.kinnear at oracle.com Thu Dec 15 14:23:15 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 15 Dec 2011 17:23:15 -0500 Subject: VM warning: Performance bug In-Reply-To: <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> Message-ID: <03CA9500-B7E2-4B0B-B6AD-B0EAAD149AF7@oracle.com> Tom, Coleen mentioned that as well. I'll see how much I can make this common code that would be reusable for other hash tables. thanks, Karen On Dec 15, 2011, at 4:10 PM, Tom Rodriguez wrote: > > On Dec 15, 2011, at 1:05 PM, Karen Kinnear wrote: > >> Actually I am working on a fix for it - see 7105270. > > Great. Will this be something that other subclasses of BasicHashtable can take advantage of? The interned string table has similar issues that we've papered over. Having more general support for rehashing would help. > > tom > >> >> It is "benign" in the sense of correct operation. However, we have an internal customer who has >> seen measurable performance loss when they get this warning. So I am working on resizing the >> system dictionary if the lookups take "too long". >> >> If you have a way to duplicate it that doesn't require a database - that would make it easier for >> me to debug. >> >> thanks, >> Karen >> >> On Dec 15, 2011, at 3:38 PM, Tom Rodriguez wrote: >> >>> >>> On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: >>> >>>> >>>> Anyone seen this message before: >>>> >>>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>>> >>>> Maybe from jdk7u2? >>> >>> I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. >>> >>> tom >>> >>>> >>>> -kto >>>> >>> >> > From karen.kinnear at oracle.com Thu Dec 15 14:32:22 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 15 Dec 2011 17:32:22 -0500 Subject: VM warning: Performance bug In-Reply-To: References: <0E6F0C9B-3A64-4D40-9301-75C2FB74C65F@oracle.com> <4AD58408-CCE6-40C7-B710-D309619BCEE8@oracle.com> <9488004E-A87B-412F-870E-8B12F97E5BDF@oracle.com> <038D3F20-A2CF-48C9-8F7C-ABEAE41F4F07@oracle.com> <78D5CAAE-10BC-4AA6-B3B2-E80AA8736F9A@oracle.com> Message-ID: Kelly, Thank you - that should help me reproduce this. I agree that PrintWarnings should be off by default - but it looks like it is on by default. I don't know the history of that decision. For this particular warning, it only shows up with ASSERT, i.e. fastdebug mode. The fix I am working on will recover instead of printing this warning. thanks, Karen On Dec 15, 2011, at 5:15 PM, Kelly O'Hair wrote: > Maurizio ran into it with a jprt boot cycle job like so: > jprt submit -boot jdk7 -control 'corba hotspot jaxp jaxws jdk langtools' -et '.*windows_i586.*' -buildenv SKIP_BOOT_CYCLE=false -buildenv SKIP_MSIVAL2=true -buildenv SKIP_COMPARE_IMAGES=true -buildsonly -noqa > > http://prt-web.us.oracle.com//archive/2011/12/2011-12-14-182027.maurizio.tl > > Probably adding -ot 'linux_x64_2.6-fastdebug' would be good, it only happens with linux 64bit fastdebug. > > The -boot jdk7 effectively uses the latest jdk7 being worked on (7u2 or 7u4) instead of the first jdk7 (jdk7fcs). > > It appears as if it has caused the javac.jar file to fail. Like maybe spitting out messages to stdout/stderr isn't a good idea? > >>>>>> /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/bootjdk/../linux-amd64-fastdebug/j2sdk-image/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/tmp/jprt/P1/182027.maurizio/source/build/linux-amd64-fastdebug/langtools/dist/bootstrap/lib/javac.jar -jar /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64-fastdebug/langtools/dist/bootstrap/lib/javac.jar -g -Xlint:all -Xlint:-path -source 7 -target 7 -encoding ascii -Xbootclasspath:/tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/classes -sourcepath /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/gensrc:../../../src/solaris/classes:../../../src/share/classes -d /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/classes @/tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/tmp/java >>>>>> /java.lang >>>>>> /java/.cla >>>>>> sses.list.filtered >>>>>> /tmp/jprt/P1/182027.maurizio/source/build/linux-amd64/../linux-amd64-fastdebug/gensrc/java/nio/charset/CharsetEncoder.java:973: error: class, interface, or enum expected >>>>>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>>>>> ^ >>>>>> 1 error >>>>>> # javac finished > > > > -kto > > > On Dec 15, 2011, at 1:47 PM, Tom Rodriguez wrote: > >> >> On Dec 15, 2011, at 1:10 PM, Tom Rodriguez wrote: >> >>> >>> On Dec 15, 2011, at 1:05 PM, Karen Kinnear wrote: >>> >>>> Actually I am working on a fix for it - see 7105270. >>> >>> Great. Will this be something that other subclasses of BasicHashtable can take advantage of? The interned string table has similar issues that we've papered over. Having more general support for rehashing would help. >>> >>> tom >>> >>>> >>>> It is "benign" in the sense of correct operation. However, we have an internal customer who has >>>> seen measurable performance loss when they get this warning. So I am working on resizing the >>>> system dictionary if the lookups take "too long". >> >> Also I didn't mean to imply that it was always benign. The message itself doesn't provide enough information to conclude anything since lots of different patterns could give you lookup statistics like that. It would need to report some structural statistics around occupancy and chain length to make sense of those numbers. Those particular numbers seem pretty benign though. >> >> tom >> >>>> >>>> If you have a way to duplicate it that doesn't require a database - that would make it easier for >>>> me to debug. >>>> >>>> thanks, >>>> Karen >>>> >>>> On Dec 15, 2011, at 3:38 PM, Tom Rodriguez wrote: >>>> >>>>> >>>>> On Dec 15, 2011, at 12:02 PM, Kelly O'Hair wrote: >>>>> >>>>>> >>>>>> Anyone seen this message before: >>>>>> >>>>>> OpenJDK 64-Bit Server VM warning: Performance bug: SystemDictionary lookup_count=22915 lookup_length=24212 average=1.056600 load=0.528246 >>>>>> >>>>>> Maybe from jdk7u2? >>>>> >>>>> I think it's fairly benign. It just means that the hashtable for the SystemDictionary isn't performing quite as well as we'd like. It's a little hard to evaluate without knowing how many entries are in the table. I would assume that it just has a lot of classes loaded. It's a somewhat useless message but it's debug only so I guess I wouldn't worry about it. >>>>> >>>>> tom >>>>> >>>>>> >>>>>> -kto >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111215/85f1e083/attachment.html From john.coomes at oracle.com Thu Dec 15 20:36:23 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:36:23 +0000 Subject: hg: hsx/hotspot-main: 3 new changesets Message-ID: <20111216043624.0C82C476FC@hg.openjdk.java.net> Changeset: 8606f4ab62dc Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8606f4ab62dc Added tag jdk8-b17 for changeset 4e06ae613e99 ! .hgtags Changeset: d82d3bb3a2e5 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d82d3bb3a2e5 Added tag jdk8-b16 for changeset 4e06ae613e99 ! .hgtags Changeset: 7010bd24cdd0 Author: katleman Date: 2011-12-15 15:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7010bd24cdd0 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:36:30 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:36:30 +0000 Subject: hg: hsx/hotspot-main/corba: 3 new changesets Message-ID: <20111216043633.E4C31476FD@hg.openjdk.java.net> Changeset: 05f47d29b438 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/05f47d29b438 Added tag jdk8-b17 for changeset 82dc033975bb ! .hgtags Changeset: 6e51ad8d3707 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/6e51ad8d3707 Added tag jdk8-b16 for changeset 82dc033975bb ! .hgtags Changeset: 312cf15d1657 Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/312cf15d1657 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:36:40 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:36:40 +0000 Subject: hg: hsx/hotspot-main/jaxp: 5 new changesets Message-ID: <20111216043640.76C06476FE@hg.openjdk.java.net> Changeset: e32444f13774 Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e32444f13774 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops Reviewed-by: ohair, xdono, mchung ! build.properties ! make/Makefile Changeset: 09eb517404b0 Author: katleman Date: 2011-12-07 13:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/09eb517404b0 Merge Changeset: db44484a9d6e Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/db44484a9d6e Added tag jdk8-b17 for changeset 09eb517404b0 ! .hgtags Changeset: bc3ed3122933 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/bc3ed3122933 Added tag jdk8-b16 for changeset 09eb517404b0 ! .hgtags Changeset: ebec6a7e8d4e Author: katleman Date: 2011-12-15 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ebec6a7e8d4e Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:36:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:36:47 +0000 Subject: hg: hsx/hotspot-main/jaxws: 5 new changesets Message-ID: <20111216043647.76E44476FF@hg.openjdk.java.net> Changeset: 23c42f40fd3e Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/23c42f40fd3e 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops Reviewed-by: ohair, xdono, mchung ! build.properties ! make/Makefile Changeset: 3d45ab79643d Author: katleman Date: 2011-12-07 13:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/3d45ab79643d Merge Changeset: b38846b9974c Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b38846b9974c Added tag jdk8-b17 for changeset 3d45ab79643d ! .hgtags Changeset: e662b652098c Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/e662b652098c Added tag jdk8-b16 for changeset 3d45ab79643d ! .hgtags Changeset: 54928c8850f5 Author: katleman Date: 2011-12-15 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/54928c8850f5 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:38:05 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:38:05 +0000 Subject: hg: hsx/hotspot-main/jdk: 64 new changesets Message-ID: <20111216045032.8ABC847708@hg.openjdk.java.net> Changeset: 23acf34c80b0 Author: neugens Date: 2011-12-03 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23acf34c80b0 7117914: Fix javac warnings in src/share/classes/sun/java2d Summary: Fix some javac warnings in java2d related code for the Warning Cleanup Day. Reviewed-by: prr, flar ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/SurfaceType.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLDrawImage.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/GlyphListPipe.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/solaris/classes/sun/java2d/x11/X11Renderer.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java Changeset: 70b40ea06df0 Author: prr Date: 2011-12-03 16:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70b40ea06df0 7117199: Fix javac warnings in src/share/classes/java/awt/font Reviewed-by: jgodinez, bae ! src/share/classes/java/awt/font/StyledParagraph.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TextLine.java ! src/share/classes/java/awt/font/TextMeasurer.java Changeset: 4075d524fa46 Author: lana Date: 2011-12-06 16:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4075d524fa46 Merge Changeset: e53a078c2840 Author: anthony Date: 2011-11-09 13:43 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e53a078c2840 7045370: Java Statically Determines Display Size on Linux platforms Summary: Listen to ConfigureNotify events on the root window and update the current screen size accordingly Reviewed-by: art, bae ! src/share/classes/java/awt/Component.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c Changeset: 84e473cf4531 Author: rupashka Date: 2011-11-10 14:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84e473cf4531 6938583: Unexpected NullPointerException by InputContext.endComposition() Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/6938583/bug6938583.java Changeset: 81f1b32f9e24 Author: malenkov Date: 2011-11-10 17:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/81f1b32f9e24 7057459: Regression: Performance degradation with java.beans.XMLEncoder Reviewed-by: rupashka ! src/share/classes/java/beans/Encoder.java Changeset: e120c78cb45c Author: malenkov Date: 2011-11-10 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e120c78cb45c 7064279: Introspector.getBeanInfo() should release some resources in timely manner Reviewed-by: art, alexp ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + src/share/classes/java/beans/ThreadGroupContext.java ! test/java/beans/Beans/6669869/TestDesignTime.java ! test/java/beans/Beans/6669869/TestGuiAvailable.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java + test/java/beans/Introspector/7064279/Test7064279.java + test/java/beans/Introspector/7064279/test.jar ! test/java/beans/Introspector/Test6660539.java ! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java Changeset: 8b6a69b2e482 Author: malenkov Date: 2011-11-10 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b6a69b2e482 7087876: java/beans/PropertyDescriptor.html#createPropertyEditor() throws RE if editor cannot be created Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/PropertyEditor/Test7087876.java Changeset: b02495c51b9c Author: malenkov Date: 2011-11-10 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b02495c51b9c 7092744: XMLEncoder fails to encode and breaks backward compatibility Reviewed-by: rupashka ! src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java + test/java/beans/XMLEncoder/Test7092744.java Changeset: 16327765859c Author: malenkov Date: 2011-11-10 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/16327765859c 7087429: Constructor of java.beans.PropertyChangeEvent should declare thrown NPE for null source Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyChangeEvent.java + test/java/beans/PropertyChangeSupport/Test7087429.java Changeset: f614bcada2a9 Author: anthony Date: 2011-11-11 15:17 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f614bcada2a9 7103610: _NET_WM_PID and WM_CLIENT_MACHINE are not set Summary: Set the properties to all top-level windows Reviewed-by: anthony Contributed-by: Danesh Dadachanji ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c0f3f1558a94 Author: rupashka Date: 2011-11-14 14:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c0f3f1558a94 7109617: Test was writed for Metal L&F but not set it Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/plaf/metal/MetalLookAndFeel/5073047/bug5073047.java Changeset: a51777c9228a Author: malenkov Date: 2011-11-14 14:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a51777c9228a 7110521: Regression test failed: Introspector/TestTypeResolver.java Reviewed-by: rupashka ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 28f768c41a90 Author: serb Date: 2011-11-12 04:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28f768c41a90 6996291: command line selection of MToolkit by -Dawt.toolkit=sun.awt.motif.MToolkit fails from jdk7 b21 on Reviewed-by: art, dcherepanov, bae, prr ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/awt/mawt.gmk - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java - src/solaris/classes/sun/awt/motif/AWTLockAccess.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_AWTEvent.c ! src/solaris/native/sun/awt/awt_Component.h - src/solaris/native/sun/awt/awt_Cursor.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/awt/awt_Font.h ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h ! src/solaris/native/sun/awt/awt_Robot.c - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h ! src/solaris/native/sun/awt/awt_p.h ! src/solaris/native/sun/awt/awt_util.c ! src/solaris/native/sun/awt/awt_util.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h ! src/solaris/native/sun/awt/canvas.h ! src/solaris/native/sun/awt/multi_font.c ! src/solaris/native/sun/awt/multi_font.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 6a9d735ebd0a Author: bagiras Date: 2011-11-16 15:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a9d735ebd0a 7108598: Pogo Table Games freeze with JDK 7 Reviewed-by: art, ant ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java + test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java Changeset: 1df53949945d Author: lana Date: 2011-11-18 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1df53949945d Merge Changeset: 90d33a64a404 Author: rupashka Date: 2011-11-21 18:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90d33a64a404 7109085: Test use hotkeys not intended for Mac Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! test/javax/swing/regtesthelpers/Util.java + test/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java + test/javax/swing/text/JTextComponent/5074573/bug5074573.java + test/javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java Changeset: c3c80f96cb83 Author: rupashka Date: 2011-11-25 11:52 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3c80f96cb83 7113337: Swing closed test tries to click in the area reserved for resize by Mac OS X Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 9cbc208dcf08 Author: rupashka Date: 2011-11-29 12:47 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9cbc208dcf08 7112925: closed/javax/swing/JTabbedPane/4624207/bug4624207.java fails on MacOS Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JTabbedPane/4624207/bug4624207.java Changeset: 051beb804b12 Author: rupashka Date: 2011-11-30 16:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/051beb804b12 7110440: closed/javax/swing/JScrollBar/4865918/bug4865918.java fails on Aqua L&F Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JScrollBar/4865918/bug4865918.java Changeset: 7dd4395fe4a5 Author: rupashka Date: 2011-11-30 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7dd4395fe4a5 7115357: closed/javax/swing/JTable/6263446/bug6263446Table.java fails on MacOS Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JTable/6263446/bug6263446.java Changeset: 4b416a0180dc Author: lana Date: 2011-11-29 15:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b416a0180dc Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 45eb5a61da07 Author: lana Date: 2011-11-30 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/45eb5a61da07 Merge Changeset: 79b5c5a8c7e9 Author: serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79b5c5a8c7e9 7115400: jdk 8 awt-gate build fails in headless toolkit on solaris. Reviewed-by: prr, art, bae ! make/sun/awt/FILES_c_unix.gmk + src/solaris/native/sun/awt/HeadlessToolkit.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h Changeset: 2b1438297561 Author: lana Date: 2011-12-06 16:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2b1438297561 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h Changeset: 387190e1f782 Author: chegar Date: 2011-11-25 10:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/387190e1f782 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java Changeset: e5ecbf555679 Author: chegar Date: 2011-11-25 13:46 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e5ecbf555679 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Reviewed-by: chegar, alanb Contributed-by: sajia at taobao.com ! src/share/classes/sun/nio/ch/SocketAdaptor.java Changeset: 022540b11147 Author: weijun Date: 2011-11-28 18:16 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/022540b11147 7115744: Do not call File::deleteOnExit in security tests Reviewed-by: xuelei ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java Changeset: d1928ae4e0a2 Author: xuelei Date: 2011-11-28 02:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d1928ae4e0a2 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java Changeset: 955aae8c1106 Author: ngmr Date: 2011-11-24 11:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/955aae8c1106 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 6fbd69f8e3ab Author: ngmr Date: 2011-11-18 09:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6fbd69f8e3ab 7094995: Trailing daemon thread causes continuous GC in agentvm mode Summary: Shutdown GcInducingThread once test (successfully) finishes Reviewed-by: alanb, chegar, dholmes, darcy Contributed-by: Neil Richards ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Changeset: cf47846165f4 Author: dholmes Date: 2011-11-29 00:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf47846165f4 7109092: Wrong computation results with double at armsflt Summary: need to link to custom soft-float library with required FP accuracy Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk Changeset: a47de985fec9 Author: sherman Date: 2011-11-29 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a47de985fec9 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Summary: updated to zlib-1.2.5 Reviewed-by: alanb ! make/common/Defs.gmk ! make/java/zip/FILES_c.gmk ! make/sun/splashscreen/FILES_c.gmk - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.5/ChangeLog + src/share/native/java/util/zip/zlib-1.2.5/README + src/share/native/java/util/zip/zlib-1.2.5/compress.c + src/share/native/java/util/zip/zlib-1.2.5/crc32.h + src/share/native/java/util/zip/zlib-1.2.5/deflate.c + src/share/native/java/util/zip/zlib-1.2.5/deflate.h + src/share/native/java/util/zip/zlib-1.2.5/gzclose.c + src/share/native/java/util/zip/zlib-1.2.5/gzguts.h + src/share/native/java/util/zip/zlib-1.2.5/gzlib.c + src/share/native/java/util/zip/zlib-1.2.5/gzread.c + src/share/native/java/util/zip/zlib-1.2.5/gzwrite.c + src/share/native/java/util/zip/zlib-1.2.5/infback.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.h + src/share/native/java/util/zip/zlib-1.2.5/inffixed.h + src/share/native/java/util/zip/zlib-1.2.5/inflate.c + src/share/native/java/util/zip/zlib-1.2.5/inflate.h + src/share/native/java/util/zip/zlib-1.2.5/inftrees.c + src/share/native/java/util/zip/zlib-1.2.5/inftrees.h + src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.5/trees.c + src/share/native/java/util/zip/zlib-1.2.5/trees.h + src/share/native/java/util/zip/zlib-1.2.5/uncompr.c + src/share/native/java/util/zip/zlib-1.2.5/zadler32.c + src/share/native/java/util/zip/zlib-1.2.5/zconf.h + src/share/native/java/util/zip/zlib-1.2.5/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.5/zlib.h + src/share/native/java/util/zip/zlib-1.2.5/zutil.c + src/share/native/java/util/zip/zlib-1.2.5/zutil.h + test/java/util/zip/DeInflate.java Changeset: 07e359b01d8a Author: sherman Date: 2011-11-29 13:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/07e359b01d8a 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: added methods Adler32/CRC32.update(ByteBuffer) Reviewed-by: alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c + test/java/util/zip/TimeChecksum.java Changeset: c5313d712ab0 Author: lana Date: 2011-11-29 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a3edcdff37e1 Merge Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4749df4f04f1 7030624: size_t usages in src/windows/native/java/io/io_util_md.c need to be re-visited Reviewed-by: lancea, chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h Changeset: 7795c41ed54c Author: alanb Date: 2011-11-30 12:42 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7795c41ed54c 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) Reviewed-by: lancea, chegar, smarks ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java Changeset: 43a630f11af6 Author: smarks Date: 2011-11-30 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43a630f11af6 7116322: enhance javac make rule with a little bit of instrumentation Reviewed-by: dholmes, ohair ! make/common/Rules.gmk Changeset: 3b8186aee592 Author: chegar Date: 2011-12-01 11:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b8186aee592 7116722: Miscellaneous warnings sun.misc ( and related classes ) Reviewed-by: alanb, darcy, forax, hawtin, lancea ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/Signal.java ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: 89130611b178 Author: mcimadamore Date: 2011-12-01 18:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89130611b178 7116954: Misc warnings in java.beans/java.beans.context Summary: Remove generic warnings form java.beans and java.beans.context Reviewed-by: alanb, chegar ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/ChangeListenerMap.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/NameGenerator.java ! src/share/classes/java/beans/PersistenceDelegate.java ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/SimpleBeanInfo.java ! src/share/classes/java/beans/Statement.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/beans/beancontext/BeanContext.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java Changeset: 0e3f706741ca Author: smarks Date: 2011-12-01 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e3f706741ca 7116890: additional warnings fixes for java.io Reviewed-by: alanb, smarks Contributed-by: Sebastian Sickelmann ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java Changeset: b03da32c3186 Author: peytoia Date: 2011-12-02 16:09 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b03da32c3186 7056472: Speed up test/java/util/ResourceBundle/Control/ExpirationTest.sh Reviewed-by: okutsu - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: f615db07991e Author: chegar Date: 2011-12-02 11:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f615db07991e 7116946: JSSecurityManager should use java.util.ServiceLoader to lookup service providers Reviewed-by: prr ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: 37f6e294759f Author: chegar Date: 2011-12-02 14:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37f6e294759f 7116957: javax.script.ScriptEngineManager should use java.util.ServiceLoader to lookup service providers Reviewed-by: alanb, lancea ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java Changeset: 9950e2c9f3b5 Author: alanb Date: 2011-12-02 17:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9950e2c9f3b5 7117357: Warnings in sun.instrument, tools and other sun.* classes Reviewed-by: lancea, chegar ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/protocol/jar/Handler.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java Changeset: 42532a097816 Author: naoto Date: 2011-12-02 16:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42532a097816 7117465: Warning cleanup for IMF classes Reviewed-by: okutsu ! src/share/classes/java/awt/im/InputMethodHighlight.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodContext.java ! src/share/classes/sun/awt/im/InputMethodJFrame.java ! src/share/classes/sun/awt/im/InputMethodManager.java ! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java Changeset: 1d7037df65ed Author: sherman Date: 2011-12-02 16:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d7037df65ed 5035850: (str) String.CASE_INSENSITIVE_ORDER should override readResolve() Summary: Fix to ensure singleton property of String.CaseInsensitiveComparator is maintained through de/serialization. Reviewed-by: alanb, forax, smarks, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/lang/String.java + test/java/lang/String/CaseInsensitiveComparator.java Changeset: 98502d7a3f98 Author: mchung Date: 2011-12-02 16:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98502d7a3f98 7117585: Eliminate java.lang.instrument, java.lang.management warnings Reviewed-by: mchung Contributed-by: Jon VanAlten ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java Changeset: 3c524deb8431 Author: lancea Date: 2011-12-02 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c524deb8431 7116445: Miscellaneous warnings in the JDBC/RowSet classes Reviewed-by: smarks, chegar ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/share/classes/com/sun/rowset/internal/Row.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: f2a5d0001f15 Author: okutsu Date: 2011-12-03 10:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2a5d0001f15 7117487: Warnings Cleanup: some i18n classes in java.util and sun.util Reviewed-by: lancea, naoto ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/sun/util/calendar/BaseCalendar.java ! src/share/classes/sun/util/calendar/CalendarSystem.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java Changeset: 2ae848ea980a Author: weijun Date: 2011-12-05 10:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ae848ea980a 7116857: Warnings in javax.security and some sun.misc Reviewed-by: smarks ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 053cb321467a Author: alanb Date: 2011-12-05 12:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/053cb321467a 7117717: (aio) Tests failing due to implementation bug 7052549 Reviewed-by: weijun, chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: da28826c5672 Author: alanb Date: 2011-12-05 12:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da28826c5672 Merge Changeset: f352dd3cdff8 Author: dl Date: 2011-12-05 13:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f352dd3cdff8 7117360: Warnings in java.util.concurrent.atomic package Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java Changeset: 194faa6fdb3c Author: sherman Date: 2011-12-05 10:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/194faa6fdb3c 5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier() incorrect return value Summary: updated the incorrect StringBuilder constructor usage Reviewed-by: dholmes, sherman Contributed-by: brandon.passanisi at oracle.com ! src/share/classes/java/util/Formatter.java + test/java/util/MissingFormatArgumentException/GetFormatSpecifier.java Changeset: ca383e32deaf Author: peytoia Date: 2011-12-06 08:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ca383e32deaf 7116914: Miscellaneous warnings (sun.text) Reviewed-by: smarks, okutsu ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java Changeset: f4fe86bba8a2 Author: smarks Date: 2011-12-05 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4fe86bba8a2 7116993: fix warnings in java.applet Reviewed-by: art, smarks Contributed-by: Danesh Dadachanji ! src/share/classes/java/applet/Applet.java Changeset: 85363edbc92f Author: naoto Date: 2011-12-05 17:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85363edbc92f 7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes Reviewed-by: okutsu, smarks ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! src/share/classes/sun/util/resources/LocaleData.java Changeset: 77f6d4360f4b Author: smarks Date: 2011-12-06 10:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77f6d4360f4b 7116997: fix warnings in java.util.PropertyPermission Reviewed-by: smarks Contributed-by: Brandon Passanisi ! src/share/classes/java/util/PropertyPermission.java Changeset: b71d1acfae52 Author: lana Date: 2011-12-06 20:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b71d1acfae52 Merge ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: cd95291bbbf3 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd95291bbbf3 Added tag jdk8-b17 for changeset b71d1acfae52 ! .hgtags Changeset: 8f3d916a9164 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8f3d916a9164 Added tag jdk8-b16 for changeset 929597c6e777 ! .hgtags Changeset: e55ac966ed95 Author: katleman Date: 2011-12-15 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e55ac966ed95 Merge ! .hgtags - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh From john.coomes at oracle.com Fri Dec 16 17:41:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 17 Dec 2011 01:41:53 +0000 Subject: hg: hsx/hsx23/hotspot: 34 new changesets Message-ID: <20111217014302.E92AF4774E@hg.openjdk.java.net> Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/698a22e99f74 Added tag jdk8-b17 for changeset d1f29d4e0bc6 ! .hgtags Changeset: 09f3b8a372b2 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/09f3b8a372b2 Added tag jdk8-b16 for changeset d1f29d4e0bc6 ! .hgtags Changeset: e46c2339d0fc Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: cf4dd13bbcd3 Author: jcoomes Date: 2011-12-02 21:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cf4dd13bbcd3 7117536: new hotspot build - hs23-b08 Reviewed-by: johnc ! make/hotspot_version Changeset: cd00eaeebef6 Author: phh Date: 2011-12-05 12:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cd00eaeebef6 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot Summary: Add a file, globals_ext.hpp, containing a null interface, to be replaced by a vendor in altsrc as needed. Reviewed-by: coleenp, kamg, dholmes, johnc, jrose ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/runtime/globals_ext.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 8657ec177a14 Author: dcubed Date: 2011-12-05 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/8657ec177a14 7117748: SA_APPLE_BOOT_JAVA and ALWAYS_PASS_TEST_GAMMA settings should not be required on MacOS X Summary: Replace SA_APPLE_BOOT_JAVA with logic that checks the boot JDK for the location of JDI classes. ALWAYS_PASS_TEST_GAMMA is true by default on Darwin. Reviewed-by: kvn, swingler ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/sa.make Changeset: 41cce03b29a8 Author: dcubed Date: 2011-12-06 05:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/41cce03b29a8 Merge Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/03865c41c4f3 Merge ! src/share/vm/runtime/globals.hpp Changeset: 55d777c0860a Author: dcubed Date: 2011-12-07 07:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/55d777c0860a 7118648: disable compressed oops by default on MacOS X until 7118647 is fixed Summary: UseCompressedOops is false by default on MacOS X; can still be set manually Reviewed-by: jmelvin, kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: e8fdaf4a66cb Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e8fdaf4a66cb 7110586: C2 generates incorrect results Summary: Exact limit of empty loop calculated incorrectly. Reviewed-by: iveresov, never ! src/share/vm/opto/loopnode.cpp + test/compiler/7110586/Test7110586.java Changeset: 8c57262447d3 Author: kvn Date: 2011-11-14 18:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/8c57262447d3 7105605: Use EA info to optimize pointers compare Summary: optimize pointers compare using EA information. Reviewed-by: never, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 6729bbc1fcd6 Author: twisti Date: 2011-11-16 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6729bbc1fcd6 7003454: order constants in constant table by number of references in code Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.hpp Changeset: 1bd45abaa507 Author: kvn Date: 2011-11-16 09:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1bd45abaa507 6890673: Eliminate allocations immediately after EA Summary: Try to eliminate allocations and related locks immediately after escape analysis. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 973293defacd Author: iveresov Date: 2011-11-16 19:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/973293defacd 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks Summary: Move the inlinee invoke notification callback into inlinee preamble Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! test/compiler/6792161/Test6792161.java Changeset: a04a201f0f5a Author: twisti Date: 2011-11-17 04:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a04a201f0f5a 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Reviewed-by: kvn, never ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: 59bc0d4d9ea3 Author: never Date: 2011-11-18 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/59bc0d4d9ea3 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Reviewed-by: kvn, iveresov, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 7793051af7d6 Author: twisti Date: 2011-11-21 00:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/7793051af7d6 7110058: change default for ScavengeRootsInCode to 2 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp Changeset: f03a3c8bd5e5 Author: roland Date: 2011-09-14 09:22 +0200 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f03a3c8bd5e5 7077312: Provide a CALL effect for instruct declaration in the ad file Summary: abstracted way to declare that the MachNode has the effect of a call (kills caller save registers, preserves callee save registers) Reviewed-by: twisti, never ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp Changeset: db2e64ca2d5a Author: roland Date: 2011-11-22 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/db2e64ca2d5a 7090968: Allow adlc register class to depend on runtime conditions Summary: allow reg_class definition as a function. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/matcher.hpp Changeset: cc81b9c09bbb Author: kvn Date: 2011-11-28 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cc81b9c09bbb 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 97825a4f7369 Author: iveresov Date: 2011-11-30 17:35 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/97825a4f7369 7116795: Tiered: enable by default for server Summary: Enable tiered compilation on server VM by default Reviewed-by: kvn, never ! make/jprt.properties ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: f745b2be3737 Author: kvn Date: 2011-12-02 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f745b2be3737 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Summary: Delay memory node transformation until the memory is processed. Reviewed-by: iveresov, never ! src/share/vm/opto/memnode.cpp Changeset: 81f7362f7bed Author: kvn Date: 2011-12-08 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/81f7362f7bed Merge ! make/jprt.properties ! src/share/vm/runtime/globals.hpp Changeset: 4406629aa157 Author: johnc Date: 2011-12-02 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4406629aa157 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj Summary: As a result of the changes for 4965777, the G1 reference field scanning closure could be applied to the discovered field of a reference object twice. The failing assert is too strong if the result of the first application of the closure is stolen, and the referenced object, evacuated by another worker thread. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: e37aedaedccd Author: tonyp Date: 2011-12-05 12:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e37aedaedccd Merge Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f1391adc6681 7112034: Parallel CMS fails to properly mark reference objects Summary: Enabled reference processing when work stealing during concurrent marking Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f4414323345f Author: stefank Date: 2011-11-28 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f4414323345f 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM Summary: Changed the conditional to see if the precompiled header has been specified. Also, removed the unused PrecompiledOption. Reviewed-by: dholmes, brutisso ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/gcc.make Changeset: d23d2b18183e Author: tonyp Date: 2011-12-07 12:54 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d23d2b18183e 7118202: G1: eden size unnecessarily drops to a minimum Summary: An integer underflow can cause the RSet lengths to be massively overpredicted which forces the eden size to the minimum. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: e9b91fd07263 Author: jmasa Date: 2011-12-09 06:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e9b91fd07263 Merge Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6d7d0790074d 7119584: UseParallelGC barrier task can be overwritten. Summary: Provoke a GC for a metadata allocation failure. Reviewed-by: johnc, iveresov ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp Changeset: 3b688d6ff3d0 Author: fparain Date: 2011-12-14 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3b688d6ff3d0 7104647: Adding a diagnostic command framework Reviewed-by: phh, dcubed ! src/share/vm/services/attachListener.cpp + src/share/vm/services/diagnosticArgument.cpp + src/share/vm/services/diagnosticArgument.hpp + src/share/vm/services/diagnosticCommand.cpp + src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticFramework.cpp + src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: 31f6f10e4379 Author: vladidan Date: 2011-12-14 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/31f6f10e4379 Merge Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/61165f53f165 Added tag hs23-b08 for changeset a2fef924d8e6 ! .hgtags From john.coomes at oracle.com Fri Dec 16 23:40:57 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 17 Dec 2011 07:40:57 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20111217074114.68B4147750@hg.openjdk.java.net> Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/698a22e99f74 Added tag jdk8-b17 for changeset d1f29d4e0bc6 ! .hgtags Changeset: 09f3b8a372b2 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/09f3b8a372b2 Added tag jdk8-b16 for changeset d1f29d4e0bc6 ! .hgtags Changeset: e46c2339d0fc Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/61165f53f165 Added tag hs23-b08 for changeset a2fef924d8e6 ! .hgtags Changeset: 434acc838772 Author: amurillo Date: 2011-12-16 12:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version From thomas.wuerthinger at oracle.com Tue Dec 20 13:26:38 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 20 Dec 2011 22:26:38 +0100 Subject: Request for review: 7064927: retransformClasses() does not pass in LocalVariableTable of a method In-Reply-To: <4EC0F8F3.9030801@oracle.com> References: <4EC0F8F3.9030801@oracle.com> Message-ID: <4EF0FD8E.8090805@oracle.com> Hi! I'd like to resend my request for review and kindly ask for a review for my patch that fixes bug number 7064927. The webrev is available at: http://cr.openjdk.java.net/~coleenp/7064927/ Thanks, thomas On 14.11.2011 12:18, Thomas Wuerthinger wrote: > Hi! > > An open webrev of the patch that fixes bug 7064927 is available at: > http://cr.openjdk.java.net/~coleenp/7064927/ > The bug is described at: http://bugs.sun.com/view_bug.do?bug_id=7064927 > > Thanks, thomas From paul.hohensee at oracle.com Tue Dec 20 14:09:44 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 20 Dec 2011 17:09:44 -0500 Subject: Request for review: 7064927: retransformClasses() does not pass in LocalVariableTable of a method In-Reply-To: <4EF0FD8E.8090805@oracle.com> References: <4EC0F8F3.9030801@oracle.com> <4EF0FD8E.8090805@oracle.com> Message-ID: <4EF107A8.4030106@oracle.com> Looks good, except that the LocalVariableTable attribute comments in write_code_attribute() and write_local_variable_table_attribute() don't match. The comment in the latter says "LineNumberTable" instead of "LocalVariableTable" and the descriptor is for the line number table rather than the local variable table. The comment in the former is missing "local_variable_table[local_variable_table_length];" Paul On 12/20/11 4:26 PM, Thomas Wuerthinger wrote: > Hi! > > I'd like to resend my request for review and kindly ask for a review > for my patch that fixes bug number 7064927. > The webrev is available at: http://cr.openjdk.java.net/~coleenp/7064927/ > > Thanks, thomas > > > On 14.11.2011 12:18, Thomas Wuerthinger wrote: >> Hi! >> >> An open webrev of the patch that fixes bug 7064927 is available at: >> http://cr.openjdk.java.net/~coleenp/7064927/ >> The bug is described at: http://bugs.sun.com/view_bug.do?bug_id=7064927 >> >> Thanks, thomas > From jon.masamitsu at oracle.com Tue Dec 20 20:58:28 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 21 Dec 2011 04:58:28 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20111221045845.8A02347776@hg.openjdk.java.net> Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c648b9ad052 7121373: Clean up CollectedHeap::is_in Summary: Fixed G1CollectedHeap::is_in, added tests, cleaned up comments and made Space::is_in pure virtual. Reviewed-by: brutisso, tonyp, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/quickSort.hpp Changeset: fd2b426c30db Author: johnc Date: 2011-12-14 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd2b426c30db 7119908: G1: Cache CSet start region for each worker for subsequent reuse Summary: Cache workers' calculated starting heap region, used for parallel iteration over the collcection set, for subsequent reuse. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 41406797186b Author: tonyp Date: 2011-12-16 02:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41406797186b 7113012: G1: rename not-fully-young GCs as "mixed" Summary: Renamed partially-young GCs as mixed and fully-young GCs as young. Change all external output that includes those terms (GC log and GC ergo log) as well as any comments, fields, methods, etc. The changeset also includes very minor code tidying up (added some curly brackets). Reviewed-by: johnc, brutisso ! 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/g1ErgoVerbose.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp Changeset: adedfbbf0360 Author: johnc Date: 2011-12-16 11:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/adedfbbf0360 7120038: G1: ParallelGCThreads==0 is broken Summary: Running G1 with ParallelGCThreads==0 results in various crashes and asserts. Most of these are caused by unguarded references to the worker threads array or an incorrect number of active workers. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: e7dead7e90af Author: johnc Date: 2011-12-19 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e7dead7e90af 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp. Reviewed-by: dholmes, ysr ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 129cd462ae89 Author: jmasa Date: 2011-12-20 12:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/129cd462ae89 Merge From thomas.wuerthinger at oracle.com Wed Dec 21 12:35:16 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 21 Dec 2011 21:35:16 +0100 Subject: Request for review: 7064927: retransformClasses() does not pass in LocalVariableTable of a method In-Reply-To: <4EF107A8.4030106@oracle.com> References: <4EC0F8F3.9030801@oracle.com> <4EF0FD8E.8090805@oracle.com> <4EF107A8.4030106@oracle.com> Message-ID: <4EF24304.9080404@oracle.com> Thanks for the review. I've corrected the comments and created a new webrev at: http://cr.openjdk.java.net/~thomaswue/7064927/webrev.00/ - thomas On 20.12.2011 23:09, Paul Hohensee wrote: > Looks good, except that the LocalVariableTable attribute comments in > write_code_attribute() and write_local_variable_table_attribute() don't > match. The comment in the latter says "LineNumberTable" instead > of "LocalVariableTable" and the descriptor is for the line number table > rather than the local variable table. The comment in the former is > missing > "local_variable_table[local_variable_table_length];" > > Paul > > On 12/20/11 4:26 PM, Thomas Wuerthinger wrote: >> Hi! >> >> I'd like to resend my request for review and kindly ask for a review >> for my patch that fixes bug number 7064927. >> The webrev is available at: http://cr.openjdk.java.net/~coleenp/7064927/ >> >> Thanks, thomas >> >> >> On 14.11.2011 12:18, Thomas Wuerthinger wrote: >>> Hi! >>> >>> An open webrev of the patch that fixes bug 7064927 is available at: >>> http://cr.openjdk.java.net/~coleenp/7064927/ >>> The bug is described at: http://bugs.sun.com/view_bug.do?bug_id=7064927 >>> >>> Thanks, thomas >> From paul.hohensee at oracle.com Wed Dec 21 12:59:34 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 21 Dec 2011 15:59:34 -0500 Subject: Request for review: 7064927: retransformClasses() does not pass in LocalVariableTable of a method In-Reply-To: <4EF24304.9080404@oracle.com> References: <4EC0F8F3.9030801@oracle.com> <4EF0FD8E.8090805@oracle.com> <4EF107A8.4030106@oracle.com> <4EF24304.9080404@oracle.com> Message-ID: <4EF248B6.2080908@oracle.com> Looks good. Thanks, Paul On 12/21/11 3:35 PM, Thomas Wuerthinger wrote: > Thanks for the review. I've corrected the comments and created a new > webrev at: http://cr.openjdk.java.net/~thomaswue/7064927/webrev.00/ > > - thomas > > > On 20.12.2011 23:09, Paul Hohensee wrote: >> Looks good, except that the LocalVariableTable attribute comments in >> write_code_attribute() and write_local_variable_table_attribute() don't >> match. The comment in the latter says "LineNumberTable" instead >> of "LocalVariableTable" and the descriptor is for the line number table >> rather than the local variable table. The comment in the former is >> missing >> "local_variable_table[local_variable_table_length];" >> >> Paul >> >> On 12/20/11 4:26 PM, Thomas Wuerthinger wrote: >>> Hi! >>> >>> I'd like to resend my request for review and kindly ask for a review >>> for my patch that fixes bug number 7064927. >>> The webrev is available at: >>> http://cr.openjdk.java.net/~coleenp/7064927/ >>> >>> Thanks, thomas >>> >>> >>> On 14.11.2011 12:18, Thomas Wuerthinger wrote: >>>> Hi! >>>> >>>> An open webrev of the patch that fixes bug 7064927 is available at: >>>> http://cr.openjdk.java.net/~coleenp/7064927/ >>>> The bug is described at: >>>> http://bugs.sun.com/view_bug.do?bug_id=7064927 >>>> >>>> Thanks, thomas >>> > From vladimir.danushevsky at oracle.com Thu Dec 22 10:37:44 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 22 Dec 2011 18:37:44 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20111222183800.8AA1547796@hg.openjdk.java.net> Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/96ce4c27112f 7122939: TraceBytecodes broken with UseCompressedOops Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register Reviewed-by: coleenp, phh Contributed-by: Volker Simonis ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c995c08526c 7122880: Extend vendor-specific command interface to include manageable switches Summary: Add Flag::external_ext()/writable_ext(), both return false. Reviewed-by: coleenp, zgu ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_ext.hpp ! src/share/vm/services/management.cpp Changeset: 4502fd5c7698 Author: phh Date: 2011-12-19 21:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4502fd5c7698 Merge Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11c26bfcf8c7 7091417: recvfrom's 6th input should be of type socklen_t Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp. Reviewed-by: coleenp, dholmes Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c01e115b095e 7064927: retransformClasses() does not pass in LocalVariableTable of a method Summary: Handle LVT attribute in the class file reconstitutor. Reviewed-by: phh, coleenp Contributed-by: thomaswue ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: d532160c55f7 Author: coleenp Date: 2011-12-21 18:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d532160c55f7 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4b18532913c7 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp From mark.reinhold at oracle.com Thu Dec 22 15:05:42 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 22 Dec 2011 15:05:42 -0800 (PST) Subject: JEP 132: More-prompt finalization Message-ID: <20111222230542.48A451084@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/132 - Mark From david.holmes at oracle.com Thu Dec 22 18:15:43 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Dec 2011 12:15:43 +1000 Subject: JEP 132: More-prompt finalization In-Reply-To: <20111222230542.48A451084@eggemoggin.niobe.net> References: <20111222230542.48A451084@eggemoggin.niobe.net> Message-ID: <4EF3E44F.1060409@oracle.com> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/132 hotspot-dev seems the wrong mailing list to discuss this. It is primarily a Java level API. I would suggest using core-libs-dev. David From john.coomes at oracle.com Thu Dec 22 20:36:10 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:36:10 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b18 for changeset 7010bd24cdd0 Message-ID: <20111223043610.61F12477A7@hg.openjdk.java.net> Changeset: e1fc13802e0c Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e1fc13802e0c Added tag jdk8-b18 for changeset 7010bd24cdd0 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:36:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:36:17 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b18 for changeset 312cf15d1657 Message-ID: <20111223043619.6248E477A8@hg.openjdk.java.net> Changeset: 46bd4a46a5a8 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/46bd4a46a5a8 Added tag jdk8-b18 for changeset 312cf15d1657 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:36:26 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:36:26 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b18 for changeset ebec6a7e8d4e Message-ID: <20111223043626.7D67A477A9@hg.openjdk.java.net> Changeset: 5fb25931f1c2 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5fb25931f1c2 Added tag jdk8-b18 for changeset ebec6a7e8d4e ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:36:34 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:36:34 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b18 for changeset 54928c8850f5 Message-ID: <20111223043634.21E92477AA@hg.openjdk.java.net> Changeset: 72d410c3bab1 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/72d410c3bab1 Added tag jdk8-b18 for changeset 54928c8850f5 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:37:30 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:37:30 +0000 Subject: hg: hsx/hotspot-main/jdk: 6 new changesets Message-ID: <20111223043857.C4A5C477AB@hg.openjdk.java.net> Changeset: 134420afe9c2 Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/134420afe9c2 7109885: security baseline for 7u2 or above is not set correctly Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: 6f594239e9dc Author: ngthomas Date: 2011-11-15 23:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f594239e9dc 7112298: remove security baseline sanity check Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: fcc7cafa0027 Author: herrick Date: 2011-11-18 06:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fcc7cafa0027 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 526e99f06a59 Author: igor Date: 2011-12-06 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/526e99f06a59 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 334bd51fb3f3 Author: igor Date: 2011-12-19 10:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/334bd51fb3f3 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: c6fab5332075 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6fab5332075 Added tag jdk8-b18 for changeset 334bd51fb3f3 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:42:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:42:27 +0000 Subject: hg: hsx/hotspot-main/langtools: 14 new changesets Message-ID: <20111223044300.4FEE8477AC@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c896d95e7469 7115046: Add AST node for lambda expressions Summary: Add tree nodes for representing lambda expressions and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: ec59a2ce9114 Author: mcimadamore Date: 2011-11-24 13:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ec59a2ce9114 7115049: Add AST node for method references Summary: Add tree nodes for representing method/constructor references and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: 9448fe783fd2 Author: mcimadamore Date: 2011-11-28 15:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9448fe783fd2 7115050: Add parser support for lambda expressions Summary: Add support for parsing lambda expressions to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/LambdaNotSupported.java + test/tools/javac/diags/examples/NotAStatement.java ! test/tools/javac/generics/rare/6665356/T6665356.out + test/tools/javac/lambda/LambdaParserTest.java Changeset: 3343b22e2761 Author: mcimadamore Date: 2011-11-28 16:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3343b22e2761 7115052: Add parser support for method references Summary: Add support for parsing method references to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/MethodReferencesNotSupported.java + test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out Changeset: 2584f5358cba Author: lana Date: 2011-12-06 20:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2584f5358cba Merge Changeset: abfa0d8ea803 Author: ksrini Date: 2011-12-07 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/abfa0d8ea803 7086015: fix test/tools/javac/parser/netbeans/JavacParserTest.java Reviewed-by: ksrini, jjg Contributed-by: matherey.nunez at oracle.com ! test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 9350d0498d21 Author: ksrini Date: 2011-12-09 08:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9350d0498d21 7119032: (javac) increase visibility of JavacParser methods to improve subtyping Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: e7d5e1a7cde5 Author: ksrini Date: 2011-12-10 17:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e7d5e1a7cde5 7119487: JavacParserTest.java test fails on Windows platforms Reviewed-by: jjg + test/tools/javac/parser/JavacParserTest.java - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: e55270a7a022 Author: mcimadamore Date: 2011-12-11 17:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e55270a7a022 7120266: javac fails to compile hotspot code Summary: Parser changes for method references cause bad intercation with method call syntax Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T7120266.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 1cbe86c11ba6 Author: lana Date: 2011-12-12 10:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1cbe86c11ba6 Merge - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 55a49c399603 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/55a49c399603 Added tag jdk8-b17 for changeset 1cbe86c11ba6 ! .hgtags Changeset: 29a512337b79 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/29a512337b79 Added tag jdk8-b16 for changeset ec2c0973cc31 ! .hgtags Changeset: ab1b1cc78577 Author: katleman Date: 2011-12-15 15:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ab1b1cc78577 Merge ! .hgtags - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 3c71fcc22b99 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3c71fcc22b99 Added tag jdk8-b18 for changeset ab1b1cc78577 ! .hgtags From mark.reinhold at oracle.com Thu Dec 22 21:04:48 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 22 Dec 2011 21:04:48 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: david.holmes@oracle.com; Fri, 23 Dec 2011 12:15:43 +1000; <4EF3E44F.1060409@oracle.com> Message-ID: <20111223050448.7B8C11030@eggemoggin.niobe.net> 2011/12/22 18:15 -0800, david.holmes at oracle.com: > On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/132 > > hotspot-dev seems the wrong mailing list to discuss this. It is primarily a > Java level API. I would suggest using core-libs-dev. Perhaps so, but the discussion list is specified by the JEP's author, in this case Jon Masamitsu, and in a private e-mail he indicated that he expects there eventually to be a separate JEP for the API work, so I left the discussion list as-is. - Mark From jon.masamitsu at oracle.com Fri Dec 23 08:13:24 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 23 Dec 2011 08:13:24 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF3E44F.1060409@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> Message-ID: <4EF4A8A4.1060502@oracle.com> David, From the VM side there are two issues that I think we should understand better before we work on an API. Those are described in the JEP as 1) more aggressive management of the of finalization queue and 2) multiple finalizer threads. We should see how much of the problem can be alleviated by either or both or by other VM side changes that occur to us during the work and then think about what is left and what information we want from the user to address what's left. As Mark has said, I think there will be a library side JEP at some point for those discussions. Jon On 12/22/2011 6:15 PM, David Holmes wrote: > On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/132 > > hotspot-dev seems the wrong mailing list to discuss this. It is > primarily a Java level API. I would suggest using core-libs-dev. > > David From ysr1729 at gmail.com Fri Dec 23 08:24:57 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 23 Dec 2011 08:24:57 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF4A8A4.1060502@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> Message-ID: Hi Jon, That is true. However, those modifications are in the core libraries. The VM<->JDK library interaction ceases, in some sense, at the GC<->RefHandler boundary. So I tend to agree with David that the immediately-affected APIs and their implementation (also mentioned by you above) are in the core libraries. It makes sense to include the core-libs alias into the discussion. The JEP also mentions modifications to he RefHandler thread (and, between the lines, perhaps has the GC<->RefHandler interaction in mind?). One question: are the changes envisaged for the RefHandler thread going to affect the promptness of handling other Reference subtypes than just FinalReferences? PS: I am glad this JEP is being executed; Finalizers are not going to go away anytime soon, even though many applications have been rewritten to reduce their reliance on promptness o Finalization. Thus, this will help many many Java users out there. +1! thanks. -- ramki On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsu wrote: > David, > > From the VM side there are two issues that I think we should understand > better before we work on an API. Those are described in the JEP as > 1) more aggressive management of the of finalization queue and 2) multiple > finalizer threads. We should see how much of the problem can be > alleviated by either or both or by other VM side changes that occur to us > during the work and then think about what is left and what information > we want from the user to address what's left. As Mark has said, I > think there will be a library side JEP at some point for those discussions. > > Jon > > > On 12/22/2011 6:15 PM, David Holmes wrote: > >> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >> >>> Posted: http://openjdk.java.net/jeps/**132 >>> >> >> hotspot-dev seems the wrong mailing list to discuss this. It is primarily >> a Java level API. I would suggest using core-libs-dev. >> >> David >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111223/bff41daf/attachment.html From ysr1729 at gmail.com Fri Dec 23 08:27:43 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 23 Dec 2011 08:27:43 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> Message-ID: i.e. unless I minsunderstood "more aggressive management of the finalization queue" as something the JVM does based on its understanding of the dynamic demographics of FinalRefs or something like that. -- ramki On Fri, Dec 23, 2011 at 8:24 AM, Srinivas Ramakrishna wrote: > Hi Jon, > > That is true. However, those modifications are in the core libraries. The > VM<->JDK library interaction ceases, > in some sense, at the GC<->RefHandler boundary. So I tend to agree with > David that > the immediately-affected APIs and their implementation (also mentioned by > you above) > are in the core libraries. It makes sense to include the core-libs alias > into the discussion. > > The JEP also mentions modifications to he RefHandler thread (and, between > the lines, perhaps > has the GC<->RefHandler interaction in mind?). One question: are the > changes envisaged for > the RefHandler thread going to affect the promptness of handling other > Reference subtypes > than just FinalReferences? > > PS: I am glad this JEP is being executed; Finalizers are not going to go > away anytime soon, > even though many applications have been rewritten to reduce their reliance > on promptness > o Finalization. Thus, this will help many many Java users out there. +1! > > thanks. > -- ramki > > > On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsu wrote: > >> David, >> >> From the VM side there are two issues that I think we should understand >> better before we work on an API. Those are described in the JEP as >> 1) more aggressive management of the of finalization queue and 2) multiple >> finalizer threads. We should see how much of the problem can be >> alleviated by either or both or by other VM side changes that occur to us >> during the work and then think about what is left and what information >> we want from the user to address what's left. As Mark has said, I >> think there will be a library side JEP at some point for those >> discussions. >> >> Jon >> >> >> On 12/22/2011 6:15 PM, David Holmes wrote: >> >>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>> >>>> Posted: http://openjdk.java.net/jeps/**132 >>>> >>> >>> hotspot-dev seems the wrong mailing list to discuss this. It is >>> primarily a Java level API. I would suggest using core-libs-dev. >>> >>> David >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111223/4b317586/attachment.html From jon.masamitsu at oracle.com Fri Dec 23 08:49:02 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 23 Dec 2011 08:49:02 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> Message-ID: <4EF4B0FE.5000805@oracle.com> David and Ramki, I stand corrected. 1) and 2) in my reply are library changes. I'll modify the JEP and throw it over the fence :-) I guess I was thinking "what can we do before we have to think about an API". Ramki, that this JEP has been published doesn't mean that anyone is executing on the changes. If I understand the rules correctly, it just says "Here's an idea, anyone want to talk about it?" The state of the JEP is "posted". I think it changes to something else if it is actually worked on. I'm not working on it. Jon On 12/23/2011 8:24 AM, Srinivas Ramakrishna wrote: > Hi Jon, > > That is true. However, those modifications are in the core libraries. The > VM<->JDK library interaction ceases, > in some sense, at the GC<->RefHandler boundary. So I tend to agree with > David that > the immediately-affected APIs and their implementation (also mentioned by > you above) > are in the core libraries. It makes sense to include the core-libs alias > into the discussion. > > The JEP also mentions modifications to he RefHandler thread (and, between > the lines, perhaps > has the GC<->RefHandler interaction in mind?). One question: are the > changes envisaged for > the RefHandler thread going to affect the promptness of handling other > Reference subtypes > than just FinalReferences? > > PS: I am glad this JEP is being executed; Finalizers are not going to go > away anytime soon, > even though many applications have been rewritten to reduce their reliance > on promptness > o Finalization. Thus, this will help many many Java users out there. +1! > > thanks. > -- ramki > > On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsuwrote: > >> David, >> >> From the VM side there are two issues that I think we should understand >> better before we work on an API. Those are described in the JEP as >> 1) more aggressive management of the of finalization queue and 2) multiple >> finalizer threads. We should see how much of the problem can be >> alleviated by either or both or by other VM side changes that occur to us >> during the work and then think about what is left and what information >> we want from the user to address what's left. As Mark has said, I >> think there will be a library side JEP at some point for those discussions. >> >> Jon >> >> >> On 12/22/2011 6:15 PM, David Holmes wrote: >> >>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>> >>>> Posted: http://openjdk.java.net/jeps/**132 >>>> >>> hotspot-dev seems the wrong mailing list to discuss this. It is primarily >>> a Java level API. I would suggest using core-libs-dev. >>> >>> David >>> From jon.masamitsu at oracle.com Fri Dec 23 08:50:35 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 23 Dec 2011 08:50:35 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> Message-ID: <4EF4B15B.70402@oracle.com> Ramki, No you were right with your original thinking. Jon On 12/23/2011 8:27 AM, Srinivas Ramakrishna wrote: > i.e. unless I minsunderstood "more aggressive management of the > finalization queue" > as something the JVM does based on its understanding of the dynamic > demographics > of FinalRefs or something like that. > > -- ramki > > On Fri, Dec 23, 2011 at 8:24 AM, Srinivas Ramakrishnawrote: > >> Hi Jon, >> >> That is true. However, those modifications are in the core libraries. The >> VM<->JDK library interaction ceases, >> in some sense, at the GC<->RefHandler boundary. So I tend to agree with >> David that >> the immediately-affected APIs and their implementation (also mentioned by >> you above) >> are in the core libraries. It makes sense to include the core-libs alias >> into the discussion. >> >> The JEP also mentions modifications to he RefHandler thread (and, between >> the lines, perhaps >> has the GC<->RefHandler interaction in mind?). One question: are the >> changes envisaged for >> the RefHandler thread going to affect the promptness of handling other >> Reference subtypes >> than just FinalReferences? >> >> PS: I am glad this JEP is being executed; Finalizers are not going to go >> away anytime soon, >> even though many applications have been rewritten to reduce their reliance >> on promptness >> o Finalization. Thus, this will help many many Java users out there. +1! >> >> thanks. >> -- ramki >> >> >> On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsuwrote: >> >>> David, >>> >>> From the VM side there are two issues that I think we should understand >>> better before we work on an API. Those are described in the JEP as >>> 1) more aggressive management of the of finalization queue and 2) multiple >>> finalizer threads. We should see how much of the problem can be >>> alleviated by either or both or by other VM side changes that occur to us >>> during the work and then think about what is left and what information >>> we want from the user to address what's left. As Mark has said, I >>> think there will be a library side JEP at some point for those >>> discussions. >>> >>> Jon >>> >>> >>> On 12/22/2011 6:15 PM, David Holmes wrote: >>> >>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>> >>>>> Posted: http://openjdk.java.net/jeps/**132 >>>>> >>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>> primarily a Java level API. I would suggest using core-libs-dev. >>>> >>>> David >>>> From kirk at kodewerk.com Fri Dec 23 12:33:23 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Fri, 23 Dec 2011 21:33:23 +0100 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF4B15B.70402@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF4B15B.70402@oracle.com> Message-ID: <108EFA66-003E-4E71-8C8D-ED728F115A38@kodewerk.com> Hi all, I don't want to sound elitist about this but I would suggest caution when thinking about exposing Java level API to "control" finalization. It is my experience when talking about finalization that it is rare that developers (and I do talk to 100s of developers every year) have any idea about how finalization works. It is rare to find a developer that knows about the finalization thread let alone that there's a helper thread and other reference types to support the process. I'm happy that finalization is there and it works as intended and that the details are buried so I don't really have to think about them. Regards, Kirk On Dec 23, 2011, at 5:50 PM, Jon Masamitsu wrote: > Ramki, > > No you were right with your original thinking. > > Jon > > On 12/23/2011 8:27 AM, Srinivas Ramakrishna wrote: >> i.e. unless I minsunderstood "more aggressive management of the >> finalization queue" >> as something the JVM does based on its understanding of the dynamic >> demographics >> of FinalRefs or something like that. >> >> -- ramki >> >> On Fri, Dec 23, 2011 at 8:24 AM, Srinivas Ramakrishnawrote: >> >>> Hi Jon, >>> >>> That is true. However, those modifications are in the core libraries. The >>> VM<->JDK library interaction ceases, >>> in some sense, at the GC<->RefHandler boundary. So I tend to agree with >>> David that >>> the immediately-affected APIs and their implementation (also mentioned by >>> you above) >>> are in the core libraries. It makes sense to include the core-libs alias >>> into the discussion. >>> >>> The JEP also mentions modifications to he RefHandler thread (and, between >>> the lines, perhaps >>> has the GC<->RefHandler interaction in mind?). One question: are the >>> changes envisaged for >>> the RefHandler thread going to affect the promptness of handling other >>> Reference subtypes >>> than just FinalReferences? >>> >>> PS: I am glad this JEP is being executed; Finalizers are not going to go >>> away anytime soon, >>> even though many applications have been rewritten to reduce their reliance >>> on promptness >>> o Finalization. Thus, this will help many many Java users out there. +1! >>> >>> thanks. >>> -- ramki >>> >>> >>> On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsuwrote: >>> >>>> David, >>>> >>>> From the VM side there are two issues that I think we should understand >>>> better before we work on an API. Those are described in the JEP as >>>> 1) more aggressive management of the of finalization queue and 2) multiple >>>> finalizer threads. We should see how much of the problem can be >>>> alleviated by either or both or by other VM side changes that occur to us >>>> during the work and then think about what is left and what information >>>> we want from the user to address what's left. As Mark has said, I >>>> think there will be a library side JEP at some point for those >>>> discussions. >>>> >>>> Jon >>>> >>>> >>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>> >>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>> >>>>>> Posted: http://openjdk.java.net/jeps/**132 >>>>>> >>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>> >>>>> David >>>>> From ysr1729 at gmail.com Fri Dec 23 13:39:25 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 23 Dec 2011 13:39:25 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: <108EFA66-003E-4E71-8C8D-ED728F115A38@kodewerk.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF4B15B.70402@oracle.com> <108EFA66-003E-4E71-8C8D-ED728F115A38@kodewerk.com> Message-ID: As Jon stated, the API may not be necessary if the other enhancements pan out and provide enough improvement in the cases being looked at. There was some discussion of a "nudge the VM" variety, and you are right that such API's can be abused. For the kind of API that "nudge the VM to finalize/process Reference objects" probably entails, one would likely put in some defensive front-end boiler-plate to protect against abuse, especially when composing from multiple 3rd party libraries each of which may evolve to use its own "local" policy for nudging. The other thing that protects against abuse is when one finds that it hurts to carelessly (ab)use the API (witness the (ab)use of System.gc() in early versions of Java applications). -- ramki On Fri, Dec 23, 2011 at 12:33 PM, Charles K Pepperdine wrote: > Hi all, > > I don't want to sound elitist about this but I would suggest caution when > thinking about exposing Java level API to "control" finalization. It is my > experience when talking about finalization that it is rare that developers > (and I do talk to 100s of developers every year) have any idea about how > finalization works. It is rare to find a developer that knows about the > finalization thread let alone that there's a helper thread and other > reference types to support the process. I'm happy that finalization is > there and it works as intended and that the details are buried so I don't > really have to think about them. > > Regards, > Kirk > > On Dec 23, 2011, at 5:50 PM, Jon Masamitsu wrote: > > > Ramki, > > > > No you were right with your original thinking. > > > > Jon > > > > On 12/23/2011 8:27 AM, Srinivas Ramakrishna wrote: > >> i.e. unless I minsunderstood "more aggressive management of the > >> finalization queue" > >> as something the JVM does based on its understanding of the dynamic > >> demographics > >> of FinalRefs or something like that. > >> > >> -- ramki > >> > >> On Fri, Dec 23, 2011 at 8:24 AM, Srinivas Ramakrishna >wrote: > >> > >>> Hi Jon, > >>> > >>> That is true. However, those modifications are in the core libraries. > The > >>> VM<->JDK library interaction ceases, > >>> in some sense, at the GC<->RefHandler boundary. So I tend to agree with > >>> David that > >>> the immediately-affected APIs and their implementation (also mentioned > by > >>> you above) > >>> are in the core libraries. It makes sense to include the core-libs > alias > >>> into the discussion. > >>> > >>> The JEP also mentions modifications to he RefHandler thread (and, > between > >>> the lines, perhaps > >>> has the GC<->RefHandler interaction in mind?). One question: are the > >>> changes envisaged for > >>> the RefHandler thread going to affect the promptness of handling other > >>> Reference subtypes > >>> than just FinalReferences? > >>> > >>> PS: I am glad this JEP is being executed; Finalizers are not going to > go > >>> away anytime soon, > >>> even though many applications have been rewritten to reduce their > reliance > >>> on promptness > >>> o Finalization. Thus, this will help many many Java users out there. > +1! > >>> > >>> thanks. > >>> -- ramki > >>> > >>> > >>> On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsu< > jon.masamitsu at oracle.com>wrote: > >>> > >>>> David, > >>>> > >>>> From the VM side there are two issues that I think we should > understand > >>>> better before we work on an API. Those are described in the JEP as > >>>> 1) more aggressive management of the of finalization queue and 2) > multiple > >>>> finalizer threads. We should see how much of the problem can be > >>>> alleviated by either or both or by other VM side changes that occur > to us > >>>> during the work and then think about what is left and what information > >>>> we want from the user to address what's left. As Mark has said, I > >>>> think there will be a library side JEP at some point for those > >>>> discussions. > >>>> > >>>> Jon > >>>> > >>>> > >>>> On 12/22/2011 6:15 PM, David Holmes wrote: > >>>> > >>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: > >>>>> > >>>>>> Posted: http://openjdk.java.net/jeps/**132< > http://openjdk.java.net/jeps/132> > >>>>>> > >>>>> hotspot-dev seems the wrong mailing list to discuss this. It is > >>>>> primarily a Java level API. I would suggest using core-libs-dev. > >>>>> > >>>>> David > >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111223/b5fcfd53/attachment.html From Ulf.Zibis at gmx.de Fri Dec 23 14:43:43 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 23 Dec 2011 23:43:43 +0100 Subject: JEP 132: More-prompt finalization In-Reply-To: <108EFA66-003E-4E71-8C8D-ED728F115A38@kodewerk.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF4B15B.70402@oracle.com> <108EFA66-003E-4E71-8C8D-ED728F115A38@kodewerk.com> Message-ID: <4EF5041F.7020109@gmx.de> +1 -Ulf Am 23.12.2011 21:33, schrieb Charles K Pepperdine: > Hi all, > > I don't want to sound elitist about this but I would suggest caution when thinking about exposing Java level API to "control" finalization. It is my experience when talking about finalization that it is rare that developers (and I do talk to 100s of developers every year) have any idea about how finalization works. It is rare to find a developer that knows about the finalization thread let alone that there's a helper thread and other reference types to support the process. I'm happy that finalization is there and it works as intended and that the details are buried so I don't really have to think about them. > > Regards, > Kirk > > On Dec 23, 2011, at 5:50 PM, Jon Masamitsu wrote: > >> Ramki, >> >> No you were right with your original thinking. >> >> Jon >> >> On 12/23/2011 8:27 AM, Srinivas Ramakrishna wrote: >>> i.e. unless I minsunderstood "more aggressive management of the >>> finalization queue" >>> as something the JVM does based on its understanding of the dynamic >>> demographics >>> of FinalRefs or something like that. >>> >>> -- ramki >>> >>> On Fri, Dec 23, 2011 at 8:24 AM, Srinivas Ramakrishnawrote: >>> >>>> Hi Jon, >>>> >>>> That is true. However, those modifications are in the core libraries. The >>>> VM<->JDK library interaction ceases, >>>> in some sense, at the GC<->RefHandler boundary. So I tend to agree with >>>> David that >>>> the immediately-affected APIs and their implementation (also mentioned by >>>> you above) >>>> are in the core libraries. It makes sense to include the core-libs alias >>>> into the discussion. >>>> >>>> The JEP also mentions modifications to he RefHandler thread (and, between >>>> the lines, perhaps >>>> has the GC<->RefHandler interaction in mind?). One question: are the >>>> changes envisaged for >>>> the RefHandler thread going to affect the promptness of handling other >>>> Reference subtypes >>>> than just FinalReferences? >>>> >>>> PS: I am glad this JEP is being executed; Finalizers are not going to go >>>> away anytime soon, >>>> even though many applications have been rewritten to reduce their reliance >>>> on promptness >>>> o Finalization. Thus, this will help many many Java users out there. +1! >>>> >>>> thanks. >>>> -- ramki >>>> >>>> >>>> On Fri, Dec 23, 2011 at 8:13 AM, Jon Masamitsuwrote: >>>> >>>>> David, >>>>> >>>>> From the VM side there are two issues that I think we should understand >>>>> better before we work on an API. Those are described in the JEP as >>>>> 1) more aggressive management of the of finalization queue and 2) multiple >>>>> finalizer threads. We should see how much of the problem can be >>>>> alleviated by either or both or by other VM side changes that occur to us >>>>> during the work and then think about what is left and what information >>>>> we want from the user to address what's left. As Mark has said, I >>>>> think there will be a library side JEP at some point for those >>>>> discussions. >>>>> >>>>> Jon >>>>> >>>>> >>>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>> >>>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>> >>>>>>> Posted: http://openjdk.java.net/jeps/**132 >>>>>>> >>>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>>> >>>>>> David >>>>>> > From john.coomes at oracle.com Fri Dec 23 17:00:54 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 24 Dec 2011 01:00:54 +0000 Subject: hg: hsx/hsx23/hotspot: 17 new changesets Message-ID: <20111224010139.4D75A477D2@hg.openjdk.java.net> Changeset: 7e075537835d Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/7e075537835d Added tag jdk8-b18 for changeset 61165f53f165 ! .hgtags Changeset: 434acc838772 Author: amurillo Date: 2011-12-16 12:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3c648b9ad052 7121373: Clean up CollectedHeap::is_in Summary: Fixed G1CollectedHeap::is_in, added tests, cleaned up comments and made Space::is_in pure virtual. Reviewed-by: brutisso, tonyp, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/quickSort.hpp Changeset: fd2b426c30db Author: johnc Date: 2011-12-14 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/fd2b426c30db 7119908: G1: Cache CSet start region for each worker for subsequent reuse Summary: Cache workers' calculated starting heap region, used for parallel iteration over the collcection set, for subsequent reuse. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 41406797186b Author: tonyp Date: 2011-12-16 02:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/41406797186b 7113012: G1: rename not-fully-young GCs as "mixed" Summary: Renamed partially-young GCs as mixed and fully-young GCs as young. Change all external output that includes those terms (GC log and GC ergo log) as well as any comments, fields, methods, etc. The changeset also includes very minor code tidying up (added some curly brackets). Reviewed-by: johnc, brutisso ! 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/g1ErgoVerbose.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp Changeset: adedfbbf0360 Author: johnc Date: 2011-12-16 11:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/adedfbbf0360 7120038: G1: ParallelGCThreads==0 is broken Summary: Running G1 with ParallelGCThreads==0 results in various crashes and asserts. Most of these are caused by unguarded references to the worker threads array or an incorrect number of active workers. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: e7dead7e90af Author: johnc Date: 2011-12-19 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/e7dead7e90af 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp. Reviewed-by: dholmes, ysr ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 129cd462ae89 Author: jmasa Date: 2011-12-20 12:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/129cd462ae89 Merge Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/96ce4c27112f 7122939: TraceBytecodes broken with UseCompressedOops Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register Reviewed-by: coleenp, phh Contributed-by: Volker Simonis ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/6c995c08526c 7122880: Extend vendor-specific command interface to include manageable switches Summary: Add Flag::external_ext()/writable_ext(), both return false. Reviewed-by: coleenp, zgu ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_ext.hpp ! src/share/vm/services/management.cpp Changeset: 4502fd5c7698 Author: phh Date: 2011-12-19 21:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4502fd5c7698 Merge Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/11c26bfcf8c7 7091417: recvfrom's 6th input should be of type socklen_t Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp. Reviewed-by: coleenp, dholmes Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c01e115b095e 7064927: retransformClasses() does not pass in LocalVariableTable of a method Summary: Handle LVT attribute in the class file reconstitutor. Reviewed-by: phh, coleenp Contributed-by: thomaswue ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: d532160c55f7 Author: coleenp Date: 2011-12-21 18:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d532160c55f7 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4b18532913c7 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 4bcf61041217 Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/9232e0ecbc2c Added tag hs23-b09 for changeset 4bcf61041217 ! .hgtags From john.coomes at oracle.com Fri Dec 23 21:24:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 24 Dec 2011 05:24:29 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20111224052439.8D284477D7@hg.openjdk.java.net> Changeset: 7e075537835d Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7e075537835d Added tag jdk8-b18 for changeset 61165f53f165 ! .hgtags Changeset: 4bcf61041217 Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9232e0ecbc2c Added tag hs23-b09 for changeset 4bcf61041217 ! .hgtags Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version From Dmitry.Samersoff at oracle.com Sat Dec 24 04:33:25 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 24 Dec 2011 16:33:25 +0400 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF4A8A4.1060502@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> Message-ID: <4EF5C695.4060206@oracle.com> Jon, One of problem with finalization nowdays is that with 1 Tb heap GC (and thus finalization) never happens. Do you plan to address this problem? -Dmitry On 2011-12-23 20:13, Jon Masamitsu wrote: > David, > > From the VM side there are two issues that I think we should understand > better before we work on an API. Those are described in the JEP as > 1) more aggressive management of the of finalization queue and 2) multiple > finalizer threads. We should see how much of the problem can be > alleviated by either or both or by other VM side changes that occur to us > during the work and then think about what is left and what information > we want from the user to address what's left. As Mark has said, I > think there will be a library side JEP at some point for those discussions. > > Jon > > On 12/22/2011 6:15 PM, David Holmes wrote: >> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>> Posted: http://openjdk.java.net/jeps/132 >> >> hotspot-dev seems the wrong mailing list to discuss this. It is >> primarily a Java level API. I would suggest using core-libs-dev. >> >> David -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Sun Dec 25 04:50:17 2011 From: david.holmes at oracle.com (David Holmes) Date: Sun, 25 Dec 2011 22:50:17 +1000 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF5C695.4060206@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> Message-ID: <4EF71C09.3030405@oracle.com> On 24/12/2011 10:33 PM, Dmitry Samersoff wrote: > Jon, > > One of problem with finalization nowdays is that with 1 Tb heap GC (and > thus finalization) never happens. > > Do you plan to address this problem? Such a change requires modifying the very definition of what finalization is. David > -Dmitry > > > On 2011-12-23 20:13, Jon Masamitsu wrote: >> David, >> >> From the VM side there are two issues that I think we should understand >> better before we work on an API. Those are described in the JEP as >> 1) more aggressive management of the of finalization queue and 2) multiple >> finalizer threads. We should see how much of the problem can be >> alleviated by either or both or by other VM side changes that occur to us >> during the work and then think about what is left and what information >> we want from the user to address what's left. As Mark has said, I >> think there will be a library side JEP at some point for those discussions. >> >> Jon >> >> On 12/22/2011 6:15 PM, David Holmes wrote: >>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>> Posted: http://openjdk.java.net/jeps/132 >>> >>> hotspot-dev seems the wrong mailing list to discuss this. It is >>> primarily a Java level API. I would suggest using core-libs-dev. >>> >>> David > > From jon.masamitsu at oracle.com Tue Dec 27 08:49:13 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 27 Dec 2011 08:49:13 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF5C695.4060206@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> Message-ID: <4EF9F709.4030101@oracle.com> Dmitry, Before I try to answer your question, do you ever try to use System.gc() to get finalizers to run? If you don't because System.gc() it too disruptive (generally being stop-the-world), are you using CMS and have you tried using System.gc() with -XX:+ExplicitGCInvokesConcurrent? Jon On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: > Jon, > > One of problem with finalization nowdays is that with 1 Tb heap GC (and > thus finalization) never happens. > > Do you plan to address this problem? > > -Dmitry > > > On 2011-12-23 20:13, Jon Masamitsu wrote: >> David, >> >> From the VM side there are two issues that I think we should understand >> better before we work on an API. Those are described in the JEP as >> 1) more aggressive management of the of finalization queue and 2) multiple >> finalizer threads. We should see how much of the problem can be >> alleviated by either or both or by other VM side changes that occur to us >> during the work and then think about what is left and what information >> we want from the user to address what's left. As Mark has said, I >> think there will be a library side JEP at some point for those discussions. >> >> Jon >> >> On 12/22/2011 6:15 PM, David Holmes wrote: >>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>> Posted: http://openjdk.java.net/jeps/132 >>> hotspot-dev seems the wrong mailing list to discuss this. It is >>> primarily a Java level API. I would suggest using core-libs-dev. >>> >>> David > From Dmitry.Samersoff at oracle.com Tue Dec 27 12:19:53 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 28 Dec 2011 00:19:53 +0400 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EF9F709.4030101@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> Message-ID: <4EFA2869.6070105@oracle.com> Jon, It's not a real (escalated) case. Just an accumulation of what I heard from cu during last five years. On 2011-12-27 20:49, Jon Masamitsu wrote: > Before I try to answer your question, do you ever try to use > System.gc() to get finalizers to run? Nope. Because (as you write it below) it's too disruptive especially because I have to call System.gc() twice to dry finalization queue. > If you don't because > System.gc() it too disruptive (generally being stop-the-world), > are you using CMS and have you tried using System.gc() > with -XX:+ExplicitGCInvokesConcurrent? Nope also. In most cases System.gc(CMS) cause valuable performance degradation for cu's app. To clarify cu requirements: e.g Huge trader like CBOE. It has the application that have to be very responsive during a stock work day. So they tune VM to have no GC during work day. Then they kill the app and start everything again next morning. The problem is - they rely to finalization to do some task. Most important (but not the only one) one is socket reclaiming . -Dmitry > > Jon > > On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >> Jon, >> >> One of problem with finalization nowdays is that with 1 Tb heap GC (and >> thus finalization) never happens. >> >> Do you plan to address this problem? >> >> -Dmitry >> >> >> On 2011-12-23 20:13, Jon Masamitsu wrote: >>> David, >>> >>> From the VM side there are two issues that I think we should understand >>> better before we work on an API. Those are described in the JEP as >>> 1) more aggressive management of the of finalization queue and 2) >>> multiple >>> finalizer threads. We should see how much of the problem can be >>> alleviated by either or both or by other VM side changes that occur >>> to us >>> during the work and then think about what is left and what information >>> we want from the user to address what's left. As Mark has said, I >>> think there will be a library side JEP at some point for those >>> discussions. >>> >>> Jon >>> >>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>> Posted: http://openjdk.java.net/jeps/132 >>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>> primarily a Java level API. I would suggest using core-libs-dev. >>>> >>>> David >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From jon.masamitsu at oracle.com Tue Dec 27 13:50:27 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 27 Dec 2011 13:50:27 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFA2869.6070105@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> Message-ID: <4EFA3DA3.6070007@oracle.com> Dmitry, For applications that have large heaps which don't fill up and so don't cause a GC (during which finalizable objects could be discovered), the least disruptive feature we've discussed is to have a concurrent phase such as CMS's concurrent marking phase discover finalizable objects. As you note this would eat up compute resources so it is something we would make the application request. For customers for which this is not acceptable, this JEP will not address their problem. Jon On 12/27/2011 12:19 PM, Dmitry Samersoff wrote: > Jon, > > It's not a real (escalated) case. Just an accumulation of > what I heard from cu during last five years. > > On 2011-12-27 20:49, Jon Masamitsu wrote: > >> Before I try to answer your question, do you ever try to use >> System.gc() to get finalizers to run? > Nope. Because (as you write it below) it's too disruptive especially > because I have to call System.gc() twice to dry finalization queue. > >> If you don't because >> System.gc() it too disruptive (generally being stop-the-world), >> are you using CMS and have you tried using System.gc() >> with -XX:+ExplicitGCInvokesConcurrent? > Nope also. In most cases System.gc(CMS) cause valuable performance > degradation for cu's app. > > > To clarify cu requirements: > > e.g Huge trader like CBOE. It has the application that have to be very > responsive during a stock work day. > So they tune VM to have no GC during work day. Then they kill the app > and start everything again next morning. > > The problem is - they rely to finalization to do some task. Most > important (but not the only one) one is socket reclaiming . > > -Dmitry > > > > >> Jon >> >> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >>> Jon, >>> >>> One of problem with finalization nowdays is that with 1 Tb heap GC (and >>> thus finalization) never happens. >>> >>> Do you plan to address this problem? >>> >>> -Dmitry >>> >>> >>> On 2011-12-23 20:13, Jon Masamitsu wrote: >>>> David, >>>> >>>> From the VM side there are two issues that I think we should understand >>>> better before we work on an API. Those are described in the JEP as >>>> 1) more aggressive management of the of finalization queue and 2) >>>> multiple >>>> finalizer threads. We should see how much of the problem can be >>>> alleviated by either or both or by other VM side changes that occur >>>> to us >>>> during the work and then think about what is left and what information >>>> we want from the user to address what's left. As Mark has said, I >>>> think there will be a library side JEP at some point for those >>>> discussions. >>>> >>>> Jon >>>> >>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>> Posted: http://openjdk.java.net/jeps/132 >>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>> >>>>> David > From jon.masamitsu at oracle.com Tue Dec 27 14:23:07 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Tue, 27 Dec 2011 22:23:07 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20111227222319.0E738477E4@hg.openjdk.java.net> Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! 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/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp From kirk at kodewerk.com Tue Dec 27 15:16:33 2011 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 28 Dec 2011 00:16:33 +0100 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFA2869.6070105@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> Message-ID: <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> Hi Dmitry, I'm not sure that this usecase is a bug in GC/finalization but a misunderstanding of what finalization does and how it's suppose to function. If they know the socket is dead, why not just call close on it? Regards, Kirk On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote: > Jon, > > It's not a real (escalated) case. Just an accumulation of > what I heard from cu during last five years. > > On 2011-12-27 20:49, Jon Masamitsu wrote: > >> Before I try to answer your question, do you ever try to use >> System.gc() to get finalizers to run? > > Nope. Because (as you write it below) it's too disruptive especially > because I have to call System.gc() twice to dry finalization queue. > >> If you don't because >> System.gc() it too disruptive (generally being stop-the-world), >> are you using CMS and have you tried using System.gc() >> with -XX:+ExplicitGCInvokesConcurrent? > > Nope also. In most cases System.gc(CMS) cause valuable performance > degradation for cu's app. > > > To clarify cu requirements: > > e.g Huge trader like CBOE. It has the application that have to be very > responsive during a stock work day. > So they tune VM to have no GC during work day. Then they kill the app > and start everything again next morning. > > The problem is - they rely to finalization to do some task. Most > important (but not the only one) one is socket reclaiming . > > -Dmitry > > > > >> >> Jon >> >> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >>> Jon, >>> >>> One of problem with finalization nowdays is that with 1 Tb heap GC (and >>> thus finalization) never happens. >>> >>> Do you plan to address this problem? >>> >>> -Dmitry >>> >>> >>> On 2011-12-23 20:13, Jon Masamitsu wrote: >>>> David, >>>> >>>> From the VM side there are two issues that I think we should understand >>>> better before we work on an API. Those are described in the JEP as >>>> 1) more aggressive management of the of finalization queue and 2) >>>> multiple >>>> finalizer threads. We should see how much of the problem can be >>>> alleviated by either or both or by other VM side changes that occur >>>> to us >>>> during the work and then think about what is left and what information >>>> we want from the user to address what's left. As Mark has said, I >>>> think there will be a library side JEP at some point for those >>>> discussions. >>>> >>>> Jon >>>> >>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>> Posted: http://openjdk.java.net/jeps/132 >>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>> >>>>> David >>> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From serguei.spitsyn at oracle.com Tue Dec 27 23:02:01 2011 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 27 Dec 2011 23:02:01 -0800 Subject: Request for review: 7064927: retransformClasses() does not pass in LocalVariableTable of a method In-Reply-To: <4EF24304.9080404@oracle.com> References: <4EC0F8F3.9030801@oracle.com> <4EF0FD8E.8090805@oracle.com> <4EF107A8.4030106@oracle.com> <4EF24304.9080404@oracle.com> Message-ID: <4EFABEE9.8040508@oracle.com> Looks good. One comment though. The attr_count should be incremented under the same condition as the attribute is written: 226 if (local_variable_table_length != 0) { 227 write_local_variable_table_attribute(method, local_variable_table_length); 228 } It means, the line 176 should be after the line 177: 174 if (method->has_localvariable_table()) { 175 local_variable_table_length = method->localvariable_table_length(); 176 ++attr_count; 177 if (local_variable_table_length != 0) { Example is: 144 if (const_method->has_linenumber_table()) { 145 line_num_cnt = line_number_table_entries(method); 146 if (line_num_cnt != 0) { 147 ++attr_count; The LVTT attribute is still missed though. :( Thanks, Serguei On 12/21/11 12:35 PM, Thomas Wuerthinger wrote: > Thanks for the review. I've corrected the comments and created a new > webrev at: http://cr.openjdk.java.net/~thomaswue/7064927/webrev.00/ > > - thomas > > > On 20.12.2011 23:09, Paul Hohensee wrote: >> Looks good, except that the LocalVariableTable attribute comments in >> write_code_attribute() and write_local_variable_table_attribute() don't >> match. The comment in the latter says "LineNumberTable" instead >> of "LocalVariableTable" and the descriptor is for the line number table >> rather than the local variable table. The comment in the former is >> missing >> "local_variable_table[local_variable_table_length];" >> >> Paul >> >> On 12/20/11 4:26 PM, Thomas Wuerthinger wrote: >>> Hi! >>> >>> I'd like to resend my request for review and kindly ask for a review >>> for my patch that fixes bug number 7064927. >>> The webrev is available at: >>> http://cr.openjdk.java.net/~coleenp/7064927/ >>> >>> Thanks, thomas >>> >>> >>> On 14.11.2011 12:18, Thomas Wuerthinger wrote: >>>> Hi! >>>> >>>> An open webrev of the patch that fixes bug 7064927 is available at: >>>> http://cr.openjdk.java.net/~coleenp/7064927/ >>>> The bug is described at: >>>> http://bugs.sun.com/view_bug.do?bug_id=7064927 >>>> >>>> Thanks, thomas >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111227/c6978be7/attachment-0001.html From Dmitry.Samersoff at oracle.com Tue Dec 27 23:09:10 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 28 Dec 2011 11:09:10 +0400 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFA3DA3.6070007@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <4EFA3DA3.6070007@oracle.com> Message-ID: <4EFAC096.3000601@oracle.com> Jon, On 2011-12-28 01:50, Jon Masamitsu wrote: > For applications that have large heaps which don't fill up > and so don't cause a GC (during which finalizable objects could be > discovered), the least disruptive feature we've discussed is > to have a concurrent phase such as CMS's concurrent > marking phase discover finalizable objects. Thank you for clarification. It's exactly what I'm looking for. -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Dec 27 23:18:31 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 28 Dec 2011 11:18:31 +0400 Subject: JEP 132: More-prompt finalization In-Reply-To: <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> Message-ID: <4EFAC2C7.7060508@oracle.com> Kirk, On 2011-12-28 03:16, Kirk Pepperdine wrote: > I'm not sure that this usecase is a bug > in GC/finalization but a misunderstanding of what > finalization does and how it's suppose to function. > If they know the socket is dead, why not just call close on it? If I know that socket is dead I don't need finalization at all, so it runs out of scope of this thread. But there are plenty of usecases when we can't determine the moment when we can explicitly close socket. Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread) but I would like to see finalizers as recommended solution for these cases. -Dmitry > Regards, > Kirk > > On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote: > >> Jon, >> >> It's not a real (escalated) case. Just an accumulation of >> what I heard from cu during last five years. >> >> On 2011-12-27 20:49, Jon Masamitsu wrote: >> >>> Before I try to answer your question, do you ever try to use >>> System.gc() to get finalizers to run? >> >> Nope. Because (as you write it below) it's too disruptive especially >> because I have to call System.gc() twice to dry finalization queue. >> >>> If you don't because >>> System.gc() it too disruptive (generally being stop-the-world), >>> are you using CMS and have you tried using System.gc() >>> with -XX:+ExplicitGCInvokesConcurrent? >> >> Nope also. In most cases System.gc(CMS) cause valuable performance >> degradation for cu's app. >> >> >> To clarify cu requirements: >> >> e.g Huge trader like CBOE. It has the application that have to be very >> responsive during a stock work day. >> So they tune VM to have no GC during work day. Then they kill the app >> and start everything again next morning. >> >> The problem is - they rely to finalization to do some task. Most >> important (but not the only one) one is socket reclaiming . >> >> -Dmitry >> >> >> >> >>> >>> Jon >>> >>> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >>>> Jon, >>>> >>>> One of problem with finalization nowdays is that with 1 Tb heap GC (and >>>> thus finalization) never happens. >>>> >>>> Do you plan to address this problem? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2011-12-23 20:13, Jon Masamitsu wrote: >>>>> David, >>>>> >>>>> From the VM side there are two issues that I think we should understand >>>>> better before we work on an API. Those are described in the JEP as >>>>> 1) more aggressive management of the of finalization queue and 2) >>>>> multiple >>>>> finalizer threads. We should see how much of the problem can be >>>>> alleviated by either or both or by other VM side changes that occur >>>>> to us >>>>> during the work and then think about what is left and what information >>>>> we want from the user to address what's left. As Mark has said, I >>>>> think there will be a library side JEP at some point for those >>>>> discussions. >>>>> >>>>> Jon >>>>> >>>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>>> Posted: http://openjdk.java.net/jeps/132 >>>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>>> >>>>>> David >>>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kirk at kodewerk.com Wed Dec 28 01:55:51 2011 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 28 Dec 2011 10:55:51 +0100 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFAC2C7.7060508@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> <4EFAC2C7.7060508@oracle.com> Message-ID: <32CBF5EE-6AB8-4888-895E-37E495ACCD74@kodewerk.com> Hi Dmitry, > Kirk, > > On 2011-12-28 03:16, Kirk Pepperdine wrote: >> I'm not sure that this usecase is a bug >> in GC/finalization but a misunderstanding of what > > finalization does and how it's suppose to function. >> If they know the socket is dead, why not just call close on it? > > If I know that socket is dead I don't need finalization at all, so > it runs out of scope of this thread. > > But there are plenty of usecases when we can't determine the moment when we can explicitly close socket. I'm not saying that these use cases don't exist but I'm not recalling running into one of them.. ever. And I if I asked this question in a more general forum my guess is that it would be unanimous in that no one else has run into them. I'm wondering if there is a one-off solution for the "use-cases" that you've happen to run into (aside from the connection pooling etc?). would certainly not want to give people more rope to hang themselves with all for the sake of a problem that most likely is rooted in the design of the application. Just say'in > Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread) I'm not sure that I'd call these work-arounds as they all serve a multitude of purposes.. but, beyond the scope > but I would like to see finalizers as recommended solution for these cases. and this is inherently tied to GC? So, if we consider Jon's solution, I still would not want a API call to trigger it. If you look at enough GC logs (which btw, I collect as a hobby ;)) you can see that these concurrent phases can be quite disruptive. And, as if the case with a full GC, when should you call it? I certainly have neither the context nor the information needed to make that decision which is why I rely on the built-in heuristics to make that decision for me. In my course notes on finalization I mention that GC never runs is one of the 3 cases where you cannot rely on finalization working for you. So, I'm going to bow out 'cos at the end of the day, I'm just a lowly observer who is now a trouble maker where as you're actually doing something useful. Happy New Year, Kirk > > -Dmitry > >> Regards, >> Kirk >> >> On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote: >> >>> Jon, >>> >>> It's not a real (escalated) case. Just an accumulation of >>> what I heard from cu during last five years. >>> >>> On 2011-12-27 20:49, Jon Masamitsu wrote: >>> >>>> Before I try to answer your question, do you ever try to use >>>> System.gc() to get finalizers to run? >>> >>> Nope. Because (as you write it below) it's too disruptive especially >>> because I have to call System.gc() twice to dry finalization queue. >>> >>>> If you don't because >>>> System.gc() it too disruptive (generally being stop-the-world), >>>> are you using CMS and have you tried using System.gc() >>>> with -XX:+ExplicitGCInvokesConcurrent? >>> >>> Nope also. In most cases System.gc(CMS) cause valuable performance >>> degradation for cu's app. >>> >>> >>> To clarify cu requirements: >>> >>> e.g Huge trader like CBOE. It has the application that have to be very >>> responsive during a stock work day. >>> So they tune VM to have no GC during work day. Then they kill the app >>> and start everything again next morning. >>> >>> The problem is - they rely to finalization to do some task. Most >>> important (but not the only one) one is socket reclaiming . >>> >>> -Dmitry >>> >>> >>> >>> >>>> >>>> Jon >>>> >>>> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >>>>> Jon, >>>>> >>>>> One of problem with finalization nowdays is that with 1 Tb heap GC (and >>>>> thus finalization) never happens. >>>>> >>>>> Do you plan to address this problem? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2011-12-23 20:13, Jon Masamitsu wrote: >>>>>> David, >>>>>> >>>>>> From the VM side there are two issues that I think we should understand >>>>>> better before we work on an API. Those are described in the JEP as >>>>>> 1) more aggressive management of the of finalization queue and 2) >>>>>> multiple >>>>>> finalizer threads. We should see how much of the problem can be >>>>>> alleviated by either or both or by other VM side changes that occur >>>>>> to us >>>>>> during the work and then think about what is left and what information >>>>>> we want from the user to address what's left. As Mark has said, I >>>>>> think there will be a library side JEP at some point for those >>>>>> discussions. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>>>> Posted: http://openjdk.java.net/jeps/132 >>>>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>>>> >>>>>>> David >>>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Java Hotspot development team, SPB04 >>> * There will come soft rains ... >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From fweimer at bfk.de Wed Dec 28 02:09:23 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 28 Dec 2011 10:09:23 +0000 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFA2869.6070105@oracle.com> (Dmitry Samersoff's message of "Wed, 28 Dec 2011 00:19:53 +0400") References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> Message-ID: <8239c5ypm4.fsf@mid.bfk.de> * Dmitry Samersoff: > The problem is - they rely to finalization to do some task. Most > important (but not the only one) one is socket reclaiming . Direct buffers (especially those mapped from files) look like a more compelling example to me, except that they do not rely on finalization (but unmapping them needs reachability information from the GC, too). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From kirk at kodewerk.com Wed Dec 28 06:33:13 2011 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 28 Dec 2011 15:33:13 +0100 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFAC2C7.7060508@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> <4EFAC2C7.7060508@oracle.com> Message-ID: <4E9BFF43-DAC8-480A-AF46-3AADD3FE2ED7@kodewerk.com> Hi Dmitry, I just received and email from one of my customers. I've cut and paste on of the paragraphs. > We have already put our expanded knowledge to good use, Daniel was doing > some debugging on an old application, performance was sub par. He checked > the gc log which showed that the application was doing full gc a lot. He > searched the code and found 118 System.gc(); calls! :-D Daniel received > guru status for removing the calls and performance was noticeable quicker! Tony dropped a nice diagnostic into the GC logs and it's a bullet point in my GC log seminars. There is something that I've not investigated so I might start by asking.. why does RMI call System.gc()? Regards, Kirk On 2011-12-28, at 8:18 AM, Dmitry Samersoff wrote: > Kirk, > > On 2011-12-28 03:16, Kirk Pepperdine wrote: >> I'm not sure that this usecase is a bug >> in GC/finalization but a misunderstanding of what > > finalization does and how it's suppose to function. >> If they know the socket is dead, why not just call close on it? > > If I know that socket is dead I don't need finalization at all, so > it runs out of scope of this thread. > > But there are plenty of usecases when we can't determine the moment when we can explicitly close socket. Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread) but I would like to see finalizers as recommended solution for these cases. > > -Dmitry > >> Regards, >> Kirk >> >> On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote: >> >>> Jon, >>> >>> It's not a real (escalated) case. Just an accumulation of >>> what I heard from cu during last five years. >>> >>> On 2011-12-27 20:49, Jon Masamitsu wrote: >>> >>>> Before I try to answer your question, do you ever try to use >>>> System.gc() to get finalizers to run? >>> >>> Nope. Because (as you write it below) it's too disruptive especially >>> because I have to call System.gc() twice to dry finalization queue. >>> >>>> If you don't because >>>> System.gc() it too disruptive (generally being stop-the-world), >>>> are you using CMS and have you tried using System.gc() >>>> with -XX:+ExplicitGCInvokesConcurrent? >>> >>> Nope also. In most cases System.gc(CMS) cause valuable performance >>> degradation for cu's app. >>> >>> >>> To clarify cu requirements: >>> >>> e.g Huge trader like CBOE. It has the application that have to be very >>> responsive during a stock work day. >>> So they tune VM to have no GC during work day. Then they kill the app >>> and start everything again next morning. >>> >>> The problem is - they rely to finalization to do some task. Most >>> important (but not the only one) one is socket reclaiming . >>> >>> -Dmitry >>> >>> >>> >>> >>>> >>>> Jon >>>> >>>> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >>>>> Jon, >>>>> >>>>> One of problem with finalization nowdays is that with 1 Tb heap GC (and >>>>> thus finalization) never happens. >>>>> >>>>> Do you plan to address this problem? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2011-12-23 20:13, Jon Masamitsu wrote: >>>>>> David, >>>>>> >>>>>> From the VM side there are two issues that I think we should understand >>>>>> better before we work on an API. Those are described in the JEP as >>>>>> 1) more aggressive management of the of finalization queue and 2) >>>>>> multiple >>>>>> finalizer threads. We should see how much of the problem can be >>>>>> alleviated by either or both or by other VM side changes that occur >>>>>> to us >>>>>> during the work and then think about what is left and what information >>>>>> we want from the user to address what's left. As Mark has said, I >>>>>> think there will be a library side JEP at some point for those >>>>>> discussions. >>>>>> >>>>>> Jon >>>>>> >>>>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>>>> Posted: http://openjdk.java.net/jeps/132 >>>>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>>>> >>>>>>> David >>>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Java Hotspot development team, SPB04 >>> * There will come soft rains ... >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... From jon.masamitsu at oracle.com Wed Dec 28 06:53:23 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 28 Dec 2011 06:53:23 -0800 Subject: JEP 132: More-prompt finalization In-Reply-To: <4E9BFF43-DAC8-480A-AF46-3AADD3FE2ED7@kodewerk.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> <4EFAC2C7.7060508@oracle.com> <4E9BFF43-DAC8-480A-AF46-3AADD3FE2ED7@kodewerk.com> Message-ID: <4EFB2D63.3080206@oracle.com> On 12/28/2011 6:33 AM, Kirk Pepperdine wrote: > ... > There is something that I've not investigated so I might start by asking.. why does RMI call System.gc()? Kirk, I think this answers your question better than I could with a code example. http://java.sun.com/developer/onlineTraining/rmi/exercises/DistributedGarbageCollector/index.html Jon > Regards, > Kirk > From tony.printezis at oracle.com Wed Dec 28 07:38:08 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 10:38:08 -0500 Subject: JEP 132: More-prompt finalization In-Reply-To: <4E9BFF43-DAC8-480A-AF46-3AADD3FE2ED7@kodewerk.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> <4EFAC2C7.7060508@oracle.com> <4E9BFF43-DAC8-480A-AF46-3AADD3FE2ED7@kodewerk.com> Message-ID: <4EFB37E0.1090509@oracle.com> Kirk, Inline. On 12/28/2011 09:33 AM, Kirk Pepperdine wrote: > Hi Dmitry, > > I just received and email from one of my customers. I've cut and paste on of the paragraphs. > >> We have already put our expanded knowledge to good use, Daniel was doing >> some debugging on an old application, performance was sub par. He checked >> the gc log which showed that the application was doing full gc a lot. He >> searched the code and found 118 System.gc(); calls! :-D Daniel received >> guru status That was an easy guru status. :-) >> for removing the calls and performance was noticeable quicker! > Tony dropped a nice diagnostic into the GC logs and it's a bullet point in my GC log seminars. You're very welcome. :-) > There is something that I've not investigated so I might start by asking.. why does RMI call System.gc()? (Jon's email pre-empted me but I'll finish the thought) RMI has a distributed GC that relies on reference processing to allow each node to recognize that some objects are unreachable so it can notify a remote node (or nodes) that some remote references to them do not exist any more. The remote node might then be able to reclaim objects that are only remotely reachable. (Or this is how I understood it at least.) RMI used to call System.gc() once a minute (!!!) but after some encouragement from yours truly they changed the default to once an hour (this is configurable using a property). Note that a STW Full GC is not really required as long as references are processed. So, in CMS (and G1), a concurrent cycle is fine which is why we recommend to use -XX:+ExplicitGCInvokesConcurrent in this case. I had been warned by the RMI folks against totally disabling those System.gc()'s (e.g., using -XX:+DisableExplicitGC) given that if Full GCs / concurrent cycles do not otherwise happen at a reasonable frequency then remote nodes might experience memory leaks since they will consider that some otherwise unreachable remote references are still live. I have no idea how severe such memory leaks would be. I guess they'd be very application-dependent. An additional thought that just occurred to me: instead of calling System.gc() every hour what RMI should really be doing is calling System.gc() every hour provided no old gen GC has taken place during the last hour. This would be relatively easy to implement by accessing the old GC counter through the GC MXBeans. Tony > Regards, > Kirk > > On 2011-12-28, at 8:18 AM, Dmitry Samersoff wrote: > >> Kirk, >> >> On 2011-12-28 03:16, Kirk Pepperdine wrote: >>> I'm not sure that this usecase is a bug >>> in GC/finalization but a misunderstanding of what >>> finalization does and how it's suppose to function. >>> If they know the socket is dead, why not just call close on it? >> If I know that socket is dead I don't need finalization at all, so >> it runs out of scope of this thread. >> >> But there are plenty of usecases when we can't determine the moment when we can explicitly close socket. Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread) but I would like to see finalizers as recommended solution for these cases. >> >> -Dmitry >> >>> Regards, >>> Kirk >>> >>> On 2011-12-27, at 9:19 PM, Dmitry Samersoff wrote: >>> >>>> Jon, >>>> >>>> It's not a real (escalated) case. Just an accumulation of >>>> what I heard from cu during last five years. >>>> >>>> On 2011-12-27 20:49, Jon Masamitsu wrote: >>>> >>>>> Before I try to answer your question, do you ever try to use >>>>> System.gc() to get finalizers to run? >>>> Nope. Because (as you write it below) it's too disruptive especially >>>> because I have to call System.gc() twice to dry finalization queue. >>>> >>>>> If you don't because >>>>> System.gc() it too disruptive (generally being stop-the-world), >>>>> are you using CMS and have you tried using System.gc() >>>>> with -XX:+ExplicitGCInvokesConcurrent? >>>> Nope also. In most cases System.gc(CMS) cause valuable performance >>>> degradation for cu's app. >>>> >>>> >>>> To clarify cu requirements: >>>> >>>> e.g Huge trader like CBOE. It has the application that have to be very >>>> responsive during a stock work day. >>>> So they tune VM to have no GC during work day. Then they kill the app >>>> and start everything again next morning. >>>> >>>> The problem is - they rely to finalization to do some task. Most >>>> important (but not the only one) one is socket reclaiming . >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> >>>>> Jon >>>>> >>>>> On 12/24/2011 4:33 AM, Dmitry Samersoff wrote: >>>>>> Jon, >>>>>> >>>>>> One of problem with finalization nowdays is that with 1 Tb heap GC (and >>>>>> thus finalization) never happens. >>>>>> >>>>>> Do you plan to address this problem? >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2011-12-23 20:13, Jon Masamitsu wrote: >>>>>>> David, >>>>>>> >>>>>>> From the VM side there are two issues that I think we should understand >>>>>>> better before we work on an API. Those are described in the JEP as >>>>>>> 1) more aggressive management of the of finalization queue and 2) >>>>>>> multiple >>>>>>> finalizer threads. We should see how much of the problem can be >>>>>>> alleviated by either or both or by other VM side changes that occur >>>>>>> to us >>>>>>> during the work and then think about what is left and what information >>>>>>> we want from the user to address what's left. As Mark has said, I >>>>>>> think there will be a library side JEP at some point for those >>>>>>> discussions. >>>>>>> >>>>>>> Jon >>>>>>> >>>>>>> On 12/22/2011 6:15 PM, David Holmes wrote: >>>>>>>> On 23/12/2011 9:05 AM, mark.reinhold at oracle.com wrote: >>>>>>>>> Posted: http://openjdk.java.net/jeps/132 >>>>>>>> hotspot-dev seems the wrong mailing list to discuss this. It is >>>>>>>> primarily a Java level API. I would suggest using core-libs-dev. >>>>>>>> >>>>>>>> David >>>> >>>> -- >>>> Dmitry Samersoff >>>> Java Hotspot development team, SPB04 >>>> * There will come soft rains ... >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... From kirk at kodewerk.com Wed Dec 28 08:21:44 2011 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 28 Dec 2011 17:21:44 +0100 Subject: JEP 132: More-prompt finalization In-Reply-To: <4EFB37E0.1090509@oracle.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> <4EFAC2C7.7060508@oracle.com> <4E9BFF43-DAC8-480A-AF46-3AADD3FE2ED7@kodewerk.com> <4EFB37E0.1090509@oracle.com> Message-ID: <4899B594-66EA-444B-9224-9EA660B4E346@kodewerk.com> Hi Tony, > > That was an easy guru status. :-) I might agree but prior to reading that simple bullet point, this problem wouldn't have been found. So, Guru in the big pond.. not the small one that you live in ;-) > >>> for removing the calls and performance was noticeable quicker! >> Tony dropped a nice diagnostic into the GC logs and it's a bullet point in my GC log seminars. > > You're very welcome. :-) > >> There is something that I've not investigated so I might start by asking.. why does RMI call System.gc()? > > (Jon's email pre-empted me but I'll finish the thought) > > RMI has a distributed GC that relies on reference processing to allow each node to recognize that some objects are unreachable so it can notify a remote node (or nodes) that some remote references to them do not exist any more. The remote node might then be able to reclaim objects that are only remotely reachable. (Or this is how I understood it at least.) > > RMI used to call System.gc() once a minute (!!!) but after some encouragement from yours truly they changed the default to once an hour (this is configurable using a property). Note that a STW Full GC is not really required as long as references are processed. So, in CMS (and G1), a concurrent cycle is fine which is why we recommend to use -XX:+ExplicitGCInvokesConcurrent in this case. > > I had been warned by the RMI folks against totally disabling those System.gc()'s (e.g., using -XX:+DisableExplicitGC) given that if Full GCs / concurrent cycles do not otherwise happen at a reasonable frequency then remote nodes might experience memory leaks since they will consider that some otherwise unreachable remote references are still live. I have no idea how severe such memory leaks would be. I guess they'd be very application-dependent. > > An additional thought that just occurred to me: instead of calling System.gc() every hour what RMI should really be doing is calling System.gc() every hour provided no old gen GC has taken place during the last hour. This would be relatively easy to implement by accessing the old GC counter through the GC MXBeans. Ok, I'm reading this with a 38 degree temp so maybe that's why I'm not getting it, my brain is slow?. I've looked at the link Jon provided.. very nice but still leaves me puzzled. Wouldn't simply implementing Unreferenced be enough to trigger the clean up? I would imagine a broken pipe or some other fault should cause the distributed objects to be dereferenced (i.e. become collectable). At the end of the day, this seems like calling System.gc() in Servlet.destroy(). Regards, Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111228/67c0142b/attachment.html From Dmitry.Samersoff at oracle.com Wed Dec 28 09:44:35 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 28 Dec 2011 21:44:35 +0400 Subject: JEP 132: More-prompt finalization In-Reply-To: <32CBF5EE-6AB8-4888-895E-37E495ACCD74@kodewerk.com> References: <20111222230542.48A451084@eggemoggin.niobe.net> <4EF3E44F.1060409@oracle.com> <4EF4A8A4.1060502@oracle.com> <4EF5C695.4060206@oracle.com> <4EF9F709.4030101@oracle.com> <4EFA2869.6070105@oracle.com> <712FF280-2C59-47A0-99DE-ECEAD5FCFB15@kodewerk.com> <4EFAC2C7.7060508@oracle.com> <32CBF5EE-6AB8-4888-895E-37E495ACCD74@kodewerk.com> Message-ID: <4EFB5583.5000005@oracle.com> On 2011-12-28 13:55, Kirk Pepperdine wrote: >> But there are plenty of usecases when we can't determine the moment when we can explicitly close socket. > > I'm not saying that these use cases don't exist but I'm not recalling running into one of them.. ever. > And I if I asked this question in a more general forum my guess is that it would be unanimous in that no one else has run into them. > I'm wondering if there is a one-off solution for the "use-cases" that you've happen to run into (aside from the connection pooling etc?). > would certainly not want to give people more rope to hang themselves with all for the sake of a problem that most likely is rooted in the design of the application. Just say'in It's not a simple question - when you should close socket ever without Java. e.g. An app read data stream and stop receiving data at some point. You can close socket immediately to benefit server or wait to benefit client. >> Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread) > I'm not sure that I'd call these work-arounds as they all serve a multitude of purposes.. but, beyond the scope Nowdays we have plenty of memory so we can delay socket (an other resources) reclamation but save some CPU power. It's especially valuable if an application have clear visible pick and spare hours. > but I would like to see finalizers as recommended solution for these cases. > and this is inherently tied to GC? So, if we consider Jon's solution, I still would not want a API call to trigger it. > If you look at enough GC logs (which btw, I collect as a hobby ;)) For about 6 years in sustaining I looked at GC logs enough times, but decided to collect hs_err_.logs - it requires less space ;-)). I agree with you - there is no reason to have an API to trigger GC or finalization explicitly. I dream about a time when JVM would be able to detect low load time and start GC/finalization automatically. But today there are a cu's cases that can't be solved without such API. > Happy New Year, Happy New Year ;) -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From vladimir.danushevsky at oracle.com Thu Dec 29 18:39:18 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Fri, 30 Dec 2011 02:39:18 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20111230023924.3B9EB4782F@hg.openjdk.java.net> Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3db6ea5ce021 Merge From john.coomes at oracle.com Thu Dec 29 20:36:20 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:36:20 +0000 Subject: hg: hsx/hotspot-main: 4 new changesets Message-ID: <20111230043620.7551247835@hg.openjdk.java.net> Changeset: 9acd7374ff8a Author: ohair Date: 2011-12-12 08:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9acd7374ff8a 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties ! test/Makefile Changeset: 00d13c40d7a7 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/00d13c40d7a7 Merge Changeset: 237bc29afbfc Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/237bc29afbfc Merge Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:36:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:36:27 +0000 Subject: hg: hsx/hotspot-main/corba: 5 new changesets Message-ID: <20111230043633.05BB947836@hg.openjdk.java.net> Changeset: 75529c21094f Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/75529c21094f 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 0289a94d653b Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0289a94d653b Merge Changeset: 052dda3b5ce3 Author: dmeetry Date: 2011-12-18 22:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/052dda3b5ce3 7046238: new InitialContext(); hangs Summary: Synchronization on a single monitor for contactInfo parameters with identical hashCode() Reviewed-by: robm, skoppar ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: e1366c5d84ef Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e1366c5d84ef Merge Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:36:40 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:36:40 +0000 Subject: hg: hsx/hotspot-main/jaxp: 5 new changesets Message-ID: <20111230043640.54CFF47837@hg.openjdk.java.net> Changeset: a482d45c93e9 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a482d45c93e9 7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac Reviewed-by: alanb ! build.xml Changeset: a49db7c01db7 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a49db7c01db7 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: f26e2ab2c2c7 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f26e2ab2c2c7 Merge Changeset: dffeb62b1a7f Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/dffeb62b1a7f Merge Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:36:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:36:47 +0000 Subject: hg: hsx/hotspot-main/jaxws: 5 new changesets Message-ID: <20111230043647.8EA3247838@hg.openjdk.java.net> Changeset: 6d622b1b4db0 Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/6d622b1b4db0 7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac Reviewed-by: alanb ! build.xml Changeset: 6d2030eacdac Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/6d2030eacdac 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: b2e4ab8b5fa3 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b2e4ab8b5fa3 Merge Changeset: b73b733214aa Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b73b733214aa Merge Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:37:42 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:37:42 +0000 Subject: hg: hsx/hotspot-main/jdk: 30 new changesets Message-ID: <20111230044358.6BE034783D@hg.openjdk.java.net> Changeset: 7dbc53242c2a Author: art Date: 2011-12-07 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7dbc53242c2a 7117008: Warnings cleanup day: reduce number of javac warnings in the sun.awt package Reviewed-by: anthony, denis, bagiras ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/CausedFocusEvent.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/EventListenerAggregate.java - src/share/classes/sun/awt/FocusingTextField.java ! src/share/classes/sun/awt/HeadlessToolkit.java - src/share/classes/sun/awt/HorizBagLayout.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ModalityEvent.java - src/share/classes/sun/awt/OrientableFlowLayout.java ! src/share/classes/sun/awt/PaintEventDispatcher.java ! src/share/classes/sun/awt/PeerEvent.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 18925904efc2 Author: alexsch Date: 2011-12-12 15:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/18925904efc2 7105890: closed/javax/swing/JScrollBar/4708809/bug4708809.java deadlocks on MacOS Reviewed-by: alexp + test/javax/swing/JScrollBar/4708809/bug4708809.java Changeset: 44b26d6a55a6 Author: alexsch Date: 2011-12-13 15:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44b26d6a55a6 7112931: closed/javax/swing/JTabbedPane/6416920/bug6416920.java fails on MacOS Reviewed-by: alexp + test/javax/swing/JTabbedPane/6416920/bug6416920.java Changeset: 70233f5e909c Author: alexsch Date: 2011-12-13 17:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70233f5e909c 7120869: javax/swing/JScrollBar/4708809/bug4708809.java fails on Windows Summary: The robot auto-delay is increased to fix the test failing on Windows. Reviewed-by: alexp ! test/javax/swing/JScrollBar/4708809/bug4708809.java Changeset: 032a91abc540 Author: alexsch Date: 2011-12-13 18:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/032a91abc540 7116950: Reduce number of warnings in swing Reviewed-by: art ! src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/ComponentInputMap.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/MenuSelectionManager.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/plaf/ComponentUI.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 282b2ce90afe Author: lana Date: 2011-12-16 12:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/282b2ce90afe Merge ! src/share/classes/java/beans/PropertyDescriptor.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 75bd7295c706 Author: bagiras Date: 2011-12-19 15:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75bd7295c706 7117334: Warnings cleanup day: reduce number of javac warnings in the java.awt package Reviewed-by: art, denis, alexsch ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/image/ColorModel.java Changeset: d15f38f08ce9 Author: denis Date: 2011-12-19 16:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d15f38f08ce9 7117011: Reduce number of warnings in sun/awt/windows and sun/awt/datatransfer Reviewed-by: art ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XClipboard.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WBufferStrategy.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WClipboard.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WDialogPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPageDialog.java ! src/windows/classes/sun/awt/windows/WPageDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialog.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: cded2429cdbf Author: anthony Date: 2011-12-20 12:48 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cded2429cdbf 7122796: SunToolkit constructor should create the EventQueue for the Main AppContext Summary: Always create an EQ for the main AppContext in SunToolkit constructor Reviewed-by: art ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/MainAppContext/MainAppContext.java Changeset: 94d7051cca13 Author: lana Date: 2011-12-20 15:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/94d7051cca13 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 4f0f9f9c4892 Author: smarks Date: 2011-12-07 12:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4f0f9f9c4892 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip Reviewed-by: alanb, dholmes, forax, sherman, smarks Contributed-by: Prasannaa , Martijn Verburg , Goerge_Albrecht , Graham Allan , Michael Barker ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/zip/ZipEntry.java Changeset: f8897baf40ea Author: omajid Date: 2011-12-08 13:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8897baf40ea 7117612: Miscellaneous warnings in java.lang Reviewed-by: smarks, dholmes, alanb, darcy ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Void.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/ProcessEnvironment.java Changeset: 9bb7c3b97384 Author: smarks Date: 2011-12-08 14:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9bb7c3b97384 7118546: fix warnings in javax.xml.crypto, javax.script Reviewed-by: mullan ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java Changeset: 77d41c0e4ffc Author: jjh Date: 2011-12-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77d41c0e4ffc 7117053: Fix build warnings in com/sun/tools/jdi/* Summary: Warnings fixed. Also reviewed by serguei.spitsyn at oracle.com, who is not yet an openjdk reviewer Reviewed-by: ksrini ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/jdwpgen/OutNode.java ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Changeset: c508f38245f8 Author: ngmr Date: 2011-12-12 11:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c508f38245f8 7118907: InetAddress.isReachable() should return false if sendto fails with EHOSTUNREACH Reviewed-by: alanb, chegar Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3216717f96f5 Author: dl Date: 2011-12-12 10:45 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3216717f96f5 7118066: Warnings in java.util.concurrent package Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! test/java/util/Collections/EmptyIterator.java Changeset: d4f9d7e86a92 Author: chegar Date: 2011-12-12 03:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d4f9d7e86a92 Merge Changeset: 9c0a6185188f Author: ohair Date: 2011-12-12 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c0a6185188f 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties ! test/Makefile Changeset: c647ebb3c4f7 Author: naoto Date: 2011-12-13 15:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c647ebb3c4f7 4808233: "Locale" not thread-safe Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java Changeset: e446c7d24d6c Author: lana Date: 2011-12-15 19:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e446c7d24d6c Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h Changeset: 33ac7a057b9c Author: chegar Date: 2011-12-16 16:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/33ac7a057b9c 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java + src/share/classes/sun/misc/JavaNetHttpCookieAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpOnly.java Changeset: abbca81a98a7 Author: smarks Date: 2011-12-17 08:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abbca81a98a7 7122235: stop the build if javac fails Reviewed-by: chegar, dholmes, mcimadamore, ohair ! make/common/Rules.gmk Changeset: 528eb0d43e3a Author: alanb Date: 2011-12-17 20:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/528eb0d43e3a 7087549: (fs) Files.newInputStream throws UOE for custom provider options Reviewed-by: alanb Contributed-by: brandon.passanisi at oracle.com ! src/share/classes/java/nio/file/spi/FileSystemProvider.java + test/java/nio/file/Files/CustomOptions.java Changeset: 5b27b978ed42 Author: sherman Date: 2011-12-19 14:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b27b978ed42 6990617: Regular expression doesn't match if unicode character next to a digit. Summary: updated RemoveQEQuotation() to deal with this case correctly Reviewed-by: sherman Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 570f3d893596 Author: lana Date: 2011-12-20 15:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/570f3d893596 Merge - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java Changeset: 6f19ff39cff4 Author: lana Date: 2011-12-23 16:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f19ff39cff4 Merge - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 60dd940eb58e Author: yhuang Date: 2011-12-12 18:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60dd940eb58e 7003124: In Bulgarian Locale DateFormat is wrong Reviewed-by: naoto, peytoia ! src/share/classes/sun/text/resources/FormatData_bg.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cd03cd0e0965 Author: mfang Date: 2011-12-15 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags From james.melvin at oracle.com Sat Dec 31 08:43:50 2011 From: james.melvin at oracle.com (James Melvin) Date: Sat, 31 Dec 2011 11:43:50 -0500 Subject: RFR (S): 7125793: MAC: test_gamma should always work Message-ID: <4EFF3BC6.3060407@oracle.com> Hi, This change fixes the 'gamma' simple launcher for HotSpot on Mac OS X. There were 3 primary changes required to re-enable gamma... 1) Statically link with CoreFoundation framework to resolve symbols The gamma launcher dlopen()s libjava.dylib from $JAVA_HOME/jre/lib. Because Mac OS X files are case-insensitive by default, we collide on $FRAMEWORK/libJPEG.dylib and ${JAVA_HOME}/jre/lib/libjpeg.dylib. This resulted in unresolved symbols in the Mac OS X framework libraries. The solution for gamma was to statically link with CoreFoundation framework to properly resolve framework symbols and allow gamma to successfully dlopen() libjava.dylib. 2) Adjust various paths to reflect no arch subdirs On Mac OS X, there are no arch subdirs, e.g jre/lib vs jre/lib/. Instead, one can use universal binaries to package multiple architectures in a single binary. At the moment though, we are only building 64-bit non-universal binaries. Note, the test_gamma script assumes an Oracle JDK layout for JAVA_HOME, derived from ALT_BOOTDIR. Using an Apple JDK for ALT_BOOTDIR will fail the test_gamma script gracefully, as libjava.dylib is in a different, unexpected place. 3) Modify test_gamma script to set library path only for gamma launch Setting DYLD_LIBRARY_PATH adversely affects the real java launcher(s). Instead, set this later in the script only for the gamma launcher test run. While in there, I took the liberty of decrypting the script to make it more maintainable and more easily merged whenever we reconcile the unix ports into a single codebase. There is no change to the script output. Feedback welcome... WEBREV: http://cr.openjdk.java.net/~jmelvin/7125793/webrev.00 TESTS RUN: JPRT 2011-12-31-061123.jmelvin.7125793 local Mac OS X builds/tests Thanks and Happy New Year! Jim