From jiangli.zhou at oracle.com Thu Dec 1 10:51:34 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 01 Dec 2011 10:51:34 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type Message-ID: <4ED7CCB6.6020908@oracle.com> The instanceKlass::_init_state is defined as instanceKlass::ClassState type, which is an enum. Currently there are 7 class states defined. The instanceKlass::_init_state can be changed to u1 type, which could hold up 256 states. There are unused bytes after instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 and move it to after the _idnum_allocate_count field would save 4-byte for each loaded class. http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ Thanks, Jiangli From paul.hohensee at oracle.com Thu Dec 1 10:57:05 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 01 Dec 2011 13:57:05 -0500 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED7CCB6.6020908@oracle.com> References: <4ED7CCB6.6020908@oracle.com> Message-ID: <4ED7CE01.5030208@oracle.com> I can review everything except the c2 change, for which one of the compiler folks might chime in. Everything else looks good. Paul On 12/1/11 1:51 PM, Jiangli Zhou wrote: > The instanceKlass::_init_state is defined as instanceKlass::ClassState > type, which is an enum. Currently there are 7 class states defined. > The instanceKlass::_init_state can be changed to u1 type, which could > hold up 256 states. There are unused bytes after > instanceKlass::_idnum_allocated_count field. Changing _init_state to > u1 and move it to after the _idnum_allocate_count field would save > 4-byte for each loaded class. > > http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ > > Thanks, > > Jiangli > From jiangli.zhou at oracle.com Thu Dec 1 10:59:45 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 01 Dec 2011 10:59:45 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED7CE01.5030208@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED7CE01.5030208@oracle.com> Message-ID: <4ED7CEA1.6090404@oracle.com> Hi Paul, Thanks for your review! Jiangli On 12/01/2011 10:57 AM, Paul Hohensee wrote: > I can review everything except the c2 change, for which one of the > compiler > folks might chime in. Everything else looks good. > > Paul > > On 12/1/11 1:51 PM, Jiangli Zhou wrote: >> The instanceKlass::_init_state is defined as >> instanceKlass::ClassState type, which is an enum. Currently there are >> 7 class states defined. The instanceKlass::_init_state can be changed >> to u1 type, which could hold up 256 states. There are unused bytes >> after instanceKlass::_idnum_allocated_count field. Changing >> _init_state to u1 and move it to after the _idnum_allocate_count >> field would save 4-byte for each loaded class. >> >> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >> >> Thanks, >> >> Jiangli >> From tom.rodriguez at oracle.com Thu Dec 1 12:42:59 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 1 Dec 2011 12:42:59 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED7CCB6.6020908@oracle.com> References: <4ED7CCB6.6020908@oracle.com> Message-ID: <0A3572EF-7956-44EA-BB27-C9ACE313144C@oracle.com> On Dec 1, 2011, at 10:51 AM, Jiangli Zhou wrote: > The instanceKlass::_init_state is defined as instanceKlass::ClassState type, which is an enum. Currently there are 7 class states defined. The instanceKlass::_init_state can be changed to u1 type, which could hold up 256 states. There are unused bytes after instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 and move it to after the _idnum_allocate_count field would save 4-byte for each loaded class. The code in C2 to load it as T_BOOLEAN is somewhat questionable. In particular typing the result as a TypeInt::BOOL says that it only returns 0 or 1, which is definitely not true. It should be TypeInt::UBYTE which is the default type of a LoadUBNode. Using T_BOOLEAN still seems a little wonky but we don't have a BasicType for unsigned byte. tom > > http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ > > Thanks, > > Jiangli > From david.holmes at oracle.com Thu Dec 1 17:18:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 02 Dec 2011 11:18:23 +1000 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED7CCB6.6020908@oracle.com> References: <4ED7CCB6.6020908@oracle.com> Message-ID: <4ED8275F.80701@oracle.com> As already mentioned in internal email, there seem to be changes missing for debug builds. In instanceKlass set_init_state has two implementations - one for product and one for debug. The debug version has not been modified to accommodate the change in type. David On 2/12/2011 4:51 AM, Jiangli Zhou wrote: > The instanceKlass::_init_state is defined as instanceKlass::ClassState > type, which is an enum. Currently there are 7 class states defined. The > instanceKlass::_init_state can be changed to u1 type, which could hold > up 256 states. There are unused bytes after > instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 > and move it to after the _idnum_allocate_count field would save 4-byte > for each loaded class. > > http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ > > Thanks, > > Jiangli > From john.coomes at oracle.com Thu Dec 1 20:45:34 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:45:34 +0000 Subject: hg: hsx/hotspot-emb: Added tag jdk8-b15 for changeset a4f28069d44a Message-ID: <20111202044534.3DB6A47503@hg.openjdk.java.net> Changeset: 4e06ae613e99 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/4e06ae613e99 Added tag jdk8-b15 for changeset a4f28069d44a ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:45:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:45:39 +0000 Subject: hg: hsx/hotspot-emb/corba: 3 new changesets Message-ID: <20111202044542.E5C0F47504@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/corba/rev/7da69e7175a7 Merge Changeset: 82dc033975bb Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/82dc033975bb Added tag jdk8-b15 for changeset 7da69e7175a7 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:45:48 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:45:48 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b15 for changeset 804f666d6d44 Message-ID: <20111202044548.8340547505@hg.openjdk.java.net> Changeset: 8181f7634e4a Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/8181f7634e4a Added tag jdk8-b15 for changeset 804f666d6d44 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:45:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:45:53 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b15 for changeset c9ab96ff23d5 Message-ID: <20111202044553.D8F7E47506@hg.openjdk.java.net> Changeset: 76e37e606354 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/76e37e606354 Added tag jdk8-b15 for changeset c9ab96ff23d5 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:46:46 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:46:46 +0000 Subject: hg: hsx/hotspot-emb/jdk: 34 new changesets Message-ID: <20111202045249.406C14750C@hg.openjdk.java.net> Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/jdk/rev/60331bbcf4ad Merge Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/e5d65a583c15 Merge Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/1266e72f7896 Merge Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/b4d7020c2a40 Merge Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/929597c6e777 Added tag jdk8-b15 for changeset 3c248d0e2c48 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:55:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:55:29 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b15 for changeset a4f28069d44a Message-ID: <20111202045529.4BA3B4750D@hg.openjdk.java.net> Changeset: 4e06ae613e99 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/4e06ae613e99 Added tag jdk8-b15 for changeset a4f28069d44a ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:55:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:55:35 +0000 Subject: hg: hsx/hotspot-rt/corba: 3 new changesets Message-ID: <20111202045538.76F1D4750E@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/corba/rev/7da69e7175a7 Merge Changeset: 82dc033975bb Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/82dc033975bb Added tag jdk8-b15 for changeset 7da69e7175a7 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:55:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:55:43 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b15 for changeset 804f666d6d44 Message-ID: <20111202045544.04C004750F@hg.openjdk.java.net> Changeset: 8181f7634e4a Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/8181f7634e4a Added tag jdk8-b15 for changeset 804f666d6d44 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:55:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:55:49 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b15 for changeset c9ab96ff23d5 Message-ID: <20111202045549.3513E47510@hg.openjdk.java.net> Changeset: 76e37e606354 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/76e37e606354 Added tag jdk8-b15 for changeset c9ab96ff23d5 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:56:41 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:56:41 +0000 Subject: hg: hsx/hotspot-rt/jdk: 34 new changesets Message-ID: <20111202050227.7066647512@hg.openjdk.java.net> Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/jdk/rev/60331bbcf4ad Merge Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/e5d65a583c15 Merge Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/1266e72f7896 Merge Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/b4d7020c2a40 Merge Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/929597c6e777 Added tag jdk8-b15 for changeset 3c248d0e2c48 ! .hgtags From frederic.parain at oracle.com Fri Dec 2 05:57:14 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 02 Dec 2011 14:57:14 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework Message-ID: <4ED8D93A.5050600@oracle.com> Hi All, [Posting to serviceability-dev, runtime-dev and core-libs-dev because changes are pretty big and touch all these areas] Here's a framework for issuing diagnostics commands to the JVM. Diagnostic commands are actions executed inside the JVM mainly for monitoring or management purpose. This work has two parts. The first part is in the hotspot repository and contains the framework itself with two diagnostic commands. The second part is in the JDK repository and contains the command line utility to invoke diagnostic commands as well as the HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean extensions allow a remote client to discover and invoke diagnostic commands using a JMX connection. This changeset only contains two diagnostic commands, more commands will be added in the future, as a standalone effort to improve the monitoring and management services of the JVM, or as part of other projects. Webrevs are here: http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ Here's a technical description of this work: 1 - The Diagnostic Command Framework 1-1 Overview The diagnostic command framework is fully implemented in native code and relies on the HotSpot's internal exception mechanism. The rational of a pure native implementation is to be able to execute diagnostic commands even in critical situations like an OutOfMemory error. All diagnostic commands are registered in a single list, and two flags control the way a user can interact with them. The "hidden" flag prevents a diagnostic command from appearing in the list of available commands returned by the "help" command. However, it's still possible to get the detailed help message for a hidden command with the "help " syntax (but it requires to know the name of the hidden command). The second flag is "enabled" and it controls if a command can be invoked or not. When listed with the "help" commands, disabled commands appear with a "[disabled]" label in their description. If the user tries to invoke a disabled command, an error message is returned and the command is not run. This error message can be customized on a per command base. The framework just provides these two flags with their semantic, it doesn't provide any policy or mechanism to set or modify these flags. These actions will be delegated to the JVM or special diagnostic commands. 1-2 Implementation All diagnostic commands are implemented as subclasses of the DCmd class defined in services/diagnosticFramework.hpp. Here's the layout of the DCmd class and the list of methods that a new command has to define or overwrite: class DCmd { DCmd(outputStream *output); static const char *get_name(); static const char *get_description(); static const char *get_disabled_message(); static const char *get_impact(); static int get_num_arguments(); virtual void print_help(outputStream* out); virtual void parse(CmdLine* line, char delim, TRAPS); virtual void execute(TRAPS); virtual void reset(TRAPS); virtual void cleanup(); virtual GrowableArray* get_argument_name_array(); virtual GrowableArray* get_argument_info_array(); } A diagnostic command is always instantiated with an outputStream in parameter. This outputStream can point either to a file, a buffer or a socket (see the ostream.hpp file). The get_name() method returns the string that will identify the command (i.e. the string to put on the command line to invoke it). The get_description() methods returns the global description of the command. The get_disabled_message() returns the customized message to return when the command is disabled, without having to instantiate the command. The get_impact() returns a description of the intrusiveness of the diagnostic command on the Java Virtual Machine behavior. The rational for this method is that some diagnostic commands can seriously disrupt the behavior of the Java Virtual Machine (for instance a Thread Dump for an application with several tens of thousands of threads, or a Head Dump with a 40GB+ heap size) and other diagnostic commands have no serious impact on the JVM (for instance, getting the command line arguments or the JVM version). The recommended format for the description is : [longer description], where the impact level is selected among this list: {low, medium, high}. The optional longer description can provide more specific details like the fact that Thread Dump impact depends on the heap size. The get_num_arguments() returns the number of options/arguments recognized by the diagnostic command. This method is only used by the JMX interface support (see below). The print_help() methods prints a detailed help on the outputStream passed in argument. The detailed help contains the list of all supported options with their type and description. The parse() method is in charge of parsing the command arguments. Each command is free to implement its own argument parser. However, an argument parser framework is provided (see section 1-3) to ease the implementation, but its use is optional. The parse method takes a delimiter character in argument, which is used to mark the limit between two arguments (typically invocation from jcmd will use a space character as a delimiter while invocation from the JVM command line parsing code will use a comma as a delimiter). The execute() method is naturally the one to invoke to get the diagnostic command executed. The parse() and the execute() methods are dissociated, so it's a possible perform the argument parsing in one thread, and delegate the execution to another thread, as long as the diagnostic command doesn't reference thread local variables. The framework allows several instances of the same diagnostic command to be executed in parallel. If for some reasons concurrent executions should not be allowed for a given diagnostic command, this is the responsibility of the diagnostic command implementor to enforce this rule, for instance by protecting the body of the execute() method with a global lock. The reset() method is used to initialize the internal fields of the diagnostic command or to reset the internal fields to their initial value to be able to re-use an already allocated diagnostic command instance. The cleanup() method is used to perform perform cleanup (like freeing of all memory allocated to store internal data). The DCmd extends the ResourceObj class, so when allocated in a ResourceArea, destructors cannot be used to perform cleanup. To ensure that cleanup is performed in all cases, it is recommended to create a DCmdMark instance for each DCmd instance. DCmdMark is a stack allocated object with a pointer to a DCmd instance. When the DCmdMark is destroyed, its destructor calls the cleanup() method of the DCmd instance it points to. If the DCmd instance has been allocated on the C-Heap, the DCmdMark will also free the memory allocated to store the DCmd instance. The get_argument_name_array() and get_argument_info_array() are related to the JMX interface of the diagnostic command framework, so they are described in section 3. 1-3 DCmdParser framework The DCmdParser class is an optional framework to help development of argument parsers. It provides many features required by the diagnostic command framework (generation of the help message or the argument descriptions for the JMX interface) but all these features can easily be re-implemented if a developer decides not to use the DCmdParser framework. The DCmdParser class is relying on the DCmdArgument template. This template must be used to define the different types of argument the parser will have to handle. When a new specialization of the template is done, three methods have to be provided: void parse_value(const char *str,size_t len,TRAPS); void init_value(TRAPS); void destroy_value(); The parse_value() method is used to convert a string into an argument value. The print_value() method is used to display the default value (support for the detailed help message). The init_value() method is used to initialize or reset the argument value. The destroy_value() method is a clean-up method (useful when the argument has allocated some C-Heap memory to store its value and this memory has to be freed before destroying the DCmdArgument instance). The DCmdParser makes a distinction between options and arguments. Options are identified by a key name that must appear on the command line, while argument are identified just by the position of the argument on the command line. Options use the = syntax. In case of boolean options, the '=' part of the syntax can be omitted to set the option to true. Arguments are just sequences characters delimited by a separator character. This separator can be specified at runtime when invoking the diagnostic command framework. If an argument contain a character that could be used as a delimiter, it's possible to enclose the argument between single or double quotes. Options are arguments are instantiated using the same DCmdArgument class but they're registered differently to the DCmdParser. The way to use the DCmdParser is to declare the parser and the option/arguments as fields of the diagnostic command class (which is itself a sub-class of the DCmd class), like this: class EchoDCmd : public DCmd { protected: DCmdParser _dcmdparser; DCmdArgument _required; DCmdArgument _intval; DCmdArgument _boolval; DCmdArgument _stringval; DCmdArgument _first_arg; DCmdArgument _second_arg; DCmdArgument _optional_arg; } The parser and the options/arguments must be initialized before the diagnostic command class, and the options/arguments have to be registered to the parser like this: EchoDCmd(outputStream *output) : DCmd(output), _stringval("-strval","a string argument","STRING",false), _boolval("-boolval","a boolean argument","BOOLEAN",false), _intval("-intval","an integer argument","INTEGER",false), _required("-req","a mandatory integer argument","INTEGER",true), _fist_arg("first argument","a string argument","STRING",true), _second_arg("second argument,"an integer argument,"INTEGER",true), _optional_arg("optional argument","an optional string argument","STRING","false") { _dcmdparser.add_dcmd_option(&_stringval) _dcmdparser.add_dcmd_option(&_boolval); _dcmdparser.add_dcmd_option(&_intval); _dcmdparser.add_dcmd_option(&_required); _dcmdparser.add_argument(&_first_arg); _dcmdparser.add_argument(&_second_arg); _dcmdparser.add_argument(&_optional_arg); }; The add_dcmd_argument()/ add_dcmd_option() method is used to add an argument/option to the parser. The option/argument constructor takes the name of the option/argument, its description, a string describing its type and a boolean to specify if the option/argument is mandatory or not. The parser doesn't support option/argument duplicates (having the same name) but the code currently doesn't check for duplicates.The order used to register options has no impact on the parser. However, the order used to register arguments is critical because the parser will use the same order to parse the command line. In the example above, the parser expects to have a first argument of type STRING (parsed using _first_arg), then a second argument of type INTEGER (parsed using _second_arg) and optionally a third parameter of type STRING (parsed using _optional_arg). A mandatory option or argument has to be specify every time the command is invoked. If it is missing, an exception is thrown at the end of the parsing. Optional arguments have to be registered after mandatory arguments. An optional argument will be considered for parsing only if all arguments before it (mandatory or not) have already been used to parse the command line. The DCmdParser and its DCmdArgument instances are embedded in the DCmd instance. The rational for this design is to limit the number of C-heap allocations but also to be able to pre-allocate diagnostic command instances for critical situations. If the process is running out of C-heap space, it's not possible to instantiate new diagnostic commands to troubleshoot the situation. By pre-allocating some diagnostic commands, it will be possible to run them even in this critical situation. Of course, the diagnostic command itself should not try to allocate memory during its execution, this prevents the diagnostic command to use variable length arguments like strings. By nature, pre-allocated diagnostic commands aim to be re-usable, this is the purpose of the reset() method which restores the default status of all arguments. 1-4 Internal invocation Using a diagnostic command from the JVM itself is pretty easy: instantiate the class and invoke the parse() method then the execute() method. A diagnostic command can be instantiated from inside the JVM even it is not registered. This is a difference with the external invocations (from jcmd or JMX) that require the command to be registered. 2 - The JCmd interface Diagnostic commands can also be invoked from outside the JVM process, using the new 'jcmd' utility. The jcmd program uses the attach API to connect to the JVM, send requests and receive results. The jcmd utility must be launched on the same machine than the one running the JVM (its a local tool). Launched without arguments, jcmd displays a list of all JVMs running on the machine. The jcmd source code is in the jdk repository like other existing j* tools. To execute a diagnostic command in a particular JVM, the generic syntax is: jcmd [arguments] The attachListener has been modified to recognized the jcmd requests. When a jcmd request is identified, it is parsed to extract the command name. The JVM performs a look up of this command in a list of registered commands. To be executable by an external request, a diagnostic command has to be registered. The registration is performed with the DCmdFactory class (see services/management.cpp). 3 - The JMX interface The framework provides a JMX based interface to the diagnostic commands. This interface allows remote invocation of diagnostic commands through a JMX connection. 3-1 The interface The information related to the diagnostic commands are accessible through new methods added to the com.sun.management.HotspotDiagnosticMXBean: public List getDiagnosticCommands(); public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); public List getDiagnosticCommandInfo(List command); public List getDiagnosticCommandInfo(); public String execute(String commandLine) throws IllegalArgumentException ; public String execute(String cmd, String... arguments) throws IllegalArgumentException; The getDiagnosticCommands() method returns an array containing the names of the not-hidden registered diagnostic commands. The three getDiagnosticCommandInfo() methods return one or several diagnostic command descriptions using the DiagnosticCommandInfo class. The two execute() methods allow the user the invoke a diagnostic command in different ways. The DiagnosticCommandInfo class is describing a diagnostic command with the following information: public class DiagnosticCommandInfo { public String getName(); public String getDescription(); public String getImpact(); public boolean isEnabled(); public List getArgumentsInfo(); } The getName() method returns the name of the diagnostic command. This name is the one to use in execute() methods to invoke the diagnostic command. The getDescription() method returns a general description of the diagnostic command. The getImpact() method returns a description of the intrusiveness of diagnostic command. The isEnabled() method returns true if the method is enabled, false if it is disabled. A disabled method cannot be executed. The getArgumentsInfo() returns a list of descriptions for the options or arguments recognized by the diagnostic command. Each option/argument is described by a DiagnosticCommandArgumentInfo instance: public class DiagnosticCommandArgumentInfo { public String getName(); public String getDescription(); public String getType(); public String getDefault(); public boolean isMandatory(); public boolean isOption(); public int getPosition(); } If the DiagnosticCommandArgumentInfo instance describes an option, isOption() returns true and getPosition() returns -1. Otherwise, when the DiagnosticCommandArgumentInfo instance describes an argument, isOption() returns false and getPosition() returns the expected position for this argument. The position of an argument is defined relatively to all arguments passed on the command line, options are not considered when defining an argument position. The getDefault() method returns the default value of the argument if a default has been defined, otherwise it returns null. 3-2 The implementation The framework has been designed in a way that prevents diagnostic command developers to worry about the JMX interface. In addition to the methods described in section 1-2, a diagnostic command developer has to provide three methods: int get_num_arguments() which returns the number of option and arguments supported by the command. GrowableArray* get_argument_name_array() which provides the name of the arguments supported by the command. GrowableyArray* get_argument_info_array() which provides the description of each argument with a DCmdArgumentInfo instance. DCmdArgumentInfo is a C++ class used by the framework to generate the sun.com.management.DcmdArgumentInfo instances. This is done automatically and the diagnostic command developer doesn't need to know how to create Java objects from the runtime. 4 - The Diagnostic Commands To avoid name collisions between diagnostic commands coming from different projects, use of a flat name space should be avoided and a more structured organization is recommended. The framework itself doesn't depend on this organization, so it will be a set of rules defining a convention in the way commands are named. Diagnostic commands can easily organized in a hierarchical way, so the template for a command name can be: .[sub-domain.] This template can be extended with sub-sub-domains and so on. A special set of commands without domain will be reserved for the commands related to the diagnostic framework itself, like the "help" command. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From jiangli.zhou at oracle.com Fri Dec 2 10:53:02 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 02 Dec 2011 10:53:02 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <0A3572EF-7956-44EA-BB27-C9ACE313144C@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <0A3572EF-7956-44EA-BB27-C9ACE313144C@oracle.com> Message-ID: <4ED91E8E.9020406@oracle.com> Hi Tom, Thanks for the suggestion. I changed TypeInt::BOOL to TypeInt::UBYTE in c2 code. The updated webrev is: http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. Thanks, Jiangli On 12/01/2011 12:42 PM, Tom Rodriguez wrote: > On Dec 1, 2011, at 10:51 AM, Jiangli Zhou wrote: > >> The instanceKlass::_init_state is defined as instanceKlass::ClassState type, which is an enum. Currently there are 7 class states defined. The instanceKlass::_init_state can be changed to u1 type, which could hold up 256 states. There are unused bytes after instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 and move it to after the _idnum_allocate_count field would save 4-byte for each loaded class. > The code in C2 to load it as T_BOOLEAN is somewhat questionable. In particular typing the result as a TypeInt::BOOL says that it only returns 0 or 1, which is definitely not true. It should be TypeInt::UBYTE which is the default type of a LoadUBNode. Using T_BOOLEAN still seems a little wonky but we don't have a BasicType for unsigned byte. > > tom > >> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >> >> Thanks, >> >> Jiangli >> From jiangli.zhou at oracle.com Fri Dec 2 10:55:01 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 02 Dec 2011 10:55:01 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED8275F.80701@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> Message-ID: <4ED91F05.3070205@oracle.com> Hi David, Thanks for catching that. I changed the debug version of set_init_state(). The updated webrev is http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. Thanks, Jiangli On 12/01/2011 05:18 PM, David Holmes wrote: > As already mentioned in internal email, there seem to be changes > missing for debug builds. In instanceKlass set_init_state has two > implementations - one for product and one for debug. The debug version > has not been modified to accommodate the change in type. > > David > > On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >> The instanceKlass::_init_state is defined as instanceKlass::ClassState >> type, which is an enum. Currently there are 7 class states defined. The >> instanceKlass::_init_state can be changed to u1 type, which could hold >> up 256 states. There are unused bytes after >> instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 >> and move it to after the _idnum_allocate_count field would save 4-byte >> for each loaded class. >> >> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >> >> Thanks, >> >> Jiangli >> From tom.rodriguez at oracle.com Fri Dec 2 11:01:46 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Dec 2011 11:01:46 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED91E8E.9020406@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <0A3572EF-7956-44EA-BB27-C9ACE313144C@oracle.com> <4ED91E8E.9020406@oracle.com> Message-ID: <07FB664F-8FB4-47CA-BFCC-886A24DD8435@oracle.com> Looks good. tom On Dec 2, 2011, at 10:53 AM, Jiangli Zhou wrote: > Hi Tom, > > Thanks for the suggestion. I changed TypeInt::BOOL to TypeInt::UBYTE in c2 code. The updated webrev is: http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. > > Thanks, > > Jiangli > > On 12/01/2011 12:42 PM, Tom Rodriguez wrote: >> On Dec 1, 2011, at 10:51 AM, Jiangli Zhou wrote: >> >>> The instanceKlass::_init_state is defined as instanceKlass::ClassState type, which is an enum. Currently there are 7 class states defined. The instanceKlass::_init_state can be changed to u1 type, which could hold up 256 states. There are unused bytes after instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 and move it to after the _idnum_allocate_count field would save 4-byte for each loaded class. >> The code in C2 to load it as T_BOOLEAN is somewhat questionable. In particular typing the result as a TypeInt::BOOL says that it only returns 0 or 1, which is definitely not true. It should be TypeInt::UBYTE which is the default type of a LoadUBNode. Using T_BOOLEAN still seems a little wonky but we don't have a BasicType for unsigned byte. >> >> tom >> >>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>> >>> Thanks, >>> >>> Jiangli >>> > From jiangli.zhou at oracle.com Fri Dec 2 11:12:50 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 02 Dec 2011 11:12:50 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <07FB664F-8FB4-47CA-BFCC-886A24DD8435@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <0A3572EF-7956-44EA-BB27-C9ACE313144C@oracle.com> <4ED91E8E.9020406@oracle.com> <07FB664F-8FB4-47CA-BFCC-886A24DD8435@oracle.com> Message-ID: <4ED92332.90807@oracle.com> Thanks, Tom! Jiangli On 12/02/2011 11:01 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Dec 2, 2011, at 10:53 AM, Jiangli Zhou wrote: > >> Hi Tom, >> >> Thanks for the suggestion. I changed TypeInt::BOOL to TypeInt::UBYTE in c2 code. The updated webrev is: http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >> >> Thanks, >> >> Jiangli >> >> On 12/01/2011 12:42 PM, Tom Rodriguez wrote: >>> On Dec 1, 2011, at 10:51 AM, Jiangli Zhou wrote: >>> >>>> The instanceKlass::_init_state is defined as instanceKlass::ClassState type, which is an enum. Currently there are 7 class states defined. The instanceKlass::_init_state can be changed to u1 type, which could hold up 256 states. There are unused bytes after instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 and move it to after the _idnum_allocate_count field would save 4-byte for each loaded class. >>> The code in C2 to load it as T_BOOLEAN is somewhat questionable. In particular typing the result as a TypeInt::BOOL says that it only returns 0 or 1, which is definitely not true. It should be TypeInt::UBYTE which is the default type of a LoadUBNode. Using T_BOOLEAN still seems a little wonky but we don't have a BasicType for unsigned byte. >>> >>> tom >>> >>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> From john.coomes at oracle.com Fri Dec 2 13:27:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 21:27:00 +0000 Subject: hg: hsx/hotspot-emb/langtools: 34 new changesets Message-ID: <20111202212814.D9DC347524@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.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/JavadocTokenizer.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! 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/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/11c184155128 Merge Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.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/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/langtools/rev/f07d6f55d39a Merge Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/langtools/rev/ec2c0973cc31 Added tag jdk8-b15 for changeset 07599bd780ca ! .hgtags From john.coomes at oracle.com Fri Dec 2 14:19:15 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 22:19:15 +0000 Subject: hg: hsx/hotspot-rt/langtools: 34 new changesets Message-ID: <20111202222026.EAE4547542@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.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/JavadocTokenizer.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! 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/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/11c184155128 Merge Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.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/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/langtools/rev/f07d6f55d39a Merge Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/langtools/rev/ec2c0973cc31 Added tag jdk8-b15 for changeset 07599bd780ca ! .hgtags From daniel.daugherty at oracle.com Sat Dec 3 20:13:58 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 03 Dec 2011 21:13:58 -0700 Subject: Code Review Request for MacOS X build change (7117748) Message-ID: <4EDAF386.30307@oracle.com> Greetings, I have a fix that allows HSX-23 to be built on MacOS X via JPRT without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA on the command line. I'm targeting this fix at RT_Baseline for the HSX-23-B08 snapshot. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ I tested this fix with the default JPRT boot JDK (JDK6 from Apple) and with JDK7 boot JDK (JDK7 bits from Oracle). Thanks, in advance, for any reviews. Dan P.S. This fix does _not_ get "gamma" working on MacOS X. That work is being done separately. From vladimir.kozlov at oracle.com Sat Dec 3 22:58:18 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 03 Dec 2011 22:58:18 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDAF386.30307@oracle.com> References: <4EDAF386.30307@oracle.com> Message-ID: <4EDB1A0A.6070704@oracle.com> Sorry for my ignorance (and I can't access bugster now) but why we should care about building current Hotspot with Apple's JDK? Is is because Macs in JPRT have only Apple's JDK? What is _JUNK_ line for? Why there is no separate check for -f $(SA_CLASSPATH)? Current check also requires presence of lib/modules directory. thanks, Vladimir On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a fix that allows HSX-23 to be built on MacOS X via JPRT > without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA > on the command line. I'm targeting this fix at RT_Baseline for > the HSX-23-B08 snapshot. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ > > I tested this fix with the default JPRT boot JDK (JDK6 from Apple) > and with JDK7 boot JDK (JDK7 bits from Oracle). > > Thanks, in advance, for any reviews. > > Dan > > P.S. > This fix does _not_ get "gamma" working on MacOS X. > That work is being done separately. From daniel.daugherty at oracle.com Sun Dec 4 10:22:50 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 04 Dec 2011 11:22:50 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDB1A0A.6070704@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> Message-ID: <4EDBBA7A.9040903@oracle.com> Vladimir, Thanks for the quick review! On 12/3/11 11:58 PM, Vladimir Kozlov wrote: > Sorry for my ignorance (and I can't access bugster now) And the bug hasn't appeared on bug.sun.com yet... sigh... > but why we should care about building current Hotspot with Apple's > JDK? Is is because Macs in JPRT have only Apple's JDK? The default release in JPRT is 'jdk7' which means that the import JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... This means that my fix has to work with an Apple JDK or an Oracle JDK as the boot JDK. > What is _JUNK_ line for? Just a dummy variable so that the "INFO" mesg can be output. I tend to output INFO lines whenever an "ALT_*" variable is used. > Why there is no separate check for -f $(SA_CLASSPATH)? Current check > also requires presence of lib/modules directory. For these lines: 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d $(MODULELIB_PATH) ] ; then \ 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of JDK."; \ all I did was add quotes around $(SA_CLASSPATH) on line 88 and change the output message on line 89. Since SA_CLASSPATH can now be empty, I needed to make sure that the '-f' check didn't blow up due to the empty variable and the error mesg was confusing with the empty variable also. As for the lib/modules directory, 1) I didn't add that logic and 2) the logic doesn't require the lib/modules directory. The logic issues the error message and fails if the file named by SA_CLASSPATH does not exist and if the lib/modules directory does not exist. Whoever put that logic in the Makefile is assuming that if the lib/modules directory exists, then the JDI classes will be found (somehow). Please let me know if I've resolved your concerns. Dan > > thanks, > Vladimir > > On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >> on the command line. I'm targeting this fix at RT_Baseline for >> the HSX-23-B08 snapshot. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >> >> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >> and with JDK7 boot JDK (JDK7 bits from Oracle). >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> P.S. >> This fix does _not_ get "gamma" working on MacOS X. >> That work is being done separately. From daniel.daugherty at oracle.com Sun Dec 4 10:35:16 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 04 Dec 2011 11:35:16 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: References: <4EDAF386.30307@oracle.com> Message-ID: <4EDBBD64.9080503@oracle.com> Hey Mike, Thanks for the quick review! On 12/4/11 9:43 AM, Mike Swingler wrote: > On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >> on the command line. I'm targeting this fix at RT_Baseline for >> the HSX-23-B08 snapshot. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >> >> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >> and with JDK7 boot JDK (JDK7 bits from Oracle). >> >> Thanks, in advance, for any reviews. > My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. My understanding is that gamma doesn't currently build on Mac OS X in either the macosx-port forest or in the 7u-osx forest. Jim Melvin has been working to resolve that issue and when that work is done, then the ALWAYS_PASS_TEST_GAMMA stuff can go away. > The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. The SA_CLASSPATH stuff only checks for Apple's Java SE 6 layout when it can't find tools.jar. Please see my answer to Vladimir for when Apple's Java SE 6 is used as the boot JDK. As for gamma, are you saying that the gamma build is not broken when the MacOS X port is built with OpenJDK7 as the boot JDK? That's not my understanding, but I haven't tested it myself (yet). > I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? Hacky? :-) And I thought it was hacky to have to pass those variables on the build command line... :-) More seriously, the goal of this changeset is to get those variables off the command line so that MacOS X JPRT jobs can be submitted just like the other platforms... For the SA_CLASSPATH stuff, I think the logic is conditional enough: - look for tools.jar - if not found and building MacOS X, then look for Apple's Java SE 6 layout (classes.jar) - complain and fail if JDI classes cannot be found For gamma, all that logic will get deleted when we start being able to build gamma. If gamma builds now when OpenJDK7 is used as the boot JDK, then we'll rework the logic to be conditional when Apple's Java SE 6 is used as the boot JDK. Please let me know if this addresses your concerns. Dan From daniel.daugherty at oracle.com Sun Dec 4 12:31:15 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 04 Dec 2011 13:31:15 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> References: <4EDAF386.30307@oracle.com> <4EDBBD64.9080503@oracle.com> <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> Message-ID: <4EDBD893.9050301@oracle.com> Mike, Are you OK if I proceed with this changeset as is and deal with any additional gamma logic tweaks as part of making sure that gamma works? Dan On 12/4/11 12:05 PM, Mike Swingler wrote: > On Dec 4, 2011, at 10:35 AM, Daniel D. Daugherty wrote: > >> Hey Mike, >> >> Thanks for the quick review! >> >> On 12/4/11 9:43 AM, Mike Swingler wrote: >>> On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>> on the command line. I'm targeting this fix at RT_Baseline for >>>> the HSX-23-B08 snapshot. >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>> >>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>> >>>> Thanks, in advance, for any reviews. >>> My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. >> My understanding is that gamma doesn't currently build on Mac OS X >> in either the macosx-port forest or in the 7u-osx forest. Jim Melvin >> has been working to resolve that issue and when that work is done, >> then the ALWAYS_PASS_TEST_GAMMA stuff can go away. >> >>> The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. >> The SA_CLASSPATH stuff only checks for Apple's Java SE 6 layout when >> it can't find tools.jar. Please see my answer to Vladimir for when >> Apple's Java SE 6 is used as the boot JDK. > Yeah, I read that after I replied. :-P > >> As for gamma, are you saying that the gamma build is not broken when >> the MacOS X port is built with OpenJDK7 as the boot JDK? That's not >> my understanding, but I haven't tested it myself (yet). > I thought it works, but only when bootstrapped under JDK7...but I could be mistaken. > >>> I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? >> Hacky? :-) And I thought it was hacky to have to pass those variables >> on the build command line... :-) More seriously, the goal of this >> changeset is to get those variables off the command line so that >> MacOS X JPRT jobs can be submitted just like the other platforms... > Oh, of course...I don't think we should have anything more on the command line than "make". Personally, I wish the parallelization options could be auto-determined based on cores and total ram size ratio, and you should pass a parameter when you don't want them, or want to override them. > >> For the SA_CLASSPATH stuff, I think the logic is conditional enough: >> >> - look for tools.jar >> - if not found and building MacOS X, then look for >> Apple's Java SE 6 layout (classes.jar) >> - complain and fail if JDI classes cannot be found >> >> For gamma, all that logic will get deleted when we start being able to >> build gamma. If gamma builds now when OpenJDK7 is used as the boot JDK, >> then we'll rework the logic to be conditional when Apple's Java SE 6 is >> used as the boot JDK. >> >> Please let me know if this addresses your concerns. > I was under the impression that gamma actually passes when JDK7 is bootstrapped with JDK7, but I haven't tested that recently. > > Cheers, > Mike Swingler > Apple Inc. > From daniel.daugherty at oracle.com Sun Dec 4 13:19:43 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 04 Dec 2011 14:19:43 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: References: <4EDAF386.30307@oracle.com> <4EDBBD64.9080503@oracle.com> <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> <4EDBD893.9050301@oracle.com> Message-ID: <4EDBE3EF.7030603@oracle.com> Thanks Mike! Dan On 12/4/11 1:38 PM, Mike Swingler wrote: > Yeah, the webrev looks fine to me. > > Mike Swingler > Apple Inc. > > On Dec 4, 2011, at 12:31 PM, Daniel D. Daugherty wrote: > >> Mike, >> >> Are you OK if I proceed with this changeset as is and deal with >> any additional gamma logic tweaks as part of making sure that >> gamma works? >> >> Dan >> >> >> On 12/4/11 12:05 PM, Mike Swingler wrote: >>> On Dec 4, 2011, at 10:35 AM, Daniel D. Daugherty wrote: >>> >>>> Hey Mike, >>>> >>>> Thanks for the quick review! >>>> >>>> On 12/4/11 9:43 AM, Mike Swingler wrote: >>>>> On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: >>>>> >>>>>> Greetings, >>>>>> >>>>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>>>> on the command line. I'm targeting this fix at RT_Baseline for >>>>>> the HSX-23-B08 snapshot. >>>>>> >>>>>> Here is the webrev URL: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>>>> >>>>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>>>> >>>>>> Thanks, in advance, for any reviews. >>>>> My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. >>>> My understanding is that gamma doesn't currently build on Mac OS X >>>> in either the macosx-port forest or in the 7u-osx forest. Jim Melvin >>>> has been working to resolve that issue and when that work is done, >>>> then the ALWAYS_PASS_TEST_GAMMA stuff can go away. >>>> >>>>> The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. >>>> The SA_CLASSPATH stuff only checks for Apple's Java SE 6 layout when >>>> it can't find tools.jar. Please see my answer to Vladimir for when >>>> Apple's Java SE 6 is used as the boot JDK. >>> Yeah, I read that after I replied. :-P >>> >>>> As for gamma, are you saying that the gamma build is not broken when >>>> the MacOS X port is built with OpenJDK7 as the boot JDK? That's not >>>> my understanding, but I haven't tested it myself (yet). >>> I thought it works, but only when bootstrapped under JDK7...but I could be mistaken. >>> >>>>> I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? >>>> Hacky? :-) And I thought it was hacky to have to pass those variables >>>> on the build command line... :-) More seriously, the goal of this >>>> changeset is to get those variables off the command line so that >>>> MacOS X JPRT jobs can be submitted just like the other platforms... >>> Oh, of course...I don't think we should have anything more on the command line than "make". Personally, I wish the parallelization options could be auto-determined based on cores and total ram size ratio, and you should pass a parameter when you don't want them, or want to override them. >>> >>>> For the SA_CLASSPATH stuff, I think the logic is conditional enough: >>>> >>>> - look for tools.jar >>>> - if not found and building MacOS X, then look for >>>> Apple's Java SE 6 layout (classes.jar) >>>> - complain and fail if JDI classes cannot be found >>>> >>>> For gamma, all that logic will get deleted when we start being able to >>>> build gamma. If gamma builds now when OpenJDK7 is used as the boot JDK, >>>> then we'll rework the logic to be conditional when Apple's Java SE 6 is >>>> used as the boot JDK. >>>> >>>> Please let me know if this addresses your concerns. >>> I was under the impression that gamma actually passes when JDK7 is bootstrapped with JDK7, but I haven't tested that recently. >>> >>> Cheers, >>> Mike Swingler >>> Apple Inc. >>> From vladimir.kozlov at oracle.com Sun Dec 4 13:21:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 04 Dec 2011 13:21:09 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDBBA7A.9040903@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> Message-ID: <4EDBE445.4080204@oracle.com> Dan, I understand that module code was there before this fix but I am still concern that if lib/modules is present the makefile will continue execution even if SA_CLASSPATH does not exits. It looks like current code works for us because we don't have lib/modules in our build environment. Someone should explain why we need this modules code. Can we remove it? I am fine with the rest changes. Thanks, Vladimir On 12/4/11 10:22 AM, Daniel D. Daugherty wrote: > Vladimir, > > Thanks for the quick review! > > > On 12/3/11 11:58 PM, Vladimir Kozlov wrote: >> Sorry for my ignorance (and I can't access bugster now) > > And the bug hasn't appeared on bug.sun.com yet... sigh... > > >> but why we should care about building current Hotspot with Apple's JDK? Is is because Macs in JPRT have only Apple's JDK? > > The default release in JPRT is 'jdk7' which means that the import > JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is > 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' > boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the > boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... > > This means that my fix has to work with an Apple JDK or an Oracle > JDK as the boot JDK. > > >> What is _JUNK_ line for? > > Just a dummy variable so that the "INFO" mesg can be output. I tend > to output INFO lines whenever an "ALT_*" variable is used. > > >> Why there is no separate check for -f $(SA_CLASSPATH)? Current check also requires presence of lib/modules directory. > > For these lines: > > 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d $(MODULELIB_PATH) ] ; then \ > 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of JDK."; \ > > all I did was add quotes around $(SA_CLASSPATH) on line 88 > and change the output message on line 89. Since SA_CLASSPATH > can now be empty, I needed to make sure that the '-f' check > didn't blow up due to the empty variable and the error mesg > was confusing with the empty variable also. > > As for the lib/modules directory, 1) I didn't add that logic and > 2) the logic doesn't require the lib/modules directory. The logic > issues the error message and fails if the file named by > SA_CLASSPATH does not exist and if the lib/modules directory > does not exist. Whoever put that logic in the Makefile is assuming > that if the lib/modules directory exists, then the JDI classes > will be found (somehow). > > Please let me know if I've resolved your concerns. > > Dan > > >> >> thanks, >> Vladimir >> >> On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>> on the command line. I'm targeting this fix at RT_Baseline for >>> the HSX-23-B08 snapshot. >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>> >>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>> >>> Thanks, in advance, for any reviews. >>> >>> Dan >>> >>> P.S. >>> This fix does _not_ get "gamma" working on MacOS X. >>> That work is being done separately. From daniel.daugherty at oracle.com Sun Dec 4 13:36:02 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 04 Dec 2011 14:36:02 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDBE445.4080204@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> Message-ID: <4EDBE7C2.5020900@oracle.com> On 12/4/11 2:21 PM, Vladimir Kozlov wrote: > Dan, > > I understand that module code was there before this fix but I am still > concern that if lib/modules is present the makefile will continue > execution even if SA_CLASSPATH does not exits. Yes, I think that is intentional. But I will figure out who added the modules logic and check with them. > It looks like current code works for us because we don't have > lib/modules in our build environment. No, the current code works when SA_APPLE_BOOT_JAVA=true is specified on the command line and the boot JDK is in Apple's format because the JDI classes are found in classes.jar. When in the boot JDK is not in Apple's format and SA_APPLE_BOOT_JAVA is not specified, then the code works because the JDI classes are found in tools.jar. As long as one of the two expected boot JDKs are provided, then the modules code doesn't come into play. Even if lib/modules did exist in either of the boot JDKs, as long as either classes.jar or tools.jar is found, then all is good. > Someone should explain why we need this modules code. Can we remove it? I'll check into why that code is there, but I think it is an initial stab at modules support for the future... Dan > > I am fine with the rest changes. > > Thanks, > Vladimir > > On 12/4/11 10:22 AM, Daniel D. Daugherty wrote: >> Vladimir, >> >> Thanks for the quick review! >> >> >> On 12/3/11 11:58 PM, Vladimir Kozlov wrote: >>> Sorry for my ignorance (and I can't access bugster now) >> >> And the bug hasn't appeared on bug.sun.com yet... sigh... >> >> >>> but why we should care about building current Hotspot with Apple's >>> JDK? Is is because Macs in JPRT have only Apple's JDK? >> >> The default release in JPRT is 'jdk7' which means that the import >> JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is >> 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' >> boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the >> boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... >> >> This means that my fix has to work with an Apple JDK or an Oracle >> JDK as the boot JDK. >> >> >>> What is _JUNK_ line for? >> >> Just a dummy variable so that the "INFO" mesg can be output. I tend >> to output INFO lines whenever an "ALT_*" variable is used. >> >> >>> Why there is no separate check for -f $(SA_CLASSPATH)? Current check >>> also requires presence of lib/modules directory. >> >> For these lines: >> >> 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d $(MODULELIB_PATH) ] >> ; then \ >> 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of JDK."; \ >> >> all I did was add quotes around $(SA_CLASSPATH) on line 88 >> and change the output message on line 89. Since SA_CLASSPATH >> can now be empty, I needed to make sure that the '-f' check >> didn't blow up due to the empty variable and the error mesg >> was confusing with the empty variable also. >> >> As for the lib/modules directory, 1) I didn't add that logic and >> 2) the logic doesn't require the lib/modules directory. The logic >> issues the error message and fails if the file named by >> SA_CLASSPATH does not exist and if the lib/modules directory >> does not exist. Whoever put that logic in the Makefile is assuming >> that if the lib/modules directory exists, then the JDI classes >> will be found (somehow). >> >> Please let me know if I've resolved your concerns. >> >> Dan >> >> >>> >>> thanks, >>> Vladimir >>> >>> On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>> on the command line. I'm targeting this fix at RT_Baseline for >>>> the HSX-23-B08 snapshot. >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>> >>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>> >>>> Thanks, in advance, for any reviews. >>>> >>>> Dan >>>> >>>> P.S. >>>> This fix does _not_ get "gamma" working on MacOS X. >>>> That work is being done separately. From karen.kinnear at oracle.com Sun Dec 4 13:42:21 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Sun, 4 Dec 2011 16:42:21 -0500 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDBE7C2.5020900@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> Message-ID: If so - Mandy would be the one to ask ... thanks, Karen On Dec 4, 2011, at 4:36 PM, Daniel D. Daugherty wrote: > On 12/4/11 2:21 PM, Vladimir Kozlov wrote: >> Dan, >> >> I understand that module code was there before this fix but I am still concern that if lib/modules is present the makefile will continue execution even if SA_CLASSPATH does not exits. > > Yes, I think that is intentional. But I will figure out who added > the modules logic and check with them. > > >> It looks like current code works for us because we don't have lib/modules in our build environment. > > No, the current code works when SA_APPLE_BOOT_JAVA=true is specified > on the command line and the boot JDK is in Apple's format because the > JDI classes are found in classes.jar. When in the boot JDK is not in > Apple's format and SA_APPLE_BOOT_JAVA is not specified, then the code > works because the JDI classes are found in tools.jar. > > As long as one of the two expected boot JDKs are provided, then the > modules code doesn't come into play. Even if lib/modules did exist > in either of the boot JDKs, as long as either classes.jar or tools.jar > is found, then all is good. > > >> Someone should explain why we need this modules code. Can we remove it? > > I'll check into why that code is there, but I think it is an > initial stab at modules support for the future... > > Dan > > >> >> I am fine with the rest changes. >> >> Thanks, >> Vladimir >> >> On 12/4/11 10:22 AM, Daniel D. Daugherty wrote: >>> Vladimir, >>> >>> Thanks for the quick review! >>> >>> >>> On 12/3/11 11:58 PM, Vladimir Kozlov wrote: >>>> Sorry for my ignorance (and I can't access bugster now) >>> >>> And the bug hasn't appeared on bug.sun.com yet... sigh... >>> >>> >>>> but why we should care about building current Hotspot with Apple's JDK? Is is because Macs in JPRT have only Apple's JDK? >>> >>> The default release in JPRT is 'jdk7' which means that the import >>> JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is >>> 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' >>> boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the >>> boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... >>> >>> This means that my fix has to work with an Apple JDK or an Oracle >>> JDK as the boot JDK. >>> >>> >>>> What is _JUNK_ line for? >>> >>> Just a dummy variable so that the "INFO" mesg can be output. I tend >>> to output INFO lines whenever an "ALT_*" variable is used. >>> >>> >>>> Why there is no separate check for -f $(SA_CLASSPATH)? Current check also requires presence of lib/modules directory. >>> >>> For these lines: >>> >>> 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d $(MODULELIB_PATH) ] ; then \ >>> 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of JDK."; \ >>> >>> all I did was add quotes around $(SA_CLASSPATH) on line 88 >>> and change the output message on line 89. Since SA_CLASSPATH >>> can now be empty, I needed to make sure that the '-f' check >>> didn't blow up due to the empty variable and the error mesg >>> was confusing with the empty variable also. >>> >>> As for the lib/modules directory, 1) I didn't add that logic and >>> 2) the logic doesn't require the lib/modules directory. The logic >>> issues the error message and fails if the file named by >>> SA_CLASSPATH does not exist and if the lib/modules directory >>> does not exist. Whoever put that logic in the Makefile is assuming >>> that if the lib/modules directory exists, then the JDI classes >>> will be found (somehow). >>> >>> Please let me know if I've resolved your concerns. >>> >>> Dan >>> >>> >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>>> on the command line. I'm targeting this fix at RT_Baseline for >>>>> the HSX-23-B08 snapshot. >>>>> >>>>> Here is the webrev URL: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>>> >>>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>>> >>>>> Thanks, in advance, for any reviews. >>>>> >>>>> Dan >>>>> >>>>> P.S. >>>>> This fix does _not_ get "gamma" working on MacOS X. >>>>> That work is being done separately. From swingler at apple.com Sun Dec 4 08:43:03 2011 From: swingler at apple.com (Mike Swingler) Date: Sun, 04 Dec 2011 08:43:03 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDAF386.30307@oracle.com> References: <4EDAF386.30307@oracle.com> Message-ID: On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a fix that allows HSX-23 to be built on MacOS X via JPRT > without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA > on the command line. I'm targeting this fix at RT_Baseline for > the HSX-23-B08 snapshot. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ > > I tested this fix with the default JPRT boot JDK (JDK6 from Apple) > and with JDK7 boot JDK (JDK7 bits from Oracle). > > Thanks, in advance, for any reviews. My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? Thanks, Mike Swingler Apple Inc. From swingler at apple.com Sun Dec 4 11:05:19 2011 From: swingler at apple.com (Mike Swingler) Date: Sun, 04 Dec 2011 11:05:19 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDBBD64.9080503@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDBBD64.9080503@oracle.com> Message-ID: <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> On Dec 4, 2011, at 10:35 AM, Daniel D. Daugherty wrote: > Hey Mike, > > Thanks for the quick review! > > On 12/4/11 9:43 AM, Mike Swingler wrote: >> On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>> on the command line. I'm targeting this fix at RT_Baseline for >>> the HSX-23-B08 snapshot. >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>> >>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>> >>> Thanks, in advance, for any reviews. >> My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. > > My understanding is that gamma doesn't currently build on Mac OS X > in either the macosx-port forest or in the 7u-osx forest. Jim Melvin > has been working to resolve that issue and when that work is done, > then the ALWAYS_PASS_TEST_GAMMA stuff can go away. > >> The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. > > The SA_CLASSPATH stuff only checks for Apple's Java SE 6 layout when > it can't find tools.jar. Please see my answer to Vladimir for when > Apple's Java SE 6 is used as the boot JDK. Yeah, I read that after I replied. :-P > As for gamma, are you saying that the gamma build is not broken when > the MacOS X port is built with OpenJDK7 as the boot JDK? That's not > my understanding, but I haven't tested it myself (yet). I thought it works, but only when bootstrapped under JDK7...but I could be mistaken. >> I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? > > Hacky? :-) And I thought it was hacky to have to pass those variables > on the build command line... :-) More seriously, the goal of this > changeset is to get those variables off the command line so that > MacOS X JPRT jobs can be submitted just like the other platforms... Oh, of course...I don't think we should have anything more on the command line than "make". Personally, I wish the parallelization options could be auto-determined based on cores and total ram size ratio, and you should pass a parameter when you don't want them, or want to override them. > For the SA_CLASSPATH stuff, I think the logic is conditional enough: > > - look for tools.jar > - if not found and building MacOS X, then look for > Apple's Java SE 6 layout (classes.jar) > - complain and fail if JDI classes cannot be found > > For gamma, all that logic will get deleted when we start being able to > build gamma. If gamma builds now when OpenJDK7 is used as the boot JDK, > then we'll rework the logic to be conditional when Apple's Java SE 6 is > used as the boot JDK. > > Please let me know if this addresses your concerns. I was under the impression that gamma actually passes when JDK7 is bootstrapped with JDK7, but I haven't tested that recently. Cheers, Mike Swingler Apple Inc. From swingler at apple.com Sun Dec 4 12:38:22 2011 From: swingler at apple.com (Mike Swingler) Date: Sun, 04 Dec 2011 12:38:22 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDBD893.9050301@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDBBD64.9080503@oracle.com> <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> <4EDBD893.9050301@oracle.com> Message-ID: Yeah, the webrev looks fine to me. Mike Swingler Apple Inc. On Dec 4, 2011, at 12:31 PM, Daniel D. Daugherty wrote: > Mike, > > Are you OK if I proceed with this changeset as is and deal with > any additional gamma logic tweaks as part of making sure that > gamma works? > > Dan > > > On 12/4/11 12:05 PM, Mike Swingler wrote: >> On Dec 4, 2011, at 10:35 AM, Daniel D. Daugherty wrote: >> >>> Hey Mike, >>> >>> Thanks for the quick review! >>> >>> On 12/4/11 9:43 AM, Mike Swingler wrote: >>>> On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: >>>> >>>>> Greetings, >>>>> >>>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>>> on the command line. I'm targeting this fix at RT_Baseline for >>>>> the HSX-23-B08 snapshot. >>>>> >>>>> Here is the webrev URL: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>>> >>>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>>> >>>>> Thanks, in advance, for any reviews. >>>> My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. >>> My understanding is that gamma doesn't currently build on Mac OS X >>> in either the macosx-port forest or in the 7u-osx forest. Jim Melvin >>> has been working to resolve that issue and when that work is done, >>> then the ALWAYS_PASS_TEST_GAMMA stuff can go away. >>> >>>> The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. >>> The SA_CLASSPATH stuff only checks for Apple's Java SE 6 layout when >>> it can't find tools.jar. Please see my answer to Vladimir for when >>> Apple's Java SE 6 is used as the boot JDK. >> Yeah, I read that after I replied. :-P >> >>> As for gamma, are you saying that the gamma build is not broken when >>> the MacOS X port is built with OpenJDK7 as the boot JDK? That's not >>> my understanding, but I haven't tested it myself (yet). >> I thought it works, but only when bootstrapped under JDK7...but I could be mistaken. >> >>>> I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? >>> Hacky? :-) And I thought it was hacky to have to pass those variables >>> on the build command line... :-) More seriously, the goal of this >>> changeset is to get those variables off the command line so that >>> MacOS X JPRT jobs can be submitted just like the other platforms... >> Oh, of course...I don't think we should have anything more on the command line than "make". Personally, I wish the parallelization options could be auto-determined based on cores and total ram size ratio, and you should pass a parameter when you don't want them, or want to override them. >> >>> For the SA_CLASSPATH stuff, I think the logic is conditional enough: >>> >>> - look for tools.jar >>> - if not found and building MacOS X, then look for >>> Apple's Java SE 6 layout (classes.jar) >>> - complain and fail if JDI classes cannot be found >>> >>> For gamma, all that logic will get deleted when we start being able to >>> build gamma. If gamma builds now when OpenJDK7 is used as the boot JDK, >>> then we'll rework the logic to be conditional when Apple's Java SE 6 is >>> used as the boot JDK. >>> >>> Please let me know if this addresses your concerns. >> I was under the impression that gamma actually passes when JDK7 is bootstrapped with JDK7, but I haven't tested that recently. >> >> Cheers, >> Mike Swingler >> Apple Inc. >> From david.holmes at oracle.com Sun Dec 4 18:17:59 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Dec 2011 12:17:59 +1000 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4ED91F05.3070205@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> Message-ID: <4EDC29D7.5040100@oracle.com> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: > Hi David, > > Thanks for catching that. I changed the debug version of > set_init_state(). The updated webrev is > http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. Thanks - that update looks fine. Have you run SA tests to confirm no impact on SA code? Have you run any performance tests? David ----- > Thanks, > > Jiangli > > On 12/01/2011 05:18 PM, David Holmes wrote: >> As already mentioned in internal email, there seem to be changes >> missing for debug builds. In instanceKlass set_init_state has two >> implementations - one for product and one for debug. The debug version >> has not been modified to accommodate the change in type. >> >> David >> >> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>> The instanceKlass::_init_state is defined as instanceKlass::ClassState >>> type, which is an enum. Currently there are 7 class states defined. The >>> instanceKlass::_init_state can be changed to u1 type, which could hold >>> up 256 states. There are unused bytes after >>> instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 >>> and move it to after the _idnum_allocate_count field would save 4-byte >>> for each loaded class. >>> >>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>> >>> Thanks, >>> >>> Jiangli >>> > From james.melvin at oracle.com Mon Dec 5 07:49:14 2011 From: james.melvin at oracle.com (James Melvin) Date: Mon, 05 Dec 2011 10:49:14 -0500 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> References: <4EDAF386.30307@oracle.com> <4EDBBD64.9080503@oracle.com> <2F3BED66-09E7-4941-8F82-DD0467950700@apple.com> Message-ID: <4EDCE7FA.6080803@oracle.com> > I was under the impression that gamma actually passes when JDK7 is > bootstrapped with JDK7, but I haven't tested that recently. I can confirm that gamma does NOT work regardless of the BOOTDIR. We're not even building it at the moment. Setting ALWAYS_PASS_TEST_GAMMA will just ignore exit status from the test_gamma script. I started building gamma again, and running into arch mismatches and symbol not found issues. When gamma is run, we have not yet packaged the JVM as a universal binary. So, some additional makefile magic needs to happen to coordinate things and align searchpaths, etc. - Jim On 12/4/11 2:05 PM, Mike Swingler wrote: > On Dec 4, 2011, at 10:35 AM, Daniel D. Daugherty wrote: > >> Hey Mike, >> >> Thanks for the quick review! >> >> On 12/4/11 9:43 AM, Mike Swingler wrote: >>> On Dec 3, 2011, at 8:13 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>> on the command line. I'm targeting this fix at RT_Baseline for >>>> the HSX-23-B08 snapshot. >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>> >>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>> >>>> Thanks, in advance, for any reviews. >>> My concern is that you are skipping the gamma checks in the case when OpenJDK is being built with OpenJDK on the Mac. >> >> My understanding is that gamma doesn't currently build on Mac OS X >> in either the macosx-port forest or in the 7u-osx forest. Jim Melvin >> has been working to resolve that issue and when that work is done, >> then the ALWAYS_PASS_TEST_GAMMA stuff can go away. >> >>> The gamma tests (and the SA_CLASSPATH) logic only needs to be adjusted when you are building OpenJDK with Apple's Java SE 6. >> >> The SA_CLASSPATH stuff only checks for Apple's Java SE 6 layout when >> it can't find tools.jar. Please see my answer to Vladimir for when >> Apple's Java SE 6 is used as the boot JDK. > > Yeah, I read that after I replied. :-P > >> As for gamma, are you saying that the gamma build is not broken when >> the MacOS X port is built with OpenJDK7 as the boot JDK? That's not >> my understanding, but I haven't tested it myself (yet). > > I thought it works, but only when bootstrapped under JDK7...but I could be mistaken. > >>> I like the general direction of these fixes, but could you conditionalize the logic so that these hacky patches only get set when the current bootstrap Java is 1.6? >> >> Hacky? :-) And I thought it was hacky to have to pass those variables >> on the build command line... :-) More seriously, the goal of this >> changeset is to get those variables off the command line so that >> MacOS X JPRT jobs can be submitted just like the other platforms... > > Oh, of course...I don't think we should have anything more on the command line than "make". Personally, I wish the parallelization options could be auto-determined based on cores and total ram size ratio, and you should pass a parameter when you don't want them, or want to override them. > >> For the SA_CLASSPATH stuff, I think the logic is conditional enough: >> >> - look for tools.jar >> - if not found and building MacOS X, then look for >> Apple's Java SE 6 layout (classes.jar) >> - complain and fail if JDI classes cannot be found >> >> For gamma, all that logic will get deleted when we start being able to >> build gamma. If gamma builds now when OpenJDK7 is used as the boot JDK, >> then we'll rework the logic to be conditional when Apple's Java SE 6 is >> used as the boot JDK. >> >> Please let me know if this addresses your concerns. > > I was under the impression that gamma actually passes when JDK7 is bootstrapped with JDK7, but I haven't tested that recently. > > Cheers, > Mike Swingler > Apple Inc. > From daniel.daugherty at oracle.com Mon Dec 5 08:57:59 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 05 Dec 2011 09:57:59 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> Message-ID: <4EDCF817.1080802@oracle.com> make/bsd/makefiles/sa.make was created by cloning make/linux/makefiles/sa.make. The modules logic was added to sa.make by the following changeset: > changeset: 1547:0e7d2a08b605 > user: mchung > date: Wed Jul 07 15:35:58 2010 -0700 > files: make/linux/makefiles/sa.make > make/solaris/makefiles/sa.make src/os/linux/vm/os_linux.cpp > src/os/solaris/vm/os_solaris.cpp src/share/vm/runtime/os.cpp > description: > 6967423: Hotspot support for modules image > Summary: Add hotspot support for modules image > Reviewed-by: acorn The diffs for Linux sa.make look like: diff -r 5087ecc10458 -r 0e7d2a08b605 make/linux/makefiles/sa.make --- a/make/linux/makefiles/sa.make Wed Jul 07 14:12:08 2010 -0400 +++ b/make/linux/makefiles/sa.make Wed Jul 07 15:35:58 2010 -0700 @@ -40,6 +40,9 @@ # tools.jar is needed by the JDI - SA binding SA_CLASSPATH = $(BOOT_JAVA_HOME)/lib/tools.jar +# TODO: if it's a modules image, check if SA module is installed. +MODULELIB_PATH= $(BOOT_JAVA_HOME)/lib/modules + # gnumake 3.78.1 does not accept the *s that # are in AGENT_FILES1 and AGENT_FILES2, so use the shell to expand them AGENT_FILES1 := $(shell /usr/bin/test -d $(AGENT_DIR) && /bin/ls $(AGENT_FILES1)) @@ -65,7 +68,7 @@ echo "ALT_BOOTDIR, BOOTDIR or JAVA_HOME needs to be defined to build SA"; \ exit 1; \ fi - $(QUIETLY) if [ ! -f $(SA_CLASSPATH) ] ; then \ + $(QUIETLY) if [ ! -f $(SA_CLASSPATH) -a ! -d $(MODULELIB_PATH) ] ; then \ echo "Missing $(SA_CLASSPATH) file. Use 1.6.0 or later version of JDK";\ echo ""; \ exit 1; \ The logic before Mandy's change says: - if the $(SA_CLASSPATH) file doesn't exist, then complain and exit Mandy's changeset updated that logic to: - if the $(SA_CLASSPATH) file doesn't exist AND if the lib/modules directory does not exist, then complain and exit Mandy also added a TODO note about needing to add a check to see if the SA module is installed. So what does all this mean? - the modules logic that Mandy added is partial - there is a TODO note about what else needs to be added - if a proper boot JDK is provided, then the modules logic that Mandy added is never executed - if an improper boot JDK is provided AND the lib/modules directory exists, then the error message and exit will be skipped, but the build will fail later because the JDI classes won't be found In short (ha - too late for that), I think the SA_CLASSPATH logic is fine as it is. More modules changes will be needed in future, but that's not relevant to this fix. Vladimir, are you OK with this fix as it is? Dan On 12/4/11 2:42 PM, Karen Kinnear wrote: > If so - Mandy would be the one to ask ... > > thanks, > Karen > > On Dec 4, 2011, at 4:36 PM, Daniel D. Daugherty wrote: > >> On 12/4/11 2:21 PM, Vladimir Kozlov wrote: >>> Dan, >>> >>> I understand that module code was there before this fix but I am still concern that if lib/modules is present the makefile will continue execution even if SA_CLASSPATH does not exits. >> Yes, I think that is intentional. But I will figure out who added >> the modules logic and check with them. >> >> >>> It looks like current code works for us because we don't have lib/modules in our build environment. >> No, the current code works when SA_APPLE_BOOT_JAVA=true is specified >> on the command line and the boot JDK is in Apple's format because the >> JDI classes are found in classes.jar. When in the boot JDK is not in >> Apple's format and SA_APPLE_BOOT_JAVA is not specified, then the code >> works because the JDI classes are found in tools.jar. >> >> As long as one of the two expected boot JDKs are provided, then the >> modules code doesn't come into play. Even if lib/modules did exist >> in either of the boot JDKs, as long as either classes.jar or tools.jar >> is found, then all is good. >> >> >>> Someone should explain why we need this modules code. Can we remove it? >> I'll check into why that code is there, but I think it is an >> initial stab at modules support for the future... >> >> Dan >> >> >>> I am fine with the rest changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/4/11 10:22 AM, Daniel D. Daugherty wrote: >>>> Vladimir, >>>> >>>> Thanks for the quick review! >>>> >>>> >>>> On 12/3/11 11:58 PM, Vladimir Kozlov wrote: >>>>> Sorry for my ignorance (and I can't access bugster now) >>>> And the bug hasn't appeared on bug.sun.com yet... sigh... >>>> >>>> >>>>> but why we should care about building current Hotspot with Apple's JDK? Is is because Macs in JPRT have only Apple's JDK? >>>> The default release in JPRT is 'jdk7' which means that the import >>>> JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is >>>> 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' >>>> boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the >>>> boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... >>>> >>>> This means that my fix has to work with an Apple JDK or an Oracle >>>> JDK as the boot JDK. >>>> >>>> >>>>> What is _JUNK_ line for? >>>> Just a dummy variable so that the "INFO" mesg can be output. I tend >>>> to output INFO lines whenever an "ALT_*" variable is used. >>>> >>>> >>>>> Why there is no separate check for -f $(SA_CLASSPATH)? Current check also requires presence of lib/modules directory. >>>> For these lines: >>>> >>>> 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d $(MODULELIB_PATH) ] ; then \ >>>> 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of JDK."; \ >>>> >>>> all I did was add quotes around $(SA_CLASSPATH) on line 88 >>>> and change the output message on line 89. Since SA_CLASSPATH >>>> can now be empty, I needed to make sure that the '-f' check >>>> didn't blow up due to the empty variable and the error mesg >>>> was confusing with the empty variable also. >>>> >>>> As for the lib/modules directory, 1) I didn't add that logic and >>>> 2) the logic doesn't require the lib/modules directory. The logic >>>> issues the error message and fails if the file named by >>>> SA_CLASSPATH does not exist and if the lib/modules directory >>>> does not exist. Whoever put that logic in the Makefile is assuming >>>> that if the lib/modules directory exists, then the JDI classes >>>> will be found (somehow). >>>> >>>> Please let me know if I've resolved your concerns. >>>> >>>> Dan >>>> >>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>>>> on the command line. I'm targeting this fix at RT_Baseline for >>>>>> the HSX-23-B08 snapshot. >>>>>> >>>>>> Here is the webrev URL: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>>>> >>>>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>>>> >>>>>> Thanks, in advance, for any reviews. >>>>>> >>>>>> Dan >>>>>> >>>>>> P.S. >>>>>> This fix does _not_ get "gamma" working on MacOS X. >>>>>> That work is being done separately. > From mandy.chung at oracle.com Mon Dec 5 11:53:58 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 05 Dec 2011 11:53:58 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDBE7C2.5020900@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> Message-ID: <4EDD2156.5030901@oracle.com> Dan, I'll add more details in the next reply once I go through the discussion in this thread. The short answer is that you can remove the lib/modules check in the makefile if it helps clear the confusion. It was the change I made in hotspot to prepare for the integration of jigsaw/jdk integration that was initially planned for jdk7 [1]. Mandy P.S. Sorry for chiming in late. I'm off today. [1] http://mreinhold.org/blog/rethinking-jdk7 On 12/4/11 1:36 PM, Daniel D. Daugherty wrote: > On 12/4/11 2:21 PM, Vladimir Kozlov wrote: >> Dan, >> >> I understand that module code was there before this fix but I am >> still concern that if lib/modules is present the makefile will >> continue execution even if SA_CLASSPATH does not exits. > > Yes, I think that is intentional. But I will figure out who added > the modules logic and check with them. > > >> It looks like current code works for us because we don't have >> lib/modules in our build environment. > > No, the current code works when SA_APPLE_BOOT_JAVA=true is specified > on the command line and the boot JDK is in Apple's format because the > JDI classes are found in classes.jar. When in the boot JDK is not in > Apple's format and SA_APPLE_BOOT_JAVA is not specified, then the code > works because the JDI classes are found in tools.jar. > > As long as one of the two expected boot JDKs are provided, then the > modules code doesn't come into play. Even if lib/modules did exist > in either of the boot JDKs, as long as either classes.jar or tools.jar > is found, then all is good. > > >> Someone should explain why we need this modules code. Can we remove it? > > I'll check into why that code is there, but I think it is an > initial stab at modules support for the future... > > Dan > From vladimir.kozlov at oracle.com Mon Dec 5 12:11:24 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 05 Dec 2011 12:11:24 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDCF817.1080802@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> <4EDCF817.1080802@oracle.com> Message-ID: <4EDD256C.3010904@oracle.com> Thank you, Dan, for digging the history of modules code. Yes, I'm OK with your fix. Thanks, Vladimir On 12/5/11 8:57 AM, Daniel D. Daugherty wrote: > make/bsd/makefiles/sa.make was created by cloning > make/linux/makefiles/sa.make. The modules logic was > added to sa.make by the following changeset: > >> changeset: 1547:0e7d2a08b605 >> user: mchung >> date: Wed Jul 07 15:35:58 2010 -0700 >> files: make/linux/makefiles/sa.make make/solaris/makefiles/sa.make src/os/linux/vm/os_linux.cpp >> src/os/solaris/vm/os_solaris.cpp src/share/vm/runtime/os.cpp >> description: >> 6967423: Hotspot support for modules image >> Summary: Add hotspot support for modules image >> Reviewed-by: acorn > > The diffs for Linux sa.make look like: > > diff -r 5087ecc10458 -r 0e7d2a08b605 make/linux/makefiles/sa.make > --- a/make/linux/makefiles/sa.make Wed Jul 07 14:12:08 2010 -0400 > +++ b/make/linux/makefiles/sa.make Wed Jul 07 15:35:58 2010 -0700 > @@ -40,6 +40,9 @@ > # tools.jar is needed by the JDI - SA binding > SA_CLASSPATH = $(BOOT_JAVA_HOME)/lib/tools.jar > > +# TODO: if it's a modules image, check if SA module is installed. > +MODULELIB_PATH= $(BOOT_JAVA_HOME)/lib/modules > + > # gnumake 3.78.1 does not accept the *s that > # are in AGENT_FILES1 and AGENT_FILES2, so use the shell to expand them > AGENT_FILES1 := $(shell /usr/bin/test -d $(AGENT_DIR) && /bin/ls $(AGENT_FILES1)) > @@ -65,7 +68,7 @@ > echo "ALT_BOOTDIR, BOOTDIR or JAVA_HOME needs to be defined to build SA"; \ > exit 1; \ > fi > - $(QUIETLY) if [ ! -f $(SA_CLASSPATH) ] ; then \ > + $(QUIETLY) if [ ! -f $(SA_CLASSPATH) -a ! -d $(MODULELIB_PATH) ] ; then \ > echo "Missing $(SA_CLASSPATH) file. Use 1.6.0 or later version of JDK";\ > echo ""; \ > exit 1; \ > > > The logic before Mandy's change says: > > - if the $(SA_CLASSPATH) file doesn't exist, then complain and exit > > Mandy's changeset updated that logic to: > > - if the $(SA_CLASSPATH) file doesn't exist AND if the lib/modules > directory does not exist, then complain and exit > > Mandy also added a TODO note about needing to add a check to see > if the SA module is installed. > > So what does all this mean? > > - the modules logic that Mandy added is partial > - there is a TODO note about what else needs to be added > - if a proper boot JDK is provided, then the modules > logic that Mandy added is never executed > - if an improper boot JDK is provided AND the lib/modules > directory exists, then the error message and exit will > be skipped, but the build will fail later because the > JDI classes won't be found > > In short (ha - too late for that), I think the SA_CLASSPATH > logic is fine as it is. More modules changes will be needed > in future, but that's not relevant to this fix. > > Vladimir, are you OK with this fix as it is? > > Dan > > > > On 12/4/11 2:42 PM, Karen Kinnear wrote: >> If so - Mandy would be the one to ask ... >> >> thanks, >> Karen >> >> On Dec 4, 2011, at 4:36 PM, Daniel D. Daugherty wrote: >> >>> On 12/4/11 2:21 PM, Vladimir Kozlov wrote: >>>> Dan, >>>> >>>> I understand that module code was there before this fix but I am still concern that if lib/modules is present the >>>> makefile will continue execution even if SA_CLASSPATH does not exits. >>> Yes, I think that is intentional. But I will figure out who added >>> the modules logic and check with them. >>> >>> >>>> It looks like current code works for us because we don't have lib/modules in our build environment. >>> No, the current code works when SA_APPLE_BOOT_JAVA=true is specified >>> on the command line and the boot JDK is in Apple's format because the >>> JDI classes are found in classes.jar. When in the boot JDK is not in >>> Apple's format and SA_APPLE_BOOT_JAVA is not specified, then the code >>> works because the JDI classes are found in tools.jar. >>> >>> As long as one of the two expected boot JDKs are provided, then the >>> modules code doesn't come into play. Even if lib/modules did exist >>> in either of the boot JDKs, as long as either classes.jar or tools.jar >>> is found, then all is good. >>> >>> >>>> Someone should explain why we need this modules code. Can we remove it? >>> I'll check into why that code is there, but I think it is an >>> initial stab at modules support for the future... >>> >>> Dan >>> >>> >>>> I am fine with the rest changes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/4/11 10:22 AM, Daniel D. Daugherty wrote: >>>>> Vladimir, >>>>> >>>>> Thanks for the quick review! >>>>> >>>>> >>>>> On 12/3/11 11:58 PM, Vladimir Kozlov wrote: >>>>>> Sorry for my ignorance (and I can't access bugster now) >>>>> And the bug hasn't appeared on bug.sun.com yet... sigh... >>>>> >>>>> >>>>>> but why we should care about building current Hotspot with Apple's JDK? Is is because Macs in JPRT have only >>>>>> Apple's JDK? >>>>> The default release in JPRT is 'jdk7' which means that the import >>>>> JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is >>>>> 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' >>>>> boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the >>>>> boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... >>>>> >>>>> This means that my fix has to work with an Apple JDK or an Oracle >>>>> JDK as the boot JDK. >>>>> >>>>> >>>>>> What is _JUNK_ line for? >>>>> Just a dummy variable so that the "INFO" mesg can be output. I tend >>>>> to output INFO lines whenever an "ALT_*" variable is used. >>>>> >>>>> >>>>>> Why there is no separate check for -f $(SA_CLASSPATH)? Current check also requires presence of lib/modules directory. >>>>> For these lines: >>>>> >>>>> 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d $(MODULELIB_PATH) ] ; then \ >>>>> 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of JDK."; \ >>>>> >>>>> all I did was add quotes around $(SA_CLASSPATH) on line 88 >>>>> and change the output message on line 89. Since SA_CLASSPATH >>>>> can now be empty, I needed to make sure that the '-f' check >>>>> didn't blow up due to the empty variable and the error mesg >>>>> was confusing with the empty variable also. >>>>> >>>>> As for the lib/modules directory, 1) I didn't add that logic and >>>>> 2) the logic doesn't require the lib/modules directory. The logic >>>>> issues the error message and fails if the file named by >>>>> SA_CLASSPATH does not exist and if the lib/modules directory >>>>> does not exist. Whoever put that logic in the Makefile is assuming >>>>> that if the lib/modules directory exists, then the JDI classes >>>>> will be found (somehow). >>>>> >>>>> Please let me know if I've resolved your concerns. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>>>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>>>>> on the command line. I'm targeting this fix at RT_Baseline for >>>>>>> the HSX-23-B08 snapshot. >>>>>>> >>>>>>> Here is the webrev URL: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>>>>> >>>>>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>>>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>>>>> >>>>>>> Thanks, in advance, for any reviews. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> P.S. >>>>>>> This fix does _not_ get "gamma" working on MacOS X. >>>>>>> That work is being done separately. >> From mandy.chung at oracle.com Mon Dec 5 13:33:35 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 05 Dec 2011 13:33:35 -0800 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDCF817.1080802@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> <4EDCF817.1080802@oracle.com> Message-ID: <4EDD38AF.3020508@oracle.com> On 12/5/11 8:57 AM, Daniel D. Daugherty wrote: > > The logic before Mandy's change says: > > - if the $(SA_CLASSPATH) file doesn't exist, then complain and exit > > Mandy's changeset updated that logic to: > > - if the $(SA_CLASSPATH) file doesn't exist AND if the lib/modules > directory does not exist, then complain and exit > > Mandy also added a TODO note about needing to add a check to see > if the SA module is installed. > > So what does all this mean? > > - the modules logic that Mandy added is partial > - there is a TODO note about what else needs to be added > - if a proper boot JDK is provided, then the modules > logic that Mandy added is never executed > - if an improper boot JDK is provided AND the lib/modules > directory exists, then the error message and exit will > be skipped, but the build will fail later because the > JDI classes won't be found > I think Dan already got what he needs and Vladmir's approval to the review. FWIW. Some background to the SA build logic and modules image to explain the change I made: The check for SA_CLASSPATH exists in the boot JDK is to detect if the classpath was setup properly to compile the SA JDI connectors that references com.sun.jdi.* API. The build will fail before it compiles any sa-jdi classes. In the modular world, tools.jar, rt.jar, and other jar files no longer exist. Instead, com.sun.jdi will be installed in the modular JDK as a module. For a skip boot cycle build, the JDK will be built with itself. In other words, for jigsaw, it will build itself with a modular JDK. The makefile needs to detect if the boot JDK is a modular JDK or legacy JDK (i.e. existing JDK releases) and then checks for tools.jar or the module for JDI. A modular JDK will have a new "lib/modules" directory in which the jdk modules are installed. That's why the "lib/modules" check was added as the partial fix. A complete fix for this modules logic is to check if the module for JDI exists. In any case, this check can be removed if it causes any confusion. Mandy From daniel.daugherty at oracle.com Mon Dec 5 13:37:50 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 05 Dec 2011 14:37:50 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDD256C.3010904@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> <4EDCF817.1080802@oracle.com> <4EDD256C.3010904@oracle.com> Message-ID: <4EDD39AE.4000909@oracle.com> Thanks Vladimir! Dan On 12/5/11 1:11 PM, Vladimir Kozlov wrote: > Thank you, Dan, for digging the history of modules code. > Yes, I'm OK with your fix. > > Thanks, > Vladimir > > On 12/5/11 8:57 AM, Daniel D. Daugherty wrote: >> make/bsd/makefiles/sa.make was created by cloning >> make/linux/makefiles/sa.make. The modules logic was >> added to sa.make by the following changeset: >> >>> changeset: 1547:0e7d2a08b605 >>> user: mchung >>> date: Wed Jul 07 15:35:58 2010 -0700 >>> files: make/linux/makefiles/sa.make make/solaris/makefiles/sa.make >>> src/os/linux/vm/os_linux.cpp >>> src/os/solaris/vm/os_solaris.cpp src/share/vm/runtime/os.cpp >>> description: >>> 6967423: Hotspot support for modules image >>> Summary: Add hotspot support for modules image >>> Reviewed-by: acorn >> >> The diffs for Linux sa.make look like: >> >> diff -r 5087ecc10458 -r 0e7d2a08b605 make/linux/makefiles/sa.make >> --- a/make/linux/makefiles/sa.make Wed Jul 07 14:12:08 2010 -0400 >> +++ b/make/linux/makefiles/sa.make Wed Jul 07 15:35:58 2010 -0700 >> @@ -40,6 +40,9 @@ >> # tools.jar is needed by the JDI - SA binding >> SA_CLASSPATH = $(BOOT_JAVA_HOME)/lib/tools.jar >> >> +# TODO: if it's a modules image, check if SA module is installed. >> +MODULELIB_PATH= $(BOOT_JAVA_HOME)/lib/modules >> + >> # gnumake 3.78.1 does not accept the *s that >> # are in AGENT_FILES1 and AGENT_FILES2, so use the shell to expand them >> AGENT_FILES1 := $(shell /usr/bin/test -d $(AGENT_DIR) && /bin/ls >> $(AGENT_FILES1)) >> @@ -65,7 +68,7 @@ >> echo "ALT_BOOTDIR, BOOTDIR or JAVA_HOME needs to be defined to build >> SA"; \ >> exit 1; \ >> fi >> - $(QUIETLY) if [ ! -f $(SA_CLASSPATH) ] ; then \ >> + $(QUIETLY) if [ ! -f $(SA_CLASSPATH) -a ! -d $(MODULELIB_PATH) ] ; >> then \ >> echo "Missing $(SA_CLASSPATH) file. Use 1.6.0 or later version of JDK";\ >> echo ""; \ >> exit 1; \ >> >> >> The logic before Mandy's change says: >> >> - if the $(SA_CLASSPATH) file doesn't exist, then complain and exit >> >> Mandy's changeset updated that logic to: >> >> - if the $(SA_CLASSPATH) file doesn't exist AND if the lib/modules >> directory does not exist, then complain and exit >> >> Mandy also added a TODO note about needing to add a check to see >> if the SA module is installed. >> >> So what does all this mean? >> >> - the modules logic that Mandy added is partial >> - there is a TODO note about what else needs to be added >> - if a proper boot JDK is provided, then the modules >> logic that Mandy added is never executed >> - if an improper boot JDK is provided AND the lib/modules >> directory exists, then the error message and exit will >> be skipped, but the build will fail later because the >> JDI classes won't be found >> >> In short (ha - too late for that), I think the SA_CLASSPATH >> logic is fine as it is. More modules changes will be needed >> in future, but that's not relevant to this fix. >> >> Vladimir, are you OK with this fix as it is? >> >> Dan >> >> >> >> On 12/4/11 2:42 PM, Karen Kinnear wrote: >>> If so - Mandy would be the one to ask ... >>> >>> thanks, >>> Karen >>> >>> On Dec 4, 2011, at 4:36 PM, Daniel D. Daugherty wrote: >>> >>>> On 12/4/11 2:21 PM, Vladimir Kozlov wrote: >>>>> Dan, >>>>> >>>>> I understand that module code was there before this fix but I am >>>>> still concern that if lib/modules is present the >>>>> makefile will continue execution even if SA_CLASSPATH does not exits. >>>> Yes, I think that is intentional. But I will figure out who added >>>> the modules logic and check with them. >>>> >>>> >>>>> It looks like current code works for us because we don't have >>>>> lib/modules in our build environment. >>>> No, the current code works when SA_APPLE_BOOT_JAVA=true is specified >>>> on the command line and the boot JDK is in Apple's format because the >>>> JDI classes are found in classes.jar. When in the boot JDK is not in >>>> Apple's format and SA_APPLE_BOOT_JAVA is not specified, then the code >>>> works because the JDI classes are found in tools.jar. >>>> >>>> As long as one of the two expected boot JDKs are provided, then the >>>> modules code doesn't come into play. Even if lib/modules did exist >>>> in either of the boot JDKs, as long as either classes.jar or tools.jar >>>> is found, then all is good. >>>> >>>> >>>>> Someone should explain why we need this modules code. Can we >>>>> remove it? >>>> I'll check into why that code is there, but I think it is an >>>> initial stab at modules support for the future... >>>> >>>> Dan >>>> >>>> >>>>> I am fine with the rest changes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/4/11 10:22 AM, Daniel D. Daugherty wrote: >>>>>> Vladimir, >>>>>> >>>>>> Thanks for the quick review! >>>>>> >>>>>> >>>>>> On 12/3/11 11:58 PM, Vladimir Kozlov wrote: >>>>>>> Sorry for my ignorance (and I can't access bugster now) >>>>>> And the bug hasn't appeared on bug.sun.com yet... sigh... >>>>>> >>>>>> >>>>>>> but why we should care about building current Hotspot with >>>>>>> Apple's JDK? Is is because Macs in JPRT have only >>>>>>> Apple's JDK? >>>>>> The default release in JPRT is 'jdk7' which means that the import >>>>>> JDK is 'jdk7'. However, the boot JDK for a 'jdk7' release job is >>>>>> 'jdk6u18'. For MacOS X, we use Apple's bits for the 'jdk6u18' >>>>>> boot JDK. For a 'jdk8' release job, we use 'jdk7' bits as the >>>>>> boot JDK. For MacOS X, we use Oracle's 'jdk7' bits... >>>>>> >>>>>> This means that my fix has to work with an Apple JDK or an Oracle >>>>>> JDK as the boot JDK. >>>>>> >>>>>> >>>>>>> What is _JUNK_ line for? >>>>>> Just a dummy variable so that the "INFO" mesg can be output. I tend >>>>>> to output INFO lines whenever an "ALT_*" variable is used. >>>>>> >>>>>> >>>>>>> Why there is no separate check for -f $(SA_CLASSPATH)? Current >>>>>>> check also requires presence of lib/modules directory. >>>>>> For these lines: >>>>>> >>>>>> 88 $(QUIETLY) if [ ! -f "$(SA_CLASSPATH)" -a ! -d >>>>>> $(MODULELIB_PATH) ] ; then \ >>>>>> 89 echo "Cannot find JDI classes. Use 1.6.0 or later version of >>>>>> JDK."; \ >>>>>> >>>>>> all I did was add quotes around $(SA_CLASSPATH) on line 88 >>>>>> and change the output message on line 89. Since SA_CLASSPATH >>>>>> can now be empty, I needed to make sure that the '-f' check >>>>>> didn't blow up due to the empty variable and the error mesg >>>>>> was confusing with the empty variable also. >>>>>> >>>>>> As for the lib/modules directory, 1) I didn't add that logic and >>>>>> 2) the logic doesn't require the lib/modules directory. The logic >>>>>> issues the error message and fails if the file named by >>>>>> SA_CLASSPATH does not exist and if the lib/modules directory >>>>>> does not exist. Whoever put that logic in the Makefile is assuming >>>>>> that if the lib/modules directory exists, then the JDI classes >>>>>> will be found (somehow). >>>>>> >>>>>> Please let me know if I've resolved your concerns. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 12/3/11 8:13 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>>>>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>>>>>> on the command line. I'm targeting this fix at RT_Baseline for >>>>>>>> the HSX-23-B08 snapshot. >>>>>>>> >>>>>>>> Here is the webrev URL: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>>>>>> >>>>>>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>>>>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>>>>>> >>>>>>>> Thanks, in advance, for any reviews. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> P.S. >>>>>>>> This fix does _not_ get "gamma" working on MacOS X. >>>>>>>> That work is being done separately. >>> From daniel.daugherty at oracle.com Mon Dec 5 13:43:37 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 05 Dec 2011 14:43:37 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDD38AF.3020508@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDB1A0A.6070704@oracle.com> <4EDBBA7A.9040903@oracle.com> <4EDBE445.4080204@oracle.com> <4EDBE7C2.5020900@oracle.com> <4EDCF817.1080802@oracle.com> <4EDD38AF.3020508@oracle.com> Message-ID: <4EDD3B09.20103@oracle.com> On 12/5/11 2:33 PM, Mandy Chung wrote: > On 12/5/11 8:57 AM, Daniel D. Daugherty wrote: >> >> The logic before Mandy's change says: >> >> - if the $(SA_CLASSPATH) file doesn't exist, then complain and exit >> >> Mandy's changeset updated that logic to: >> >> - if the $(SA_CLASSPATH) file doesn't exist AND if the lib/modules >> directory does not exist, then complain and exit >> >> Mandy also added a TODO note about needing to add a check to see >> if the SA module is installed. >> >> So what does all this mean? >> >> - the modules logic that Mandy added is partial >> - there is a TODO note about what else needs to be added >> - if a proper boot JDK is provided, then the modules >> logic that Mandy added is never executed >> - if an improper boot JDK is provided AND the lib/modules >> directory exists, then the error message and exit will >> be skipped, but the build will fail later because the >> JDI classes won't be found >> > > I think Dan already got what he needs and Vladmir's approval to the > review. > > FWIW. Some background to the SA build logic and modules image to > explain the change I made: > > The check for SA_CLASSPATH exists in the boot JDK is to detect if the > classpath was setup properly to compile the SA JDI connectors that > references com.sun.jdi.* API. The build will fail before it compiles > any sa-jdi classes. In the modular world, tools.jar, rt.jar, and > other jar files no longer exist. Instead, com.sun.jdi will be > installed in the modular JDK as a module. For a skip boot cycle > build, the JDK will be built with itself. In other words, for jigsaw, > it will build itself with a modular JDK. The makefile needs to detect > if the boot JDK is a modular JDK or legacy JDK (i.e. existing JDK > releases) and then checks for tools.jar or the module for JDI. A > modular JDK will have a new "lib/modules" directory in which the jdk > modules are installed. That's why the "lib/modules" check was added > as the partial fix. A complete fix for this modules logic is to check > if the module for JDI exists. In any case, this check can be removed > if it causes any confusion. > > Mandy Mandy, Thanks for filling in the history. I think I'm going with the fix for 7117748 as it is since I have reviews from Vladimir and Mike S from Apple. Dan From paul.hohensee at oracle.com Mon Dec 5 15:37:42 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Mon, 05 Dec 2011 23:37:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot Message-ID: <20111205233746.B380147590@hg.openjdk.java.net> Changeset: cd00eaeebef6 Author: phh Date: 2011-12-05 12:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 From jiangli.zhou at oracle.com Mon Dec 5 17:21:32 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 05 Dec 2011 17:21:32 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EDC29D7.5040100@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> Message-ID: <4EDD6E1C.3000608@oracle.com> Hi David, Thanks for the review and suggestions. Could you please let me know where I can find SA tests and instructions for running those tests? I'm double check the performance impact. Thanks, Jiangli On 12/04/2011 06:17 PM, David Holmes wrote: > On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >> Hi David, >> >> Thanks for catching that. I changed the debug version of >> set_init_state(). The updated webrev is >> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. > > Thanks - that update looks fine. > > Have you run SA tests to confirm no impact on SA code? > > Have you run any performance tests? > > David > ----- > >> Thanks, >> >> Jiangli >> >> On 12/01/2011 05:18 PM, David Holmes wrote: >>> As already mentioned in internal email, there seem to be changes >>> missing for debug builds. In instanceKlass set_init_state has two >>> implementations - one for product and one for debug. The debug version >>> has not been modified to accommodate the change in type. >>> >>> David >>> >>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>> The instanceKlass::_init_state is defined as instanceKlass::ClassState >>>> type, which is an enum. Currently there are 7 class states defined. >>>> The >>>> instanceKlass::_init_state can be changed to u1 type, which could hold >>>> up 256 states. There are unused bytes after >>>> instanceKlass::_idnum_allocated_count field. Changing _init_state >>>> to u1 >>>> and move it to after the _idnum_allocate_count field would save 4-byte >>>> for each loaded class. >>>> >>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >> From daniel.daugherty at oracle.com Tue Dec 6 06:53:39 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 06 Dec 2011 07:53:39 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDAF386.30307@oracle.com> References: <4EDAF386.30307@oracle.com> Message-ID: <4EDE2C73.1000005@oracle.com> Paul, I'd like to push this fix to the jdk7u/jdk7u-osx/hotspot repo. The fix is in the JPRT-hotspotwest queue heading to RT_Baseline and I have it setup so that the same changeset can also go into the jdk7u/jdk7u-osx/hotspot repo. Do I have permission? Dan On 12/3/11 9:13 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a fix that allows HSX-23 to be built on MacOS X via JPRT > without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA > on the command line. I'm targeting this fix at RT_Baseline for > the HSX-23-B08 snapshot. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ > > I tested this fix with the default JPRT boot JDK (JDK6 from Apple) > and with JDK7 boot JDK (JDK7 bits from Oracle). > > Thanks, in advance, for any reviews. > > Dan > > P.S. > This fix does _not_ get "gamma" working on MacOS X. > That work is being done separately. > From paul.hohensee at oracle.com Tue Dec 6 07:02:14 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 06 Dec 2011 10:02:14 -0500 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDE2C73.1000005@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDE2C73.1000005@oracle.com> Message-ID: <4EDE2E76.4090402@oracle.com> [dropped some of the cc's inadvertently] If you push directly to jdk7u-osx/hotspot, and then we pull hs23 with the identical fix down into it, we'll have a conflict. Current process is to push up to hsx/hsx23, PIT over the weekend and push the following week. In this case, that'd be next week. So, do you really, really have to push this change into jdk7u-osx/hotspot right now? E.g., could you publish a patch instead as Mike has done? Paul On 12/6/11 9:53 AM, Daniel D. Daugherty wrote: > Paul, > > I'd like to push this fix to the jdk7u/jdk7u-osx/hotspot repo. > The fix is in the JPRT-hotspotwest queue heading to RT_Baseline > and I have it setup so that the same changeset can also go into > the jdk7u/jdk7u-osx/hotspot repo. > > Do I have permission? > > Dan > > > On 12/3/11 9:13 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >> on the command line. I'm targeting this fix at RT_Baseline for >> the HSX-23-B08 snapshot. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >> >> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >> and with JDK7 boot JDK (JDK7 bits from Oracle). >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> P.S. >> This fix does _not_ get "gamma" working on MacOS X. >> That work is being done separately. >> From daniel.daugherty at oracle.com Tue Dec 6 07:04:36 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 06 Dec 2011 08:04:36 -0700 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDE2E76.4090402@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDE2C73.1000005@oracle.com> <4EDE2E76.4090402@oracle.com> Message-ID: <4EDE2F04.4010601@oracle.com> No conflict because it is the same changeset. I'm just trying to make it easier to build the jdk7u-osx forest with JPRT. Your call as to whether you want it now or later... Dan On 12/6/11 8:02 AM, Paul Hohensee wrote: > [dropped some of the cc's inadvertently] > > If you push directly to jdk7u-osx/hotspot, and then we pull hs23 with > the identical fix down into it, we'll have a conflict. Current process > is to push up to hsx/hsx23, PIT over the weekend and push the > following week. In this case, that'd be next week. So, do you > really, really have to push this change into jdk7u-osx/hotspot > right now? E.g., could you publish a patch instead as Mike has done? > > Paul > > On 12/6/11 9:53 AM, Daniel D. Daugherty wrote: >> Paul, >> >> I'd like to push this fix to the jdk7u/jdk7u-osx/hotspot repo. >> The fix is in the JPRT-hotspotwest queue heading to RT_Baseline >> and I have it setup so that the same changeset can also go into >> the jdk7u/jdk7u-osx/hotspot repo. >> >> Do I have permission? >> >> Dan >> >> >> On 12/3/11 9:13 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>> on the command line. I'm targeting this fix at RT_Baseline for >>> the HSX-23-B08 snapshot. >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>> >>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>> >>> Thanks, in advance, for any reviews. >>> >>> Dan >>> >>> P.S. >>> This fix does _not_ get "gamma" working on MacOS X. >>> That work is being done separately. >>> From paul.hohensee at oracle.com Tue Dec 6 07:09:47 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 06 Dec 2011 10:09:47 -0500 Subject: Code Review Request for MacOS X build change (7117748) In-Reply-To: <4EDE2F04.4010601@oracle.com> References: <4EDAF386.30307@oracle.com> <4EDE2C73.1000005@oracle.com> <4EDE2E76.4090402@oracle.com> <4EDE2F04.4010601@oracle.com> Message-ID: <4EDE303B.7080201@oracle.com> Push now, please. Paul On 12/6/11 10:04 AM, Daniel D. Daugherty wrote: > No conflict because it is the same changeset. > I'm just trying to make it easier to build the > jdk7u-osx forest with JPRT. Your call as to > whether you want it now or later... > > Dan > > On 12/6/11 8:02 AM, Paul Hohensee wrote: >> [dropped some of the cc's inadvertently] >> >> If you push directly to jdk7u-osx/hotspot, and then we pull hs23 with >> the identical fix down into it, we'll have a conflict. Current process >> is to push up to hsx/hsx23, PIT over the weekend and push the >> following week. In this case, that'd be next week. So, do you >> really, really have to push this change into jdk7u-osx/hotspot >> right now? E.g., could you publish a patch instead as Mike has done? >> >> Paul >> >> On 12/6/11 9:53 AM, Daniel D. Daugherty wrote: >>> Paul, >>> >>> I'd like to push this fix to the jdk7u/jdk7u-osx/hotspot repo. >>> The fix is in the JPRT-hotspotwest queue heading to RT_Baseline >>> and I have it setup so that the same changeset can also go into >>> the jdk7u/jdk7u-osx/hotspot repo. >>> >>> Do I have permission? >>> >>> Dan >>> >>> >>> On 12/3/11 9:13 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a fix that allows HSX-23 to be built on MacOS X via JPRT >>>> without specifying SA_APPLE_BOOT_JAVA or ALWAYS_PASS_TEST_GAMMA >>>> on the command line. I'm targeting this fix at RT_Baseline for >>>> the HSX-23-B08 snapshot. >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7117748-webrev/0/ >>>> >>>> I tested this fix with the default JPRT boot JDK (JDK6 from Apple) >>>> and with JDK7 boot JDK (JDK7 bits from Oracle). >>>> >>>> Thanks, in advance, for any reviews. >>>> >>>> Dan >>>> >>>> P.S. >>>> This fix does _not_ get "gamma" working on MacOS X. >>>> That work is being done separately. >>>> From daniel.daugherty at oracle.com Tue Dec 6 07:53:49 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 06 Dec 2011 15:53:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 6 new changesets Message-ID: <20111206155401.46D9947599@hg.openjdk.java.net> Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/088d09a130ff Added tag jdk8-b13 for changeset b92ca8e229d2 ! .hgtags Changeset: 883328bfc472 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/883328bfc472 Added tag jdk8-b14 for changeset 088d09a130ff ! .hgtags Changeset: 6c2a55d4902f Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags Changeset: 8657ec177a14 Author: dcubed Date: 2011-12-05 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/41cce03b29a8 Merge From tom.rodriguez at oracle.com Tue Dec 6 10:10:16 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 6 Dec 2011 10:10:16 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EDD6E1C.3000608@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> Message-ID: <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> You can run them using ute, /net/sqenfs-1.us.oracle.com/export1/tools/gtee/bin/ute. Use -jdk to specify the test JDK, -vmopts to pass any options and -test select a suite. nsk/sajdi/ and tmtools/ are the main ones that exercise the SA. nsk/sajdi has quite a few known failures so it can be tricky to evaluate the results. tom On Dec 5, 2011, at 5:21 PM, Jiangli Zhou wrote: > Hi David, > > Thanks for the review and suggestions. Could you please let me know where I can find SA tests and instructions for running those tests? > > I'm double check the performance impact. > > > Thanks, > Jiangli > > On 12/04/2011 06:17 PM, David Holmes wrote: >> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >>> Hi David, >>> >>> Thanks for catching that. I changed the debug version of >>> set_init_state(). The updated webrev is >>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >> >> Thanks - that update looks fine. >> >> Have you run SA tests to confirm no impact on SA code? >> >> Have you run any performance tests? >> >> David >> ----- >> >>> Thanks, >>> >>> Jiangli >>> >>> On 12/01/2011 05:18 PM, David Holmes wrote: >>>> As already mentioned in internal email, there seem to be changes >>>> missing for debug builds. In instanceKlass set_init_state has two >>>> implementations - one for product and one for debug. The debug version >>>> has not been modified to accommodate the change in type. >>>> >>>> David >>>> >>>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>>> The instanceKlass::_init_state is defined as instanceKlass::ClassState >>>>> type, which is an enum. Currently there are 7 class states defined. The >>>>> instanceKlass::_init_state can be changed to u1 type, which could hold >>>>> up 256 states. There are unused bytes after >>>>> instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 >>>>> and move it to after the _idnum_allocate_count field would save 4-byte >>>>> for each loaded class. >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>> > From jiangli.zhou at oracle.com Tue Dec 6 10:13:26 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 06 Dec 2011 10:13:26 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> Message-ID: <4EDE5B46.60901@oracle.com> Thanks, Tom! On 12/06/2011 10:10 AM, Tom Rodriguez wrote: > You can run them using ute, /net/sqenfs-1.us.oracle.com/export1/tools/gtee/bin/ute. Use -jdk to specify the test JDK, -vmopts to pass any options and -test select a suite. nsk/sajdi/ and tmtools/ are the main ones that exercise the SA. nsk/sajdi has quite a few known failures so it can be tricky to evaluate the results. I'll compare with a baseline to make sure the changes do not introduce new failures. Thanks, Jiangli > tom > > On Dec 5, 2011, at 5:21 PM, Jiangli Zhou wrote: > >> Hi David, >> >> Thanks for the review and suggestions. Could you please let me know where I can find SA tests and instructions for running those tests? >> >> I'm double check the performance impact. >> >> >> Thanks, >> Jiangli >> >> On 12/04/2011 06:17 PM, David Holmes wrote: >>> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >>>> Hi David, >>>> >>>> Thanks for catching that. I changed the debug version of >>>> set_init_state(). The updated webrev is >>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >>> Thanks - that update looks fine. >>> >>> Have you run SA tests to confirm no impact on SA code? >>> >>> Have you run any performance tests? >>> >>> David >>> ----- >>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> On 12/01/2011 05:18 PM, David Holmes wrote: >>>>> As already mentioned in internal email, there seem to be changes >>>>> missing for debug builds. In instanceKlass set_init_state has two >>>>> implementations - one for product and one for debug. The debug version >>>>> has not been modified to accommodate the change in type. >>>>> >>>>> David >>>>> >>>>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>>>> The instanceKlass::_init_state is defined as instanceKlass::ClassState >>>>>> type, which is an enum. Currently there are 7 class states defined. The >>>>>> instanceKlass::_init_state can be changed to u1 type, which could hold >>>>>> up 256 states. There are unused bytes after >>>>>> instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 >>>>>> and move it to after the _idnum_allocate_count field would save 4-byte >>>>>> for each loaded class. >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> From jiangli.zhou at oracle.com Tue Dec 6 11:23:03 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 06 Dec 2011 11:23:03 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> Message-ID: <4EDE6B97.6030905@oracle.com> Hi David and Tom, I ran nsk/sajdi/ tests for the class state changes. Comparing to a baseline, there is no new failure in those tests. The changes do not seem to have noticeable performance impact. Specjvm98 shows only noise variation (-0.06 ~ 0.39). ============================================================================== logs.baseline: Benchmark Samples Mean Stdev Geomean Weight specjvm98 3 264.56 4.50 ============================================================================== logs.1: Benchmark Samples Mean Stdev %Diff P Significant specjvm98 3 264.41 11.12 -0.06 0.984 * ============================================================================== ============================================================================== logs.baseline: Benchmark Samples Mean Stdev Geomean Weight specjvm98 3 264.56 4.50 ============================================================================== logs.1.2: Benchmark Samples Mean Stdev %Diff P Significant specjvm98 3 265.61 4.92 0.39 0.800 * ============================================================================== Thanks, Jiangli On 12/06/2011 10:10 AM, Tom Rodriguez wrote: > You can run them using ute, /net/sqenfs-1.us.oracle.com/export1/tools/gtee/bin/ute. Use -jdk to specify the test JDK, -vmopts to pass any options and -test select a suite. nsk/sajdi/ and tmtools/ are the main ones that exercise the SA. nsk/sajdi has quite a few known failures so it can be tricky to evaluate the results. > > tom > > On Dec 5, 2011, at 5:21 PM, Jiangli Zhou wrote: > >> Hi David, >> >> Thanks for the review and suggestions. Could you please let me know where I can find SA tests and instructions for running those tests? >> >> I'm double check the performance impact. >> >> >> Thanks, >> Jiangli >> >> On 12/04/2011 06:17 PM, David Holmes wrote: >>> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >>>> Hi David, >>>> >>>> Thanks for catching that. I changed the debug version of >>>> set_init_state(). The updated webrev is >>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >>> Thanks - that update looks fine. >>> >>> Have you run SA tests to confirm no impact on SA code? >>> >>> Have you run any performance tests? >>> >>> David >>> ----- >>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> On 12/01/2011 05:18 PM, David Holmes wrote: >>>>> As already mentioned in internal email, there seem to be changes >>>>> missing for debug builds. In instanceKlass set_init_state has two >>>>> implementations - one for product and one for debug. The debug version >>>>> has not been modified to accommodate the change in type. >>>>> >>>>> David >>>>> >>>>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>>>> The instanceKlass::_init_state is defined as instanceKlass::ClassState >>>>>> type, which is an enum. Currently there are 7 class states defined. The >>>>>> instanceKlass::_init_state can be changed to u1 type, which could hold >>>>>> up 256 states. There are unused bytes after >>>>>> instanceKlass::_idnum_allocated_count field. Changing _init_state to u1 >>>>>> and move it to after the _idnum_allocate_count field would save 4-byte >>>>>> for each loaded class. >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> From mandy.chung at oracle.com Tue Dec 6 17:32:15 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 06 Dec 2011 17:32:15 -0800 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4ED8D93A.5050600@oracle.com> References: <4ED8D93A.5050600@oracle.com> Message-ID: <4EDEC21F.4000902@oracle.com> On 12/2/2011 5:57 AM, Frederic Parain wrote: > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ ManagementPermission.java The diagnostic command is not part of the platform. It doesn't seem right to add this new "diagnosticCommand" ManagementPermission. Are the existing "control" and "monitor" permission not adequate for the diagnostic command use? On the other hand, I expect that the required ManagementPermission should be specified in the new methods added in HotSpotDiagnosticMXBean (see below). HotSpotDiagnosticMXBean.java sun.managment.HotSpotDiagnostic does check if the execute method has the "diagnosticCommand" permission. The javadoc must specify the SecurityException be thrown under what condition. To me, the execute methods could require ManagementPermission("control") as the setVMOption method. I'm not certain if DiagnosticCommandInfo is considered as non-sensitive information. Have you checked with the security team to get their advice? L112: Since you are in this file, can you fix the typo "java.security.SecurityException" to "java.lang.SecurityException"? The execute method doesn't throw any exception other than IAE. What happens if the specified command execution fails in the target VM? If no exception is thrown, how does the caller detect if the command succeeds or not and handle it gracefully? It seems that this mechanism should provide a way to detect if a command succeeds or fails programmatically rather than burying the error message in the returned string. The spec needs some clarification about the list of diagnostic commands may change during JVM execution. HotSpotDiagnostic.java L45-49: jvm is not used and can be removed. L133: do you need to check if command == null and throw NPE? or NPE will be thrown somewhere? L159: NPE should be thrown instead of IAE, right? Unless the javadoc for the execute method is modified to reflect that. L176: minor: I wonder if it's any simpler for this native method to take the DiagnosticCommandInfo[] argument (i.e. the caller method does the array allocation than in the native method implementation). ManagementFactoryHelper.java L270: The new parameter "jvm" doesn't seem to be needed. Util.java See comments in ManagementPermission. jmm.h L316-326: the parameters should be lined up with the first one. L316-317 was aligned improperly and it's good to fix them in this batch. HotSpotDiagnostic.c L44, 51, 76-85: indentation needs fixing. L158, 172: this should never happen unless the hotspot/jdk is mismatched. But would it better to throw an exception with an informative message to help diagnostic in case the mismatch does happen? jcmd.1 (man page) Should PerfCounter.print be listed in the man page? Or treat it like other diagnostic commands that are implementation-dependent? That's all the comments I have on the jdk side. Mandy From vladimir.danushevsky at oracle.com Tue Dec 6 19:14:30 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Wed, 07 Dec 2011 03:14:30 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 19 new changesets Message-ID: <20111207031509.F1AEB475C9@hg.openjdk.java.net> Changeset: da4182086289 Author: jcoomes Date: 2011-11-18 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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: 1d090cf33da6 Author: coleenp Date: 2011-11-21 10:22 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1d090cf33da6 Merge Changeset: 81a08cd7f6a1 Author: coleenp Date: 2011-12-01 13:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/81a08cd7f6a1 Merge Changeset: a88de71c4e3a Author: tonyp Date: 2011-11-18 12:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/hotspot/rev/3a298e04d914 Merge Changeset: bca17e38de00 Author: jmasa Date: 2011-08-09 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/hotspot/rev/1bbf5b6fb7b0 Merge ! src/share/vm/runtime/globals.hpp Changeset: d1f29d4e0bc6 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/cf4dd13bbcd3 7117536: new hotspot build - hs23-b08 Reviewed-by: johnc ! make/hotspot_version Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/03865c41c4f3 Merge ! src/share/vm/runtime/globals.hpp From daniel.daugherty at oracle.com Tue Dec 6 20:36:40 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 06 Dec 2011 21:36:40 -0700 Subject: code review request for MacOS X compressed oops work around (7118648) Message-ID: <4EDEED58.6030403@oracle.com> Greetings, The UseCompressedOops flag is enabled ergonomically in a 64-bit VM. With MacOS X, we're seeing intermittent crashes in our automated build/test system (JPRT) that look like this: Internal Error (/private/tmp/jprt/P1/050642.jmelvin/source/src/share/vm/runtime/virtualspace.cpp:460), pid=53634, tid=4531154944 # assert((_noaccess_prefix != 0) == (UseCompressedOops && _base != NULL && (size_t(_base + _size) > OopEncodingHeapMax) && Universe::narrow_oop_use_implicit_null_checks())) failed: noaccess_prefix should be used only with non zero based compressed oops I have filed the following bug to track that failure mode: 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test In order to make more reliable progress on getting MacOS X fully enabled in JPRT, I'm planning to disable compressed oops by default in the 64-bit MacOS X VM until 7118647 can be fixed. The work around is trivial so I'm including it here rather than generate a webrev: diff -r a5a9db0e0203 src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Tue Dec 06 07:23:42 2011 -0800 +++ b/src/share/vm/runtime/arguments.cpp Tue Dec 06 15:29:17 2011 -0800 @@ -1359,9 +1359,12 @@ // by ergonomics. if (MaxHeapSize <= max_heap_for_compressed_oops()) { #if !defined(COMPILER1) || defined(TIERED) +#ifndef __APPLE__ + // disable UseCompressedOops by default on MacOS X until 7118647 is fixed if (FLAG_IS_DEFAULT(UseCompressedOops)) { FLAG_SET_ERGO(bool, UseCompressedOops, true); } +#endif // !__APPLE__ #endif #ifdef _WIN64 if (UseLargePages && UseCompressedOops) { What the above code does is prevent the UseCompressedOops flag from being set to true ergonomically on MacOS X. It can still be set to true with the '-XX:+UseCompressedOops' option. I'm planning to push this fix to RT_Baseline for the HSX-23-B08 snapshot. Jim Melvin has already reviewed the fix so I just need one more reviewer. Thanks, in advance, for any additional reviews. Dan From vladimir.kozlov at oracle.com Tue Dec 6 20:51:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Dec 2011 20:51:10 -0800 Subject: code review request for MacOS X compressed oops work around (7118648) In-Reply-To: <4EDEED58.6030403@oracle.com> References: <4EDEED58.6030403@oracle.com> Message-ID: <4EDEF0BE.5030209@oracle.com> Could you move the comment before #ifndef __APPLE__? Vladimir Daniel D. Daugherty wrote: > Greetings, > > The UseCompressedOops flag is enabled ergonomically in a 64-bit VM. > With MacOS X, we're seeing intermittent crashes in our automated > build/test system (JPRT) that look like this: > > Internal Error > (/private/tmp/jprt/P1/050642.jmelvin/source/src/share/vm/runtime/virtualspace.cpp:460), > pid=53634, tid=4531154944 > # assert((_noaccess_prefix != 0) == (UseCompressedOops && _base != NULL > && (size_t(_base + _size) > OopEncodingHeapMax) && > Universe::narrow_oop_use_implicit_null_checks())) failed: > noaccess_prefix should be used only with non zero based compressed oops > > I have filed the following bug to track that failure mode: > > 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test > > In order to make more reliable progress on getting MacOS X fully > enabled in JPRT, I'm planning to disable compressed oops by default > in the 64-bit MacOS X VM until 7118647 can be fixed. > > The work around is trivial so I'm including it here rather than > generate a webrev: > > diff -r a5a9db0e0203 src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp Tue Dec 06 07:23:42 2011 > -0800 > +++ b/src/share/vm/runtime/arguments.cpp Tue Dec 06 15:29:17 2011 > -0800 > @@ -1359,9 +1359,12 @@ > // by ergonomics. > if (MaxHeapSize <= max_heap_for_compressed_oops()) { > #if !defined(COMPILER1) || defined(TIERED) > +#ifndef __APPLE__ > + // disable UseCompressedOops by default on MacOS X until 7118647 is > fixed > if (FLAG_IS_DEFAULT(UseCompressedOops)) { > FLAG_SET_ERGO(bool, UseCompressedOops, true); > } > +#endif // !__APPLE__ > #endif > #ifdef _WIN64 > if (UseLargePages && UseCompressedOops) { > > > What the above code does is prevent the UseCompressedOops flag > from being set to true ergonomically on MacOS X. It can still be > set to true with the '-XX:+UseCompressedOops' option. > > I'm planning to push this fix to RT_Baseline for the HSX-23-B08 > snapshot. Jim Melvin has already reviewed the fix so I just need > one more reviewer. > > Thanks, in advance, for any additional reviews. > > Dan > From coleen.phillimore at oracle.com Tue Dec 6 20:56:42 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 07 Dec 2011 04:56:42 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 7117052: instanceKlass::_init_state can be u1 type Message-ID: <20111207045645.91F4B475CA@hg.openjdk.java.net> Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp From david.holmes at oracle.com Tue Dec 6 21:53:49 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Dec 2011 15:53:49 +1000 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EDE6B97.6030905@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> <4EDE6B97.6030905@oracle.com> Message-ID: <4EDEFF6D.2060805@oracle.com> On 7/12/2011 5:23 AM, Jiangli Zhou wrote: > Hi David and Tom, > > I ran nsk/sajdi/ tests for the class state changes. Comparing to a > baseline, there is no new failure in those tests. > > The changes do not seem to have noticeable performance impact. Specjvm98 > shows only noise variation (-0.06 ~ 0.39). Something more classloading intensive might be a better choice - specjbb perhaps? I'm not sure which benchmarks exercise which facilities the most. Thanks, David ----- > ============================================================================== > > logs.baseline: > Benchmark Samples Mean Stdev Geomean Weight > specjvm98 3 264.56 4.50 > ============================================================================== > > logs.1: > Benchmark Samples Mean Stdev %Diff P Significant > specjvm98 3 264.41 11.12 -0.06 0.984 * > ============================================================================== > > > > ============================================================================== > > logs.baseline: > Benchmark Samples Mean Stdev Geomean Weight > specjvm98 3 264.56 4.50 > ============================================================================== > > logs.1.2: > Benchmark Samples Mean Stdev %Diff P Significant > specjvm98 3 265.61 4.92 0.39 0.800 * > ============================================================================== > > > > Thanks, > Jiangli > > > On 12/06/2011 10:10 AM, Tom Rodriguez wrote: >> You can run them using ute, >> /net/sqenfs-1.us.oracle.com/export1/tools/gtee/bin/ute. Use -jdk to >> specify the test JDK, -vmopts to pass any options and -test select a >> suite. nsk/sajdi/ and tmtools/ are the main ones that exercise the SA. >> nsk/sajdi has quite a few known failures so it can be tricky to >> evaluate the results. >> >> tom >> >> On Dec 5, 2011, at 5:21 PM, Jiangli Zhou wrote: >> >>> Hi David, >>> >>> Thanks for the review and suggestions. Could you please let me know >>> where I can find SA tests and instructions for running those tests? >>> >>> I'm double check the performance impact. >>> >>> >>> Thanks, >>> Jiangli >>> >>> On 12/04/2011 06:17 PM, David Holmes wrote: >>>> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >>>>> Hi David, >>>>> >>>>> Thanks for catching that. I changed the debug version of >>>>> set_init_state(). The updated webrev is >>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >>>> Thanks - that update looks fine. >>>> >>>> Have you run SA tests to confirm no impact on SA code? >>>> >>>> Have you run any performance tests? >>>> >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>>>> On 12/01/2011 05:18 PM, David Holmes wrote: >>>>>> As already mentioned in internal email, there seem to be changes >>>>>> missing for debug builds. In instanceKlass set_init_state has two >>>>>> implementations - one for product and one for debug. The debug >>>>>> version >>>>>> has not been modified to accommodate the change in type. >>>>>> >>>>>> David >>>>>> >>>>>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>>>>> The instanceKlass::_init_state is defined as >>>>>>> instanceKlass::ClassState >>>>>>> type, which is an enum. Currently there are 7 class states >>>>>>> defined. The >>>>>>> instanceKlass::_init_state can be changed to u1 type, which could >>>>>>> hold >>>>>>> up 256 states. There are unused bytes after >>>>>>> instanceKlass::_idnum_allocated_count field. Changing _init_state >>>>>>> to u1 >>>>>>> and move it to after the _idnum_allocate_count field would save >>>>>>> 4-byte >>>>>>> for each loaded class. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> > From david.holmes at oracle.com Tue Dec 6 22:08:30 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Dec 2011 16:08:30 +1000 Subject: code review request for MacOS X compressed oops work around (7118648) In-Reply-To: <4EDEF0BE.5030209@oracle.com> References: <4EDEED58.6030403@oracle.com> <4EDEF0BE.5030209@oracle.com> Message-ID: <4EDF02DE.5030603@oracle.com> On 7/12/2011 2:51 PM, Vladimir Kozlov wrote: > Could you move the comment before #ifndef __APPLE__? I second that. If you didn't want the flag turned on at all you could use the UNSUPPORTED_OPTION macro. David > Vladimir > > Daniel D. Daugherty wrote: >> Greetings, >> >> The UseCompressedOops flag is enabled ergonomically in a 64-bit VM. >> With MacOS X, we're seeing intermittent crashes in our automated >> build/test system (JPRT) that look like this: >> >> Internal Error >> (/private/tmp/jprt/P1/050642.jmelvin/source/src/share/vm/runtime/virtualspace.cpp:460), >> pid=53634, tid=4531154944 >> # assert((_noaccess_prefix != 0) == (UseCompressedOops && _base != >> NULL && (size_t(_base + _size) > OopEncodingHeapMax) && >> Universe::narrow_oop_use_implicit_null_checks())) failed: >> noaccess_prefix should be used only with non zero based compressed oops >> >> I have filed the following bug to track that failure mode: >> >> 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test >> >> In order to make more reliable progress on getting MacOS X fully >> enabled in JPRT, I'm planning to disable compressed oops by default >> in the 64-bit MacOS X VM until 7118647 can be fixed. >> >> The work around is trivial so I'm including it here rather than >> generate a webrev: >> >> diff -r a5a9db0e0203 src/share/vm/runtime/arguments.cpp >> --- a/src/share/vm/runtime/arguments.cpp Tue Dec 06 07:23:42 2011 -0800 >> +++ b/src/share/vm/runtime/arguments.cpp Tue Dec 06 15:29:17 2011 -0800 >> @@ -1359,9 +1359,12 @@ >> // by ergonomics. >> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >> #if !defined(COMPILER1) || defined(TIERED) >> +#ifndef __APPLE__ >> + // disable UseCompressedOops by default on MacOS X until 7118647 is >> fixed >> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >> FLAG_SET_ERGO(bool, UseCompressedOops, true); >> } >> +#endif // !__APPLE__ >> #endif >> #ifdef _WIN64 >> if (UseLargePages && UseCompressedOops) { >> >> >> What the above code does is prevent the UseCompressedOops flag >> from being set to true ergonomically on MacOS X. It can still be >> set to true with the '-XX:+UseCompressedOops' option. >> >> I'm planning to push this fix to RT_Baseline for the HSX-23-B08 >> snapshot. Jim Melvin has already reviewed the fix so I just need >> one more reviewer. >> >> Thanks, in advance, for any additional reviews. >> >> Dan >> From daniel.daugherty at oracle.com Wed Dec 7 07:03:49 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 07 Dec 2011 08:03:49 -0700 Subject: code review request for MacOS X compressed oops work around (7118648) In-Reply-To: <4EDEF0BE.5030209@oracle.com> References: <4EDEED58.6030403@oracle.com> <4EDEF0BE.5030209@oracle.com> Message-ID: <4EDF8055.2010609@oracle.com> Vladimir, Definitely. Thanks for the quick review. Dan On 12/6/11 9:51 PM, Vladimir Kozlov wrote: > Could you move the comment before #ifndef __APPLE__? > > Vladimir > > Daniel D. Daugherty wrote: >> Greetings, >> >> The UseCompressedOops flag is enabled ergonomically in a 64-bit VM. >> With MacOS X, we're seeing intermittent crashes in our automated >> build/test system (JPRT) that look like this: >> >> Internal Error >> (/private/tmp/jprt/P1/050642.jmelvin/source/src/share/vm/runtime/virtualspace.cpp:460), >> pid=53634, tid=4531154944 >> # assert((_noaccess_prefix != 0) == (UseCompressedOops && _base != >> NULL && (size_t(_base + _size) > OopEncodingHeapMax) && >> Universe::narrow_oop_use_implicit_null_checks())) failed: >> noaccess_prefix should be used only with non zero based compressed oops >> >> I have filed the following bug to track that failure mode: >> >> 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher >> test >> >> In order to make more reliable progress on getting MacOS X fully >> enabled in JPRT, I'm planning to disable compressed oops by default >> in the 64-bit MacOS X VM until 7118647 can be fixed. >> >> The work around is trivial so I'm including it here rather than >> generate a webrev: >> >> diff -r a5a9db0e0203 src/share/vm/runtime/arguments.cpp >> --- a/src/share/vm/runtime/arguments.cpp Tue Dec 06 07:23:42 >> 2011 -0800 >> +++ b/src/share/vm/runtime/arguments.cpp Tue Dec 06 15:29:17 >> 2011 -0800 >> @@ -1359,9 +1359,12 @@ >> // by ergonomics. >> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >> #if !defined(COMPILER1) || defined(TIERED) >> +#ifndef __APPLE__ >> + // disable UseCompressedOops by default on MacOS X until 7118647 >> is fixed >> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >> FLAG_SET_ERGO(bool, UseCompressedOops, true); >> } >> +#endif // !__APPLE__ >> #endif >> #ifdef _WIN64 >> if (UseLargePages && UseCompressedOops) { >> >> >> What the above code does is prevent the UseCompressedOops flag >> from being set to true ergonomically on MacOS X. It can still be >> set to true with the '-XX:+UseCompressedOops' option. >> >> I'm planning to push this fix to RT_Baseline for the HSX-23-B08 >> snapshot. Jim Melvin has already reviewed the fix so I just need >> one more reviewer. >> >> Thanks, in advance, for any additional reviews. >> >> Dan >> From daniel.daugherty at oracle.com Wed Dec 7 07:05:50 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 07 Dec 2011 08:05:50 -0700 Subject: code review request for MacOS X compressed oops work around (7118648) In-Reply-To: <4EDF02DE.5030603@oracle.com> References: <4EDEED58.6030403@oracle.com> <4EDEF0BE.5030209@oracle.com> <4EDF02DE.5030603@oracle.com> Message-ID: <4EDF80CE.4030509@oracle.com> David, Thanks for the quick review! On 12/6/11 11:08 PM, David Holmes wrote: > On 7/12/2011 2:51 PM, Vladimir Kozlov wrote: >> Could you move the comment before #ifndef __APPLE__? > > I second that. Will move the comment. > If you didn't want the flag turned on at all you could use the > UNSUPPORTED_OPTION macro. Just wanted it false by default. If I disable it entirely, then it will be (slightly) harder to diagnose via 7118647... Dan > > David > >> Vladimir >> >> Daniel D. Daugherty wrote: >>> Greetings, >>> >>> The UseCompressedOops flag is enabled ergonomically in a 64-bit VM. >>> With MacOS X, we're seeing intermittent crashes in our automated >>> build/test system (JPRT) that look like this: >>> >>> Internal Error >>> (/private/tmp/jprt/P1/050642.jmelvin/source/src/share/vm/runtime/virtualspace.cpp:460), >>> >>> pid=53634, tid=4531154944 >>> # assert((_noaccess_prefix != 0) == (UseCompressedOops && _base != >>> NULL && (size_t(_base + _size) > OopEncodingHeapMax) && >>> Universe::narrow_oop_use_implicit_null_checks())) failed: >>> noaccess_prefix should be used only with non zero based compressed oops >>> >>> I have filed the following bug to track that failure mode: >>> >>> 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test >>> >>> In order to make more reliable progress on getting MacOS X fully >>> enabled in JPRT, I'm planning to disable compressed oops by default >>> in the 64-bit MacOS X VM until 7118647 can be fixed. >>> >>> The work around is trivial so I'm including it here rather than >>> generate a webrev: >>> >>> diff -r a5a9db0e0203 src/share/vm/runtime/arguments.cpp >>> --- a/src/share/vm/runtime/arguments.cpp Tue Dec 06 07:23:42 2011 -0800 >>> +++ b/src/share/vm/runtime/arguments.cpp Tue Dec 06 15:29:17 2011 -0800 >>> @@ -1359,9 +1359,12 @@ >>> // by ergonomics. >>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>> #if !defined(COMPILER1) || defined(TIERED) >>> +#ifndef __APPLE__ >>> + // disable UseCompressedOops by default on MacOS X until 7118647 is >>> fixed >>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>> } >>> +#endif // !__APPLE__ >>> #endif >>> #ifdef _WIN64 >>> if (UseLargePages && UseCompressedOops) { >>> >>> >>> What the above code does is prevent the UseCompressedOops flag >>> from being set to true ergonomically on MacOS X. It can still be >>> set to true with the '-XX:+UseCompressedOops' option. >>> >>> I'm planning to push this fix to RT_Baseline for the HSX-23-B08 >>> snapshot. Jim Melvin has already reviewed the fix so I just need >>> one more reviewer. >>> >>> Thanks, in advance, for any additional reviews. >>> >>> Dan >>> From vladimir.kozlov at oracle.com Wed Dec 7 09:15:19 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Dec 2011 09:15:19 -0800 Subject: code review request for MacOS X compressed oops work around (7118648) In-Reply-To: <4EDF80CE.4030509@oracle.com> References: <4EDEED58.6030403@oracle.com> <4EDEF0BE.5030209@oracle.com> <4EDF02DE.5030603@oracle.com> <4EDF80CE.4030509@oracle.com> Message-ID: <4EDF9F27.7030202@oracle.com> Daniel D. Daugherty wrote: > David, > > Thanks for the quick review! > > On 12/6/11 11:08 PM, David Holmes wrote: >> On 7/12/2011 2:51 PM, Vladimir Kozlov wrote: >>> Could you move the comment before #ifndef __APPLE__? >> >> I second that. > > Will move the comment. > > >> If you didn't want the flag turned on at all you could use the >> UNSUPPORTED_OPTION macro. > > Just wanted it false by default. If I disable it entirely, then > it will be (slightly) harder to diagnose via 7118647... Yes, we need to turn on COOP on command line to debug the probem. This fix is good. Thanks, Vladimir > > Dan > > >> >> David >> >>> Vladimir >>> >>> Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> The UseCompressedOops flag is enabled ergonomically in a 64-bit VM. >>>> With MacOS X, we're seeing intermittent crashes in our automated >>>> build/test system (JPRT) that look like this: >>>> >>>> Internal Error >>>> (/private/tmp/jprt/P1/050642.jmelvin/source/src/share/vm/runtime/virtualspace.cpp:460), >>>> >>>> pid=53634, tid=4531154944 >>>> # assert((_noaccess_prefix != 0) == (UseCompressedOops && _base != >>>> NULL && (size_t(_base + _size) > OopEncodingHeapMax) && >>>> Universe::narrow_oop_use_implicit_null_checks())) failed: >>>> noaccess_prefix should be used only with non zero based compressed oops >>>> >>>> I have filed the following bug to track that failure mode: >>>> >>>> 7118647 3/3 compressed oops crashes on MacOS X with JPRT GCBasher test >>>> >>>> In order to make more reliable progress on getting MacOS X fully >>>> enabled in JPRT, I'm planning to disable compressed oops by default >>>> in the 64-bit MacOS X VM until 7118647 can be fixed. >>>> >>>> The work around is trivial so I'm including it here rather than >>>> generate a webrev: >>>> >>>> diff -r a5a9db0e0203 src/share/vm/runtime/arguments.cpp >>>> --- a/src/share/vm/runtime/arguments.cpp Tue Dec 06 07:23:42 2011 -0800 >>>> +++ b/src/share/vm/runtime/arguments.cpp Tue Dec 06 15:29:17 2011 -0800 >>>> @@ -1359,9 +1359,12 @@ >>>> // by ergonomics. >>>> if (MaxHeapSize <= max_heap_for_compressed_oops()) { >>>> #if !defined(COMPILER1) || defined(TIERED) >>>> +#ifndef __APPLE__ >>>> + // disable UseCompressedOops by default on MacOS X until 7118647 is >>>> fixed >>>> if (FLAG_IS_DEFAULT(UseCompressedOops)) { >>>> FLAG_SET_ERGO(bool, UseCompressedOops, true); >>>> } >>>> +#endif // !__APPLE__ >>>> #endif >>>> #ifdef _WIN64 >>>> if (UseLargePages && UseCompressedOops) { >>>> >>>> >>>> What the above code does is prevent the UseCompressedOops flag >>>> from being set to true ergonomically on MacOS X. It can still be >>>> set to true with the '-XX:+UseCompressedOops' option. >>>> >>>> I'm planning to push this fix to RT_Baseline for the HSX-23-B08 >>>> snapshot. Jim Melvin has already reviewed the fix so I just need >>>> one more reviewer. >>>> >>>> Thanks, in advance, for any additional reviews. >>>> >>>> Dan >>>> From jiangli.zhou at oracle.com Wed Dec 7 09:47:36 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 07 Dec 2011 09:47:36 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EDEFF6D.2060805@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> <4EDE6B97.6030905@oracle.com> <4EDEFF6D.2060805@oracle.com> Message-ID: <4EDFA6B8.6060800@oracle.com> Hi David, On 12/06/2011 09:53 PM, David Holmes wrote: > On 7/12/2011 5:23 AM, Jiangli Zhou wrote: >> Hi David and Tom, >> >> I ran nsk/sajdi/ tests for the class state changes. Comparing to a >> baseline, there is no new failure in those tests. >> >> The changes do not seem to have noticeable performance impact. Specjvm98 >> shows only noise variation (-0.06 ~ 0.39). > > Something more classloading intensive might be a better choice - > specjbb perhaps? I'm not sure which benchmarks exercise which > facilities the most. My laptop is not fast enough to run specjbb. The benchmark was killed after time limit. Is there a way to increase time limit for refworkload? Thanks, Jiangli > > Thanks, > David > ----- > >> ============================================================================== >> >> >> logs.baseline: >> Benchmark Samples Mean Stdev Geomean Weight >> specjvm98 3 264.56 4.50 >> ============================================================================== >> >> >> logs.1: >> Benchmark Samples Mean Stdev %Diff P Significant >> specjvm98 3 264.41 11.12 -0.06 0.984 * >> ============================================================================== >> >> >> >> >> ============================================================================== >> >> >> logs.baseline: >> Benchmark Samples Mean Stdev Geomean Weight >> specjvm98 3 264.56 4.50 >> ============================================================================== >> >> >> logs.1.2: >> Benchmark Samples Mean Stdev %Diff P Significant >> specjvm98 3 265.61 4.92 0.39 0.800 * >> ============================================================================== >> >> >> >> >> Thanks, >> Jiangli >> >> >> On 12/06/2011 10:10 AM, Tom Rodriguez wrote: >>> You can run them using ute, >>> /net/sqenfs-1.us.oracle.com/export1/tools/gtee/bin/ute. Use -jdk to >>> specify the test JDK, -vmopts to pass any options and -test select a >>> suite. nsk/sajdi/ and tmtools/ are the main ones that exercise the SA. >>> nsk/sajdi has quite a few known failures so it can be tricky to >>> evaluate the results. >>> >>> tom >>> >>> On Dec 5, 2011, at 5:21 PM, Jiangli Zhou wrote: >>> >>>> Hi David, >>>> >>>> Thanks for the review and suggestions. Could you please let me know >>>> where I can find SA tests and instructions for running those tests? >>>> >>>> I'm double check the performance impact. >>>> >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 12/04/2011 06:17 PM, David Holmes wrote: >>>>> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for catching that. I changed the debug version of >>>>>> set_init_state(). The updated webrev is >>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >>>>> Thanks - that update looks fine. >>>>> >>>>> Have you run SA tests to confirm no impact on SA code? >>>>> >>>>> Have you run any performance tests? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>>> On 12/01/2011 05:18 PM, David Holmes wrote: >>>>>>> As already mentioned in internal email, there seem to be changes >>>>>>> missing for debug builds. In instanceKlass set_init_state has two >>>>>>> implementations - one for product and one for debug. The debug >>>>>>> version >>>>>>> has not been modified to accommodate the change in type. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>>>>>> The instanceKlass::_init_state is defined as >>>>>>>> instanceKlass::ClassState >>>>>>>> type, which is an enum. Currently there are 7 class states >>>>>>>> defined. The >>>>>>>> instanceKlass::_init_state can be changed to u1 type, which could >>>>>>>> hold >>>>>>>> up 256 states. There are unused bytes after >>>>>>>> instanceKlass::_idnum_allocated_count field. Changing _init_state >>>>>>>> to u1 >>>>>>>> and move it to after the _idnum_allocate_count field would save >>>>>>>> 4-byte >>>>>>>> for each loaded class. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jiangli >>>>>>>> >> From john.cuthbertson at oracle.com Wed Dec 7 09:59:08 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 07 Dec 2011 09:59:08 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Message-ID: <4EDFA96C.9020007@oracle.com> Hi Everyone, Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. Summary: I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. Thanks, JohnC From daniel.daugherty at oracle.com Wed Dec 7 13:08:58 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 07 Dec 2011 21:08:58 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7118648: disable compressed oops by default on MacOS X until 7118647 is fixed Message-ID: <20111207210902.B209447625@hg.openjdk.java.net> Changeset: 55d777c0860a Author: dcubed Date: 2011-12-07 07:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 paul.hohensee at oracle.com Wed Dec 7 13:15:26 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 07 Dec 2011 16:15:26 -0500 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4ED8D93A.5050600@oracle.com> References: <4ED8D93A.5050600@oracle.com> Message-ID: <4EDFD76E.8000302@oracle.com> For the hotspot part: In attachListener.cpp, you might want to delete the first "return JNI_OK;" line, since the code under HAS_PENDING_EXCEPTION just falls through. In jmm.h, minor formatting nit: be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the existing declarations. Add a newline just before it on line 322. On 12/2/11 8:57 AM, Frederic Parain wrote: > Hi All, > > [Posting to serviceability-dev, runtime-dev and core-libs-dev > because changes are pretty big and touch all these areas] > > Here's a framework for issuing diagnostics commands to the JVM. > Diagnostic commands are actions executed inside the JVM mainly > for monitoring or management purpose. This work has two parts. > The first part is in the hotspot repository and contains the > framework itself with two diagnostic commands. The second > part is in the JDK repository and contains the command line > utility to invoke diagnostic commands as well as the > HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean > extensions allow a remote client to discover and invoke > diagnostic commands using a JMX connection. > > This changeset only contains two diagnostic commands, more > commands will be added in the future, as a standalone effort > to improve the monitoring and management services of the > JVM, or as part of other projects. > > Webrevs are here: > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ > > Here's a technical description of this work: > > 1 - The Diagnostic Command Framework > 1-1 Overview > > The diagnostic command framework is fully implemented in native code > and relies on the HotSpot's internal exception mechanism. > The rational of a pure native implementation is to be able to execute > diagnostic commands even in critical situations like an OutOfMemory > error. All diagnostic commands are registered in a single list, and two > flags control the way a user can interact with them. The "hidden" flag > prevents a diagnostic command from appearing in the list of available > commands returned by the "help" command. However, it's still possible to > get the detailed help message for a hidden command with the "help > " syntax (but it requires to know the name of the hidden > command). The second flag is "enabled" and it controls if a command can > be invoked or not. When listed with the "help" commands, disabled > commands appear with a "[disabled]" label in their description. If the > user tries to invoke a disabled command, an error message is returned > and the command is not run. This error message can be customized on a > per command base. The framework just provides these two flags with their > semantic, it doesn't provide any policy or mechanism to set or modify > these flags. These actions will be delegated to the JVM or special > diagnostic commands. > > 1-2 Implementation > > All diagnostic commands are implemented as subclasses of the DCmd class > defined in services/diagnosticFramework.hpp. Here's the layout of the > DCmd class and the list of methods that a new command has to define or > overwrite: > > class DCmd { > DCmd(outputStream *output); > > static const char *get_name(); > > static const char *get_description(); > > static const char *get_disabled_message(); > > static const char *get_impact(); > > static int get_num_arguments(); > > virtual void print_help(outputStream* out); > > virtual void parse(CmdLine* line, char delim, TRAPS); > > virtual void execute(TRAPS); > > virtual void reset(TRAPS); > > virtual void cleanup(); > > virtual GrowableArray* get_argument_name_array(); > > virtual GrowableArray* get_argument_info_array(); > } > > A diagnostic command is always instantiated with an outputStream in > parameter. This outputStream can point either to a file, a buffer or a > socket (see the ostream.hpp file). > > The get_name() method returns the string that will identify the command > (i.e. the string to put on the command line to invoke it). > > The get_description() methods returns the global description of the > command. > > The get_disabled_message() returns the customized message to return when > the command is disabled, without having to instantiate the command. > > The get_impact() returns a description of the intrusiveness of the > diagnostic command on the Java Virtual Machine behavior. The rational > for this method is that some diagnostic commands can seriously disrupt > the behavior of the Java Virtual Machine (for instance a Thread Dump for > an application with several tens of thousands of threads, or a Head Dump > with a 40GB+ heap size) and other diagnostic commands have no serious > impact on the JVM (for instance, getting the command line arguments or > the JVM version). The recommended format for the description is level>: [longer description], where the impact level is selected among > this list: {low, medium, high}. The optional longer description can > provide more specific details like the fact that Thread Dump impact > depends on the heap size. > > The get_num_arguments() returns the number of options/arguments > recognized by the diagnostic command. This method is only used by the > JMX interface support (see below). > > The print_help() methods prints a detailed help on the outputStream > passed in argument. The detailed help contains the list of all supported > options with their type and description. > > The parse() method is in charge of parsing the command arguments. Each > command is free to implement its own argument parser. However, an > argument parser framework is provided (see section 1-3) to ease the > implementation, but its use is optional. The parse method takes a > delimiter character in argument, which is used to mark the limit between > two arguments (typically invocation from jcmd will use a space character > as a delimiter while invocation from the JVM command line parsing code > will use a comma as a delimiter). > > The execute() method is naturally the one to invoke to get the > diagnostic command executed. The parse() and the execute() methods are > dissociated, so it's a possible perform the argument parsing in one > thread, and delegate the execution to another thread, as long as the > diagnostic command doesn't reference thread local variables. The > framework allows several instances of the same diagnostic command to be > executed in parallel. If for some reasons concurrent executions should > not be allowed for a given diagnostic command, this is the > responsibility of the diagnostic command implementor to enforce this > rule, for instance by protecting the body of the execute() method with a > global lock. > > The reset() method is used to initialize the internal fields of the > diagnostic command or to reset the internal fields to their initial > value to be able to re-use an already allocated diagnostic command > instance. > > The cleanup() method is used to perform perform cleanup (like freeing of > all memory allocated to store internal data). The DCmd extends the > ResourceObj class, so when allocated in a ResourceArea, destructors > cannot be used to perform cleanup. To ensure that cleanup is performed > in all cases, it is recommended to create a DCmdMark instance for each > DCmd instance. DCmdMark is a stack allocated object with a pointer to a > DCmd instance. When the DCmdMark is destroyed, its destructor calls the > cleanup() method of the DCmd instance it points to. If the DCmd instance > has been allocated on the C-Heap, the DCmdMark will also free the memory > allocated to store the DCmd instance. > > The get_argument_name_array() and get_argument_info_array() are related > to the JMX interface of the diagnostic command framework, so they are > described in section 3. > > 1-3 DCmdParser framework > > The DCmdParser class is an optional framework to help development of > argument parsers. It provides many features required by the diagnostic > command framework (generation of the help message or the argument > descriptions for the JMX interface) but all these features can easily be > re-implemented if a developer decides not to use the DCmdParser > framework. > > The DCmdParser class is relying on the DCmdArgument template. This > template must be used to define the different types of argument the > parser will have to handle. When a new specialization of the template is > done, three methods have to be provided: > > void parse_value(const char *str,size_t len,TRAPS); > void init_value(TRAPS); > void destroy_value(); > > The parse_value() method is used to convert a string into an argument > value. The print_value() method is used to display the default value > (support for the detailed help message). The init_value() method is used > to initialize or reset the argument value. The destroy_value() method is > a clean-up method (useful when the argument has allocated some C-Heap > memory to store its value and this memory has to be freed before > destroying the DCmdArgument instance). > > The DCmdParser makes a distinction between options and arguments. > Options are identified by a key name that must appear on the command > line, while argument are identified just by the position of the argument > on the command line. Options use the = syntax. In case of > boolean options, the '=' part of the syntax can be omitted to set > the option to true. Arguments are just sequences characters delimited by > a separator character. This separator can be specified at runtime when > invoking the diagnostic command framework. If an argument contain a > character that could be used as a delimiter, it's possible to enclose > the argument between single or double quotes. Options are arguments are > instantiated using the same DCmdArgument class but they're registered > differently to the DCmdParser. > > The way to use the DCmdParser is to declare the parser and the > option/arguments as fields of the diagnostic command class (which is > itself a sub-class of the DCmd class), like this: > > > class EchoDCmd : public DCmd { > protected: > DCmdParser _dcmdparser; > > DCmdArgument _required; > > DCmdArgument _intval; > > DCmdArgument _boolval; > > DCmdArgument _stringval; > > DCmdArgument _first_arg; > > DCmdArgument _second_arg; > > DCmdArgument _optional_arg; > > } > > The parser and the options/arguments must be initialized before the > diagnostic command class, and the options/arguments have to be > registered to the parser like this: > > EchoDCmd(outputStream *output) : DCmd(output), > _stringval("-strval","a string argument","STRING",false), > > _boolval("-boolval","a boolean argument","BOOLEAN",false), > > _intval("-intval","an integer argument","INTEGER",false), > > _required("-req","a mandatory integer argument","INTEGER",true), > > _fist_arg("first argument","a string argument","STRING",true), > > _second_arg("second argument,"an integer argument,"INTEGER",true), > > _optional_arg("optional argument","an optional string > argument","STRING","false") > > { > > _dcmdparser.add_dcmd_option(&_stringval) > > _dcmdparser.add_dcmd_option(&_boolval); > > _dcmdparser.add_dcmd_option(&_intval); > > _dcmdparser.add_dcmd_option(&_required); > > _dcmdparser.add_argument(&_first_arg); > > _dcmdparser.add_argument(&_second_arg); > > _dcmdparser.add_argument(&_optional_arg); > }; > > The add_dcmd_argument()/ add_dcmd_option() method is used to add an > argument/option to the parser. The option/argument constructor takes the > name of the option/argument, its description, a string describing its > type and a boolean to specify if the option/argument is mandatory or > not. The parser doesn't support option/argument duplicates (having the > same name) but the code currently doesn't check for duplicates.The order > used to register options has no impact on the parser. However, the order > used to register arguments is critical because the parser will use the > same order to parse the command line. In the example above, the parser > expects to have a first argument of type STRING (parsed using > _first_arg), then a second argument of type INTEGER (parsed using > _second_arg) and optionally a third parameter of type STRING (parsed > using _optional_arg). A mandatory option or argument has to be specify > every time the command is invoked. If it is missing, an exception is > thrown at the end of the parsing. Optional arguments have to be > registered after mandatory arguments. An optional argument will be > considered for parsing only if all arguments before it (mandatory or > not) have already been used to parse the command line. > > The DCmdParser and its DCmdArgument instances are embedded in the DCmd > instance. The rational for this design is to limit the number of C-heap > allocations but also to be able to pre-allocate diagnostic command > instances for critical situations. If the process is running out of > C-heap space, it's not possible to instantiate new diagnostic commands > to troubleshoot the situation. By pre-allocating some diagnostic > commands, it will be possible to run them even in this critical > situation. Of course, the diagnostic command itself should not try to > allocate memory during its execution, this prevents the diagnostic > command to use variable length arguments like strings. By nature, > pre-allocated diagnostic commands aim to be re-usable, this is the > purpose of the reset() method which restores the default status of all > arguments. > > 1-4 Internal invocation > > Using a diagnostic command from the JVM itself is pretty easy: > instantiate the class and invoke the parse() method then the execute() > method. A diagnostic command can be instantiated from inside the JVM > even it is not registered. This is a difference with the external > invocations (from jcmd or JMX) that require the command to be registered. > > 2 - The JCmd interface > > Diagnostic commands can also be invoked from outside the JVM process, > using the new 'jcmd' utility. The jcmd program uses the attach API > to connect to the JVM, send requests and receive results. The > jcmd utility must be launched on the same machine than the one running > the JVM (its a local tool). Launched without arguments, jcmd displays a > list of all JVMs running on the machine. The jcmd source code is in > the jdk repository like other existing j* tools. > > To execute a diagnostic command in a particular JVM, the generic > syntax is: > > jcmd [arguments] > > The attachListener has been modified to recognized the jcmd requests. > When a jcmd request is identified, it is parsed to extract the command > name. The JVM performs a look up of this command in a list of registered > commands. To be executable by an external request, a diagnostic command > has to be registered. The registration is performed with the DCmdFactory > class (see services/management.cpp). > > 3 - The JMX interface > > The framework provides a JMX based interface to the diagnostic commands. > This interface allows remote invocation of diagnostic commands through a > JMX connection. > > 3-1 The interface > > The information related to the diagnostic commands are accessible > through new methods added to the > com.sun.management.HotspotDiagnosticMXBean: > > public List getDiagnosticCommands(); > > public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); > > public List getDiagnosticCommandInfo(List > command); > > public List getDiagnosticCommandInfo(); > > public String execute(String commandLine) throws > IllegalArgumentException ; > > public String execute(String cmd, String... arguments) > throws IllegalArgumentException; > > > The getDiagnosticCommands() method returns an array containing the names > of the not-hidden registered diagnostic commands. > > The three getDiagnosticCommandInfo() methods return one or several > diagnostic command descriptions using the DiagnosticCommandInfo class. > > The two execute() methods allow the user the invoke a diagnostic command > in different ways. > > The DiagnosticCommandInfo class is describing a diagnostic command with > the following information: > > public class DiagnosticCommandInfo { > > public String getName(); > > public String getDescription(); > > public String getImpact(); > > public boolean isEnabled(); > > public List getArgumentsInfo(); > } > > The getName() method returns the name of the diagnostic command. This > name is the one to use in execute() methods to invoke the diagnostic > command. > > The getDescription() method returns a general description of the > diagnostic command. > > The getImpact() method returns a description of the intrusiveness of > diagnostic command. > > The isEnabled() method returns true if the method is enabled, false if > it is disabled. A disabled method cannot be executed. > > The getArgumentsInfo() returns a list of descriptions for the options or > arguments recognized by the diagnostic command. Each option/argument is > described by a DiagnosticCommandArgumentInfo instance: > > public class DiagnosticCommandArgumentInfo { > > public String getName(); > > public String getDescription(); > > public String getType(); > > public String getDefault(); > > public boolean isMandatory(); > > public boolean isOption(); > > public int getPosition(); > } > > If the DiagnosticCommandArgumentInfo instance describes an option, > isOption() returns true and getPosition() returns -1. Otherwise, when > the DiagnosticCommandArgumentInfo instance describes an argument, > isOption() returns false and getPosition() returns the expected position > for this argument. The position of an argument is defined relatively to > all arguments passed on the command line, options are not considered > when defining an argument position. The getDefault() method returns the > default value of the argument if a default has been defined, otherwise > it returns null. > > 3-2 The implementation > > The framework has been designed in a way that prevents diagnostic > command developers to worry about the JMX interface. In addition to > the methods described in section 1-2, a diagnostic command developer has > to provide three methods: > > int get_num_arguments() > > which returns the number of option and arguments supported by the > command. > > GrowableArray* get_argument_name_array() > > which provides the name of the arguments supported by the command. > > GrowableyArray* get_argument_info_array() > > which provides the description of each argument with a DCmdArgumentInfo > instance. DCmdArgumentInfo is a C++ class used by the framework to > generate the sun.com.management.DcmdArgumentInfo instances. This is done > automatically and the diagnostic command developer doesn't need to know > how to create Java objects from the runtime. > > 4 - The Diagnostic Commands > > To avoid name collisions between diagnostic commands coming from > different projects, use of a flat name space should be avoided and > a more structured organization is recommended. The framework itself > doesn't depend on this organization, so it will be a set of rules > defining a convention in the way commands are named. > > Diagnostic commands can easily organized in a hierarchical way, so the > template for a command name can be: > > .[sub-domain.] > > This template can be extended with sub-sub-domains and so on. > > A special set of commands without domain will be reserved for the > commands related to the diagnostic framework itself, like the "help" > command. > > > Thanks, > > Fred > From paul.hohensee at oracle.com Wed Dec 7 13:16:20 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 07 Dec 2011 16:16:20 -0500 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EDFD76E.8000302@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EDFD76E.8000302@oracle.com> Message-ID: <4EDFD7A4.6090901@oracle.com> This is just the start of a review: fumble-fingers sent it well before it's time. Paul On 12/7/11 4:15 PM, Paul Hohensee wrote: > For the hotspot part: > > In attachListener.cpp, you might want to delete the first "return > JNI_OK;" > line, since the code under HAS_PENDING_EXCEPTION just falls through. > > In jmm.h, minor formatting nit: be nice to indent "(JNIEnv" on lines 318, > 319 and 325 the same as the existing declarations. Add a newline > just before it on line 322. > > > > On 12/2/11 8:57 AM, Frederic Parain wrote: >> Hi All, >> >> [Posting to serviceability-dev, runtime-dev and core-libs-dev >> because changes are pretty big and touch all these areas] >> >> Here's a framework for issuing diagnostics commands to the JVM. >> Diagnostic commands are actions executed inside the JVM mainly >> for monitoring or management purpose. This work has two parts. >> The first part is in the hotspot repository and contains the >> framework itself with two diagnostic commands. The second >> part is in the JDK repository and contains the command line >> utility to invoke diagnostic commands as well as the >> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >> extensions allow a remote client to discover and invoke >> diagnostic commands using a JMX connection. >> >> This changeset only contains two diagnostic commands, more >> commands will be added in the future, as a standalone effort >> to improve the monitoring and management services of the >> JVM, or as part of other projects. >> >> Webrevs are here: >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >> >> Here's a technical description of this work: >> >> 1 - The Diagnostic Command Framework >> 1-1 Overview >> >> The diagnostic command framework is fully implemented in native code >> and relies on the HotSpot's internal exception mechanism. >> The rational of a pure native implementation is to be able to execute >> diagnostic commands even in critical situations like an OutOfMemory >> error. All diagnostic commands are registered in a single list, and two >> flags control the way a user can interact with them. The "hidden" flag >> prevents a diagnostic command from appearing in the list of available >> commands returned by the "help" command. However, it's still possible to >> get the detailed help message for a hidden command with the "help >> " syntax (but it requires to know the name of the hidden >> command). The second flag is "enabled" and it controls if a command can >> be invoked or not. When listed with the "help" commands, disabled >> commands appear with a "[disabled]" label in their description. If the >> user tries to invoke a disabled command, an error message is returned >> and the command is not run. This error message can be customized on a >> per command base. The framework just provides these two flags with their >> semantic, it doesn't provide any policy or mechanism to set or modify >> these flags. These actions will be delegated to the JVM or special >> diagnostic commands. >> >> 1-2 Implementation >> >> All diagnostic commands are implemented as subclasses of the DCmd class >> defined in services/diagnosticFramework.hpp. Here's the layout of the >> DCmd class and the list of methods that a new command has to define or >> overwrite: >> >> class DCmd { >> DCmd(outputStream *output); >> >> static const char *get_name(); >> >> static const char *get_description(); >> >> static const char *get_disabled_message(); >> >> static const char *get_impact(); >> >> static int get_num_arguments(); >> >> virtual void print_help(outputStream* out); >> >> virtual void parse(CmdLine* line, char delim, TRAPS); >> >> virtual void execute(TRAPS); >> >> virtual void reset(TRAPS); >> >> virtual void cleanup(); >> >> virtual GrowableArray* get_argument_name_array(); >> >> virtual GrowableArray* get_argument_info_array(); >> } >> >> A diagnostic command is always instantiated with an outputStream in >> parameter. This outputStream can point either to a file, a buffer or a >> socket (see the ostream.hpp file). >> >> The get_name() method returns the string that will identify the command >> (i.e. the string to put on the command line to invoke it). >> >> The get_description() methods returns the global description of the >> command. >> >> The get_disabled_message() returns the customized message to return when >> the command is disabled, without having to instantiate the command. >> >> The get_impact() returns a description of the intrusiveness of the >> diagnostic command on the Java Virtual Machine behavior. The rational >> for this method is that some diagnostic commands can seriously disrupt >> the behavior of the Java Virtual Machine (for instance a Thread Dump for >> an application with several tens of thousands of threads, or a Head Dump >> with a 40GB+ heap size) and other diagnostic commands have no serious >> impact on the JVM (for instance, getting the command line arguments or >> the JVM version). The recommended format for the description is > level>: [longer description], where the impact level is selected among >> this list: {low, medium, high}. The optional longer description can >> provide more specific details like the fact that Thread Dump impact >> depends on the heap size. >> >> The get_num_arguments() returns the number of options/arguments >> recognized by the diagnostic command. This method is only used by the >> JMX interface support (see below). >> >> The print_help() methods prints a detailed help on the outputStream >> passed in argument. The detailed help contains the list of all supported >> options with their type and description. >> >> The parse() method is in charge of parsing the command arguments. Each >> command is free to implement its own argument parser. However, an >> argument parser framework is provided (see section 1-3) to ease the >> implementation, but its use is optional. The parse method takes a >> delimiter character in argument, which is used to mark the limit between >> two arguments (typically invocation from jcmd will use a space character >> as a delimiter while invocation from the JVM command line parsing code >> will use a comma as a delimiter). >> >> The execute() method is naturally the one to invoke to get the >> diagnostic command executed. The parse() and the execute() methods are >> dissociated, so it's a possible perform the argument parsing in one >> thread, and delegate the execution to another thread, as long as the >> diagnostic command doesn't reference thread local variables. The >> framework allows several instances of the same diagnostic command to be >> executed in parallel. If for some reasons concurrent executions should >> not be allowed for a given diagnostic command, this is the >> responsibility of the diagnostic command implementor to enforce this >> rule, for instance by protecting the body of the execute() method with a >> global lock. >> >> The reset() method is used to initialize the internal fields of the >> diagnostic command or to reset the internal fields to their initial >> value to be able to re-use an already allocated diagnostic command >> instance. >> >> The cleanup() method is used to perform perform cleanup (like freeing of >> all memory allocated to store internal data). The DCmd extends the >> ResourceObj class, so when allocated in a ResourceArea, destructors >> cannot be used to perform cleanup. To ensure that cleanup is performed >> in all cases, it is recommended to create a DCmdMark instance for each >> DCmd instance. DCmdMark is a stack allocated object with a pointer to a >> DCmd instance. When the DCmdMark is destroyed, its destructor calls the >> cleanup() method of the DCmd instance it points to. If the DCmd instance >> has been allocated on the C-Heap, the DCmdMark will also free the memory >> allocated to store the DCmd instance. >> >> The get_argument_name_array() and get_argument_info_array() are related >> to the JMX interface of the diagnostic command framework, so they are >> described in section 3. >> >> 1-3 DCmdParser framework >> >> The DCmdParser class is an optional framework to help development of >> argument parsers. It provides many features required by the diagnostic >> command framework (generation of the help message or the argument >> descriptions for the JMX interface) but all these features can easily be >> re-implemented if a developer decides not to use the DCmdParser >> framework. >> >> The DCmdParser class is relying on the DCmdArgument template. This >> template must be used to define the different types of argument the >> parser will have to handle. When a new specialization of the template is >> done, three methods have to be provided: >> >> void parse_value(const char *str,size_t len,TRAPS); >> void init_value(TRAPS); >> void destroy_value(); >> >> The parse_value() method is used to convert a string into an argument >> value. The print_value() method is used to display the default value >> (support for the detailed help message). The init_value() method is used >> to initialize or reset the argument value. The destroy_value() method is >> a clean-up method (useful when the argument has allocated some C-Heap >> memory to store its value and this memory has to be freed before >> destroying the DCmdArgument instance). >> >> The DCmdParser makes a distinction between options and arguments. >> Options are identified by a key name that must appear on the command >> line, while argument are identified just by the position of the argument >> on the command line. Options use the = syntax. In case of >> boolean options, the '=' part of the syntax can be omitted to set >> the option to true. Arguments are just sequences characters delimited by >> a separator character. This separator can be specified at runtime when >> invoking the diagnostic command framework. If an argument contain a >> character that could be used as a delimiter, it's possible to enclose >> the argument between single or double quotes. Options are arguments are >> instantiated using the same DCmdArgument class but they're registered >> differently to the DCmdParser. >> >> The way to use the DCmdParser is to declare the parser and the >> option/arguments as fields of the diagnostic command class (which is >> itself a sub-class of the DCmd class), like this: >> >> >> class EchoDCmd : public DCmd { >> protected: >> DCmdParser _dcmdparser; >> >> DCmdArgument _required; >> >> DCmdArgument _intval; >> >> DCmdArgument _boolval; >> >> DCmdArgument _stringval; >> >> DCmdArgument _first_arg; >> >> DCmdArgument _second_arg; >> >> DCmdArgument _optional_arg; >> >> } >> >> The parser and the options/arguments must be initialized before the >> diagnostic command class, and the options/arguments have to be >> registered to the parser like this: >> >> EchoDCmd(outputStream *output) : DCmd(output), >> _stringval("-strval","a string argument","STRING",false), >> >> _boolval("-boolval","a boolean argument","BOOLEAN",false), >> >> _intval("-intval","an integer argument","INTEGER",false), >> >> _required("-req","a mandatory integer argument","INTEGER",true), >> >> _fist_arg("first argument","a string argument","STRING",true), >> >> _second_arg("second argument,"an integer argument,"INTEGER",true), >> >> _optional_arg("optional argument","an optional string >> argument","STRING","false") >> >> { >> >> _dcmdparser.add_dcmd_option(&_stringval) >> >> _dcmdparser.add_dcmd_option(&_boolval); >> >> _dcmdparser.add_dcmd_option(&_intval); >> >> _dcmdparser.add_dcmd_option(&_required); >> >> _dcmdparser.add_argument(&_first_arg); >> >> _dcmdparser.add_argument(&_second_arg); >> >> _dcmdparser.add_argument(&_optional_arg); >> }; >> >> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >> argument/option to the parser. The option/argument constructor takes the >> name of the option/argument, its description, a string describing its >> type and a boolean to specify if the option/argument is mandatory or >> not. The parser doesn't support option/argument duplicates (having the >> same name) but the code currently doesn't check for duplicates.The order >> used to register options has no impact on the parser. However, the order >> used to register arguments is critical because the parser will use the >> same order to parse the command line. In the example above, the parser >> expects to have a first argument of type STRING (parsed using >> _first_arg), then a second argument of type INTEGER (parsed using >> _second_arg) and optionally a third parameter of type STRING (parsed >> using _optional_arg). A mandatory option or argument has to be specify >> every time the command is invoked. If it is missing, an exception is >> thrown at the end of the parsing. Optional arguments have to be >> registered after mandatory arguments. An optional argument will be >> considered for parsing only if all arguments before it (mandatory or >> not) have already been used to parse the command line. >> >> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >> instance. The rational for this design is to limit the number of C-heap >> allocations but also to be able to pre-allocate diagnostic command >> instances for critical situations. If the process is running out of >> C-heap space, it's not possible to instantiate new diagnostic commands >> to troubleshoot the situation. By pre-allocating some diagnostic >> commands, it will be possible to run them even in this critical >> situation. Of course, the diagnostic command itself should not try to >> allocate memory during its execution, this prevents the diagnostic >> command to use variable length arguments like strings. By nature, >> pre-allocated diagnostic commands aim to be re-usable, this is the >> purpose of the reset() method which restores the default status of all >> arguments. >> >> 1-4 Internal invocation >> >> Using a diagnostic command from the JVM itself is pretty easy: >> instantiate the class and invoke the parse() method then the execute() >> method. A diagnostic command can be instantiated from inside the JVM >> even it is not registered. This is a difference with the external >> invocations (from jcmd or JMX) that require the command to be >> registered. >> >> 2 - The JCmd interface >> >> Diagnostic commands can also be invoked from outside the JVM process, >> using the new 'jcmd' utility. The jcmd program uses the attach API >> to connect to the JVM, send requests and receive results. The >> jcmd utility must be launched on the same machine than the one running >> the JVM (its a local tool). Launched without arguments, jcmd displays a >> list of all JVMs running on the machine. The jcmd source code is in >> the jdk repository like other existing j* tools. >> >> To execute a diagnostic command in a particular JVM, the generic >> syntax is: >> >> jcmd [arguments] >> >> The attachListener has been modified to recognized the jcmd requests. >> When a jcmd request is identified, it is parsed to extract the command >> name. The JVM performs a look up of this command in a list of registered >> commands. To be executable by an external request, a diagnostic command >> has to be registered. The registration is performed with the DCmdFactory >> class (see services/management.cpp). >> >> 3 - The JMX interface >> >> The framework provides a JMX based interface to the diagnostic commands. >> This interface allows remote invocation of diagnostic commands through a >> JMX connection. >> >> 3-1 The interface >> >> The information related to the diagnostic commands are accessible >> through new methods added to the >> com.sun.management.HotspotDiagnosticMXBean: >> >> public List getDiagnosticCommands(); >> >> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >> >> public List getDiagnosticCommandInfo(List >> command); >> >> public List getDiagnosticCommandInfo(); >> >> public String execute(String commandLine) throws >> IllegalArgumentException ; >> >> public String execute(String cmd, String... arguments) >> throws IllegalArgumentException; >> >> >> The getDiagnosticCommands() method returns an array containing the names >> of the not-hidden registered diagnostic commands. >> >> The three getDiagnosticCommandInfo() methods return one or several >> diagnostic command descriptions using the DiagnosticCommandInfo class. >> >> The two execute() methods allow the user the invoke a diagnostic command >> in different ways. >> >> The DiagnosticCommandInfo class is describing a diagnostic command with >> the following information: >> >> public class DiagnosticCommandInfo { >> >> public String getName(); >> >> public String getDescription(); >> >> public String getImpact(); >> >> public boolean isEnabled(); >> >> public List getArgumentsInfo(); >> } >> >> The getName() method returns the name of the diagnostic command. This >> name is the one to use in execute() methods to invoke the diagnostic >> command. >> >> The getDescription() method returns a general description of the >> diagnostic command. >> >> The getImpact() method returns a description of the intrusiveness of >> diagnostic command. >> >> The isEnabled() method returns true if the method is enabled, false if >> it is disabled. A disabled method cannot be executed. >> >> The getArgumentsInfo() returns a list of descriptions for the options or >> arguments recognized by the diagnostic command. Each option/argument is >> described by a DiagnosticCommandArgumentInfo instance: >> >> public class DiagnosticCommandArgumentInfo { >> >> public String getName(); >> >> public String getDescription(); >> >> public String getType(); >> >> public String getDefault(); >> >> public boolean isMandatory(); >> >> public boolean isOption(); >> >> public int getPosition(); >> } >> >> If the DiagnosticCommandArgumentInfo instance describes an option, >> isOption() returns true and getPosition() returns -1. Otherwise, when >> the DiagnosticCommandArgumentInfo instance describes an argument, >> isOption() returns false and getPosition() returns the expected position >> for this argument. The position of an argument is defined relatively to >> all arguments passed on the command line, options are not considered >> when defining an argument position. The getDefault() method returns the >> default value of the argument if a default has been defined, otherwise >> it returns null. >> >> 3-2 The implementation >> >> The framework has been designed in a way that prevents diagnostic >> command developers to worry about the JMX interface. In addition to >> the methods described in section 1-2, a diagnostic command developer has >> to provide three methods: >> >> int get_num_arguments() >> >> which returns the number of option and arguments supported by the >> command. >> >> GrowableArray* get_argument_name_array() >> >> which provides the name of the arguments supported by the command. >> >> GrowableyArray* get_argument_info_array() >> >> which provides the description of each argument with a DCmdArgumentInfo >> instance. DCmdArgumentInfo is a C++ class used by the framework to >> generate the sun.com.management.DcmdArgumentInfo instances. This is done >> automatically and the diagnostic command developer doesn't need to know >> how to create Java objects from the runtime. >> >> 4 - The Diagnostic Commands >> >> To avoid name collisions between diagnostic commands coming from >> different projects, use of a flat name space should be avoided and >> a more structured organization is recommended. The framework itself >> doesn't depend on this organization, so it will be a set of rules >> defining a convention in the way commands are named. >> >> Diagnostic commands can easily organized in a hierarchical way, so the >> template for a command name can be: >> >> .[sub-domain.] >> >> This template can be extended with sub-sub-domains and so on. >> >> A special set of commands without domain will be reserved for the >> commands related to the diagnostic framework itself, like the "help" >> command. >> >> >> Thanks, >> >> Fred >> From frederic.parain at oracle.com Wed Dec 7 13:30:51 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 07 Dec 2011 22:30:51 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EDEC21F.4000902@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EDEC21F.4000902@oracle.com> Message-ID: <4EDFDB0B.1060802@oracle.com> On 12/7/11 2:32 AM, Mandy Chung wrote: > On 12/2/2011 5:57 AM, Frederic Parain wrote: > >> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ > L112: Since you are in this file, can you fix the typo > "java.security.SecurityException" to "java.lang.SecurityException"? Fixed. > The execute method doesn't throw any exception other than > IAE. What happens if the specified command execution fails > in the target VM? If no exception is thrown, how does the > caller detect if the command succeeds or not and handle it > gracefully? It seems that this mechanism should provide > a way to detect if a command succeeds or fails programmatically > rather than burying the error message in the returned string. This changeset contains the framework, and the framework only throws NPE or IAE. However, a diagnostic command impementation is free to throw any other exception. If such an exception is thrown, it is simply printed on the output stream if the command has been invoked through the attachAPI, or it is propagated like any other exception through JMX if the command has been invoked from the HotSpotDiagnosticMXBean. > HotSpotDiagnostic.java > L45-49: jvm is not used and can be removed. Removed. > L133: do you need to check if command == null and throw NPE? > or NPE will be thrown somewhere? The native code is protected against null commands, it will throw the NPE. > L159: NPE should be thrown instead of IAE, right? Unless > the javadoc for the execute method is modified to reflect that. Fixed. > L176: minor: I wonder if it's any simpler for this native method > to take the DiagnosticCommandInfo[] argument (i.e. the caller > method does the array allocation than in the native method > implementation). It doesn't really help, because native code has allocations to performs anyway (for argument info). > ManagementFactoryHelper.java > L270: The new parameter "jvm" doesn't seem to be needed. Fixed. > jmm.h > L316-326: the parameters should be lined up with the first one. > L316-317 was aligned improperly and it's good to fix them > in this batch. Fixed > HotSpotDiagnostic.c > L44, 51, 76-85: indentation needs fixing. Fixed. > L158, 172: this should never happen unless the hotspot/jdk is > mismatched. But would it better to throw an exception with > an informative message to help diagnostic in case the mismatch > does happen? If a mismatch is detected, the implementation now throws an UnsupportedOperationException("Diagnostic commands are not supported by this VM"). > jcmd.1 (man page) > Should PerfCounter.print be listed in the man page? Or > treat it like other diagnostic commands that are > implementation-dependent? PerfCounter is a built-in command, it doesn't appear in the list of commands returned by the 'help' command. This is why it is documented in the jcmd man page. I'll upload new webrevs tomorrow morning. Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From mandy.chung at oracle.com Wed Dec 7 14:04:48 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 07 Dec 2011 14:04:48 -0800 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EDFDB0B.1060802@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EDEC21F.4000902@oracle.com> <4EDFDB0B.1060802@oracle.com> Message-ID: <4EDFE300.2030200@oracle.com> On 12/7/2011 1:30 PM, Frederic Parain wrote: > >> The execute method doesn't throw any exception other than >> IAE. What happens if the specified command execution fails >> in the target VM? If no exception is thrown, how does the >> caller detect if the command succeeds or not and handle it >> gracefully? It seems that this mechanism should provide >> a way to detect if a command succeeds or fails programmatically >> rather than burying the error message in the returned string. > > This changeset contains the framework, and the framework > only throws NPE or IAE. However, a diagnostic command > impementation is free to throw any other exception. If such > an exception is thrown, it is simply printed on the output > stream if the command has been invoked through the attachAPI, > or it is propagated like any other exception through JMX > if the command has been invoked from the HotSpotDiagnosticMXBean. > What happens when HotSpotDiagnosticMXBean is called locally within the same process but through JMX MBeanServer? I still think you might need DiagnosticCommandException (something like that). > >> L133: do you need to check if command == null and throw NPE? >> or NPE will be thrown somewhere? > > The native code is protected against null commands, it will > throw the NPE. Ok. It's still good to add the null check to make this more explicit - you can use the java.util.Objects.requireNonNull method. > >> L158, 172: this should never happen unless the hotspot/jdk is >> mismatched. But would it better to throw an exception with >> an informative message to help diagnostic in case the mismatch >> does happen? > > If a mismatch is detected, the implementation now throws an > UnsupportedOperationException("Diagnostic commands are not supported > by this VM"). > That's better. Thanks Mandy From mandy.chung at oracle.com Wed Dec 7 14:11:19 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 07 Dec 2011 14:11:19 -0800 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EDFE300.2030200@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EDEC21F.4000902@oracle.com> <4EDFDB0B.1060802@oracle.com> <4EDFE300.2030200@oracle.com> Message-ID: <4EDFE487.903@oracle.com> On 12/7/2011 2:04 PM, Mandy Chung wrote: > > On 12/7/2011 1:30 PM, Frederic Parain wrote: >> >>> The execute method doesn't throw any exception other than >>> IAE. What happens if the specified command execution fails >>> in the target VM? If no exception is thrown, how does the >>> caller detect if the command succeeds or not and handle it >>> gracefully? It seems that this mechanism should provide >>> a way to detect if a command succeeds or fails programmatically >>> rather than burying the error message in the returned string. >> >> This changeset contains the framework, and the framework >> only throws NPE or IAE. However, a diagnostic command >> impementation is free to throw any other exception. If such >> an exception is thrown, it is simply printed on the output >> stream if the command has been invoked through the attachAPI, >> or it is propagated like any other exception through JMX >> if the command has been invoked from the HotSpotDiagnosticMXBean. >> > > What happens when HotSpotDiagnosticMXBean is called locally within the > same process but through JMX MBeanServer? oops.. typo. s/but through/but not through/ the uncaught exception will cause the running JVM to crash which seems to be undesirable. Mandy From david.holmes at oracle.com Wed Dec 7 21:21:28 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Dec 2011 15:21:28 +1000 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EDFA6B8.6060800@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> <4EDE6B97.6030905@oracle.com> <4EDEFF6D.2060805@oracle.com> <4EDFA6B8.6060800@oracle.com> Message-ID: <4EE04958.4080603@oracle.com> On 8/12/2011 3:47 AM, Jiangli Zhou wrote: > Hi David, > > On 12/06/2011 09:53 PM, David Holmes wrote: >> On 7/12/2011 5:23 AM, Jiangli Zhou wrote: >>> Hi David and Tom, >>> >>> I ran nsk/sajdi/ tests for the class state changes. Comparing to a >>> baseline, there is no new failure in those tests. >>> >>> The changes do not seem to have noticeable performance impact. Specjvm98 >>> shows only noise variation (-0.06 ~ 0.39). >> >> Something more classloading intensive might be a better choice - >> specjbb perhaps? I'm not sure which benchmarks exercise which >> facilities the most. > > My laptop is not fast enough to run specjbb. The benchmark was killed > after time limit. Is there a way to increase time limit for refworkload? No idea - sorry. But performance runs should be carried it out in a suitable environment. Our own laptops/dev-machines are only good for quick "back of the envelope" checks. Proper performance runs need to be done on dedicated machines under the right conditions. David ----- > Thanks, > Jiangli > >> >> Thanks, >> David >> ----- >> >>> ============================================================================== >>> >>> >>> logs.baseline: >>> Benchmark Samples Mean Stdev Geomean Weight >>> specjvm98 3 264.56 4.50 >>> ============================================================================== >>> >>> >>> logs.1: >>> Benchmark Samples Mean Stdev %Diff P Significant >>> specjvm98 3 264.41 11.12 -0.06 0.984 * >>> ============================================================================== >>> >>> >>> >>> >>> ============================================================================== >>> >>> >>> logs.baseline: >>> Benchmark Samples Mean Stdev Geomean Weight >>> specjvm98 3 264.56 4.50 >>> ============================================================================== >>> >>> >>> logs.1.2: >>> Benchmark Samples Mean Stdev %Diff P Significant >>> specjvm98 3 265.61 4.92 0.39 0.800 * >>> ============================================================================== >>> >>> >>> >>> >>> Thanks, >>> Jiangli >>> >>> >>> On 12/06/2011 10:10 AM, Tom Rodriguez wrote: >>>> You can run them using ute, >>>> /net/sqenfs-1.us.oracle.com/export1/tools/gtee/bin/ute. Use -jdk to >>>> specify the test JDK, -vmopts to pass any options and -test select a >>>> suite. nsk/sajdi/ and tmtools/ are the main ones that exercise the SA. >>>> nsk/sajdi has quite a few known failures so it can be tricky to >>>> evaluate the results. >>>> >>>> tom >>>> >>>> On Dec 5, 2011, at 5:21 PM, Jiangli Zhou wrote: >>>> >>>>> Hi David, >>>>> >>>>> Thanks for the review and suggestions. Could you please let me know >>>>> where I can find SA tests and instructions for running those tests? >>>>> >>>>> I'm double check the performance impact. >>>>> >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 12/04/2011 06:17 PM, David Holmes wrote: >>>>>> On 3/12/2011 4:55 AM, Jiangli Zhou wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for catching that. I changed the debug version of >>>>>>> set_init_state(). The updated webrev is >>>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.01/. >>>>>> Thanks - that update looks fine. >>>>>> >>>>>> Have you run SA tests to confirm no impact on SA code? >>>>>> >>>>>> Have you run any performance tests? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>>>> On 12/01/2011 05:18 PM, David Holmes wrote: >>>>>>>> As already mentioned in internal email, there seem to be changes >>>>>>>> missing for debug builds. In instanceKlass set_init_state has two >>>>>>>> implementations - one for product and one for debug. The debug >>>>>>>> version >>>>>>>> has not been modified to accommodate the change in type. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 2/12/2011 4:51 AM, Jiangli Zhou wrote: >>>>>>>>> The instanceKlass::_init_state is defined as >>>>>>>>> instanceKlass::ClassState >>>>>>>>> type, which is an enum. Currently there are 7 class states >>>>>>>>> defined. The >>>>>>>>> instanceKlass::_init_state can be changed to u1 type, which could >>>>>>>>> hold >>>>>>>>> up 256 states. There are unused bytes after >>>>>>>>> instanceKlass::_idnum_allocated_count field. Changing _init_state >>>>>>>>> to u1 >>>>>>>>> and move it to after the _idnum_allocate_count field would save >>>>>>>>> 4-byte >>>>>>>>> for each loaded class. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~jiangli/7117052/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jiangli >>>>>>>>> >>> > From david.holmes at oracle.com Wed Dec 7 21:48:57 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Dec 2011 15:48:57 +1000 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EDFA96C.9020007@oracle.com> References: <4EDFA96C.9020007@oracle.com> Message-ID: <4EE04FC9.30605@oracle.com> Hi John, On 8/12/2011 3:59 AM, John Cuthbertson wrote: > Can I have a couple of volunteers review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. > > Summary: > I replaced the calls to os::javaTimeMillis() in the GC where we expect > monotonicity with calls os::javaTimeNanos(), converting the result to > milliseconds. os::javaTimeNanos(), at least on some configurations, does > guarantee monotonicity and so is a better alternative. javaTimeNanos is "guaranteed" monotonic if the underlying platform provides a monotonic timesource. I think this comment: ! // os::javaTimeMillis() does not guarantee monotonicity. might be better expressed as: // need to use a monotonic time source or perhaps // need a monotonic time in ms but os::javaTimeMillis() does not guarantee monotonicity > The changes in > the os_<*> files are to make use of the named conversion constants I > added/moved to globalDefinitions.hpp - we seemed to have multiple names > for the same two constants. Yeah that little cleanup has been on the to-do list for quite a while - thanks. genCollectedHeap.cpp: This comment block can be shortened from: ! // XXX Since javaTimeNanos() mostly guarantees monotonically ! // increasing return values, depending upon the underlying ! // os-dependent implementation, we still need to guard against ! // getting back a time later than now. This should be fixed ! // by basing the implementation on something like gethrtime() ! // which does guarantee monotonicity. ! // Note that cond_wait() is susceptible to a similar problem, ! // because its interface is based on absolute time in the form ! // of the system time's notion of UCT. See also 4506635 for yet ! // another problem of similar nature. XXX to just // javaTimeNanos() is guaranteed to be monotonic non-decreasing // provided the underlying platform provides such a time source // (and it is bug free). So we still have to guard against getting // back a time later than 'now'. javaTimeNanos _is_ based on gethrtime (on Solaris which is the only place it exists) or on CLOCK_MONOTONIC on Linux (if present). It is as monotonic as the platform provides. The ref to cond_wait is just completely out of place. David ----- > Testing: GC test suite on solaris and Linux, NSK tests on solaris, and > jprt. > > Thanks, > > JohnC From bertrand.delsart at oracle.com Thu Dec 8 01:54:16 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 08 Dec 2011 10:54:16 +0100 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EDFA6B8.6060800@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> <4EDE6B97.6030905@oracle.com> <4EDEFF6D.2060805@oracle.com> <4EDFA6B8.6060800@oracle.com> Message-ID: <4EE08948.4050408@oracle.com> On 12/ 7/11 06:47 PM, Jiangli Zhou wrote: >> On 7/12/2011 5:23 AM, Jiangli Zhou wrote: > My laptop is not fast enough to run specjbb. The benchmark was killed > after time limit. Is there a way to increase time limit for refworkload? Yes, I'm doing it for my embedded runs since our platforms are slower. You can in fact specify values for each benchmark in the property file. For instance: specjvm2008.timeout=60000 Now, the only one I had to increase was in fact that specjvm2008 value. Looks like your laptop is really slooow :-) FYI, the properties for the test engine and the benchmarks are specified in the docs/users_guide directory. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From paul.hohensee at oracle.com Thu Dec 8 10:26:01 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 08 Dec 2011 13:26:01 -0500 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4ED8D93A.5050600@oracle.com> References: <4ED8D93A.5050600@oracle.com> Message-ID: <4EE10139.8020905@oracle.com> For the hotspot part at http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ Most of my comments are style-related. Nice job on the implementation architecture. In attachListener.cpp: You might want to delete the first "return JNI_OK;" line, since the code under HAS_PENDING_EXCEPTION just falls through. In jmm.h: Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the existing declarations. Add a newline just before it on line 322. In diagnosticFramework.hpp: Fix indenting for lines 63-66, insert blank before "size_t" on line 48. Hotspot convention is that getter method names don't include a "get_" prefix. So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). Similarly, getters such as is_enabled() should retrieve a field named "_is_enabled" rather than one named "enabled". You follow the "_is_enabled" convention in other places such as GenDCmdArgument. Or you could use enabled() to get the value of the _enabled field. Also generally, I'd use accessor methods in the implementation of more complex member methods rather than access the underlying fields directly. E.g. in GenDCmdArgument::read_value, I'd use is_set() and set_is_set(true), (set_is_set() is not actually defined, but should be) rather than directly accessing _is_set. Though sometimes doing this is too much of a pain with fields whose type is a template argument, as in the DCmdArggument::parse_value() method in diagnosticArgument.cpp. For easy readability, it'd be nice to line up field names (the ones with an _ prefix) at the same column. On line 200, "instanciated" -> "instantiated" On line 218, I'd use "heap_allocated" rather than "heap" for the formal arg name. On line 248, you could indent the text to start underneath "outputStream". I generally find that indenting arguments lines (formal or actual) so they line up with the first argument position make the code more readable, but I'm not religious about it. On line 265, "instanciated" -> "instantiated" DCmdFactorys are members of a singly-linked list, right? If so, it'd be good to have a comment to that effect on the declaration of _next. On line 322, insert a blank before "true". You might fix this in other places where there's no blank between a comma in an argument list and the following parameter value. In diagnosticCommandFramework.cpp: The code from lines 80-95 and 105-120 is identical. Factor out? In diagnosticArgument.cpp: On line 41, insert blanks before the actual arguments. (see above generic comment) On line 77, the "if" is indented one space too many. In management.cpp: I'd be consistent with having or not having a space between "while", "if" and "for" and the following "(" in this and your other code. Most hotspot code has a space. Thanks, Paul On 12/2/11 8:57 AM, Frederic Parain wrote: > Hi All, > > [Posting to serviceability-dev, runtime-dev and core-libs-dev > because changes are pretty big and touch all these areas] > > Here's a framework for issuing diagnostics commands to the JVM. > Diagnostic commands are actions executed inside the JVM mainly > for monitoring or management purpose. This work has two parts. > The first part is in the hotspot repository and contains the > framework itself with two diagnostic commands. The second > part is in the JDK repository and contains the command line > utility to invoke diagnostic commands as well as the > HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean > extensions allow a remote client to discover and invoke > diagnostic commands using a JMX connection. > > This changeset only contains two diagnostic commands, more > commands will be added in the future, as a standalone effort > to improve the monitoring and management services of the > JVM, or as part of other projects. > > Webrevs are here: > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ > > Here's a technical description of this work: > > 1 - The Diagnostic Command Framework > 1-1 Overview > > The diagnostic command framework is fully implemented in native code > and relies on the HotSpot's internal exception mechanism. > The rational of a pure native implementation is to be able to execute > diagnostic commands even in critical situations like an OutOfMemory > error. All diagnostic commands are registered in a single list, and two > flags control the way a user can interact with them. The "hidden" flag > prevents a diagnostic command from appearing in the list of available > commands returned by the "help" command. However, it's still possible to > get the detailed help message for a hidden command with the "help > " syntax (but it requires to know the name of the hidden > command). The second flag is "enabled" and it controls if a command can > be invoked or not. When listed with the "help" commands, disabled > commands appear with a "[disabled]" label in their description. If the > user tries to invoke a disabled command, an error message is returned > and the command is not run. This error message can be customized on a > per command base. The framework just provides these two flags with their > semantic, it doesn't provide any policy or mechanism to set or modify > these flags. These actions will be delegated to the JVM or special > diagnostic commands. > > 1-2 Implementation > > All diagnostic commands are implemented as subclasses of the DCmd class > defined in services/diagnosticFramework.hpp. Here's the layout of the > DCmd class and the list of methods that a new command has to define or > overwrite: > > class DCmd { > DCmd(outputStream *output); > > static const char *get_name(); > > static const char *get_description(); > > static const char *get_disabled_message(); > > static const char *get_impact(); > > static int get_num_arguments(); > > virtual void print_help(outputStream* out); > > virtual void parse(CmdLine* line, char delim, TRAPS); > > virtual void execute(TRAPS); > > virtual void reset(TRAPS); > > virtual void cleanup(); > > virtual GrowableArray* get_argument_name_array(); > > virtual GrowableArray* get_argument_info_array(); > } > > A diagnostic command is always instantiated with an outputStream in > parameter. This outputStream can point either to a file, a buffer or a > socket (see the ostream.hpp file). > > The get_name() method returns the string that will identify the command > (i.e. the string to put on the command line to invoke it). > > The get_description() methods returns the global description of the > command. > > The get_disabled_message() returns the customized message to return when > the command is disabled, without having to instantiate the command. > > The get_impact() returns a description of the intrusiveness of the > diagnostic command on the Java Virtual Machine behavior. The rational > for this method is that some diagnostic commands can seriously disrupt > the behavior of the Java Virtual Machine (for instance a Thread Dump for > an application with several tens of thousands of threads, or a Head Dump > with a 40GB+ heap size) and other diagnostic commands have no serious > impact on the JVM (for instance, getting the command line arguments or > the JVM version). The recommended format for the description is level>: [longer description], where the impact level is selected among > this list: {low, medium, high}. The optional longer description can > provide more specific details like the fact that Thread Dump impact > depends on the heap size. > > The get_num_arguments() returns the number of options/arguments > recognized by the diagnostic command. This method is only used by the > JMX interface support (see below). > > The print_help() methods prints a detailed help on the outputStream > passed in argument. The detailed help contains the list of all supported > options with their type and description. > > The parse() method is in charge of parsing the command arguments. Each > command is free to implement its own argument parser. However, an > argument parser framework is provided (see section 1-3) to ease the > implementation, but its use is optional. The parse method takes a > delimiter character in argument, which is used to mark the limit between > two arguments (typically invocation from jcmd will use a space character > as a delimiter while invocation from the JVM command line parsing code > will use a comma as a delimiter). > > The execute() method is naturally the one to invoke to get the > diagnostic command executed. The parse() and the execute() methods are > dissociated, so it's a possible perform the argument parsing in one > thread, and delegate the execution to another thread, as long as the > diagnostic command doesn't reference thread local variables. The > framework allows several instances of the same diagnostic command to be > executed in parallel. If for some reasons concurrent executions should > not be allowed for a given diagnostic command, this is the > responsibility of the diagnostic command implementor to enforce this > rule, for instance by protecting the body of the execute() method with a > global lock. > > The reset() method is used to initialize the internal fields of the > diagnostic command or to reset the internal fields to their initial > value to be able to re-use an already allocated diagnostic command > instance. > > The cleanup() method is used to perform perform cleanup (like freeing of > all memory allocated to store internal data). The DCmd extends the > ResourceObj class, so when allocated in a ResourceArea, destructors > cannot be used to perform cleanup. To ensure that cleanup is performed > in all cases, it is recommended to create a DCmdMark instance for each > DCmd instance. DCmdMark is a stack allocated object with a pointer to a > DCmd instance. When the DCmdMark is destroyed, its destructor calls the > cleanup() method of the DCmd instance it points to. If the DCmd instance > has been allocated on the C-Heap, the DCmdMark will also free the memory > allocated to store the DCmd instance. > > The get_argument_name_array() and get_argument_info_array() are related > to the JMX interface of the diagnostic command framework, so they are > described in section 3. > > 1-3 DCmdParser framework > > The DCmdParser class is an optional framework to help development of > argument parsers. It provides many features required by the diagnostic > command framework (generation of the help message or the argument > descriptions for the JMX interface) but all these features can easily be > re-implemented if a developer decides not to use the DCmdParser > framework. > > The DCmdParser class is relying on the DCmdArgument template. This > template must be used to define the different types of argument the > parser will have to handle. When a new specialization of the template is > done, three methods have to be provided: > > void parse_value(const char *str,size_t len,TRAPS); > void init_value(TRAPS); > void destroy_value(); > > The parse_value() method is used to convert a string into an argument > value. The print_value() method is used to display the default value > (support for the detailed help message). The init_value() method is used > to initialize or reset the argument value. The destroy_value() method is > a clean-up method (useful when the argument has allocated some C-Heap > memory to store its value and this memory has to be freed before > destroying the DCmdArgument instance). > > The DCmdParser makes a distinction between options and arguments. > Options are identified by a key name that must appear on the command > line, while argument are identified just by the position of the argument > on the command line. Options use the = syntax. In case of > boolean options, the '=' part of the syntax can be omitted to set > the option to true. Arguments are just sequences characters delimited by > a separator character. This separator can be specified at runtime when > invoking the diagnostic command framework. If an argument contain a > character that could be used as a delimiter, it's possible to enclose > the argument between single or double quotes. Options are arguments are > instantiated using the same DCmdArgument class but they're registered > differently to the DCmdParser. > > The way to use the DCmdParser is to declare the parser and the > option/arguments as fields of the diagnostic command class (which is > itself a sub-class of the DCmd class), like this: > > > class EchoDCmd : public DCmd { > protected: > DCmdParser _dcmdparser; > > DCmdArgument _required; > > DCmdArgument _intval; > > DCmdArgument _boolval; > > DCmdArgument _stringval; > > DCmdArgument _first_arg; > > DCmdArgument _second_arg; > > DCmdArgument _optional_arg; > > } > > The parser and the options/arguments must be initialized before the > diagnostic command class, and the options/arguments have to be > registered to the parser like this: > > EchoDCmd(outputStream *output) : DCmd(output), > _stringval("-strval","a string argument","STRING",false), > > _boolval("-boolval","a boolean argument","BOOLEAN",false), > > _intval("-intval","an integer argument","INTEGER",false), > > _required("-req","a mandatory integer argument","INTEGER",true), > > _fist_arg("first argument","a string argument","STRING",true), > > _second_arg("second argument,"an integer argument,"INTEGER",true), > > _optional_arg("optional argument","an optional string > argument","STRING","false") > > { > > _dcmdparser.add_dcmd_option(&_stringval) > > _dcmdparser.add_dcmd_option(&_boolval); > > _dcmdparser.add_dcmd_option(&_intval); > > _dcmdparser.add_dcmd_option(&_required); > > _dcmdparser.add_argument(&_first_arg); > > _dcmdparser.add_argument(&_second_arg); > > _dcmdparser.add_argument(&_optional_arg); > }; > > The add_dcmd_argument()/ add_dcmd_option() method is used to add an > argument/option to the parser. The option/argument constructor takes the > name of the option/argument, its description, a string describing its > type and a boolean to specify if the option/argument is mandatory or > not. The parser doesn't support option/argument duplicates (having the > same name) but the code currently doesn't check for duplicates.The order > used to register options has no impact on the parser. However, the order > used to register arguments is critical because the parser will use the > same order to parse the command line. In the example above, the parser > expects to have a first argument of type STRING (parsed using > _first_arg), then a second argument of type INTEGER (parsed using > _second_arg) and optionally a third parameter of type STRING (parsed > using _optional_arg). A mandatory option or argument has to be specify > every time the command is invoked. If it is missing, an exception is > thrown at the end of the parsing. Optional arguments have to be > registered after mandatory arguments. An optional argument will be > considered for parsing only if all arguments before it (mandatory or > not) have already been used to parse the command line. > > The DCmdParser and its DCmdArgument instances are embedded in the DCmd > instance. The rational for this design is to limit the number of C-heap > allocations but also to be able to pre-allocate diagnostic command > instances for critical situations. If the process is running out of > C-heap space, it's not possible to instantiate new diagnostic commands > to troubleshoot the situation. By pre-allocating some diagnostic > commands, it will be possible to run them even in this critical > situation. Of course, the diagnostic command itself should not try to > allocate memory during its execution, this prevents the diagnostic > command to use variable length arguments like strings. By nature, > pre-allocated diagnostic commands aim to be re-usable, this is the > purpose of the reset() method which restores the default status of all > arguments. > > 1-4 Internal invocation > > Using a diagnostic command from the JVM itself is pretty easy: > instantiate the class and invoke the parse() method then the execute() > method. A diagnostic command can be instantiated from inside the JVM > even it is not registered. This is a difference with the external > invocations (from jcmd or JMX) that require the command to be registered. > > 2 - The JCmd interface > > Diagnostic commands can also be invoked from outside the JVM process, > using the new 'jcmd' utility. The jcmd program uses the attach API > to connect to the JVM, send requests and receive results. The > jcmd utility must be launched on the same machine than the one running > the JVM (its a local tool). Launched without arguments, jcmd displays a > list of all JVMs running on the machine. The jcmd source code is in > the jdk repository like other existing j* tools. > > To execute a diagnostic command in a particular JVM, the generic > syntax is: > > jcmd [arguments] > > The attachListener has been modified to recognized the jcmd requests. > When a jcmd request is identified, it is parsed to extract the command > name. The JVM performs a look up of this command in a list of registered > commands. To be executable by an external request, a diagnostic command > has to be registered. The registration is performed with the DCmdFactory > class (see services/management.cpp). > > 3 - The JMX interface > > The framework provides a JMX based interface to the diagnostic commands. > This interface allows remote invocation of diagnostic commands through a > JMX connection. > > 3-1 The interface > > The information related to the diagnostic commands are accessible > through new methods added to the > com.sun.management.HotspotDiagnosticMXBean: > > public List getDiagnosticCommands(); > > public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); > > public List getDiagnosticCommandInfo(List > command); > > public List getDiagnosticCommandInfo(); > > public String execute(String commandLine) throws > IllegalArgumentException ; > > public String execute(String cmd, String... arguments) > throws IllegalArgumentException; > > > The getDiagnosticCommands() method returns an array containing the names > of the not-hidden registered diagnostic commands. > > The three getDiagnosticCommandInfo() methods return one or several > diagnostic command descriptions using the DiagnosticCommandInfo class. > > The two execute() methods allow the user the invoke a diagnostic command > in different ways. > > The DiagnosticCommandInfo class is describing a diagnostic command with > the following information: > > public class DiagnosticCommandInfo { > > public String getName(); > > public String getDescription(); > > public String getImpact(); > > public boolean isEnabled(); > > public List getArgumentsInfo(); > } > > The getName() method returns the name of the diagnostic command. This > name is the one to use in execute() methods to invoke the diagnostic > command. > > The getDescription() method returns a general description of the > diagnostic command. > > The getImpact() method returns a description of the intrusiveness of > diagnostic command. > > The isEnabled() method returns true if the method is enabled, false if > it is disabled. A disabled method cannot be executed. > > The getArgumentsInfo() returns a list of descriptions for the options or > arguments recognized by the diagnostic command. Each option/argument is > described by a DiagnosticCommandArgumentInfo instance: > > public class DiagnosticCommandArgumentInfo { > > public String getName(); > > public String getDescription(); > > public String getType(); > > public String getDefault(); > > public boolean isMandatory(); > > public boolean isOption(); > > public int getPosition(); > } > > If the DiagnosticCommandArgumentInfo instance describes an option, > isOption() returns true and getPosition() returns -1. Otherwise, when > the DiagnosticCommandArgumentInfo instance describes an argument, > isOption() returns false and getPosition() returns the expected position > for this argument. The position of an argument is defined relatively to > all arguments passed on the command line, options are not considered > when defining an argument position. The getDefault() method returns the > default value of the argument if a default has been defined, otherwise > it returns null. > > 3-2 The implementation > > The framework has been designed in a way that prevents diagnostic > command developers to worry about the JMX interface. In addition to > the methods described in section 1-2, a diagnostic command developer has > to provide three methods: > > int get_num_arguments() > > which returns the number of option and arguments supported by the > command. > > GrowableArray* get_argument_name_array() > > which provides the name of the arguments supported by the command. > > GrowableyArray* get_argument_info_array() > > which provides the description of each argument with a DCmdArgumentInfo > instance. DCmdArgumentInfo is a C++ class used by the framework to > generate the sun.com.management.DcmdArgumentInfo instances. This is done > automatically and the diagnostic command developer doesn't need to know > how to create Java objects from the runtime. > > 4 - The Diagnostic Commands > > To avoid name collisions between diagnostic commands coming from > different projects, use of a flat name space should be avoided and > a more structured organization is recommended. The framework itself > doesn't depend on this organization, so it will be a set of rules > defining a convention in the way commands are named. > > Diagnostic commands can easily organized in a hierarchical way, so the > template for a command name can be: > > .[sub-domain.] > > This template can be extended with sub-sub-domains and so on. > > A special set of commands without domain will be reserved for the > commands related to the diagnostic framework itself, like the "help" > command. > > > Thanks, > > Fred > From vladimir.danushevsky at oracle.com Thu Dec 8 11:20:47 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 08 Dec 2011 19:20:47 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Message-ID: <20111208192052.6F21847641@hg.openjdk.java.net> Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp From jiangli.zhou at oracle.com Thu Dec 8 11:42:16 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 08 Dec 2011 11:42:16 -0800 Subject: Request for review: 7117052 instanceKlass::_init_state can be u1 type In-Reply-To: <4EE08948.4050408@oracle.com> References: <4ED7CCB6.6020908@oracle.com> <4ED8275F.80701@oracle.com> <4ED91F05.3070205@oracle.com> <4EDC29D7.5040100@oracle.com> <4EDD6E1C.3000608@oracle.com> <6480DCA2-54F1-4888-B5AB-CEE68779824C@oracle.com> <4EDE6B97.6030905@oracle.com> <4EDEFF6D.2060805@oracle.com> <4EDFA6B8.6060800@oracle.com> <4EE08948.4050408@oracle.com> Message-ID: <4EE11318.8050005@oracle.com> On 12/08/2011 01:54 AM, Bertrand Delsart wrote: > On 12/ 7/11 06:47 PM, Jiangli Zhou wrote: >>> On 7/12/2011 5:23 AM, Jiangli Zhou wrote: >> My laptop is not fast enough to run specjbb. The benchmark was killed >> after time limit. Is there a way to increase time limit for refworkload? > > Yes, I'm doing it for my embedded runs since our platforms are slower. > You can in fact specify values for each benchmark in the property > file. For instance: > specjvm2008.timeout=60000 > > Now, the only one I had to increase was in fact that specjvm2008 > value. Looks like your laptop is really slooow :-) > > FYI, the properties for the test engine and the benchmarks are > specified in the docs/users_guide directory. Thanks! Jiangli > > Bertrand. > > From john.cuthbertson at oracle.com Thu Dec 8 12:28:42 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 08 Dec 2011 12:28:42 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE04FC9.30605@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE04FC9.30605@oracle.com> Message-ID: <4EE11DFA.1090304@oracle.com> Hi David, Thanks for the code review comments - I'll change the comments to what you suggest and send out a new webrev. JohnC On 12/07/11 21:48, David Holmes wrote: > Hi John, > > On 8/12/2011 3:59 AM, John Cuthbertson wrote: >> Can I have a couple of volunteers review the changes for this CR? The >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where we expect >> monotonicity with calls os::javaTimeNanos(), converting the result to >> milliseconds. os::javaTimeNanos(), at least on some configurations, does >> guarantee monotonicity and so is a better alternative. > > javaTimeNanos is "guaranteed" monotonic if the underlying platform > provides a monotonic timesource. > > I think this comment: > > ! // os::javaTimeMillis() does not guarantee monotonicity. > > might be better expressed as: > > // need to use a monotonic time source > > or perhaps > > // need a monotonic time in ms but os::javaTimeMillis() does not > guarantee monotonicity > >> The changes in >> the os_<*> files are to make use of the named conversion constants I >> added/moved to globalDefinitions.hpp - we seemed to have multiple names >> for the same two constants. > > Yeah that little cleanup has been on the to-do list for quite a while > - thanks. > > genCollectedHeap.cpp: > > This comment block can be shortened from: > > ! // XXX Since javaTimeNanos() mostly guarantees monotonically > ! // increasing return values, depending upon the underlying > ! // os-dependent implementation, we still need to guard against > ! // getting back a time later than now. This should be fixed > ! // by basing the implementation on something like gethrtime() > ! // which does guarantee monotonicity. > ! // Note that cond_wait() is susceptible to a similar problem, > ! // because its interface is based on absolute time in the form > ! // of the system time's notion of UCT. See also 4506635 for yet > ! // another problem of similar nature. XXX > > to just > > // javaTimeNanos() is guaranteed to be monotonic non-decreasing > // provided the underlying platform provides such a time source > // (and it is bug free). So we still have to guard against getting > // back a time later than 'now'. > > javaTimeNanos _is_ based on gethrtime (on Solaris which is the only > place it exists) or on CLOCK_MONOTONIC on Linux (if present). It is as > monotonic as the platform provides. The ref to cond_wait is just > completely out of place. > > David > ----- > >> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and >> jprt. >> >> Thanks, >> >> JohnC From robert.ottenhag at oracle.com Fri Dec 9 06:17:05 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Fri, 9 Dec 2011 06:17:05 -0800 (PST) Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE10139.8020905@oracle.com> References: <4ED8D93A.5050600@oracle.com 4EE10139.8020905@oracle.com> Message-ID: <34278e49-efbc-4370-ab36-a50331a9ff65@default> Adding to the review of jmm.h, that is modified in both the jdk part and the hotspot part, these files should be identical, without any differences in whitespace. Also, regarding whitespace and indentation, the use TAB characters in many files in the jdk patch makes jcheck complain (when trying to import your patch locally), and should be replaced by spaces. Best regards, /Robert > -----Original Message----- > From: Paul Hohensee > Sent: Thursday, December 08, 2011 7:26 PM > To: Frederic Parain > Cc: serviceability-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; > hotspot-runtime-dev at openjdk.java.net > Subject: Re: Request for Review (XXL): 7104647: Adding a diagnostic > command framework > > For the hotspot part at > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ > > Most of my comments are style-related. Nice job on the implementation > architecture. > > In attachListener.cpp: > > You might want to delete the first "return JNI_OK;" line, since the code > under > HAS_PENDING_EXCEPTION just falls through. > > In jmm.h: > > Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the > existing declarations. Add a newline just before it on line 322. > > > In diagnosticFramework.hpp: > > Fix indenting for lines 63-66, insert blank before "size_t" on line 48. > > Hotspot convention is that getter method names don't include a "get_" > prefix. > So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). > Similarly, getters such as is_enabled() should retrieve a field named > "_is_enabled" > rather than one named "enabled". You follow the "_is_enabled" convention > in other places such as GenDCmdArgument. Or you could use enabled() to > get the value of the _enabled field. > > Also generally, I'd use accessor methods in the implementation of more > complex member methods rather than access the underlying fields directly. > E.g. in GenDCmdArgument::read_value, I'd use is_set() and > set_is_set(true), > (set_is_set() is not actually defined, but should be) rather than directly > accessing _is_set. Though sometimes doing this is too much of a pain > with fields whose type is a template argument, as in the > DCmdArggument::parse_value() method in diagnosticArgument.cpp. > > For easy readability, it'd be nice to line up field names (the ones with > an > _ prefix) at the same column. > > On line 200, "instanciated" -> "instantiated" > > On line 218, I'd use "heap_allocated" rather than "heap" for the formal > arg name. > > On line 248, you could indent the text to start underneath "outputStream". > I generally find that indenting arguments lines (formal or actual) so > they line > up with the first argument position make the code more readable, but I'm > not > religious about it. > > On line 265, "instanciated" -> "instantiated" > > DCmdFactorys are members of a singly-linked list, right? If so, it'd be > good to > have a comment to that effect on the declaration of _next. > > On line 322, insert a blank before "true". You might fix this in other > places > where there's no blank between a comma in an argument list and the > following parameter value. > > > In diagnosticCommandFramework.cpp: > > The code from lines 80-95 and 105-120 is identical. Factor out? > > > In diagnosticArgument.cpp: > > On line 41, insert blanks before the actual arguments. (see above > generic comment) > > On line 77, the "if" is indented one space too many. > > > In management.cpp: > > I'd be consistent with having or not having a space between "while", > "if" and "for" > and the following "(" in this and your other code. Most hotspot code > has a space. > > > Thanks, > > Paul > > > On 12/2/11 8:57 AM, Frederic Parain wrote: > > Hi All, > > > > [Posting to serviceability-dev, runtime-dev and core-libs-dev > > because changes are pretty big and touch all these areas] > > > > Here's a framework for issuing diagnostics commands to the JVM. > > Diagnostic commands are actions executed inside the JVM mainly > > for monitoring or management purpose. This work has two parts. > > The first part is in the hotspot repository and contains the > > framework itself with two diagnostic commands. The second > > part is in the JDK repository and contains the command line > > utility to invoke diagnostic commands as well as the > > HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean > > extensions allow a remote client to discover and invoke > > diagnostic commands using a JMX connection. > > > > This changeset only contains two diagnostic commands, more > > commands will be added in the future, as a standalone effort > > to improve the monitoring and management services of the > > JVM, or as part of other projects. > > > > Webrevs are here: > > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ > > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ > > > > Here's a technical description of this work: > > > > 1 - The Diagnostic Command Framework > > 1-1 Overview > > > > The diagnostic command framework is fully implemented in native code > > and relies on the HotSpot's internal exception mechanism. > > The rational of a pure native implementation is to be able to execute > > diagnostic commands even in critical situations like an OutOfMemory > > error. All diagnostic commands are registered in a single list, and two > > flags control the way a user can interact with them. The "hidden" flag > > prevents a diagnostic command from appearing in the list of available > > commands returned by the "help" command. However, it's still possible to > > get the detailed help message for a hidden command with the "help > > " syntax (but it requires to know the name of the hidden > > command). The second flag is "enabled" and it controls if a command can > > be invoked or not. When listed with the "help" commands, disabled > > commands appear with a "[disabled]" label in their description. If the > > user tries to invoke a disabled command, an error message is returned > > and the command is not run. This error message can be customized on a > > per command base. The framework just provides these two flags with their > > semantic, it doesn't provide any policy or mechanism to set or modify > > these flags. These actions will be delegated to the JVM or special > > diagnostic commands. > > > > 1-2 Implementation > > > > All diagnostic commands are implemented as subclasses of the DCmd class > > defined in services/diagnosticFramework.hpp. Here's the layout of the > > DCmd class and the list of methods that a new command has to define or > > overwrite: > > > > class DCmd { > > DCmd(outputStream *output); > > > > static const char *get_name(); > > > > static const char *get_description(); > > > > static const char *get_disabled_message(); > > > > static const char *get_impact(); > > > > static int get_num_arguments(); > > > > virtual void print_help(outputStream* out); > > > > virtual void parse(CmdLine* line, char delim, TRAPS); > > > > virtual void execute(TRAPS); > > > > virtual void reset(TRAPS); > > > > virtual void cleanup(); > > > > virtual GrowableArray* get_argument_name_array(); > > > > virtual GrowableArray* get_argument_info_array(); > > } > > > > A diagnostic command is always instantiated with an outputStream in > > parameter. This outputStream can point either to a file, a buffer or a > > socket (see the ostream.hpp file). > > > > The get_name() method returns the string that will identify the command > > (i.e. the string to put on the command line to invoke it). > > > > The get_description() methods returns the global description of the > > command. > > > > The get_disabled_message() returns the customized message to return when > > the command is disabled, without having to instantiate the command. > > > > The get_impact() returns a description of the intrusiveness of the > > diagnostic command on the Java Virtual Machine behavior. The rational > > for this method is that some diagnostic commands can seriously disrupt > > the behavior of the Java Virtual Machine (for instance a Thread Dump for > > an application with several tens of thousands of threads, or a Head Dump > > with a 40GB+ heap size) and other diagnostic commands have no serious > > impact on the JVM (for instance, getting the command line arguments or > > the JVM version). The recommended format for the description is > level>: [longer description], where the impact level is selected among > > this list: {low, medium, high}. The optional longer description can > > provide more specific details like the fact that Thread Dump impact > > depends on the heap size. > > > > The get_num_arguments() returns the number of options/arguments > > recognized by the diagnostic command. This method is only used by the > > JMX interface support (see below). > > > > The print_help() methods prints a detailed help on the outputStream > > passed in argument. The detailed help contains the list of all supported > > options with their type and description. > > > > The parse() method is in charge of parsing the command arguments. Each > > command is free to implement its own argument parser. However, an > > argument parser framework is provided (see section 1-3) to ease the > > implementation, but its use is optional. The parse method takes a > > delimiter character in argument, which is used to mark the limit between > > two arguments (typically invocation from jcmd will use a space character > > as a delimiter while invocation from the JVM command line parsing code > > will use a comma as a delimiter). > > > > The execute() method is naturally the one to invoke to get the > > diagnostic command executed. The parse() and the execute() methods are > > dissociated, so it's a possible perform the argument parsing in one > > thread, and delegate the execution to another thread, as long as the > > diagnostic command doesn't reference thread local variables. The > > framework allows several instances of the same diagnostic command to be > > executed in parallel. If for some reasons concurrent executions should > > not be allowed for a given diagnostic command, this is the > > responsibility of the diagnostic command implementor to enforce this > > rule, for instance by protecting the body of the execute() method with a > > global lock. > > > > The reset() method is used to initialize the internal fields of the > > diagnostic command or to reset the internal fields to their initial > > value to be able to re-use an already allocated diagnostic command > > instance. > > > > The cleanup() method is used to perform perform cleanup (like freeing of > > all memory allocated to store internal data). The DCmd extends the > > ResourceObj class, so when allocated in a ResourceArea, destructors > > cannot be used to perform cleanup. To ensure that cleanup is performed > > in all cases, it is recommended to create a DCmdMark instance for each > > DCmd instance. DCmdMark is a stack allocated object with a pointer to a > > DCmd instance. When the DCmdMark is destroyed, its destructor calls the > > cleanup() method of the DCmd instance it points to. If the DCmd instance > > has been allocated on the C-Heap, the DCmdMark will also free the memory > > allocated to store the DCmd instance. > > > > The get_argument_name_array() and get_argument_info_array() are related > > to the JMX interface of the diagnostic command framework, so they are > > described in section 3. > > > > 1-3 DCmdParser framework > > > > The DCmdParser class is an optional framework to help development of > > argument parsers. It provides many features required by the diagnostic > > command framework (generation of the help message or the argument > > descriptions for the JMX interface) but all these features can easily be > > re-implemented if a developer decides not to use the DCmdParser > > framework. > > > > The DCmdParser class is relying on the DCmdArgument template. This > > template must be used to define the different types of argument the > > parser will have to handle. When a new specialization of the template is > > done, three methods have to be provided: > > > > void parse_value(const char *str,size_t len,TRAPS); > > void init_value(TRAPS); > > void destroy_value(); > > > > The parse_value() method is used to convert a string into an argument > > value. The print_value() method is used to display the default value > > (support for the detailed help message). The init_value() method is used > > to initialize or reset the argument value. The destroy_value() method is > > a clean-up method (useful when the argument has allocated some C-Heap > > memory to store its value and this memory has to be freed before > > destroying the DCmdArgument instance). > > > > The DCmdParser makes a distinction between options and arguments. > > Options are identified by a key name that must appear on the command > > line, while argument are identified just by the position of the argument > > on the command line. Options use the = syntax. In case of > > boolean options, the '=' part of the syntax can be omitted to set > > the option to true. Arguments are just sequences characters delimited by > > a separator character. This separator can be specified at runtime when > > invoking the diagnostic command framework. If an argument contain a > > character that could be used as a delimiter, it's possible to enclose > > the argument between single or double quotes. Options are arguments are > > instantiated using the same DCmdArgument class but they're registered > > differently to the DCmdParser. > > > > The way to use the DCmdParser is to declare the parser and the > > option/arguments as fields of the diagnostic command class (which is > > itself a sub-class of the DCmd class), like this: > > > > > > class EchoDCmd : public DCmd { > > protected: > > DCmdParser _dcmdparser; > > > > DCmdArgument _required; > > > > DCmdArgument _intval; > > > > DCmdArgument _boolval; > > > > DCmdArgument _stringval; > > > > DCmdArgument _first_arg; > > > > DCmdArgument _second_arg; > > > > DCmdArgument _optional_arg; > > > > } > > > > The parser and the options/arguments must be initialized before the > > diagnostic command class, and the options/arguments have to be > > registered to the parser like this: > > > > EchoDCmd(outputStream *output) : DCmd(output), > > _stringval("-strval","a string argument","STRING",false), > > > > _boolval("-boolval","a boolean argument","BOOLEAN",false), > > > > _intval("-intval","an integer argument","INTEGER",false), > > > > _required("-req","a mandatory integer argument","INTEGER",true), > > > > _fist_arg("first argument","a string argument","STRING",true), > > > > _second_arg("second argument,"an integer argument,"INTEGER",true), > > > > _optional_arg("optional argument","an optional string > > argument","STRING","false") > > > > { > > > > _dcmdparser.add_dcmd_option(&_stringval) > > > > _dcmdparser.add_dcmd_option(&_boolval); > > > > _dcmdparser.add_dcmd_option(&_intval); > > > > _dcmdparser.add_dcmd_option(&_required); > > > > _dcmdparser.add_argument(&_first_arg); > > > > _dcmdparser.add_argument(&_second_arg); > > > > _dcmdparser.add_argument(&_optional_arg); > > }; > > > > The add_dcmd_argument()/ add_dcmd_option() method is used to add an > > argument/option to the parser. The option/argument constructor takes the > > name of the option/argument, its description, a string describing its > > type and a boolean to specify if the option/argument is mandatory or > > not. The parser doesn't support option/argument duplicates (having the > > same name) but the code currently doesn't check for duplicates.The order > > used to register options has no impact on the parser. However, the order > > used to register arguments is critical because the parser will use the > > same order to parse the command line. In the example above, the parser > > expects to have a first argument of type STRING (parsed using > > _first_arg), then a second argument of type INTEGER (parsed using > > _second_arg) and optionally a third parameter of type STRING (parsed > > using _optional_arg). A mandatory option or argument has to be specify > > every time the command is invoked. If it is missing, an exception is > > thrown at the end of the parsing. Optional arguments have to be > > registered after mandatory arguments. An optional argument will be > > considered for parsing only if all arguments before it (mandatory or > > not) have already been used to parse the command line. > > > > The DCmdParser and its DCmdArgument instances are embedded in the DCmd > > instance. The rational for this design is to limit the number of C-heap > > allocations but also to be able to pre-allocate diagnostic command > > instances for critical situations. If the process is running out of > > C-heap space, it's not possible to instantiate new diagnostic commands > > to troubleshoot the situation. By pre-allocating some diagnostic > > commands, it will be possible to run them even in this critical > > situation. Of course, the diagnostic command itself should not try to > > allocate memory during its execution, this prevents the diagnostic > > command to use variable length arguments like strings. By nature, > > pre-allocated diagnostic commands aim to be re-usable, this is the > > purpose of the reset() method which restores the default status of all > > arguments. > > > > 1-4 Internal invocation > > > > Using a diagnostic command from the JVM itself is pretty easy: > > instantiate the class and invoke the parse() method then the execute() > > method. A diagnostic command can be instantiated from inside the JVM > > even it is not registered. This is a difference with the external > > invocations (from jcmd or JMX) that require the command to be > registered. > > > > 2 - The JCmd interface > > > > Diagnostic commands can also be invoked from outside the JVM process, > > using the new 'jcmd' utility. The jcmd program uses the attach API > > to connect to the JVM, send requests and receive results. The > > jcmd utility must be launched on the same machine than the one running > > the JVM (its a local tool). Launched without arguments, jcmd displays a > > list of all JVMs running on the machine. The jcmd source code is in > > the jdk repository like other existing j* tools. > > > > To execute a diagnostic command in a particular JVM, the generic > > syntax is: > > > > jcmd [arguments] > > > > The attachListener has been modified to recognized the jcmd requests. > > When a jcmd request is identified, it is parsed to extract the command > > name. The JVM performs a look up of this command in a list of registered > > commands. To be executable by an external request, a diagnostic command > > has to be registered. The registration is performed with the DCmdFactory > > class (see services/management.cpp). > > > > 3 - The JMX interface > > > > The framework provides a JMX based interface to the diagnostic commands. > > This interface allows remote invocation of diagnostic commands through a > > JMX connection. > > > > 3-1 The interface > > > > The information related to the diagnostic commands are accessible > > through new methods added to the > > com.sun.management.HotspotDiagnosticMXBean: > > > > public List getDiagnosticCommands(); > > > > public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); > > > > public List getDiagnosticCommandInfo(List > > command); > > > > public List getDiagnosticCommandInfo(); > > > > public String execute(String commandLine) throws > > IllegalArgumentException ; > > > > public String execute(String cmd, String... arguments) > > throws IllegalArgumentException; > > > > > > The getDiagnosticCommands() method returns an array containing the names > > of the not-hidden registered diagnostic commands. > > > > The three getDiagnosticCommandInfo() methods return one or several > > diagnostic command descriptions using the DiagnosticCommandInfo class. > > > > The two execute() methods allow the user the invoke a diagnostic command > > in different ways. > > > > The DiagnosticCommandInfo class is describing a diagnostic command with > > the following information: > > > > public class DiagnosticCommandInfo { > > > > public String getName(); > > > > public String getDescription(); > > > > public String getImpact(); > > > > public boolean isEnabled(); > > > > public List getArgumentsInfo(); > > } > > > > The getName() method returns the name of the diagnostic command. This > > name is the one to use in execute() methods to invoke the diagnostic > > command. > > > > The getDescription() method returns a general description of the > > diagnostic command. > > > > The getImpact() method returns a description of the intrusiveness of > > diagnostic command. > > > > The isEnabled() method returns true if the method is enabled, false if > > it is disabled. A disabled method cannot be executed. > > > > The getArgumentsInfo() returns a list of descriptions for the options or > > arguments recognized by the diagnostic command. Each option/argument is > > described by a DiagnosticCommandArgumentInfo instance: > > > > public class DiagnosticCommandArgumentInfo { > > > > public String getName(); > > > > public String getDescription(); > > > > public String getType(); > > > > public String getDefault(); > > > > public boolean isMandatory(); > > > > public boolean isOption(); > > > > public int getPosition(); > > } > > > > If the DiagnosticCommandArgumentInfo instance describes an option, > > isOption() returns true and getPosition() returns -1. Otherwise, when > > the DiagnosticCommandArgumentInfo instance describes an argument, > > isOption() returns false and getPosition() returns the expected position > > for this argument. The position of an argument is defined relatively to > > all arguments passed on the command line, options are not considered > > when defining an argument position. The getDefault() method returns the > > default value of the argument if a default has been defined, otherwise > > it returns null. > > > > 3-2 The implementation > > > > The framework has been designed in a way that prevents diagnostic > > command developers to worry about the JMX interface. In addition to > > the methods described in section 1-2, a diagnostic command developer has > > to provide three methods: > > > > int get_num_arguments() > > > > which returns the number of option and arguments supported by the > > command. > > > > GrowableArray* get_argument_name_array() > > > > which provides the name of the arguments supported by the command. > > > > GrowableyArray* get_argument_info_array() > > > > which provides the description of each argument with a DCmdArgumentInfo > > instance. DCmdArgumentInfo is a C++ class used by the framework to > > generate the sun.com.management.DcmdArgumentInfo instances. This is done > > automatically and the diagnostic command developer doesn't need to know > > how to create Java objects from the runtime. > > > > 4 - The Diagnostic Commands > > > > To avoid name collisions between diagnostic commands coming from > > different projects, use of a flat name space should be avoided and > > a more structured organization is recommended. The framework itself > > doesn't depend on this organization, so it will be a set of rules > > defining a convention in the way commands are named. > > > > Diagnostic commands can easily organized in a hierarchical way, so the > > template for a command name can be: > > > > .[sub-domain.] > > > > This template can be extended with sub-sub-domains and so on. > > > > A special set of commands without domain will be reserved for the > > commands related to the diagnostic framework itself, like the "help" > > command. > > > > > > Thanks, > > > > Fred > > From john.cuthbertson at oracle.com Fri Dec 9 11:30:37 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 09 Dec 2011 11:30:37 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EDFA96C.9020007@oracle.com> References: <4EDFA96C.9020007@oracle.com> Message-ID: <4EE261DD.9020806@oracle.com> Hi Everyone, I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ Thanks, JohnC On 12/7/2011 9:59 AM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. > > Summary: > I replaced the calls to os::javaTimeMillis() in the GC where we expect > monotonicity with calls os::javaTimeNanos(), converting the result to > milliseconds. os::javaTimeNanos(), at least on some configurations, > does guarantee monotonicity and so is a better alternative. The > changes in the os_<*> files are to make use of the named conversion > constants I added/moved to globalDefinitions.hpp - we seemed to have > multiple names for the same two constants. > > Testing: GC test suite on solaris and Linux, NSK tests on solaris, and > jprt. > > Thanks, > > JohnC From kirk at kodewerk.com Fri Dec 9 23:59:15 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Sat, 10 Dec 2011 08:59:15 +0100 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE261DD.9020806@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: Hi John, The link http://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. Regards, Kirk On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: > Hi Everyone, > > I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ > > Thanks, > > JohnC > > On 12/7/2011 9:59 AM, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >> >> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >> >> Thanks, >> >> JohnC From ysr1729 at gmail.com Sun Dec 11 01:32:35 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sun, 11 Dec 2011 01:32:35 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE261DD.9020806@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: Hi John -- Looks fine. Two minor comments: (1) by defining an os::javaTimeNanosInMillis() you may be able to consolidate the divide by NANOS_IN_MILLISEC to one place instead of it appearing at each use. (2) you might consolidate the commentary about monotonicity into os::javaTimeNanosInMillis(), then at each client simly say "Protect against possible nonmonotonicity" That will reduce the number of repeated lines while still providing all of the commentary in all the relevant places. (By the way, you might want to check if there;s another CR with the same content which might be closed as a dup of this... just a very vague recollection.) reviewed. -- ramki (opendjk: ysr) On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson < john.cuthbertson at oracle.com> wrote: > Hi Everyone, > > I have updated the comments based upon feedback from David Holmes. A new > webrev can be found at: http://cr.openjdk.java.net/~** > johnc/7117303/webrev.1/ > > Thanks, > > JohnC > > > On 12/7/2011 9:59 AM, John Cuthbertson wrote: > >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this CR? The >> webrev can be found at: http://cr.openjdk.java.net/~** >> johnc/7117303/webrev.0/ >> . >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where we expect >> monotonicity with calls os::javaTimeNanos(), converting the result to >> milliseconds. os::javaTimeNanos(), at least on some configurations, does >> guarantee monotonicity and so is a better alternative. The changes in the >> os_<*> files are to make use of the named conversion constants I >> added/moved to globalDefinitions.hpp - we seemed to have multiple names for >> the same two constants. >> >> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and >> jprt. >> >> Thanks, >> >> JohnC >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111211/ccb883bd/attachment.html From frederic.parain at oracle.com Mon Dec 12 06:29:40 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 12 Dec 2011 15:29:40 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE10139.8020905@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> Message-ID: <4EE60FD4.3040404@oracle.com> Hi Paul, Thank you for the review. I've applied all your recommendations except the refactoring in diagnosticCommandFramework.cpp (too few lines can be really factored out without passing many arguments). New webrev is here: http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ Regards, Fred On 12/ 8/11 07:26 PM, Paul Hohensee wrote: > For the hotspot part at > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ > > Most of my comments are style-related. Nice job on the implementation > architecture. > > In attachListener.cpp: > > You might want to delete the first "return JNI_OK;" line, since the code > under > HAS_PENDING_EXCEPTION just falls through. > > In jmm.h: > > Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the > existing declarations. Add a newline just before it on line 322. > > > In diagnosticFramework.hpp: > > Fix indenting for lines 63-66, insert blank before "size_t" on line 48. > > Hotspot convention is that getter method names don't include a "get_" > prefix. > So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). > Similarly, getters such as is_enabled() should retrieve a field named > "_is_enabled" > rather than one named "enabled". You follow the "_is_enabled" convention > in other places such as GenDCmdArgument. Or you could use enabled() to > get the value of the _enabled field. > > Also generally, I'd use accessor methods in the implementation of more > complex member methods rather than access the underlying fields directly. > E.g. in GenDCmdArgument::read_value, I'd use is_set() and set_is_set(true), > (set_is_set() is not actually defined, but should be) rather than directly > accessing _is_set. Though sometimes doing this is too much of a pain > with fields whose type is a template argument, as in the > DCmdArggument::parse_value() method in diagnosticArgument.cpp. > > For easy readability, it'd be nice to line up field names (the ones with an > _ prefix) at the same column. > > On line 200, "instanciated" -> "instantiated" > > On line 218, I'd use "heap_allocated" rather than "heap" for the formal > arg name. > > On line 248, you could indent the text to start underneath "outputStream". > I generally find that indenting arguments lines (formal or actual) so > they line > up with the first argument position make the code more readable, but I'm > not > religious about it. > > On line 265, "instanciated" -> "instantiated" > > DCmdFactorys are members of a singly-linked list, right? If so, it'd be > good to > have a comment to that effect on the declaration of _next. > > On line 322, insert a blank before "true". You might fix this in other > places > where there's no blank between a comma in an argument list and the > following parameter value. > > > In diagnosticCommandFramework.cpp: > > The code from lines 80-95 and 105-120 is identical. Factor out? > > > In diagnosticArgument.cpp: > > On line 41, insert blanks before the actual arguments. (see above > generic comment) > > On line 77, the "if" is indented one space too many. > > > In management.cpp: > > I'd be consistent with having or not having a space between "while", > "if" and "for" > and the following "(" in this and your other code. Most hotspot code has > a space. > > > Thanks, > > Paul > > > On 12/2/11 8:57 AM, Frederic Parain wrote: >> Hi All, >> >> [Posting to serviceability-dev, runtime-dev and core-libs-dev >> because changes are pretty big and touch all these areas] >> >> Here's a framework for issuing diagnostics commands to the JVM. >> Diagnostic commands are actions executed inside the JVM mainly >> for monitoring or management purpose. This work has two parts. >> The first part is in the hotspot repository and contains the >> framework itself with two diagnostic commands. The second >> part is in the JDK repository and contains the command line >> utility to invoke diagnostic commands as well as the >> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >> extensions allow a remote client to discover and invoke >> diagnostic commands using a JMX connection. >> >> This changeset only contains two diagnostic commands, more >> commands will be added in the future, as a standalone effort >> to improve the monitoring and management services of the >> JVM, or as part of other projects. >> >> Webrevs are here: >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >> >> Here's a technical description of this work: >> >> 1 - The Diagnostic Command Framework >> 1-1 Overview >> >> The diagnostic command framework is fully implemented in native code >> and relies on the HotSpot's internal exception mechanism. >> The rational of a pure native implementation is to be able to execute >> diagnostic commands even in critical situations like an OutOfMemory >> error. All diagnostic commands are registered in a single list, and two >> flags control the way a user can interact with them. The "hidden" flag >> prevents a diagnostic command from appearing in the list of available >> commands returned by the "help" command. However, it's still possible to >> get the detailed help message for a hidden command with the "help >> " syntax (but it requires to know the name of the hidden >> command). The second flag is "enabled" and it controls if a command can >> be invoked or not. When listed with the "help" commands, disabled >> commands appear with a "[disabled]" label in their description. If the >> user tries to invoke a disabled command, an error message is returned >> and the command is not run. This error message can be customized on a >> per command base. The framework just provides these two flags with their >> semantic, it doesn't provide any policy or mechanism to set or modify >> these flags. These actions will be delegated to the JVM or special >> diagnostic commands. >> >> 1-2 Implementation >> >> All diagnostic commands are implemented as subclasses of the DCmd class >> defined in services/diagnosticFramework.hpp. Here's the layout of the >> DCmd class and the list of methods that a new command has to define or >> overwrite: >> >> class DCmd { >> DCmd(outputStream *output); >> >> static const char *get_name(); >> >> static const char *get_description(); >> >> static const char *get_disabled_message(); >> >> static const char *get_impact(); >> >> static int get_num_arguments(); >> >> virtual void print_help(outputStream* out); >> >> virtual void parse(CmdLine* line, char delim, TRAPS); >> >> virtual void execute(TRAPS); >> >> virtual void reset(TRAPS); >> >> virtual void cleanup(); >> >> virtual GrowableArray* get_argument_name_array(); >> >> virtual GrowableArray* get_argument_info_array(); >> } >> >> A diagnostic command is always instantiated with an outputStream in >> parameter. This outputStream can point either to a file, a buffer or a >> socket (see the ostream.hpp file). >> >> The get_name() method returns the string that will identify the command >> (i.e. the string to put on the command line to invoke it). >> >> The get_description() methods returns the global description of the >> command. >> >> The get_disabled_message() returns the customized message to return when >> the command is disabled, without having to instantiate the command. >> >> The get_impact() returns a description of the intrusiveness of the >> diagnostic command on the Java Virtual Machine behavior. The rational >> for this method is that some diagnostic commands can seriously disrupt >> the behavior of the Java Virtual Machine (for instance a Thread Dump for >> an application with several tens of thousands of threads, or a Head Dump >> with a 40GB+ heap size) and other diagnostic commands have no serious >> impact on the JVM (for instance, getting the command line arguments or >> the JVM version). The recommended format for the description is > level>: [longer description], where the impact level is selected among >> this list: {low, medium, high}. The optional longer description can >> provide more specific details like the fact that Thread Dump impact >> depends on the heap size. >> >> The get_num_arguments() returns the number of options/arguments >> recognized by the diagnostic command. This method is only used by the >> JMX interface support (see below). >> >> The print_help() methods prints a detailed help on the outputStream >> passed in argument. The detailed help contains the list of all supported >> options with their type and description. >> >> The parse() method is in charge of parsing the command arguments. Each >> command is free to implement its own argument parser. However, an >> argument parser framework is provided (see section 1-3) to ease the >> implementation, but its use is optional. The parse method takes a >> delimiter character in argument, which is used to mark the limit between >> two arguments (typically invocation from jcmd will use a space character >> as a delimiter while invocation from the JVM command line parsing code >> will use a comma as a delimiter). >> >> The execute() method is naturally the one to invoke to get the >> diagnostic command executed. The parse() and the execute() methods are >> dissociated, so it's a possible perform the argument parsing in one >> thread, and delegate the execution to another thread, as long as the >> diagnostic command doesn't reference thread local variables. The >> framework allows several instances of the same diagnostic command to be >> executed in parallel. If for some reasons concurrent executions should >> not be allowed for a given diagnostic command, this is the >> responsibility of the diagnostic command implementor to enforce this >> rule, for instance by protecting the body of the execute() method with a >> global lock. >> >> The reset() method is used to initialize the internal fields of the >> diagnostic command or to reset the internal fields to their initial >> value to be able to re-use an already allocated diagnostic command >> instance. >> >> The cleanup() method is used to perform perform cleanup (like freeing of >> all memory allocated to store internal data). The DCmd extends the >> ResourceObj class, so when allocated in a ResourceArea, destructors >> cannot be used to perform cleanup. To ensure that cleanup is performed >> in all cases, it is recommended to create a DCmdMark instance for each >> DCmd instance. DCmdMark is a stack allocated object with a pointer to a >> DCmd instance. When the DCmdMark is destroyed, its destructor calls the >> cleanup() method of the DCmd instance it points to. If the DCmd instance >> has been allocated on the C-Heap, the DCmdMark will also free the memory >> allocated to store the DCmd instance. >> >> The get_argument_name_array() and get_argument_info_array() are related >> to the JMX interface of the diagnostic command framework, so they are >> described in section 3. >> >> 1-3 DCmdParser framework >> >> The DCmdParser class is an optional framework to help development of >> argument parsers. It provides many features required by the diagnostic >> command framework (generation of the help message or the argument >> descriptions for the JMX interface) but all these features can easily be >> re-implemented if a developer decides not to use the DCmdParser >> framework. >> >> The DCmdParser class is relying on the DCmdArgument template. This >> template must be used to define the different types of argument the >> parser will have to handle. When a new specialization of the template is >> done, three methods have to be provided: >> >> void parse_value(const char *str,size_t len,TRAPS); >> void init_value(TRAPS); >> void destroy_value(); >> >> The parse_value() method is used to convert a string into an argument >> value. The print_value() method is used to display the default value >> (support for the detailed help message). The init_value() method is used >> to initialize or reset the argument value. The destroy_value() method is >> a clean-up method (useful when the argument has allocated some C-Heap >> memory to store its value and this memory has to be freed before >> destroying the DCmdArgument instance). >> >> The DCmdParser makes a distinction between options and arguments. >> Options are identified by a key name that must appear on the command >> line, while argument are identified just by the position of the argument >> on the command line. Options use the = syntax. In case of >> boolean options, the '=' part of the syntax can be omitted to set >> the option to true. Arguments are just sequences characters delimited by >> a separator character. This separator can be specified at runtime when >> invoking the diagnostic command framework. If an argument contain a >> character that could be used as a delimiter, it's possible to enclose >> the argument between single or double quotes. Options are arguments are >> instantiated using the same DCmdArgument class but they're registered >> differently to the DCmdParser. >> >> The way to use the DCmdParser is to declare the parser and the >> option/arguments as fields of the diagnostic command class (which is >> itself a sub-class of the DCmd class), like this: >> >> >> class EchoDCmd : public DCmd { >> protected: >> DCmdParser _dcmdparser; >> >> DCmdArgument _required; >> >> DCmdArgument _intval; >> >> DCmdArgument _boolval; >> >> DCmdArgument _stringval; >> >> DCmdArgument _first_arg; >> >> DCmdArgument _second_arg; >> >> DCmdArgument _optional_arg; >> >> } >> >> The parser and the options/arguments must be initialized before the >> diagnostic command class, and the options/arguments have to be >> registered to the parser like this: >> >> EchoDCmd(outputStream *output) : DCmd(output), >> _stringval("-strval","a string argument","STRING",false), >> >> _boolval("-boolval","a boolean argument","BOOLEAN",false), >> >> _intval("-intval","an integer argument","INTEGER",false), >> >> _required("-req","a mandatory integer argument","INTEGER",true), >> >> _fist_arg("first argument","a string argument","STRING",true), >> >> _second_arg("second argument,"an integer argument,"INTEGER",true), >> >> _optional_arg("optional argument","an optional string >> argument","STRING","false") >> >> { >> >> _dcmdparser.add_dcmd_option(&_stringval) >> >> _dcmdparser.add_dcmd_option(&_boolval); >> >> _dcmdparser.add_dcmd_option(&_intval); >> >> _dcmdparser.add_dcmd_option(&_required); >> >> _dcmdparser.add_argument(&_first_arg); >> >> _dcmdparser.add_argument(&_second_arg); >> >> _dcmdparser.add_argument(&_optional_arg); >> }; >> >> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >> argument/option to the parser. The option/argument constructor takes the >> name of the option/argument, its description, a string describing its >> type and a boolean to specify if the option/argument is mandatory or >> not. The parser doesn't support option/argument duplicates (having the >> same name) but the code currently doesn't check for duplicates.The order >> used to register options has no impact on the parser. However, the order >> used to register arguments is critical because the parser will use the >> same order to parse the command line. In the example above, the parser >> expects to have a first argument of type STRING (parsed using >> _first_arg), then a second argument of type INTEGER (parsed using >> _second_arg) and optionally a third parameter of type STRING (parsed >> using _optional_arg). A mandatory option or argument has to be specify >> every time the command is invoked. If it is missing, an exception is >> thrown at the end of the parsing. Optional arguments have to be >> registered after mandatory arguments. An optional argument will be >> considered for parsing only if all arguments before it (mandatory or >> not) have already been used to parse the command line. >> >> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >> instance. The rational for this design is to limit the number of C-heap >> allocations but also to be able to pre-allocate diagnostic command >> instances for critical situations. If the process is running out of >> C-heap space, it's not possible to instantiate new diagnostic commands >> to troubleshoot the situation. By pre-allocating some diagnostic >> commands, it will be possible to run them even in this critical >> situation. Of course, the diagnostic command itself should not try to >> allocate memory during its execution, this prevents the diagnostic >> command to use variable length arguments like strings. By nature, >> pre-allocated diagnostic commands aim to be re-usable, this is the >> purpose of the reset() method which restores the default status of all >> arguments. >> >> 1-4 Internal invocation >> >> Using a diagnostic command from the JVM itself is pretty easy: >> instantiate the class and invoke the parse() method then the execute() >> method. A diagnostic command can be instantiated from inside the JVM >> even it is not registered. This is a difference with the external >> invocations (from jcmd or JMX) that require the command to be registered. >> >> 2 - The JCmd interface >> >> Diagnostic commands can also be invoked from outside the JVM process, >> using the new 'jcmd' utility. The jcmd program uses the attach API >> to connect to the JVM, send requests and receive results. The >> jcmd utility must be launched on the same machine than the one running >> the JVM (its a local tool). Launched without arguments, jcmd displays a >> list of all JVMs running on the machine. The jcmd source code is in >> the jdk repository like other existing j* tools. >> >> To execute a diagnostic command in a particular JVM, the generic >> syntax is: >> >> jcmd [arguments] >> >> The attachListener has been modified to recognized the jcmd requests. >> When a jcmd request is identified, it is parsed to extract the command >> name. The JVM performs a look up of this command in a list of registered >> commands. To be executable by an external request, a diagnostic command >> has to be registered. The registration is performed with the DCmdFactory >> class (see services/management.cpp). >> >> 3 - The JMX interface >> >> The framework provides a JMX based interface to the diagnostic commands. >> This interface allows remote invocation of diagnostic commands through a >> JMX connection. >> >> 3-1 The interface >> >> The information related to the diagnostic commands are accessible >> through new methods added to the >> com.sun.management.HotspotDiagnosticMXBean: >> >> public List getDiagnosticCommands(); >> >> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >> >> public List getDiagnosticCommandInfo(List >> command); >> >> public List getDiagnosticCommandInfo(); >> >> public String execute(String commandLine) throws >> IllegalArgumentException ; >> >> public String execute(String cmd, String... arguments) >> throws IllegalArgumentException; >> >> >> The getDiagnosticCommands() method returns an array containing the names >> of the not-hidden registered diagnostic commands. >> >> The three getDiagnosticCommandInfo() methods return one or several >> diagnostic command descriptions using the DiagnosticCommandInfo class. >> >> The two execute() methods allow the user the invoke a diagnostic command >> in different ways. >> >> The DiagnosticCommandInfo class is describing a diagnostic command with >> the following information: >> >> public class DiagnosticCommandInfo { >> >> public String getName(); >> >> public String getDescription(); >> >> public String getImpact(); >> >> public boolean isEnabled(); >> >> public List getArgumentsInfo(); >> } >> >> The getName() method returns the name of the diagnostic command. This >> name is the one to use in execute() methods to invoke the diagnostic >> command. >> >> The getDescription() method returns a general description of the >> diagnostic command. >> >> The getImpact() method returns a description of the intrusiveness of >> diagnostic command. >> >> The isEnabled() method returns true if the method is enabled, false if >> it is disabled. A disabled method cannot be executed. >> >> The getArgumentsInfo() returns a list of descriptions for the options or >> arguments recognized by the diagnostic command. Each option/argument is >> described by a DiagnosticCommandArgumentInfo instance: >> >> public class DiagnosticCommandArgumentInfo { >> >> public String getName(); >> >> public String getDescription(); >> >> public String getType(); >> >> public String getDefault(); >> >> public boolean isMandatory(); >> >> public boolean isOption(); >> >> public int getPosition(); >> } >> >> If the DiagnosticCommandArgumentInfo instance describes an option, >> isOption() returns true and getPosition() returns -1. Otherwise, when >> the DiagnosticCommandArgumentInfo instance describes an argument, >> isOption() returns false and getPosition() returns the expected position >> for this argument. The position of an argument is defined relatively to >> all arguments passed on the command line, options are not considered >> when defining an argument position. The getDefault() method returns the >> default value of the argument if a default has been defined, otherwise >> it returns null. >> >> 3-2 The implementation >> >> The framework has been designed in a way that prevents diagnostic >> command developers to worry about the JMX interface. In addition to >> the methods described in section 1-2, a diagnostic command developer has >> to provide three methods: >> >> int get_num_arguments() >> >> which returns the number of option and arguments supported by the >> command. >> >> GrowableArray* get_argument_name_array() >> >> which provides the name of the arguments supported by the command. >> >> GrowableyArray* get_argument_info_array() >> >> which provides the description of each argument with a DCmdArgumentInfo >> instance. DCmdArgumentInfo is a C++ class used by the framework to >> generate the sun.com.management.DcmdArgumentInfo instances. This is done >> automatically and the diagnostic command developer doesn't need to know >> how to create Java objects from the runtime. >> >> 4 - The Diagnostic Commands >> >> To avoid name collisions between diagnostic commands coming from >> different projects, use of a flat name space should be avoided and >> a more structured organization is recommended. The framework itself >> doesn't depend on this organization, so it will be a set of rules >> defining a convention in the way commands are named. >> >> Diagnostic commands can easily organized in a hierarchical way, so the >> template for a command name can be: >> >> .[sub-domain.] >> >> This template can be extended with sub-sub-domains and so on. >> >> A special set of commands without domain will be reserved for the >> commands related to the diagnostic framework itself, like the "help" >> command. >> >> >> Thanks, >> >> Fred >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Mon Dec 12 06:31:28 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 12 Dec 2011 15:31:28 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <34278e49-efbc-4370-ab36-a50331a9ff65@default> References: <4ED8D93A.5050600@oracle.com 4EE10139.8020905@oracle.com> <34278e49-efbc-4370-ab36-a50331a9ff65@default> Message-ID: <4EE61040.5040704@oracle.com> Hi Robert, These issues should be solved with the new webrevs: http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.03/ Regards, Fred On 12/ 9/11 03:17 PM, Robert Ottenhag wrote: > Adding to the review of jmm.h, that is modified in both the jdk part > and the hotspot part, these files should be identical, without any > differences in whitespace. > > Also, regarding whitespace and indentation, the use TAB characters in > many files in the jdk patch makes jcheck complain (when trying to > import your patch locally), and should be replaced by spaces. > > Best regards, > > /Robert > > >> -----Original Message----- From: Paul Hohensee Sent: Thursday, >> December 08, 2011 7:26 PM To: Frederic Parain Cc: >> serviceability-dev at openjdk.java.net; >> core-libs-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net Subject: Re: Request for >> Review (XXL): 7104647: Adding a diagnostic command framework >> >> For the hotspot part at >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >> >> Most of my comments are style-related. Nice job on the >> implementation architecture. >> >> In attachListener.cpp: >> >> You might want to delete the first "return JNI_OK;" line, since the >> code under HAS_PENDING_EXCEPTION just falls through. >> >> In jmm.h: >> >> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as >> the existing declarations. Add a newline just before it on line >> 322. >> >> >> In diagnosticFramework.hpp: >> >> Fix indenting for lines 63-66, insert blank before "size_t" on line >> 48. >> >> Hotspot convention is that getter method names don't include a >> "get_" prefix. So, e.g., DCmdArgIter::get_key_addr() s/b >> DCmdArgIter::key_addr(). Similarly, getters such as is_enabled() >> should retrieve a field named "_is_enabled" rather than one named >> "enabled". You follow the "_is_enabled" convention in other places >> such as GenDCmdArgument. Or you could use enabled() to get the >> value of the _enabled field. >> >> Also generally, I'd use accessor methods in the implementation of >> more complex member methods rather than access the underlying >> fields directly. E.g. in GenDCmdArgument::read_value, I'd use >> is_set() and set_is_set(true), (set_is_set() is not actually >> defined, but should be) rather than directly accessing _is_set. >> Though sometimes doing this is too much of a pain with fields whose >> type is a template argument, as in the >> DCmdArggument::parse_value() method in >> diagnosticArgument.cpp. >> >> For easy readability, it'd be nice to line up field names (the ones >> with an _ prefix) at the same column. >> >> On line 200, "instanciated" -> "instantiated" >> >> On line 218, I'd use "heap_allocated" rather than "heap" for the >> formal arg name. >> >> On line 248, you could indent the text to start underneath >> "outputStream". I generally find that indenting arguments lines >> (formal or actual) so they line up with the first argument position >> make the code more readable, but I'm not religious about it. >> >> On line 265, "instanciated" -> "instantiated" >> >> DCmdFactorys are members of a singly-linked list, right? If so, >> it'd be good to have a comment to that effect on the declaration of >> _next. >> >> On line 322, insert a blank before "true". You might fix this in >> other places where there's no blank between a comma in an argument >> list and the following parameter value. >> >> >> In diagnosticCommandFramework.cpp: >> >> The code from lines 80-95 and 105-120 is identical. Factor out? >> >> >> In diagnosticArgument.cpp: >> >> On line 41, insert blanks before the actual arguments. (see above >> generic comment) >> >> On line 77, the "if" is indented one space too many. >> >> >> In management.cpp: >> >> I'd be consistent with having or not having a space between >> "while", "if" and "for" and the following "(" in this and your >> other code. Most hotspot code has a space. >> >> >> Thanks, >> >> Paul >> >> >> On 12/2/11 8:57 AM, Frederic Parain wrote: >>> Hi All, >>> >>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>> because changes are pretty big and touch all these areas] >>> >>> Here's a framework for issuing diagnostics commands to the JVM. >>> Diagnostic commands are actions executed inside the JVM mainly >>> for monitoring or management purpose. This work has two parts. >>> The first part is in the hotspot repository and contains the >>> framework itself with two diagnostic commands. The second part is >>> in the JDK repository and contains the command line utility to >>> invoke diagnostic commands as well as the HotSpotDiagnosticMXBean >>> extensions. The HotSpotDiagnosticMXBean extensions allow a remote >>> client to discover and invoke diagnostic commands using a JMX >>> connection. >>> >>> This changeset only contains two diagnostic commands, more >>> commands will be added in the future, as a standalone effort to >>> improve the monitoring and management services of the JVM, or as >>> part of other projects. >>> >>> Webrevs are here: >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>> >>> Here's a technical description of this work: >>> >>> 1 - The Diagnostic Command Framework 1-1 Overview >>> >>> The diagnostic command framework is fully implemented in native >>> code and relies on the HotSpot's internal exception mechanism. >>> The rational of a pure native implementation is to be able to >>> execute diagnostic commands even in critical situations like an >>> OutOfMemory error. All diagnostic commands are registered in a >>> single list, and two flags control the way a user can interact >>> with them. The "hidden" flag prevents a diagnostic command from >>> appearing in the list of available commands returned by the >>> "help" command. However, it's still possible to get the detailed >>> help message for a hidden command with the "help " >>> syntax (but it requires to know the name of the hidden command). >>> The second flag is "enabled" and it controls if a command can be >>> invoked or not. When listed with the "help" commands, disabled >>> commands appear with a "[disabled]" label in their description. >>> If the user tries to invoke a disabled command, an error message >>> is returned and the command is not run. This error message can be >>> customized on a per command base. The framework just provides >>> these two flags with their semantic, it doesn't provide any >>> policy or mechanism to set or modify these flags. These actions >>> will be delegated to the JVM or special diagnostic commands. >>> >>> 1-2 Implementation >>> >>> All diagnostic commands are implemented as subclasses of the DCmd >>> class defined in services/diagnosticFramework.hpp. Here's the >>> layout of the DCmd class and the list of methods that a new >>> command has to define or overwrite: >>> >>> class DCmd { DCmd(outputStream *output); >>> >>> static const char *get_name(); >>> >>> static const char *get_description(); >>> >>> static const char *get_disabled_message(); >>> >>> static const char *get_impact(); >>> >>> static int get_num_arguments(); >>> >>> virtual void print_help(outputStream* out); >>> >>> virtual void parse(CmdLine* line, char delim, TRAPS); >>> >>> virtual void execute(TRAPS); >>> >>> virtual void reset(TRAPS); >>> >>> virtual void cleanup(); >>> >>> virtual GrowableArray* get_argument_name_array(); >>> >>> virtual GrowableArray* >>> get_argument_info_array(); } >>> >>> A diagnostic command is always instantiated with an outputStream >>> in parameter. This outputStream can point either to a file, a >>> buffer or a socket (see the ostream.hpp file). >>> >>> The get_name() method returns the string that will identify the >>> command (i.e. the string to put on the command line to invoke >>> it). >>> >>> The get_description() methods returns the global description of >>> the command. >>> >>> The get_disabled_message() returns the customized message to >>> return when the command is disabled, without having to >>> instantiate the command. >>> >>> The get_impact() returns a description of the intrusiveness of >>> the diagnostic command on the Java Virtual Machine behavior. The >>> rational for this method is that some diagnostic commands can >>> seriously disrupt the behavior of the Java Virtual Machine (for >>> instance a Thread Dump for an application with several tens of >>> thousands of threads, or a Head Dump with a 40GB+ heap size) and >>> other diagnostic commands have no serious impact on the JVM (for >>> instance, getting the command line arguments or the JVM version). >>> The recommended format for the description is: >>> [longer description], where the impact level is selected among >>> this list: {low, medium, high}. The optional longer description >>> can provide more specific details like the fact that Thread Dump >>> impact depends on the heap size. >>> >>> The get_num_arguments() returns the number of options/arguments >>> recognized by the diagnostic command. This method is only used by >>> the JMX interface support (see below). >>> >>> The print_help() methods prints a detailed help on the >>> outputStream passed in argument. The detailed help contains the >>> list of all supported options with their type and description. >>> >>> The parse() method is in charge of parsing the command arguments. >>> Each command is free to implement its own argument parser. >>> However, an argument parser framework is provided (see section >>> 1-3) to ease the implementation, but its use is optional. The >>> parse method takes a delimiter character in argument, which is >>> used to mark the limit between two arguments (typically >>> invocation from jcmd will use a space character as a delimiter >>> while invocation from the JVM command line parsing code will use >>> a comma as a delimiter). >>> >>> The execute() method is naturally the one to invoke to get the >>> diagnostic command executed. The parse() and the execute() >>> methods are dissociated, so it's a possible perform the argument >>> parsing in one thread, and delegate the execution to another >>> thread, as long as the diagnostic command doesn't reference >>> thread local variables. The framework allows several instances of >>> the same diagnostic command to be executed in parallel. If for >>> some reasons concurrent executions should not be allowed for a >>> given diagnostic command, this is the responsibility of the >>> diagnostic command implementor to enforce this rule, for instance >>> by protecting the body of the execute() method with a global >>> lock. >>> >>> The reset() method is used to initialize the internal fields of >>> the diagnostic command or to reset the internal fields to their >>> initial value to be able to re-use an already allocated >>> diagnostic command instance. >>> >>> The cleanup() method is used to perform perform cleanup (like >>> freeing of all memory allocated to store internal data). The DCmd >>> extends the ResourceObj class, so when allocated in a >>> ResourceArea, destructors cannot be used to perform cleanup. To >>> ensure that cleanup is performed in all cases, it is recommended >>> to create a DCmdMark instance for each DCmd instance. DCmdMark is >>> a stack allocated object with a pointer to a DCmd instance. When >>> the DCmdMark is destroyed, its destructor calls the cleanup() >>> method of the DCmd instance it points to. If the DCmd instance >>> has been allocated on the C-Heap, the DCmdMark will also free the >>> memory allocated to store the DCmd instance. >>> >>> The get_argument_name_array() and get_argument_info_array() are >>> related to the JMX interface of the diagnostic command framework, >>> so they are described in section 3. >>> >>> 1-3 DCmdParser framework >>> >>> The DCmdParser class is an optional framework to help development >>> of argument parsers. It provides many features required by the >>> diagnostic command framework (generation of the help message or >>> the argument descriptions for the JMX interface) but all these >>> features can easily be re-implemented if a developer decides not >>> to use the DCmdParser framework. >>> >>> The DCmdParser class is relying on the DCmdArgument template. >>> This template must be used to define the different types of >>> argument the parser will have to handle. When a new >>> specialization of the template is done, three methods have to be >>> provided: >>> >>> void parse_value(const char *str,size_t len,TRAPS); void >>> init_value(TRAPS); void destroy_value(); >>> >>> The parse_value() method is used to convert a string into an >>> argument value. The print_value() method is used to display the >>> default value (support for the detailed help message). The >>> init_value() method is used to initialize or reset the argument >>> value. The destroy_value() method is a clean-up method (useful >>> when the argument has allocated some C-Heap memory to store its >>> value and this memory has to be freed before destroying the >>> DCmdArgument instance). >>> >>> The DCmdParser makes a distinction between options and >>> arguments. Options are identified by a key name that must appear >>> on the command line, while argument are identified just by the >>> position of the argument on the command line. Options use >>> the= syntax. In case of boolean options, the >>> '=' part of the syntax can be omitted to set the option to >>> true. Arguments are just sequences characters delimited by a >>> separator character. This separator can be specified at runtime >>> when invoking the diagnostic command framework. If an argument >>> contain a character that could be used as a delimiter, it's >>> possible to enclose the argument between single or double quotes. >>> Options are arguments are instantiated using the same >>> DCmdArgument class but they're registered differently to the >>> DCmdParser. >>> >>> The way to use the DCmdParser is to declare the parser and the >>> option/arguments as fields of the diagnostic command class (which >>> is itself a sub-class of the DCmd class), like this: >>> >>> >>> class EchoDCmd : public DCmd { protected: DCmdParser >>> _dcmdparser; >>> >>> DCmdArgument _required; >>> >>> DCmdArgument _intval; >>> >>> DCmdArgument _boolval; >>> >>> DCmdArgument _stringval; >>> >>> DCmdArgument _first_arg; >>> >>> DCmdArgument _second_arg; >>> >>> DCmdArgument _optional_arg; >>> >>> } >>> >>> The parser and the options/arguments must be initialized before >>> the diagnostic command class, and the options/arguments have to >>> be registered to the parser like this: >>> >>> EchoDCmd(outputStream *output) : DCmd(output), >>> _stringval("-strval","a string argument","STRING",false), >>> >>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>> >>> _intval("-intval","an integer argument","INTEGER",false), >>> >>> _required("-req","a mandatory integer argument","INTEGER",true), >>> >>> _fist_arg("first argument","a string argument","STRING",true), >>> >>> _second_arg("second argument,"an integer >>> argument,"INTEGER",true), >>> >>> _optional_arg("optional argument","an optional string >>> argument","STRING","false") >>> >>> { >>> >>> _dcmdparser.add_dcmd_option(&_stringval) >>> >>> _dcmdparser.add_dcmd_option(&_boolval); >>> >>> _dcmdparser.add_dcmd_option(&_intval); >>> >>> _dcmdparser.add_dcmd_option(&_required); >>> >>> _dcmdparser.add_argument(&_first_arg); >>> >>> _dcmdparser.add_argument(&_second_arg); >>> >>> _dcmdparser.add_argument(&_optional_arg); }; >>> >>> The add_dcmd_argument()/ add_dcmd_option() method is used to add >>> an argument/option to the parser. The option/argument constructor >>> takes the name of the option/argument, its description, a string >>> describing its type and a boolean to specify if the >>> option/argument is mandatory or not. The parser doesn't support >>> option/argument duplicates (having the same name) but the code >>> currently doesn't check for duplicates.The order used to register >>> options has no impact on the parser. However, the order used to >>> register arguments is critical because the parser will use the >>> same order to parse the command line. In the example above, the >>> parser expects to have a first argument of type STRING (parsed >>> using _first_arg), then a second argument of type INTEGER (parsed >>> using _second_arg) and optionally a third parameter of type >>> STRING (parsed using _optional_arg). A mandatory option or >>> argument has to be specify every time the command is invoked. If >>> it is missing, an exception is thrown at the end of the parsing. >>> Optional arguments have to be registered after mandatory >>> arguments. An optional argument will be considered for parsing >>> only if all arguments before it (mandatory or not) have already >>> been used to parse the command line. >>> >>> The DCmdParser and its DCmdArgument instances are embedded in the >>> DCmd instance. The rational for this design is to limit the >>> number of C-heap allocations but also to be able to pre-allocate >>> diagnostic command instances for critical situations. If the >>> process is running out of C-heap space, it's not possible to >>> instantiate new diagnostic commands to troubleshoot the >>> situation. By pre-allocating some diagnostic commands, it will be >>> possible to run them even in this critical situation. Of course, >>> the diagnostic command itself should not try to allocate memory >>> during its execution, this prevents the diagnostic command to use >>> variable length arguments like strings. By nature, pre-allocated >>> diagnostic commands aim to be re-usable, this is the purpose of >>> the reset() method which restores the default status of all >>> arguments. >>> >>> 1-4 Internal invocation >>> >>> Using a diagnostic command from the JVM itself is pretty easy: >>> instantiate the class and invoke the parse() method then the >>> execute() method. A diagnostic command can be instantiated from >>> inside the JVM even it is not registered. This is a difference >>> with the external invocations (from jcmd or JMX) that require the >>> command to be >> registered. >>> >>> 2 - The JCmd interface >>> >>> Diagnostic commands can also be invoked from outside the JVM >>> process, using the new 'jcmd' utility. The jcmd program uses the >>> attach API to connect to the JVM, send requests and receive >>> results. The jcmd utility must be launched on the same machine >>> than the one running the JVM (its a local tool). Launched without >>> arguments, jcmd displays a list of all JVMs running on the >>> machine. The jcmd source code is in the jdk repository like other >>> existing j* tools. >>> >>> To execute a diagnostic command in a particular JVM, the generic >>> syntax is: >>> >>> jcmd [arguments] >>> >>> The attachListener has been modified to recognized the jcmd >>> requests. When a jcmd request is identified, it is parsed to >>> extract the command name. The JVM performs a look up of this >>> command in a list of registered commands. To be executable by an >>> external request, a diagnostic command has to be registered. The >>> registration is performed with the DCmdFactory class (see >>> services/management.cpp). >>> >>> 3 - The JMX interface >>> >>> The framework provides a JMX based interface to the diagnostic >>> commands. This interface allows remote invocation of diagnostic >>> commands through a JMX connection. >>> >>> 3-1 The interface >>> >>> The information related to the diagnostic commands are >>> accessible through new methods added to the >>> com.sun.management.HotspotDiagnosticMXBean: >>> >>> public List getDiagnosticCommands(); >>> >>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String >>> command); >>> >>> public List >>> getDiagnosticCommandInfo(List command); >>> >>> public List getDiagnosticCommandInfo(); >>> >>> public String execute(String commandLine) throws >>> IllegalArgumentException ; >>> >>> public String execute(String cmd, String... arguments) throws >>> IllegalArgumentException; >>> >>> >>> The getDiagnosticCommands() method returns an array containing >>> the names of the not-hidden registered diagnostic commands. >>> >>> The three getDiagnosticCommandInfo() methods return one or >>> several diagnostic command descriptions using the >>> DiagnosticCommandInfo class. >>> >>> The two execute() methods allow the user the invoke a diagnostic >>> command in different ways. >>> >>> The DiagnosticCommandInfo class is describing a diagnostic >>> command with the following information: >>> >>> public class DiagnosticCommandInfo { >>> >>> public String getName(); >>> >>> public String getDescription(); >>> >>> public String getImpact(); >>> >>> public boolean isEnabled(); >>> >>> public List getArgumentsInfo(); >>> } >>> >>> The getName() method returns the name of the diagnostic command. >>> This name is the one to use in execute() methods to invoke the >>> diagnostic command. >>> >>> The getDescription() method returns a general description of the >>> diagnostic command. >>> >>> The getImpact() method returns a description of the intrusiveness >>> of diagnostic command. >>> >>> The isEnabled() method returns true if the method is enabled, >>> false if it is disabled. A disabled method cannot be executed. >>> >>> The getArgumentsInfo() returns a list of descriptions for the >>> options or arguments recognized by the diagnostic command. Each >>> option/argument is described by a DiagnosticCommandArgumentInfo >>> instance: >>> >>> public class DiagnosticCommandArgumentInfo { >>> >>> public String getName(); >>> >>> public String getDescription(); >>> >>> public String getType(); >>> >>> public String getDefault(); >>> >>> public boolean isMandatory(); >>> >>> public boolean isOption(); >>> >>> public int getPosition(); } >>> >>> If the DiagnosticCommandArgumentInfo instance describes an >>> option, isOption() returns true and getPosition() returns -1. >>> Otherwise, when the DiagnosticCommandArgumentInfo instance >>> describes an argument, isOption() returns false and getPosition() >>> returns the expected position for this argument. The position of >>> an argument is defined relatively to all arguments passed on the >>> command line, options are not considered when defining an >>> argument position. The getDefault() method returns the default >>> value of the argument if a default has been defined, otherwise it >>> returns null. >>> >>> 3-2 The implementation >>> >>> The framework has been designed in a way that prevents >>> diagnostic command developers to worry about the JMX interface. >>> In addition to the methods described in section 1-2, a diagnostic >>> command developer has to provide three methods: >>> >>> int get_num_arguments() >>> >>> which returns the number of option and arguments supported by >>> the command. >>> >>> GrowableArray* get_argument_name_array() >>> >>> which provides the name of the arguments supported by the >>> command. >>> >>> GrowableyArray* get_argument_info_array() >>> >>> which provides the description of each argument with a >>> DCmdArgumentInfo instance. DCmdArgumentInfo is a C++ class used >>> by the framework to generate the >>> sun.com.management.DcmdArgumentInfo instances. This is done >>> automatically and the diagnostic command developer doesn't need >>> to know how to create Java objects from the runtime. >>> >>> 4 - The Diagnostic Commands >>> >>> To avoid name collisions between diagnostic commands coming from >>> different projects, use of a flat name space should be avoided >>> and a more structured organization is recommended. The framework >>> itself doesn't depend on this organization, so it will be a set >>> of rules defining a convention in the way commands are named. >>> >>> Diagnostic commands can easily organized in a hierarchical way, >>> so the template for a command name can be: >>> >>> .[sub-domain.] >>> >>> This template can be extended with sub-sub-domains and so on. >>> >>> A special set of commands without domain will be reserved for >>> the commands related to the diagnostic framework itself, like the >>> "help" command. >>> >>> >>> Thanks, >>> >>> Fred >>> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Mon Dec 12 07:56:43 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 12 Dec 2011 16:56:43 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE60FD4.3040404@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> <4EE60FD4.3040404@oracle.com> Message-ID: <4EE6243B.6070200@oracle.com> Minor updates: http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.04/ Fred On 12/12/11 03:29 PM, Frederic Parain wrote: > Hi Paul, > > Thank you for the review. > I've applied all your recommendations except the refactoring > in diagnosticCommandFramework.cpp (too few lines can be really > factored out without passing many arguments). > > New webrev is here: > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ > > Regards, > > Fred > > On 12/ 8/11 07:26 PM, Paul Hohensee wrote: >> For the hotspot part at >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >> >> Most of my comments are style-related. Nice job on the implementation >> architecture. >> >> In attachListener.cpp: >> >> You might want to delete the first "return JNI_OK;" line, since the code >> under >> HAS_PENDING_EXCEPTION just falls through. >> >> In jmm.h: >> >> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the >> existing declarations. Add a newline just before it on line 322. >> >> >> In diagnosticFramework.hpp: >> >> Fix indenting for lines 63-66, insert blank before "size_t" on line 48. >> >> Hotspot convention is that getter method names don't include a "get_" >> prefix. >> So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). >> Similarly, getters such as is_enabled() should retrieve a field named >> "_is_enabled" >> rather than one named "enabled". You follow the "_is_enabled" convention >> in other places such as GenDCmdArgument. Or you could use enabled() to >> get the value of the _enabled field. >> >> Also generally, I'd use accessor methods in the implementation of more >> complex member methods rather than access the underlying fields directly. >> E.g. in GenDCmdArgument::read_value, I'd use is_set() and >> set_is_set(true), >> (set_is_set() is not actually defined, but should be) rather than >> directly >> accessing _is_set. Though sometimes doing this is too much of a pain >> with fields whose type is a template argument, as in the >> DCmdArggument::parse_value() method in diagnosticArgument.cpp. >> >> For easy readability, it'd be nice to line up field names (the ones >> with an >> _ prefix) at the same column. >> >> On line 200, "instanciated" -> "instantiated" >> >> On line 218, I'd use "heap_allocated" rather than "heap" for the formal >> arg name. >> >> On line 248, you could indent the text to start underneath >> "outputStream". >> I generally find that indenting arguments lines (formal or actual) so >> they line >> up with the first argument position make the code more readable, but I'm >> not >> religious about it. >> >> On line 265, "instanciated" -> "instantiated" >> >> DCmdFactorys are members of a singly-linked list, right? If so, it'd be >> good to >> have a comment to that effect on the declaration of _next. >> >> On line 322, insert a blank before "true". You might fix this in other >> places >> where there's no blank between a comma in an argument list and the >> following parameter value. >> >> >> In diagnosticCommandFramework.cpp: >> >> The code from lines 80-95 and 105-120 is identical. Factor out? >> >> >> In diagnosticArgument.cpp: >> >> On line 41, insert blanks before the actual arguments. (see above >> generic comment) >> >> On line 77, the "if" is indented one space too many. >> >> >> In management.cpp: >> >> I'd be consistent with having or not having a space between "while", >> "if" and "for" >> and the following "(" in this and your other code. Most hotspot code has >> a space. >> >> >> Thanks, >> >> Paul >> >> >> On 12/2/11 8:57 AM, Frederic Parain wrote: >>> Hi All, >>> >>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>> because changes are pretty big and touch all these areas] >>> >>> Here's a framework for issuing diagnostics commands to the JVM. >>> Diagnostic commands are actions executed inside the JVM mainly >>> for monitoring or management purpose. This work has two parts. >>> The first part is in the hotspot repository and contains the >>> framework itself with two diagnostic commands. The second >>> part is in the JDK repository and contains the command line >>> utility to invoke diagnostic commands as well as the >>> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >>> extensions allow a remote client to discover and invoke >>> diagnostic commands using a JMX connection. >>> >>> This changeset only contains two diagnostic commands, more >>> commands will be added in the future, as a standalone effort >>> to improve the monitoring and management services of the >>> JVM, or as part of other projects. >>> >>> Webrevs are here: >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>> >>> Here's a technical description of this work: >>> >>> 1 - The Diagnostic Command Framework >>> 1-1 Overview >>> >>> The diagnostic command framework is fully implemented in native code >>> and relies on the HotSpot's internal exception mechanism. >>> The rational of a pure native implementation is to be able to execute >>> diagnostic commands even in critical situations like an OutOfMemory >>> error. All diagnostic commands are registered in a single list, and two >>> flags control the way a user can interact with them. The "hidden" flag >>> prevents a diagnostic command from appearing in the list of available >>> commands returned by the "help" command. However, it's still possible to >>> get the detailed help message for a hidden command with the "help >>> " syntax (but it requires to know the name of the hidden >>> command). The second flag is "enabled" and it controls if a command can >>> be invoked or not. When listed with the "help" commands, disabled >>> commands appear with a "[disabled]" label in their description. If the >>> user tries to invoke a disabled command, an error message is returned >>> and the command is not run. This error message can be customized on a >>> per command base. The framework just provides these two flags with their >>> semantic, it doesn't provide any policy or mechanism to set or modify >>> these flags. These actions will be delegated to the JVM or special >>> diagnostic commands. >>> >>> 1-2 Implementation >>> >>> All diagnostic commands are implemented as subclasses of the DCmd class >>> defined in services/diagnosticFramework.hpp. Here's the layout of the >>> DCmd class and the list of methods that a new command has to define or >>> overwrite: >>> >>> class DCmd { >>> DCmd(outputStream *output); >>> >>> static const char *get_name(); >>> >>> static const char *get_description(); >>> >>> static const char *get_disabled_message(); >>> >>> static const char *get_impact(); >>> >>> static int get_num_arguments(); >>> >>> virtual void print_help(outputStream* out); >>> >>> virtual void parse(CmdLine* line, char delim, TRAPS); >>> >>> virtual void execute(TRAPS); >>> >>> virtual void reset(TRAPS); >>> >>> virtual void cleanup(); >>> >>> virtual GrowableArray* get_argument_name_array(); >>> >>> virtual GrowableArray* get_argument_info_array(); >>> } >>> >>> A diagnostic command is always instantiated with an outputStream in >>> parameter. This outputStream can point either to a file, a buffer or a >>> socket (see the ostream.hpp file). >>> >>> The get_name() method returns the string that will identify the command >>> (i.e. the string to put on the command line to invoke it). >>> >>> The get_description() methods returns the global description of the >>> command. >>> >>> The get_disabled_message() returns the customized message to return when >>> the command is disabled, without having to instantiate the command. >>> >>> The get_impact() returns a description of the intrusiveness of the >>> diagnostic command on the Java Virtual Machine behavior. The rational >>> for this method is that some diagnostic commands can seriously disrupt >>> the behavior of the Java Virtual Machine (for instance a Thread Dump for >>> an application with several tens of thousands of threads, or a Head Dump >>> with a 40GB+ heap size) and other diagnostic commands have no serious >>> impact on the JVM (for instance, getting the command line arguments or >>> the JVM version). The recommended format for the description is >> level>: [longer description], where the impact level is selected among >>> this list: {low, medium, high}. The optional longer description can >>> provide more specific details like the fact that Thread Dump impact >>> depends on the heap size. >>> >>> The get_num_arguments() returns the number of options/arguments >>> recognized by the diagnostic command. This method is only used by the >>> JMX interface support (see below). >>> >>> The print_help() methods prints a detailed help on the outputStream >>> passed in argument. The detailed help contains the list of all supported >>> options with their type and description. >>> >>> The parse() method is in charge of parsing the command arguments. Each >>> command is free to implement its own argument parser. However, an >>> argument parser framework is provided (see section 1-3) to ease the >>> implementation, but its use is optional. The parse method takes a >>> delimiter character in argument, which is used to mark the limit between >>> two arguments (typically invocation from jcmd will use a space character >>> as a delimiter while invocation from the JVM command line parsing code >>> will use a comma as a delimiter). >>> >>> The execute() method is naturally the one to invoke to get the >>> diagnostic command executed. The parse() and the execute() methods are >>> dissociated, so it's a possible perform the argument parsing in one >>> thread, and delegate the execution to another thread, as long as the >>> diagnostic command doesn't reference thread local variables. The >>> framework allows several instances of the same diagnostic command to be >>> executed in parallel. If for some reasons concurrent executions should >>> not be allowed for a given diagnostic command, this is the >>> responsibility of the diagnostic command implementor to enforce this >>> rule, for instance by protecting the body of the execute() method with a >>> global lock. >>> >>> The reset() method is used to initialize the internal fields of the >>> diagnostic command or to reset the internal fields to their initial >>> value to be able to re-use an already allocated diagnostic command >>> instance. >>> >>> The cleanup() method is used to perform perform cleanup (like freeing of >>> all memory allocated to store internal data). The DCmd extends the >>> ResourceObj class, so when allocated in a ResourceArea, destructors >>> cannot be used to perform cleanup. To ensure that cleanup is performed >>> in all cases, it is recommended to create a DCmdMark instance for each >>> DCmd instance. DCmdMark is a stack allocated object with a pointer to a >>> DCmd instance. When the DCmdMark is destroyed, its destructor calls the >>> cleanup() method of the DCmd instance it points to. If the DCmd instance >>> has been allocated on the C-Heap, the DCmdMark will also free the memory >>> allocated to store the DCmd instance. >>> >>> The get_argument_name_array() and get_argument_info_array() are related >>> to the JMX interface of the diagnostic command framework, so they are >>> described in section 3. >>> >>> 1-3 DCmdParser framework >>> >>> The DCmdParser class is an optional framework to help development of >>> argument parsers. It provides many features required by the diagnostic >>> command framework (generation of the help message or the argument >>> descriptions for the JMX interface) but all these features can easily be >>> re-implemented if a developer decides not to use the DCmdParser >>> framework. >>> >>> The DCmdParser class is relying on the DCmdArgument template. This >>> template must be used to define the different types of argument the >>> parser will have to handle. When a new specialization of the template is >>> done, three methods have to be provided: >>> >>> void parse_value(const char *str,size_t len,TRAPS); >>> void init_value(TRAPS); >>> void destroy_value(); >>> >>> The parse_value() method is used to convert a string into an argument >>> value. The print_value() method is used to display the default value >>> (support for the detailed help message). The init_value() method is used >>> to initialize or reset the argument value. The destroy_value() method is >>> a clean-up method (useful when the argument has allocated some C-Heap >>> memory to store its value and this memory has to be freed before >>> destroying the DCmdArgument instance). >>> >>> The DCmdParser makes a distinction between options and arguments. >>> Options are identified by a key name that must appear on the command >>> line, while argument are identified just by the position of the argument >>> on the command line. Options use the = syntax. In case of >>> boolean options, the '=' part of the syntax can be omitted to set >>> the option to true. Arguments are just sequences characters delimited by >>> a separator character. This separator can be specified at runtime when >>> invoking the diagnostic command framework. If an argument contain a >>> character that could be used as a delimiter, it's possible to enclose >>> the argument between single or double quotes. Options are arguments are >>> instantiated using the same DCmdArgument class but they're registered >>> differently to the DCmdParser. >>> >>> The way to use the DCmdParser is to declare the parser and the >>> option/arguments as fields of the diagnostic command class (which is >>> itself a sub-class of the DCmd class), like this: >>> >>> >>> class EchoDCmd : public DCmd { >>> protected: >>> DCmdParser _dcmdparser; >>> >>> DCmdArgument _required; >>> >>> DCmdArgument _intval; >>> >>> DCmdArgument _boolval; >>> >>> DCmdArgument _stringval; >>> >>> DCmdArgument _first_arg; >>> >>> DCmdArgument _second_arg; >>> >>> DCmdArgument _optional_arg; >>> >>> } >>> >>> The parser and the options/arguments must be initialized before the >>> diagnostic command class, and the options/arguments have to be >>> registered to the parser like this: >>> >>> EchoDCmd(outputStream *output) : DCmd(output), >>> _stringval("-strval","a string argument","STRING",false), >>> >>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>> >>> _intval("-intval","an integer argument","INTEGER",false), >>> >>> _required("-req","a mandatory integer argument","INTEGER",true), >>> >>> _fist_arg("first argument","a string argument","STRING",true), >>> >>> _second_arg("second argument,"an integer argument,"INTEGER",true), >>> >>> _optional_arg("optional argument","an optional string >>> argument","STRING","false") >>> >>> { >>> >>> _dcmdparser.add_dcmd_option(&_stringval) >>> >>> _dcmdparser.add_dcmd_option(&_boolval); >>> >>> _dcmdparser.add_dcmd_option(&_intval); >>> >>> _dcmdparser.add_dcmd_option(&_required); >>> >>> _dcmdparser.add_argument(&_first_arg); >>> >>> _dcmdparser.add_argument(&_second_arg); >>> >>> _dcmdparser.add_argument(&_optional_arg); >>> }; >>> >>> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >>> argument/option to the parser. The option/argument constructor takes the >>> name of the option/argument, its description, a string describing its >>> type and a boolean to specify if the option/argument is mandatory or >>> not. The parser doesn't support option/argument duplicates (having the >>> same name) but the code currently doesn't check for duplicates.The order >>> used to register options has no impact on the parser. However, the order >>> used to register arguments is critical because the parser will use the >>> same order to parse the command line. In the example above, the parser >>> expects to have a first argument of type STRING (parsed using >>> _first_arg), then a second argument of type INTEGER (parsed using >>> _second_arg) and optionally a third parameter of type STRING (parsed >>> using _optional_arg). A mandatory option or argument has to be specify >>> every time the command is invoked. If it is missing, an exception is >>> thrown at the end of the parsing. Optional arguments have to be >>> registered after mandatory arguments. An optional argument will be >>> considered for parsing only if all arguments before it (mandatory or >>> not) have already been used to parse the command line. >>> >>> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >>> instance. The rational for this design is to limit the number of C-heap >>> allocations but also to be able to pre-allocate diagnostic command >>> instances for critical situations. If the process is running out of >>> C-heap space, it's not possible to instantiate new diagnostic commands >>> to troubleshoot the situation. By pre-allocating some diagnostic >>> commands, it will be possible to run them even in this critical >>> situation. Of course, the diagnostic command itself should not try to >>> allocate memory during its execution, this prevents the diagnostic >>> command to use variable length arguments like strings. By nature, >>> pre-allocated diagnostic commands aim to be re-usable, this is the >>> purpose of the reset() method which restores the default status of all >>> arguments. >>> >>> 1-4 Internal invocation >>> >>> Using a diagnostic command from the JVM itself is pretty easy: >>> instantiate the class and invoke the parse() method then the execute() >>> method. A diagnostic command can be instantiated from inside the JVM >>> even it is not registered. This is a difference with the external >>> invocations (from jcmd or JMX) that require the command to be >>> registered. >>> >>> 2 - The JCmd interface >>> >>> Diagnostic commands can also be invoked from outside the JVM process, >>> using the new 'jcmd' utility. The jcmd program uses the attach API >>> to connect to the JVM, send requests and receive results. The >>> jcmd utility must be launched on the same machine than the one running >>> the JVM (its a local tool). Launched without arguments, jcmd displays a >>> list of all JVMs running on the machine. The jcmd source code is in >>> the jdk repository like other existing j* tools. >>> >>> To execute a diagnostic command in a particular JVM, the generic >>> syntax is: >>> >>> jcmd [arguments] >>> >>> The attachListener has been modified to recognized the jcmd requests. >>> When a jcmd request is identified, it is parsed to extract the command >>> name. The JVM performs a look up of this command in a list of registered >>> commands. To be executable by an external request, a diagnostic command >>> has to be registered. The registration is performed with the DCmdFactory >>> class (see services/management.cpp). >>> >>> 3 - The JMX interface >>> >>> The framework provides a JMX based interface to the diagnostic commands. >>> This interface allows remote invocation of diagnostic commands through a >>> JMX connection. >>> >>> 3-1 The interface >>> >>> The information related to the diagnostic commands are accessible >>> through new methods added to the >>> com.sun.management.HotspotDiagnosticMXBean: >>> >>> public List getDiagnosticCommands(); >>> >>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >>> >>> public List getDiagnosticCommandInfo(List >>> command); >>> >>> public List getDiagnosticCommandInfo(); >>> >>> public String execute(String commandLine) throws >>> IllegalArgumentException ; >>> >>> public String execute(String cmd, String... arguments) >>> throws IllegalArgumentException; >>> >>> >>> The getDiagnosticCommands() method returns an array containing the names >>> of the not-hidden registered diagnostic commands. >>> >>> The three getDiagnosticCommandInfo() methods return one or several >>> diagnostic command descriptions using the DiagnosticCommandInfo class. >>> >>> The two execute() methods allow the user the invoke a diagnostic command >>> in different ways. >>> >>> The DiagnosticCommandInfo class is describing a diagnostic command with >>> the following information: >>> >>> public class DiagnosticCommandInfo { >>> >>> public String getName(); >>> >>> public String getDescription(); >>> >>> public String getImpact(); >>> >>> public boolean isEnabled(); >>> >>> public List getArgumentsInfo(); >>> } >>> >>> The getName() method returns the name of the diagnostic command. This >>> name is the one to use in execute() methods to invoke the diagnostic >>> command. >>> >>> The getDescription() method returns a general description of the >>> diagnostic command. >>> >>> The getImpact() method returns a description of the intrusiveness of >>> diagnostic command. >>> >>> The isEnabled() method returns true if the method is enabled, false if >>> it is disabled. A disabled method cannot be executed. >>> >>> The getArgumentsInfo() returns a list of descriptions for the options or >>> arguments recognized by the diagnostic command. Each option/argument is >>> described by a DiagnosticCommandArgumentInfo instance: >>> >>> public class DiagnosticCommandArgumentInfo { >>> >>> public String getName(); >>> >>> public String getDescription(); >>> >>> public String getType(); >>> >>> public String getDefault(); >>> >>> public boolean isMandatory(); >>> >>> public boolean isOption(); >>> >>> public int getPosition(); >>> } >>> >>> If the DiagnosticCommandArgumentInfo instance describes an option, >>> isOption() returns true and getPosition() returns -1. Otherwise, when >>> the DiagnosticCommandArgumentInfo instance describes an argument, >>> isOption() returns false and getPosition() returns the expected position >>> for this argument. The position of an argument is defined relatively to >>> all arguments passed on the command line, options are not considered >>> when defining an argument position. The getDefault() method returns the >>> default value of the argument if a default has been defined, otherwise >>> it returns null. >>> >>> 3-2 The implementation >>> >>> The framework has been designed in a way that prevents diagnostic >>> command developers to worry about the JMX interface. In addition to >>> the methods described in section 1-2, a diagnostic command developer has >>> to provide three methods: >>> >>> int get_num_arguments() >>> >>> which returns the number of option and arguments supported by the >>> command. >>> >>> GrowableArray* get_argument_name_array() >>> >>> which provides the name of the arguments supported by the command. >>> >>> GrowableyArray* get_argument_info_array() >>> >>> which provides the description of each argument with a DCmdArgumentInfo >>> instance. DCmdArgumentInfo is a C++ class used by the framework to >>> generate the sun.com.management.DcmdArgumentInfo instances. This is done >>> automatically and the diagnostic command developer doesn't need to know >>> how to create Java objects from the runtime. >>> >>> 4 - The Diagnostic Commands >>> >>> To avoid name collisions between diagnostic commands coming from >>> different projects, use of a flat name space should be avoided and >>> a more structured organization is recommended. The framework itself >>> doesn't depend on this organization, so it will be a set of rules >>> defining a convention in the way commands are named. >>> >>> Diagnostic commands can easily organized in a hierarchical way, so the >>> template for a command name can be: >>> >>> .[sub-domain.] >>> >>> This template can be extended with sub-sub-domains and so on. >>> >>> A special set of commands without domain will be reserved for the >>> commands related to the diagnostic framework itself, like the "help" >>> command. >>> >>> >>> Thanks, >>> >>> Fred >>> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From paul.hohensee at oracle.com Mon Dec 12 08:11:13 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 12 Dec 2011 11:11:13 -0500 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE6243B.6070200@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> <4EE60FD4.3040404@oracle.com> <4EE6243B.6070200@oracle.com> Message-ID: <4EE627A1.8020004@oracle.com> Looks good. Thanks, Paul On 12/12/11 10:56 AM, Frederic Parain wrote: > Minor updates: > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.04/ > > Fred > > On 12/12/11 03:29 PM, Frederic Parain wrote: >> Hi Paul, >> >> Thank you for the review. >> I've applied all your recommendations except the refactoring >> in diagnosticCommandFramework.cpp (too few lines can be really >> factored out without passing many arguments). >> >> New webrev is here: >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ >> >> Regards, >> >> Fred >> >> On 12/ 8/11 07:26 PM, Paul Hohensee wrote: >>> For the hotspot part at >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>> >>> Most of my comments are style-related. Nice job on the implementation >>> architecture. >>> >>> In attachListener.cpp: >>> >>> You might want to delete the first "return JNI_OK;" line, since the >>> code >>> under >>> HAS_PENDING_EXCEPTION just falls through. >>> >>> In jmm.h: >>> >>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the >>> existing declarations. Add a newline just before it on line 322. >>> >>> >>> In diagnosticFramework.hpp: >>> >>> Fix indenting for lines 63-66, insert blank before "size_t" on line 48. >>> >>> Hotspot convention is that getter method names don't include a "get_" >>> prefix. >>> So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). >>> Similarly, getters such as is_enabled() should retrieve a field named >>> "_is_enabled" >>> rather than one named "enabled". You follow the "_is_enabled" >>> convention >>> in other places such as GenDCmdArgument. Or you could use enabled() to >>> get the value of the _enabled field. >>> >>> Also generally, I'd use accessor methods in the implementation of more >>> complex member methods rather than access the underlying fields >>> directly. >>> E.g. in GenDCmdArgument::read_value, I'd use is_set() and >>> set_is_set(true), >>> (set_is_set() is not actually defined, but should be) rather than >>> directly >>> accessing _is_set. Though sometimes doing this is too much of a pain >>> with fields whose type is a template argument, as in the >>> DCmdArggument::parse_value() method in diagnosticArgument.cpp. >>> >>> For easy readability, it'd be nice to line up field names (the ones >>> with an >>> _ prefix) at the same column. >>> >>> On line 200, "instanciated" -> "instantiated" >>> >>> On line 218, I'd use "heap_allocated" rather than "heap" for the formal >>> arg name. >>> >>> On line 248, you could indent the text to start underneath >>> "outputStream". >>> I generally find that indenting arguments lines (formal or actual) so >>> they line >>> up with the first argument position make the code more readable, but >>> I'm >>> not >>> religious about it. >>> >>> On line 265, "instanciated" -> "instantiated" >>> >>> DCmdFactorys are members of a singly-linked list, right? If so, it'd be >>> good to >>> have a comment to that effect on the declaration of _next. >>> >>> On line 322, insert a blank before "true". You might fix this in other >>> places >>> where there's no blank between a comma in an argument list and the >>> following parameter value. >>> >>> >>> In diagnosticCommandFramework.cpp: >>> >>> The code from lines 80-95 and 105-120 is identical. Factor out? >>> >>> >>> In diagnosticArgument.cpp: >>> >>> On line 41, insert blanks before the actual arguments. (see above >>> generic comment) >>> >>> On line 77, the "if" is indented one space too many. >>> >>> >>> In management.cpp: >>> >>> I'd be consistent with having or not having a space between "while", >>> "if" and "for" >>> and the following "(" in this and your other code. Most hotspot code >>> has >>> a space. >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>> Hi All, >>>> >>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>> because changes are pretty big and touch all these areas] >>>> >>>> Here's a framework for issuing diagnostics commands to the JVM. >>>> Diagnostic commands are actions executed inside the JVM mainly >>>> for monitoring or management purpose. This work has two parts. >>>> The first part is in the hotspot repository and contains the >>>> framework itself with two diagnostic commands. The second >>>> part is in the JDK repository and contains the command line >>>> utility to invoke diagnostic commands as well as the >>>> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >>>> extensions allow a remote client to discover and invoke >>>> diagnostic commands using a JMX connection. >>>> >>>> This changeset only contains two diagnostic commands, more >>>> commands will be added in the future, as a standalone effort >>>> to improve the monitoring and management services of the >>>> JVM, or as part of other projects. >>>> >>>> Webrevs are here: >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>> >>>> Here's a technical description of this work: >>>> >>>> 1 - The Diagnostic Command Framework >>>> 1-1 Overview >>>> >>>> The diagnostic command framework is fully implemented in native code >>>> and relies on the HotSpot's internal exception mechanism. >>>> The rational of a pure native implementation is to be able to execute >>>> diagnostic commands even in critical situations like an OutOfMemory >>>> error. All diagnostic commands are registered in a single list, and >>>> two >>>> flags control the way a user can interact with them. The "hidden" flag >>>> prevents a diagnostic command from appearing in the list of available >>>> commands returned by the "help" command. However, it's still >>>> possible to >>>> get the detailed help message for a hidden command with the "help >>>> " syntax (but it requires to know the name of the hidden >>>> command). The second flag is "enabled" and it controls if a command >>>> can >>>> be invoked or not. When listed with the "help" commands, disabled >>>> commands appear with a "[disabled]" label in their description. If the >>>> user tries to invoke a disabled command, an error message is returned >>>> and the command is not run. This error message can be customized on a >>>> per command base. The framework just provides these two flags with >>>> their >>>> semantic, it doesn't provide any policy or mechanism to set or modify >>>> these flags. These actions will be delegated to the JVM or special >>>> diagnostic commands. >>>> >>>> 1-2 Implementation >>>> >>>> All diagnostic commands are implemented as subclasses of the DCmd >>>> class >>>> defined in services/diagnosticFramework.hpp. Here's the layout of the >>>> DCmd class and the list of methods that a new command has to define or >>>> overwrite: >>>> >>>> class DCmd { >>>> DCmd(outputStream *output); >>>> >>>> static const char *get_name(); >>>> >>>> static const char *get_description(); >>>> >>>> static const char *get_disabled_message(); >>>> >>>> static const char *get_impact(); >>>> >>>> static int get_num_arguments(); >>>> >>>> virtual void print_help(outputStream* out); >>>> >>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>> >>>> virtual void execute(TRAPS); >>>> >>>> virtual void reset(TRAPS); >>>> >>>> virtual void cleanup(); >>>> >>>> virtual GrowableArray* get_argument_name_array(); >>>> >>>> virtual GrowableArray* get_argument_info_array(); >>>> } >>>> >>>> A diagnostic command is always instantiated with an outputStream in >>>> parameter. This outputStream can point either to a file, a buffer or a >>>> socket (see the ostream.hpp file). >>>> >>>> The get_name() method returns the string that will identify the >>>> command >>>> (i.e. the string to put on the command line to invoke it). >>>> >>>> The get_description() methods returns the global description of the >>>> command. >>>> >>>> The get_disabled_message() returns the customized message to return >>>> when >>>> the command is disabled, without having to instantiate the command. >>>> >>>> The get_impact() returns a description of the intrusiveness of the >>>> diagnostic command on the Java Virtual Machine behavior. The rational >>>> for this method is that some diagnostic commands can seriously disrupt >>>> the behavior of the Java Virtual Machine (for instance a Thread >>>> Dump for >>>> an application with several tens of thousands of threads, or a Head >>>> Dump >>>> with a 40GB+ heap size) and other diagnostic commands have no serious >>>> impact on the JVM (for instance, getting the command line arguments or >>>> the JVM version). The recommended format for the description is >>>> >>> level>: [longer description], where the impact level is selected among >>>> this list: {low, medium, high}. The optional longer description can >>>> provide more specific details like the fact that Thread Dump impact >>>> depends on the heap size. >>>> >>>> The get_num_arguments() returns the number of options/arguments >>>> recognized by the diagnostic command. This method is only used by the >>>> JMX interface support (see below). >>>> >>>> The print_help() methods prints a detailed help on the outputStream >>>> passed in argument. The detailed help contains the list of all >>>> supported >>>> options with their type and description. >>>> >>>> The parse() method is in charge of parsing the command arguments. Each >>>> command is free to implement its own argument parser. However, an >>>> argument parser framework is provided (see section 1-3) to ease the >>>> implementation, but its use is optional. The parse method takes a >>>> delimiter character in argument, which is used to mark the limit >>>> between >>>> two arguments (typically invocation from jcmd will use a space >>>> character >>>> as a delimiter while invocation from the JVM command line parsing code >>>> will use a comma as a delimiter). >>>> >>>> The execute() method is naturally the one to invoke to get the >>>> diagnostic command executed. The parse() and the execute() methods are >>>> dissociated, so it's a possible perform the argument parsing in one >>>> thread, and delegate the execution to another thread, as long as the >>>> diagnostic command doesn't reference thread local variables. The >>>> framework allows several instances of the same diagnostic command >>>> to be >>>> executed in parallel. If for some reasons concurrent executions should >>>> not be allowed for a given diagnostic command, this is the >>>> responsibility of the diagnostic command implementor to enforce this >>>> rule, for instance by protecting the body of the execute() method >>>> with a >>>> global lock. >>>> >>>> The reset() method is used to initialize the internal fields of the >>>> diagnostic command or to reset the internal fields to their initial >>>> value to be able to re-use an already allocated diagnostic command >>>> instance. >>>> >>>> The cleanup() method is used to perform perform cleanup (like >>>> freeing of >>>> all memory allocated to store internal data). The DCmd extends the >>>> ResourceObj class, so when allocated in a ResourceArea, destructors >>>> cannot be used to perform cleanup. To ensure that cleanup is performed >>>> in all cases, it is recommended to create a DCmdMark instance for each >>>> DCmd instance. DCmdMark is a stack allocated object with a pointer >>>> to a >>>> DCmd instance. When the DCmdMark is destroyed, its destructor calls >>>> the >>>> cleanup() method of the DCmd instance it points to. If the DCmd >>>> instance >>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>> memory >>>> allocated to store the DCmd instance. >>>> >>>> The get_argument_name_array() and get_argument_info_array() are >>>> related >>>> to the JMX interface of the diagnostic command framework, so they are >>>> described in section 3. >>>> >>>> 1-3 DCmdParser framework >>>> >>>> The DCmdParser class is an optional framework to help development of >>>> argument parsers. It provides many features required by the diagnostic >>>> command framework (generation of the help message or the argument >>>> descriptions for the JMX interface) but all these features can >>>> easily be >>>> re-implemented if a developer decides not to use the DCmdParser >>>> framework. >>>> >>>> The DCmdParser class is relying on the DCmdArgument template. This >>>> template must be used to define the different types of argument the >>>> parser will have to handle. When a new specialization of the >>>> template is >>>> done, three methods have to be provided: >>>> >>>> void parse_value(const char *str,size_t len,TRAPS); >>>> void init_value(TRAPS); >>>> void destroy_value(); >>>> >>>> The parse_value() method is used to convert a string into an argument >>>> value. The print_value() method is used to display the default value >>>> (support for the detailed help message). The init_value() method is >>>> used >>>> to initialize or reset the argument value. The destroy_value() >>>> method is >>>> a clean-up method (useful when the argument has allocated some C-Heap >>>> memory to store its value and this memory has to be freed before >>>> destroying the DCmdArgument instance). >>>> >>>> The DCmdParser makes a distinction between options and arguments. >>>> Options are identified by a key name that must appear on the command >>>> line, while argument are identified just by the position of the >>>> argument >>>> on the command line. Options use the = syntax. In case of >>>> boolean options, the '=' part of the syntax can be omitted >>>> to set >>>> the option to true. Arguments are just sequences characters >>>> delimited by >>>> a separator character. This separator can be specified at runtime when >>>> invoking the diagnostic command framework. If an argument contain a >>>> character that could be used as a delimiter, it's possible to enclose >>>> the argument between single or double quotes. Options are arguments >>>> are >>>> instantiated using the same DCmdArgument class but they're registered >>>> differently to the DCmdParser. >>>> >>>> The way to use the DCmdParser is to declare the parser and the >>>> option/arguments as fields of the diagnostic command class (which is >>>> itself a sub-class of the DCmd class), like this: >>>> >>>> >>>> class EchoDCmd : public DCmd { >>>> protected: >>>> DCmdParser _dcmdparser; >>>> >>>> DCmdArgument _required; >>>> >>>> DCmdArgument _intval; >>>> >>>> DCmdArgument _boolval; >>>> >>>> DCmdArgument _stringval; >>>> >>>> DCmdArgument _first_arg; >>>> >>>> DCmdArgument _second_arg; >>>> >>>> DCmdArgument _optional_arg; >>>> >>>> } >>>> >>>> The parser and the options/arguments must be initialized before the >>>> diagnostic command class, and the options/arguments have to be >>>> registered to the parser like this: >>>> >>>> EchoDCmd(outputStream *output) : DCmd(output), >>>> _stringval("-strval","a string argument","STRING",false), >>>> >>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>> >>>> _intval("-intval","an integer argument","INTEGER",false), >>>> >>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>> >>>> _fist_arg("first argument","a string argument","STRING",true), >>>> >>>> _second_arg("second argument,"an integer argument,"INTEGER",true), >>>> >>>> _optional_arg("optional argument","an optional string >>>> argument","STRING","false") >>>> >>>> { >>>> >>>> _dcmdparser.add_dcmd_option(&_stringval) >>>> >>>> _dcmdparser.add_dcmd_option(&_boolval); >>>> >>>> _dcmdparser.add_dcmd_option(&_intval); >>>> >>>> _dcmdparser.add_dcmd_option(&_required); >>>> >>>> _dcmdparser.add_argument(&_first_arg); >>>> >>>> _dcmdparser.add_argument(&_second_arg); >>>> >>>> _dcmdparser.add_argument(&_optional_arg); >>>> }; >>>> >>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >>>> argument/option to the parser. The option/argument constructor >>>> takes the >>>> name of the option/argument, its description, a string describing its >>>> type and a boolean to specify if the option/argument is mandatory or >>>> not. The parser doesn't support option/argument duplicates (having the >>>> same name) but the code currently doesn't check for duplicates.The >>>> order >>>> used to register options has no impact on the parser. However, the >>>> order >>>> used to register arguments is critical because the parser will use the >>>> same order to parse the command line. In the example above, the parser >>>> expects to have a first argument of type STRING (parsed using >>>> _first_arg), then a second argument of type INTEGER (parsed using >>>> _second_arg) and optionally a third parameter of type STRING (parsed >>>> using _optional_arg). A mandatory option or argument has to be specify >>>> every time the command is invoked. If it is missing, an exception is >>>> thrown at the end of the parsing. Optional arguments have to be >>>> registered after mandatory arguments. An optional argument will be >>>> considered for parsing only if all arguments before it (mandatory or >>>> not) have already been used to parse the command line. >>>> >>>> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >>>> instance. The rational for this design is to limit the number of >>>> C-heap >>>> allocations but also to be able to pre-allocate diagnostic command >>>> instances for critical situations. If the process is running out of >>>> C-heap space, it's not possible to instantiate new diagnostic commands >>>> to troubleshoot the situation. By pre-allocating some diagnostic >>>> commands, it will be possible to run them even in this critical >>>> situation. Of course, the diagnostic command itself should not try to >>>> allocate memory during its execution, this prevents the diagnostic >>>> command to use variable length arguments like strings. By nature, >>>> pre-allocated diagnostic commands aim to be re-usable, this is the >>>> purpose of the reset() method which restores the default status of all >>>> arguments. >>>> >>>> 1-4 Internal invocation >>>> >>>> Using a diagnostic command from the JVM itself is pretty easy: >>>> instantiate the class and invoke the parse() method then the execute() >>>> method. A diagnostic command can be instantiated from inside the JVM >>>> even it is not registered. This is a difference with the external >>>> invocations (from jcmd or JMX) that require the command to be >>>> registered. >>>> >>>> 2 - The JCmd interface >>>> >>>> Diagnostic commands can also be invoked from outside the JVM process, >>>> using the new 'jcmd' utility. The jcmd program uses the attach API >>>> to connect to the JVM, send requests and receive results. The >>>> jcmd utility must be launched on the same machine than the one running >>>> the JVM (its a local tool). Launched without arguments, jcmd >>>> displays a >>>> list of all JVMs running on the machine. The jcmd source code is in >>>> the jdk repository like other existing j* tools. >>>> >>>> To execute a diagnostic command in a particular JVM, the generic >>>> syntax is: >>>> >>>> jcmd [arguments] >>>> >>>> The attachListener has been modified to recognized the jcmd requests. >>>> When a jcmd request is identified, it is parsed to extract the command >>>> name. The JVM performs a look up of this command in a list of >>>> registered >>>> commands. To be executable by an external request, a diagnostic >>>> command >>>> has to be registered. The registration is performed with the >>>> DCmdFactory >>>> class (see services/management.cpp). >>>> >>>> 3 - The JMX interface >>>> >>>> The framework provides a JMX based interface to the diagnostic >>>> commands. >>>> This interface allows remote invocation of diagnostic commands >>>> through a >>>> JMX connection. >>>> >>>> 3-1 The interface >>>> >>>> The information related to the diagnostic commands are accessible >>>> through new methods added to the >>>> com.sun.management.HotspotDiagnosticMXBean: >>>> >>>> public List getDiagnosticCommands(); >>>> >>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >>>> >>>> public List >>>> getDiagnosticCommandInfo(List >>>> command); >>>> >>>> public List getDiagnosticCommandInfo(); >>>> >>>> public String execute(String commandLine) throws >>>> IllegalArgumentException ; >>>> >>>> public String execute(String cmd, String... arguments) >>>> throws IllegalArgumentException; >>>> >>>> >>>> The getDiagnosticCommands() method returns an array containing the >>>> names >>>> of the not-hidden registered diagnostic commands. >>>> >>>> The three getDiagnosticCommandInfo() methods return one or several >>>> diagnostic command descriptions using the DiagnosticCommandInfo class. >>>> >>>> The two execute() methods allow the user the invoke a diagnostic >>>> command >>>> in different ways. >>>> >>>> The DiagnosticCommandInfo class is describing a diagnostic command >>>> with >>>> the following information: >>>> >>>> public class DiagnosticCommandInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getImpact(); >>>> >>>> public boolean isEnabled(); >>>> >>>> public List getArgumentsInfo(); >>>> } >>>> >>>> The getName() method returns the name of the diagnostic command. This >>>> name is the one to use in execute() methods to invoke the diagnostic >>>> command. >>>> >>>> The getDescription() method returns a general description of the >>>> diagnostic command. >>>> >>>> The getImpact() method returns a description of the intrusiveness of >>>> diagnostic command. >>>> >>>> The isEnabled() method returns true if the method is enabled, false if >>>> it is disabled. A disabled method cannot be executed. >>>> >>>> The getArgumentsInfo() returns a list of descriptions for the >>>> options or >>>> arguments recognized by the diagnostic command. Each >>>> option/argument is >>>> described by a DiagnosticCommandArgumentInfo instance: >>>> >>>> public class DiagnosticCommandArgumentInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getType(); >>>> >>>> public String getDefault(); >>>> >>>> public boolean isMandatory(); >>>> >>>> public boolean isOption(); >>>> >>>> public int getPosition(); >>>> } >>>> >>>> If the DiagnosticCommandArgumentInfo instance describes an option, >>>> isOption() returns true and getPosition() returns -1. Otherwise, when >>>> the DiagnosticCommandArgumentInfo instance describes an argument, >>>> isOption() returns false and getPosition() returns the expected >>>> position >>>> for this argument. The position of an argument is defined >>>> relatively to >>>> all arguments passed on the command line, options are not considered >>>> when defining an argument position. The getDefault() method returns >>>> the >>>> default value of the argument if a default has been defined, otherwise >>>> it returns null. >>>> >>>> 3-2 The implementation >>>> >>>> The framework has been designed in a way that prevents diagnostic >>>> command developers to worry about the JMX interface. In addition to >>>> the methods described in section 1-2, a diagnostic command >>>> developer has >>>> to provide three methods: >>>> >>>> int get_num_arguments() >>>> >>>> which returns the number of option and arguments supported by the >>>> command. >>>> >>>> GrowableArray* get_argument_name_array() >>>> >>>> which provides the name of the arguments supported by the command. >>>> >>>> GrowableyArray* get_argument_info_array() >>>> >>>> which provides the description of each argument with a >>>> DCmdArgumentInfo >>>> instance. DCmdArgumentInfo is a C++ class used by the framework to >>>> generate the sun.com.management.DcmdArgumentInfo instances. This is >>>> done >>>> automatically and the diagnostic command developer doesn't need to >>>> know >>>> how to create Java objects from the runtime. >>>> >>>> 4 - The Diagnostic Commands >>>> >>>> To avoid name collisions between diagnostic commands coming from >>>> different projects, use of a flat name space should be avoided and >>>> a more structured organization is recommended. The framework itself >>>> doesn't depend on this organization, so it will be a set of rules >>>> defining a convention in the way commands are named. >>>> >>>> Diagnostic commands can easily organized in a hierarchical way, so the >>>> template for a command name can be: >>>> >>>> .[sub-domain.] >>>> >>>> This template can be extended with sub-sub-domains and so on. >>>> >>>> A special set of commands without domain will be reserved for the >>>> commands related to the diagnostic framework itself, like the "help" >>>> command. >>>> >>>> >>>> Thanks, >>>> >>>> Fred >>>> >> > From vladimir.danushevsky at oracle.com Mon Dec 12 08:23:26 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Mon, 12 Dec 2011 16:23:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 20 new changesets Message-ID: <20111212162410.EED7047673@hg.openjdk.java.net> Changeset: e8fdaf4a66cb Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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/hotspot-rt/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-rt/hotspot/rev/e37aedaedccd Merge Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/hotspot/rev/e9b91fd07263 Merge From mandy.chung at oracle.com Mon Dec 12 09:35:49 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Dec 2011 09:35:49 -0800 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE61040.5040704@oracle.com> References: <4ED8D93A.5050600@oracle.com 4EE10139.8020905@oracle.com> <34278e49-efbc-4370-ab36-a50331a9ff65@default> <4EE61040.5040704@oracle.com> Message-ID: <4EE63B75.2000309@oracle.com> On 12/12/2011 6:31 AM, Frederic Parain wrote: > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.03/ The jdk change looks okay to me. Mandy From john.cuthbertson at oracle.com Mon Dec 12 11:48:09 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 12 Dec 2011 11:48:09 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: <4EE65A79.3050809@oracle.com> Hi Kirk, Can you please try monaco.us.oracle.com? I believe the link is supplied by the webrev tool automatically when it sees the CR# in the mercurial queue patch. It could be that my path references an old version. Thanks, JohnC On 12/09/11 23:59, Charles K Pepperdine wrote: > Hi John, > > The link http://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. > > Regards, > Kirk > > > On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: > > >> Hi Everyone, >> >> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >> >> Thanks, >> >> JohnC >> >> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >> >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >>> >>> Summary: >>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >>> >>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >>> >>> Thanks, >>> >>> JohnC >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111212/897d7ad5/attachment.html From john.cuthbertson at oracle.com Mon Dec 12 12:06:50 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 12 Dec 2011 12:06:50 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: <4EE65EDA.80300@oracle.com> Hi Ramki, Thanks for looking at the code changes and for the suggestions. Extending the os API is a good idea. Not sure about the name though - how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp already has an internal monotonic version of javaTimeMillis() so there are alternatives to using javaTimeNanos() in the implementation. Thanks for the heads up about the other CR. I'll check. Thanks, JohnC On 12/11/11 01:32, Srinivas Ramakrishna wrote: > Hi John -- Looks fine. Two minor comments: > > (1) by defining an os::javaTimeNanosInMillis() you may be able to > consolidate the divide by NANOS_IN_MILLISEC to one place instead of it > appearing at each use. > (2) you might consolidate the commentary about monotonicity into > os::javaTimeNanosInMillis(), then at each client simly say "Protect > against possible nonmonotonicity" > > That will reduce the number of repeated lines while still providing > all of the commentary in all the relevant places. (By the way, you > might want to > check if there;s another CR with the same content which might be > closed as a dup of this... just a very vague recollection.) > > reviewed. > -- ramki (opendjk: ysr) > > On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson > > wrote: > > Hi Everyone, > > I have updated the comments based upon feedback from David Holmes. > A new webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ > > > Thanks, > > JohnC > > > On 12/7/2011 9:59 AM, John Cuthbertson wrote: > > Hi Everyone, > > Can I have a couple of volunteers review the changes for this > CR? The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.0/ > . > > Summary: > I replaced the calls to os::javaTimeMillis() in the GC where > we expect monotonicity with calls os::javaTimeNanos(), > converting the result to milliseconds. os::javaTimeNanos(), at > least on some configurations, does guarantee monotonicity and > so is a better alternative. The changes in the os_<*> files > are to make use of the named conversion constants I > added/moved to globalDefinitions.hpp - we seemed to have > multiple names for the same two constants. > > Testing: GC test suite on solaris and Linux, NSK tests on > solaris, and jprt. > > Thanks, > > JohnC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111212/d56512a2/attachment.html From daniel.daugherty at oracle.com Mon Dec 12 12:08:45 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 12 Dec 2011 13:08:45 -0700 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE6243B.6070200@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> <4EE60FD4.3040404@oracle.com> <4EE6243B.6070200@oracle.com> Message-ID: <4EE65F4D.7040109@oracle.com> On 12/12/11 8:56 AM, Frederic Parain wrote: > Minor updates: > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.04/ src/share/vm/services/attachListener.cpp The new include should be in alpha-order (between lines 36 & 37). I'm pretty sure that's the new style... Block comment on lines 152-155 should be in '//' style and not in JavaDoc style (/** ... */) src/share/vm/services/jmm.h lines 192-208 - HotSpot convention is to mimic the existing style in a file. For these structs, the field names should all be lined up (see 181-188 for an example). src/share/vm/services/management.cpp line 2126 calls JNIHandles::make_local(), but this is a JVM_ENTRY wrapped function which means it depends on VM_ENTRY_BASE which has a HandleMarkCleaner in it. Since this is a make_local() call, won't the local JNIHandle get scrubbed on the way back to the caller? line 2231 also calls JNIHandles::make_local() from a JVM_ENTRY wrapped function. Same local JNIHandle scrubbing issue? src/share/vm/services/diagnosticArgument.hpp lines 45-50 - too much indent; should be 4 spaces src/share/vm/services/diagnosticArgument.cpp HotSpot style is generally 'if (' and not 'if(' src/share/vm/services/diagnosticCommand.hpp lines 28-36 - includes should be in alpha order lines 44, 64 - Parameter defaults in new code is generally frowned upon in HotSpot. They're used when adding a parameter to existing code to avoid changing existing calls where the default is OK. (I happen to disagree with that last part and I think that all calls should be updated just to make sure your reviewers see all uses, but I'm just one cranky voice... :-)) src/share/vm/services/diagnosticCommand.cpp line 28: includes should be in alpha order lines 31-33 - should be some indent here line 74: It would be useful to display the command that can't be found: help foo Help unavailable: 'foo': No such command or something like that. line 101: just FYI, a ResourceMark without a Thread parameter can be expensive. Not an issue for HelpDCmd::num_arguments(). line 103: HotSpot style is generally 'if (' and not 'if(' src/share/vm/services/diagnosticFramework.hpp line 38: typo: 'provides method' -> 'provides methods' line 40: typo: 'keywor' -> 'keyword' lines 43-46 - fields nicely indented here, but not in other new header files. Any particular reason? lines 48, 154, 218, 286, 324 - Parameter defaults again. line 55: is_stop should be: return !is_empty() && strncmp("stop", _cmd, _cmd_len) == 0; !strncmp() is frowned upon and spaces between params line 82 - returns a local variable; that shouldn't work. line 155: missing a space after '=' lines 256, 258: HotSpot style is generally 'if (' and not 'if(' line 304: typo: 'DCmdFActory' -> 'DCmdFactory' line 306: typo: 'command to be executed' -> 'command from being executed' src/share/vm/services/diagnosticFramework.cpp line 55: _cmd_len = cmd_end - line; This length includes any leading white space that was skipped on lines 42-44. It seems odd that '_cmd' points to the first non-whitespace in the command, but _cmd_len includes the leading white space. If you change the _cmd_len calculation, then you have to also change the logic on line 58 so that args_len is also not too long. lines 79, 104: typo: 'simple' -> 'single' line 318 - what is 'idx' used for? line 367: HotSpot style is generally 'if (' and not 'if(' lines 371, 372, 380, 403, 416: space after comma Dan > > Fred > > On 12/12/11 03:29 PM, Frederic Parain wrote: >> Hi Paul, >> >> Thank you for the review. >> I've applied all your recommendations except the refactoring >> in diagnosticCommandFramework.cpp (too few lines can be really >> factored out without passing many arguments). >> >> New webrev is here: >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ >> >> Regards, >> >> Fred >> >> On 12/ 8/11 07:26 PM, Paul Hohensee wrote: >>> For the hotspot part at >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>> >>> Most of my comments are style-related. Nice job on the implementation >>> architecture. >>> >>> In attachListener.cpp: >>> >>> You might want to delete the first "return JNI_OK;" line, since the >>> code >>> under >>> HAS_PENDING_EXCEPTION just falls through. >>> >>> In jmm.h: >>> >>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the >>> existing declarations. Add a newline just before it on line 322. >>> >>> >>> In diagnosticFramework.hpp: >>> >>> Fix indenting for lines 63-66, insert blank before "size_t" on line 48. >>> >>> Hotspot convention is that getter method names don't include a "get_" >>> prefix. >>> So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). >>> Similarly, getters such as is_enabled() should retrieve a field named >>> "_is_enabled" >>> rather than one named "enabled". You follow the "_is_enabled" >>> convention >>> in other places such as GenDCmdArgument. Or you could use enabled() to >>> get the value of the _enabled field. >>> >>> Also generally, I'd use accessor methods in the implementation of more >>> complex member methods rather than access the underlying fields >>> directly. >>> E.g. in GenDCmdArgument::read_value, I'd use is_set() and >>> set_is_set(true), >>> (set_is_set() is not actually defined, but should be) rather than >>> directly >>> accessing _is_set. Though sometimes doing this is too much of a pain >>> with fields whose type is a template argument, as in the >>> DCmdArggument::parse_value() method in diagnosticArgument.cpp. >>> >>> For easy readability, it'd be nice to line up field names (the ones >>> with an >>> _ prefix) at the same column. >>> >>> On line 200, "instanciated" -> "instantiated" >>> >>> On line 218, I'd use "heap_allocated" rather than "heap" for the formal >>> arg name. >>> >>> On line 248, you could indent the text to start underneath >>> "outputStream". >>> I generally find that indenting arguments lines (formal or actual) so >>> they line >>> up with the first argument position make the code more readable, but >>> I'm >>> not >>> religious about it. >>> >>> On line 265, "instanciated" -> "instantiated" >>> >>> DCmdFactorys are members of a singly-linked list, right? If so, it'd be >>> good to >>> have a comment to that effect on the declaration of _next. >>> >>> On line 322, insert a blank before "true". You might fix this in other >>> places >>> where there's no blank between a comma in an argument list and the >>> following parameter value. >>> >>> >>> In diagnosticCommandFramework.cpp: >>> >>> The code from lines 80-95 and 105-120 is identical. Factor out? >>> >>> >>> In diagnosticArgument.cpp: >>> >>> On line 41, insert blanks before the actual arguments. (see above >>> generic comment) >>> >>> On line 77, the "if" is indented one space too many. >>> >>> >>> In management.cpp: >>> >>> I'd be consistent with having or not having a space between "while", >>> "if" and "for" >>> and the following "(" in this and your other code. Most hotspot code >>> has >>> a space. >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>> Hi All, >>>> >>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>> because changes are pretty big and touch all these areas] >>>> >>>> Here's a framework for issuing diagnostics commands to the JVM. >>>> Diagnostic commands are actions executed inside the JVM mainly >>>> for monitoring or management purpose. This work has two parts. >>>> The first part is in the hotspot repository and contains the >>>> framework itself with two diagnostic commands. The second >>>> part is in the JDK repository and contains the command line >>>> utility to invoke diagnostic commands as well as the >>>> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >>>> extensions allow a remote client to discover and invoke >>>> diagnostic commands using a JMX connection. >>>> >>>> This changeset only contains two diagnostic commands, more >>>> commands will be added in the future, as a standalone effort >>>> to improve the monitoring and management services of the >>>> JVM, or as part of other projects. >>>> >>>> Webrevs are here: >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>> >>>> Here's a technical description of this work: >>>> >>>> 1 - The Diagnostic Command Framework >>>> 1-1 Overview >>>> >>>> The diagnostic command framework is fully implemented in native code >>>> and relies on the HotSpot's internal exception mechanism. >>>> The rational of a pure native implementation is to be able to execute >>>> diagnostic commands even in critical situations like an OutOfMemory >>>> error. All diagnostic commands are registered in a single list, and >>>> two >>>> flags control the way a user can interact with them. The "hidden" flag >>>> prevents a diagnostic command from appearing in the list of available >>>> commands returned by the "help" command. However, it's still >>>> possible to >>>> get the detailed help message for a hidden command with the "help >>>> " syntax (but it requires to know the name of the hidden >>>> command). The second flag is "enabled" and it controls if a command >>>> can >>>> be invoked or not. When listed with the "help" commands, disabled >>>> commands appear with a "[disabled]" label in their description. If the >>>> user tries to invoke a disabled command, an error message is returned >>>> and the command is not run. This error message can be customized on a >>>> per command base. The framework just provides these two flags with >>>> their >>>> semantic, it doesn't provide any policy or mechanism to set or modify >>>> these flags. These actions will be delegated to the JVM or special >>>> diagnostic commands. >>>> >>>> 1-2 Implementation >>>> >>>> All diagnostic commands are implemented as subclasses of the DCmd >>>> class >>>> defined in services/diagnosticFramework.hpp. Here's the layout of the >>>> DCmd class and the list of methods that a new command has to define or >>>> overwrite: >>>> >>>> class DCmd { >>>> DCmd(outputStream *output); >>>> >>>> static const char *get_name(); >>>> >>>> static const char *get_description(); >>>> >>>> static const char *get_disabled_message(); >>>> >>>> static const char *get_impact(); >>>> >>>> static int get_num_arguments(); >>>> >>>> virtual void print_help(outputStream* out); >>>> >>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>> >>>> virtual void execute(TRAPS); >>>> >>>> virtual void reset(TRAPS); >>>> >>>> virtual void cleanup(); >>>> >>>> virtual GrowableArray* get_argument_name_array(); >>>> >>>> virtual GrowableArray* get_argument_info_array(); >>>> } >>>> >>>> A diagnostic command is always instantiated with an outputStream in >>>> parameter. This outputStream can point either to a file, a buffer or a >>>> socket (see the ostream.hpp file). >>>> >>>> The get_name() method returns the string that will identify the >>>> command >>>> (i.e. the string to put on the command line to invoke it). >>>> >>>> The get_description() methods returns the global description of the >>>> command. >>>> >>>> The get_disabled_message() returns the customized message to return >>>> when >>>> the command is disabled, without having to instantiate the command. >>>> >>>> The get_impact() returns a description of the intrusiveness of the >>>> diagnostic command on the Java Virtual Machine behavior. The rational >>>> for this method is that some diagnostic commands can seriously disrupt >>>> the behavior of the Java Virtual Machine (for instance a Thread >>>> Dump for >>>> an application with several tens of thousands of threads, or a Head >>>> Dump >>>> with a 40GB+ heap size) and other diagnostic commands have no serious >>>> impact on the JVM (for instance, getting the command line arguments or >>>> the JVM version). The recommended format for the description is >>>> >>> level>: [longer description], where the impact level is selected among >>>> this list: {low, medium, high}. The optional longer description can >>>> provide more specific details like the fact that Thread Dump impact >>>> depends on the heap size. >>>> >>>> The get_num_arguments() returns the number of options/arguments >>>> recognized by the diagnostic command. This method is only used by the >>>> JMX interface support (see below). >>>> >>>> The print_help() methods prints a detailed help on the outputStream >>>> passed in argument. The detailed help contains the list of all >>>> supported >>>> options with their type and description. >>>> >>>> The parse() method is in charge of parsing the command arguments. Each >>>> command is free to implement its own argument parser. However, an >>>> argument parser framework is provided (see section 1-3) to ease the >>>> implementation, but its use is optional. The parse method takes a >>>> delimiter character in argument, which is used to mark the limit >>>> between >>>> two arguments (typically invocation from jcmd will use a space >>>> character >>>> as a delimiter while invocation from the JVM command line parsing code >>>> will use a comma as a delimiter). >>>> >>>> The execute() method is naturally the one to invoke to get the >>>> diagnostic command executed. The parse() and the execute() methods are >>>> dissociated, so it's a possible perform the argument parsing in one >>>> thread, and delegate the execution to another thread, as long as the >>>> diagnostic command doesn't reference thread local variables. The >>>> framework allows several instances of the same diagnostic command >>>> to be >>>> executed in parallel. If for some reasons concurrent executions should >>>> not be allowed for a given diagnostic command, this is the >>>> responsibility of the diagnostic command implementor to enforce this >>>> rule, for instance by protecting the body of the execute() method >>>> with a >>>> global lock. >>>> >>>> The reset() method is used to initialize the internal fields of the >>>> diagnostic command or to reset the internal fields to their initial >>>> value to be able to re-use an already allocated diagnostic command >>>> instance. >>>> >>>> The cleanup() method is used to perform perform cleanup (like >>>> freeing of >>>> all memory allocated to store internal data). The DCmd extends the >>>> ResourceObj class, so when allocated in a ResourceArea, destructors >>>> cannot be used to perform cleanup. To ensure that cleanup is performed >>>> in all cases, it is recommended to create a DCmdMark instance for each >>>> DCmd instance. DCmdMark is a stack allocated object with a pointer >>>> to a >>>> DCmd instance. When the DCmdMark is destroyed, its destructor calls >>>> the >>>> cleanup() method of the DCmd instance it points to. If the DCmd >>>> instance >>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>> memory >>>> allocated to store the DCmd instance. >>>> >>>> The get_argument_name_array() and get_argument_info_array() are >>>> related >>>> to the JMX interface of the diagnostic command framework, so they are >>>> described in section 3. >>>> >>>> 1-3 DCmdParser framework >>>> >>>> The DCmdParser class is an optional framework to help development of >>>> argument parsers. It provides many features required by the diagnostic >>>> command framework (generation of the help message or the argument >>>> descriptions for the JMX interface) but all these features can >>>> easily be >>>> re-implemented if a developer decides not to use the DCmdParser >>>> framework. >>>> >>>> The DCmdParser class is relying on the DCmdArgument template. This >>>> template must be used to define the different types of argument the >>>> parser will have to handle. When a new specialization of the >>>> template is >>>> done, three methods have to be provided: >>>> >>>> void parse_value(const char *str,size_t len,TRAPS); >>>> void init_value(TRAPS); >>>> void destroy_value(); >>>> >>>> The parse_value() method is used to convert a string into an argument >>>> value. The print_value() method is used to display the default value >>>> (support for the detailed help message). The init_value() method is >>>> used >>>> to initialize or reset the argument value. The destroy_value() >>>> method is >>>> a clean-up method (useful when the argument has allocated some C-Heap >>>> memory to store its value and this memory has to be freed before >>>> destroying the DCmdArgument instance). >>>> >>>> The DCmdParser makes a distinction between options and arguments. >>>> Options are identified by a key name that must appear on the command >>>> line, while argument are identified just by the position of the >>>> argument >>>> on the command line. Options use the = syntax. In case of >>>> boolean options, the '=' part of the syntax can be omitted >>>> to set >>>> the option to true. Arguments are just sequences characters >>>> delimited by >>>> a separator character. This separator can be specified at runtime when >>>> invoking the diagnostic command framework. If an argument contain a >>>> character that could be used as a delimiter, it's possible to enclose >>>> the argument between single or double quotes. Options are arguments >>>> are >>>> instantiated using the same DCmdArgument class but they're registered >>>> differently to the DCmdParser. >>>> >>>> The way to use the DCmdParser is to declare the parser and the >>>> option/arguments as fields of the diagnostic command class (which is >>>> itself a sub-class of the DCmd class), like this: >>>> >>>> >>>> class EchoDCmd : public DCmd { >>>> protected: >>>> DCmdParser _dcmdparser; >>>> >>>> DCmdArgument _required; >>>> >>>> DCmdArgument _intval; >>>> >>>> DCmdArgument _boolval; >>>> >>>> DCmdArgument _stringval; >>>> >>>> DCmdArgument _first_arg; >>>> >>>> DCmdArgument _second_arg; >>>> >>>> DCmdArgument _optional_arg; >>>> >>>> } >>>> >>>> The parser and the options/arguments must be initialized before the >>>> diagnostic command class, and the options/arguments have to be >>>> registered to the parser like this: >>>> >>>> EchoDCmd(outputStream *output) : DCmd(output), >>>> _stringval("-strval","a string argument","STRING",false), >>>> >>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>> >>>> _intval("-intval","an integer argument","INTEGER",false), >>>> >>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>> >>>> _fist_arg("first argument","a string argument","STRING",true), >>>> >>>> _second_arg("second argument,"an integer argument,"INTEGER",true), >>>> >>>> _optional_arg("optional argument","an optional string >>>> argument","STRING","false") >>>> >>>> { >>>> >>>> _dcmdparser.add_dcmd_option(&_stringval) >>>> >>>> _dcmdparser.add_dcmd_option(&_boolval); >>>> >>>> _dcmdparser.add_dcmd_option(&_intval); >>>> >>>> _dcmdparser.add_dcmd_option(&_required); >>>> >>>> _dcmdparser.add_argument(&_first_arg); >>>> >>>> _dcmdparser.add_argument(&_second_arg); >>>> >>>> _dcmdparser.add_argument(&_optional_arg); >>>> }; >>>> >>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >>>> argument/option to the parser. The option/argument constructor >>>> takes the >>>> name of the option/argument, its description, a string describing its >>>> type and a boolean to specify if the option/argument is mandatory or >>>> not. The parser doesn't support option/argument duplicates (having the >>>> same name) but the code currently doesn't check for duplicates.The >>>> order >>>> used to register options has no impact on the parser. However, the >>>> order >>>> used to register arguments is critical because the parser will use the >>>> same order to parse the command line. In the example above, the parser >>>> expects to have a first argument of type STRING (parsed using >>>> _first_arg), then a second argument of type INTEGER (parsed using >>>> _second_arg) and optionally a third parameter of type STRING (parsed >>>> using _optional_arg). A mandatory option or argument has to be specify >>>> every time the command is invoked. If it is missing, an exception is >>>> thrown at the end of the parsing. Optional arguments have to be >>>> registered after mandatory arguments. An optional argument will be >>>> considered for parsing only if all arguments before it (mandatory or >>>> not) have already been used to parse the command line. >>>> >>>> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >>>> instance. The rational for this design is to limit the number of >>>> C-heap >>>> allocations but also to be able to pre-allocate diagnostic command >>>> instances for critical situations. If the process is running out of >>>> C-heap space, it's not possible to instantiate new diagnostic commands >>>> to troubleshoot the situation. By pre-allocating some diagnostic >>>> commands, it will be possible to run them even in this critical >>>> situation. Of course, the diagnostic command itself should not try to >>>> allocate memory during its execution, this prevents the diagnostic >>>> command to use variable length arguments like strings. By nature, >>>> pre-allocated diagnostic commands aim to be re-usable, this is the >>>> purpose of the reset() method which restores the default status of all >>>> arguments. >>>> >>>> 1-4 Internal invocation >>>> >>>> Using a diagnostic command from the JVM itself is pretty easy: >>>> instantiate the class and invoke the parse() method then the execute() >>>> method. A diagnostic command can be instantiated from inside the JVM >>>> even it is not registered. This is a difference with the external >>>> invocations (from jcmd or JMX) that require the command to be >>>> registered. >>>> >>>> 2 - The JCmd interface >>>> >>>> Diagnostic commands can also be invoked from outside the JVM process, >>>> using the new 'jcmd' utility. The jcmd program uses the attach API >>>> to connect to the JVM, send requests and receive results. The >>>> jcmd utility must be launched on the same machine than the one running >>>> the JVM (its a local tool). Launched without arguments, jcmd >>>> displays a >>>> list of all JVMs running on the machine. The jcmd source code is in >>>> the jdk repository like other existing j* tools. >>>> >>>> To execute a diagnostic command in a particular JVM, the generic >>>> syntax is: >>>> >>>> jcmd [arguments] >>>> >>>> The attachListener has been modified to recognized the jcmd requests. >>>> When a jcmd request is identified, it is parsed to extract the command >>>> name. The JVM performs a look up of this command in a list of >>>> registered >>>> commands. To be executable by an external request, a diagnostic >>>> command >>>> has to be registered. The registration is performed with the >>>> DCmdFactory >>>> class (see services/management.cpp). >>>> >>>> 3 - The JMX interface >>>> >>>> The framework provides a JMX based interface to the diagnostic >>>> commands. >>>> This interface allows remote invocation of diagnostic commands >>>> through a >>>> JMX connection. >>>> >>>> 3-1 The interface >>>> >>>> The information related to the diagnostic commands are accessible >>>> through new methods added to the >>>> com.sun.management.HotspotDiagnosticMXBean: >>>> >>>> public List getDiagnosticCommands(); >>>> >>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >>>> >>>> public List >>>> getDiagnosticCommandInfo(List >>>> command); >>>> >>>> public List getDiagnosticCommandInfo(); >>>> >>>> public String execute(String commandLine) throws >>>> IllegalArgumentException ; >>>> >>>> public String execute(String cmd, String... arguments) >>>> throws IllegalArgumentException; >>>> >>>> >>>> The getDiagnosticCommands() method returns an array containing the >>>> names >>>> of the not-hidden registered diagnostic commands. >>>> >>>> The three getDiagnosticCommandInfo() methods return one or several >>>> diagnostic command descriptions using the DiagnosticCommandInfo class. >>>> >>>> The two execute() methods allow the user the invoke a diagnostic >>>> command >>>> in different ways. >>>> >>>> The DiagnosticCommandInfo class is describing a diagnostic command >>>> with >>>> the following information: >>>> >>>> public class DiagnosticCommandInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getImpact(); >>>> >>>> public boolean isEnabled(); >>>> >>>> public List getArgumentsInfo(); >>>> } >>>> >>>> The getName() method returns the name of the diagnostic command. This >>>> name is the one to use in execute() methods to invoke the diagnostic >>>> command. >>>> >>>> The getDescription() method returns a general description of the >>>> diagnostic command. >>>> >>>> The getImpact() method returns a description of the intrusiveness of >>>> diagnostic command. >>>> >>>> The isEnabled() method returns true if the method is enabled, false if >>>> it is disabled. A disabled method cannot be executed. >>>> >>>> The getArgumentsInfo() returns a list of descriptions for the >>>> options or >>>> arguments recognized by the diagnostic command. Each >>>> option/argument is >>>> described by a DiagnosticCommandArgumentInfo instance: >>>> >>>> public class DiagnosticCommandArgumentInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getType(); >>>> >>>> public String getDefault(); >>>> >>>> public boolean isMandatory(); >>>> >>>> public boolean isOption(); >>>> >>>> public int getPosition(); >>>> } >>>> >>>> If the DiagnosticCommandArgumentInfo instance describes an option, >>>> isOption() returns true and getPosition() returns -1. Otherwise, when >>>> the DiagnosticCommandArgumentInfo instance describes an argument, >>>> isOption() returns false and getPosition() returns the expected >>>> position >>>> for this argument. The position of an argument is defined >>>> relatively to >>>> all arguments passed on the command line, options are not considered >>>> when defining an argument position. The getDefault() method returns >>>> the >>>> default value of the argument if a default has been defined, otherwise >>>> it returns null. >>>> >>>> 3-2 The implementation >>>> >>>> The framework has been designed in a way that prevents diagnostic >>>> command developers to worry about the JMX interface. In addition to >>>> the methods described in section 1-2, a diagnostic command >>>> developer has >>>> to provide three methods: >>>> >>>> int get_num_arguments() >>>> >>>> which returns the number of option and arguments supported by the >>>> command. >>>> >>>> GrowableArray* get_argument_name_array() >>>> >>>> which provides the name of the arguments supported by the command. >>>> >>>> GrowableyArray* get_argument_info_array() >>>> >>>> which provides the description of each argument with a >>>> DCmdArgumentInfo >>>> instance. DCmdArgumentInfo is a C++ class used by the framework to >>>> generate the sun.com.management.DcmdArgumentInfo instances. This is >>>> done >>>> automatically and the diagnostic command developer doesn't need to >>>> know >>>> how to create Java objects from the runtime. >>>> >>>> 4 - The Diagnostic Commands >>>> >>>> To avoid name collisions between diagnostic commands coming from >>>> different projects, use of a flat name space should be avoided and >>>> a more structured organization is recommended. The framework itself >>>> doesn't depend on this organization, so it will be a set of rules >>>> defining a convention in the way commands are named. >>>> >>>> Diagnostic commands can easily organized in a hierarchical way, so the >>>> template for a command name can be: >>>> >>>> .[sub-domain.] >>>> >>>> This template can be extended with sub-sub-domains and so on. >>>> >>>> A special set of commands without domain will be reserved for the >>>> commands related to the diagnostic framework itself, like the "help" >>>> command. >>>> >>>> >>>> Thanks, >>>> >>>> Fred >>>> >> > From kirk at kodewerk.com Mon Dec 12 13:36:13 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Mon, 12 Dec 2011 22:36:13 +0100 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE65A79.3050809@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65A79.3050809@oracle.com> Message-ID: <6CA74534-43E3-484E-A5E3-E1E7E50F8756@kodewerk.com> Hi John, Thanks, that one fails also. Regards, Kirk On Dec 12, 2011, at 8:48 PM, John Cuthbertson wrote: > Hi Kirk, > > Can you please try monaco.us.oracle.com? I believe the link is supplied by the webrev tool automatically when it sees the CR# in the mercurial queue patch. It could be that my path references an old version. > > Thanks, > > JohnC > > On 12/09/11 23:59, Charles K Pepperdine wrote: >> >> Hi John, >> >> The link http://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. >> >> Regards, >> Kirk >> >> >> On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: >> >> >>> Hi Everyone, >>> >>> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >>> >>> Thanks, >>> >>> JohnC >>> >>> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >>> >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >>>> >>>> Summary: >>>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >>>> >>>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111212/e7a7a17a/attachment.html From david.holmes at oracle.com Mon Dec 12 19:08:16 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 13:08:16 +1000 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <6CA74534-43E3-484E-A5E3-E1E7E50F8756@kodewerk.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65A79.3050809@oracle.com> <6CA74534-43E3-484E-A5E3-E1E7E50F8756@kodewerk.com> Message-ID: <4EE6C1A0.8070201@oracle.com> John, monaco is Oracle internal, you need to link to bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117303 Cheers, David On 13/12/2011 7:36 AM, Charles K Pepperdine wrote: > Hi John, > > Thanks, that one fails also. > > Regards, > Kirk > > On Dec 12, 2011, at 8:48 PM, John Cuthbertson wrote: > >> Hi Kirk, >> >> Can you please try monaco.us.oracle.com ? >> I believe the link is supplied by the webrev tool automatically when >> it sees the CR# in the mercurial queue patch. It could be that my path >> references an old version. >> >> Thanks, >> >> JohnC >> >> On 12/09/11 23:59, Charles K Pepperdine wrote: >>> Hi John, >>> >>> The linkhttp://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. >>> >>> Regards, >>> Kirk >>> >>> >>> On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: >>> >>> >>>> Hi Everyone, >>>> >>>> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at:http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at:http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >>>>> >>>>> Summary: >>>>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >>>>> >>>>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>>>> >>> >>> >> > From david.holmes at oracle.com Mon Dec 12 21:28:44 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 15:28:44 +1000 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE65EDA.80300@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65EDA.80300@oracle.com> Message-ID: <4EE6E28C.6080501@oracle.com> On 13/12/2011 6:06 AM, John Cuthbertson wrote: > Thanks for looking at the code changes and for the suggestions. > > Extending the os API is a good idea. Not sure about the name though - > how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp > already has an internal monotonic version of javaTimeMillis() so there > are alternatives to using javaTimeNanos() in the implementation. I'm somewhat opposed to extending the API simply because there are already too many time functions. What about a TO_MILLIS macro? #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC jlong start = TO_MILLIS(javaTimeNanos()); BTW the "java" in javaTimeMillis and javaTimeNanos identifies these methods as being part of the Java API (System.currentTimeMillis and System.nanoTime respectively) - so javaMonotonicTimeMillis would not be appropriate. John: you have a recurrent typo in the comments: monton instead of monoton (and I mistyped it myself writing that!) > Thanks for the heads up about the other CR. I'll check. See 4741166. It wanted to make javaTimeMillis monotonic, which it can not be. Pretty much all internal uses of javaTimeMillis (those not part of implementing System.currentTimeMillis()) should really be using a monotonic time source. David ----- > Thanks, > > JohnC > > On 12/11/11 01:32, Srinivas Ramakrishna wrote: >> Hi John -- Looks fine. Two minor comments: >> >> (1) by defining an os::javaTimeNanosInMillis() you may be able to >> consolidate the divide by NANOS_IN_MILLISEC to one place instead of it >> appearing at each use. >> (2) you might consolidate the commentary about monotonicity into >> os::javaTimeNanosInMillis(), then at each client simly say "Protect >> against possible nonmonotonicity" >> >> That will reduce the number of repeated lines while still providing >> all of the commentary in all the relevant places. (By the way, you >> might want to >> check if there;s another CR with the same content which might be >> closed as a dup of this... just a very vague recollection.) >> >> reviewed. >> -- ramki (opendjk: ysr) >> >> On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson >> > wrote: >> >> Hi Everyone, >> >> I have updated the comments based upon feedback from David Holmes. >> A new webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >> >> >> Thanks, >> >> JohnC >> >> >> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >> >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this >> CR? The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7117303/webrev.0/ >> . >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where >> we expect monotonicity with calls os::javaTimeNanos(), >> converting the result to milliseconds. os::javaTimeNanos(), at >> least on some configurations, does guarantee monotonicity and >> so is a better alternative. The changes in the os_<*> files >> are to make use of the named conversion constants I >> added/moved to globalDefinitions.hpp - we seemed to have >> multiple names for the same two constants. >> >> Testing: GC test suite on solaris and Linux, NSK tests on >> solaris, and jprt. >> >> Thanks, >> >> JohnC >> >> > From ysr1729 at gmail.com Mon Dec 12 22:40:24 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 12 Dec 2011 22:40:24 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE6E28C.6080501@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65EDA.80300@oracle.com> <4EE6E28C.6080501@oracle.com> Message-ID: Hi David -- On Mon, Dec 12, 2011 at 9:28 PM, David Holmes wrote: > On 13/12/2011 6:06 AM, John Cuthbertson wrote: > >> Thanks for looking at the code changes and for the suggestions. >> >> Extending the os API is a good idea. Not sure about the name though - >> how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp >> already has an internal monotonic version of javaTimeMillis() so there >> are alternatives to using javaTimeNanos() in the implementation. >> > > I'm somewhat opposed to extending the API simply because there are already > too many time functions. What about a TO_MILLIS macro? > > #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC > > jlong start = TO_MILLIS(javaTimeNanos()); > While the macro reduces the # characters, that was not the intent of my suggestion... > > BTW the "java" in javaTimeMillis and javaTimeNanos identifies these > methods as being part of the Java API (System.currentTimeMillis and > System.nanoTime respectively) - so javaMonotonicTimeMillis would not be > appropriate. > Then, how about os::monotonicTimeMillis() defined as an inline method in os:: ? One of the reasons for wanting the consolidation into one place was also so that the commentary would be in one place, including the part about monotonicity only if and when the underlying platform guarantees it, which isn't true today on all the supported platforms. Anyway, do whatever makes sense wrt proper naming and reducing duplication, clutter or confusion as the case may be... thanks. -- ramki > > John: you have a recurrent typo in the comments: monton instead of monoton > (and I mistyped it myself writing that!) > > > Thanks for the heads up about the other CR. I'll check. >> > > See 4741166. It wanted to make javaTimeMillis monotonic, which it can not > be. Pretty much all internal uses of javaTimeMillis (those not part of > implementing System.currentTimeMillis()) should really be using a monotonic > time source. > > David > ----- > > Thanks, >> >> JohnC >> >> On 12/11/11 01:32, Srinivas Ramakrishna wrote: >> >>> Hi John -- Looks fine. Two minor comments: >>> >>> (1) by defining an os::javaTimeNanosInMillis() you may be able to >>> consolidate the divide by NANOS_IN_MILLISEC to one place instead of it >>> appearing at each use. >>> (2) you might consolidate the commentary about monotonicity into >>> os::javaTimeNanosInMillis(), then at each client simly say "Protect >>> against possible nonmonotonicity" >>> >>> That will reduce the number of repeated lines while still providing >>> all of the commentary in all the relevant places. (By the way, you >>> might want to >>> check if there;s another CR with the same content which might be >>> closed as a dup of this... just a very vague recollection.) >>> >>> reviewed. >>> -- ramki (opendjk: ysr) >>> >>> On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson >>> >> >>> wrote: >>> >>> Hi Everyone, >>> >>> I have updated the comments based upon feedback from David Holmes. >>> A new webrev can be found at: >>> http://cr.openjdk.java.net/~**johnc/7117303/webrev.1/ >>> >>> > >>> >>> >>> Thanks, >>> >>> JohnC >>> >>> >>> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >>> >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review the changes for this >>> CR? The webrev can be found at: >>> http://cr.openjdk.java.net/~**johnc/7117303/webrev.0/ >>> >>> >. >>> >>> >>> Summary: >>> I replaced the calls to os::javaTimeMillis() in the GC where >>> we expect monotonicity with calls os::javaTimeNanos(), >>> converting the result to milliseconds. os::javaTimeNanos(), at >>> least on some configurations, does guarantee monotonicity and >>> so is a better alternative. The changes in the os_<*> files >>> are to make use of the named conversion constants I >>> added/moved to globalDefinitions.hpp - we seemed to have >>> multiple names for the same two constants. >>> >>> Testing: GC test suite on solaris and Linux, NSK tests on >>> solaris, and jprt. >>> >>> Thanks, >>> >>> JohnC >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111212/7417cab0/attachment-0001.html From david.holmes at oracle.com Mon Dec 12 22:49:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 16:49:23 +1000 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE61040.5040704@oracle.com> References: <4ED8D93A.5050600@oracle.com 4EE10139.8020905@oracle.com> <34278e49-efbc-4370-ab36-a50331a9ff65@default> <4EE61040.5040704@oracle.com> Message-ID: <4EE6F573.4040802@oracle.com> Hi Fred, A couple of minor comments on the JDK side: HotSpotDiagnosticMXBean.java: Sorry if this is old ground but a query on the API design: is there a specific reason to use Lists rather than the arrays the VM will provide? HotSpotDiagnostic.java: 139 public List getDiagnosticCommandInfo( 140 List commands) { 141 if (commands == null) { 142 throw new NullPointerException(); 143 } 144 return Arrays.asList(getDiagnosticCommandInfo0( 145 commands.toArray(new String[commands.size()]))); 146 } The explicit null check is redundant as commands.size() will be the first thing invoked. --- jmm.h: The structs should use an indent of 2 to match the style of the file. --- hotspotDiagnostic.c: 39 Java_sun_management_HotSpotDiagnostic_getDiagnosticCommands0 40 (JNIEnv *env, jobject dummy) Put on one line. 42 if((jmm_version > JMM_VERSION_1_2_1) Space after 'if' 50 jobject getDiagnosticCommandArgumentInfoArray(JNIEnv *env, jstring command, 51 int num_arg) { Align arg with opening parentheses 52-59, 107-112 It is not necessary with modern C compilers to declare all variables at the start of a block/function. You can declare them in the scope they will be used. 61 dcmd_arg_info_array = (dcmdArgInfo*) malloc(num_arg * sizeof(dcmdArgInfo)); Cast is not needed. --- General: I suggest generating the javadoc for your new classes and having an editorial check done. I spotted a couple of typos eg: DiagnosticCommandArgumentInfo.java: 32 * of one parameter of diagnostic command. ^the DiagnosticCommandInfo.java 89 * Returns the a list of the ^^^^ typo Cheers, David On 13/12/2011 12:31 AM, Frederic Parain wrote: > Hi Robert, > > These issues should be solved with the new webrevs: > > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.03/ > > Regards, > > Fred > > On 12/ 9/11 03:17 PM, Robert Ottenhag wrote: >> Adding to the review of jmm.h, that is modified in both the jdk part >> and the hotspot part, these files should be identical, without any >> differences in whitespace. >> >> Also, regarding whitespace and indentation, the use TAB characters in >> many files in the jdk patch makes jcheck complain (when trying to >> import your patch locally), and should be replaced by spaces. >> >> Best regards, >> >> /Robert >> >> >>> -----Original Message----- From: Paul Hohensee Sent: Thursday, >>> December 08, 2011 7:26 PM To: Frederic Parain Cc: >>> serviceability-dev at openjdk.java.net; >>> core-libs-dev at openjdk.java.net; >>> hotspot-runtime-dev at openjdk.java.net Subject: Re: Request for >>> Review (XXL): 7104647: Adding a diagnostic command framework >>> >>> For the hotspot part at >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>> >>> Most of my comments are style-related. Nice job on the >>> implementation architecture. >>> >>> In attachListener.cpp: >>> >>> You might want to delete the first "return JNI_OK;" line, since the >>> code under HAS_PENDING_EXCEPTION just falls through. >>> >>> In jmm.h: >>> >>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as >>> the existing declarations. Add a newline just before it on line >>> 322. >>> >>> >>> In diagnosticFramework.hpp: >>> >>> Fix indenting for lines 63-66, insert blank before "size_t" on line >>> 48. >>> >>> Hotspot convention is that getter method names don't include a >>> "get_" prefix. So, e.g., DCmdArgIter::get_key_addr() s/b >>> DCmdArgIter::key_addr(). Similarly, getters such as is_enabled() >>> should retrieve a field named "_is_enabled" rather than one named >>> "enabled". You follow the "_is_enabled" convention in other places >>> such as GenDCmdArgument. Or you could use enabled() to get the >>> value of the _enabled field. >>> >>> Also generally, I'd use accessor methods in the implementation of >>> more complex member methods rather than access the underlying >>> fields directly. E.g. in GenDCmdArgument::read_value, I'd use >>> is_set() and set_is_set(true), (set_is_set() is not actually >>> defined, but should be) rather than directly accessing _is_set. >>> Though sometimes doing this is too much of a pain with fields whose >>> type is a template argument, as in the >>> DCmdArggument::parse_value() method in >>> diagnosticArgument.cpp. >>> >>> For easy readability, it'd be nice to line up field names (the ones >>> with an _ prefix) at the same column. >>> >>> On line 200, "instanciated" -> "instantiated" >>> >>> On line 218, I'd use "heap_allocated" rather than "heap" for the >>> formal arg name. >>> >>> On line 248, you could indent the text to start underneath >>> "outputStream". I generally find that indenting arguments lines >>> (formal or actual) so they line up with the first argument position >>> make the code more readable, but I'm not religious about it. >>> >>> On line 265, "instanciated" -> "instantiated" >>> >>> DCmdFactorys are members of a singly-linked list, right? If so, >>> it'd be good to have a comment to that effect on the declaration of >>> _next. >>> >>> On line 322, insert a blank before "true". You might fix this in >>> other places where there's no blank between a comma in an argument >>> list and the following parameter value. >>> >>> >>> In diagnosticCommandFramework.cpp: >>> >>> The code from lines 80-95 and 105-120 is identical. Factor out? >>> >>> >>> In diagnosticArgument.cpp: >>> >>> On line 41, insert blanks before the actual arguments. (see above >>> generic comment) >>> >>> On line 77, the "if" is indented one space too many. >>> >>> >>> In management.cpp: >>> >>> I'd be consistent with having or not having a space between >>> "while", "if" and "for" and the following "(" in this and your >>> other code. Most hotspot code has a space. >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>> Hi All, >>>> >>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>> because changes are pretty big and touch all these areas] >>>> >>>> Here's a framework for issuing diagnostics commands to the JVM. >>>> Diagnostic commands are actions executed inside the JVM mainly >>>> for monitoring or management purpose. This work has two parts. >>>> The first part is in the hotspot repository and contains the >>>> framework itself with two diagnostic commands. The second part is >>>> in the JDK repository and contains the command line utility to >>>> invoke diagnostic commands as well as the HotSpotDiagnosticMXBean >>>> extensions. The HotSpotDiagnosticMXBean extensions allow a remote >>>> client to discover and invoke diagnostic commands using a JMX >>>> connection. >>>> >>>> This changeset only contains two diagnostic commands, more >>>> commands will be added in the future, as a standalone effort to >>>> improve the monitoring and management services of the JVM, or as >>>> part of other projects. >>>> >>>> Webrevs are here: >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>> >>>> Here's a technical description of this work: >>>> >>>> 1 - The Diagnostic Command Framework 1-1 Overview >>>> >>>> The diagnostic command framework is fully implemented in native >>>> code and relies on the HotSpot's internal exception mechanism. >>>> The rational of a pure native implementation is to be able to >>>> execute diagnostic commands even in critical situations like an >>>> OutOfMemory error. All diagnostic commands are registered in a >>>> single list, and two flags control the way a user can interact >>>> with them. The "hidden" flag prevents a diagnostic command from >>>> appearing in the list of available commands returned by the >>>> "help" command. However, it's still possible to get the detailed >>>> help message for a hidden command with the "help " >>>> syntax (but it requires to know the name of the hidden command). >>>> The second flag is "enabled" and it controls if a command can be >>>> invoked or not. When listed with the "help" commands, disabled >>>> commands appear with a "[disabled]" label in their description. >>>> If the user tries to invoke a disabled command, an error message >>>> is returned and the command is not run. This error message can be >>>> customized on a per command base. The framework just provides >>>> these two flags with their semantic, it doesn't provide any >>>> policy or mechanism to set or modify these flags. These actions >>>> will be delegated to the JVM or special diagnostic commands. >>>> >>>> 1-2 Implementation >>>> >>>> All diagnostic commands are implemented as subclasses of the DCmd >>>> class defined in services/diagnosticFramework.hpp. Here's the >>>> layout of the DCmd class and the list of methods that a new >>>> command has to define or overwrite: >>>> >>>> class DCmd { DCmd(outputStream *output); >>>> >>>> static const char *get_name(); >>>> >>>> static const char *get_description(); >>>> >>>> static const char *get_disabled_message(); >>>> >>>> static const char *get_impact(); >>>> >>>> static int get_num_arguments(); >>>> >>>> virtual void print_help(outputStream* out); >>>> >>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>> >>>> virtual void execute(TRAPS); >>>> >>>> virtual void reset(TRAPS); >>>> >>>> virtual void cleanup(); >>>> >>>> virtual GrowableArray* get_argument_name_array(); >>>> >>>> virtual GrowableArray* >>>> get_argument_info_array(); } >>>> >>>> A diagnostic command is always instantiated with an outputStream >>>> in parameter. This outputStream can point either to a file, a >>>> buffer or a socket (see the ostream.hpp file). >>>> >>>> The get_name() method returns the string that will identify the >>>> command (i.e. the string to put on the command line to invoke >>>> it). >>>> >>>> The get_description() methods returns the global description of >>>> the command. >>>> >>>> The get_disabled_message() returns the customized message to >>>> return when the command is disabled, without having to >>>> instantiate the command. >>>> >>>> The get_impact() returns a description of the intrusiveness of >>>> the diagnostic command on the Java Virtual Machine behavior. The >>>> rational for this method is that some diagnostic commands can >>>> seriously disrupt the behavior of the Java Virtual Machine (for >>>> instance a Thread Dump for an application with several tens of >>>> thousands of threads, or a Head Dump with a 40GB+ heap size) and >>>> other diagnostic commands have no serious impact on the JVM (for >>>> instance, getting the command line arguments or the JVM version). >>>> The recommended format for the description is: >>>> [longer description], where the impact level is selected among >>>> this list: {low, medium, high}. The optional longer description >>>> can provide more specific details like the fact that Thread Dump >>>> impact depends on the heap size. >>>> >>>> The get_num_arguments() returns the number of options/arguments >>>> recognized by the diagnostic command. This method is only used by >>>> the JMX interface support (see below). >>>> >>>> The print_help() methods prints a detailed help on the >>>> outputStream passed in argument. The detailed help contains the >>>> list of all supported options with their type and description. >>>> >>>> The parse() method is in charge of parsing the command arguments. >>>> Each command is free to implement its own argument parser. >>>> However, an argument parser framework is provided (see section >>>> 1-3) to ease the implementation, but its use is optional. The >>>> parse method takes a delimiter character in argument, which is >>>> used to mark the limit between two arguments (typically >>>> invocation from jcmd will use a space character as a delimiter >>>> while invocation from the JVM command line parsing code will use >>>> a comma as a delimiter). >>>> >>>> The execute() method is naturally the one to invoke to get the >>>> diagnostic command executed. The parse() and the execute() >>>> methods are dissociated, so it's a possible perform the argument >>>> parsing in one thread, and delegate the execution to another >>>> thread, as long as the diagnostic command doesn't reference >>>> thread local variables. The framework allows several instances of >>>> the same diagnostic command to be executed in parallel. If for >>>> some reasons concurrent executions should not be allowed for a >>>> given diagnostic command, this is the responsibility of the >>>> diagnostic command implementor to enforce this rule, for instance >>>> by protecting the body of the execute() method with a global >>>> lock. >>>> >>>> The reset() method is used to initialize the internal fields of >>>> the diagnostic command or to reset the internal fields to their >>>> initial value to be able to re-use an already allocated >>>> diagnostic command instance. >>>> >>>> The cleanup() method is used to perform perform cleanup (like >>>> freeing of all memory allocated to store internal data). The DCmd >>>> extends the ResourceObj class, so when allocated in a >>>> ResourceArea, destructors cannot be used to perform cleanup. To >>>> ensure that cleanup is performed in all cases, it is recommended >>>> to create a DCmdMark instance for each DCmd instance. DCmdMark is >>>> a stack allocated object with a pointer to a DCmd instance. When >>>> the DCmdMark is destroyed, its destructor calls the cleanup() >>>> method of the DCmd instance it points to. If the DCmd instance >>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>> memory allocated to store the DCmd instance. >>>> >>>> The get_argument_name_array() and get_argument_info_array() are >>>> related to the JMX interface of the diagnostic command framework, >>>> so they are described in section 3. >>>> >>>> 1-3 DCmdParser framework >>>> >>>> The DCmdParser class is an optional framework to help development >>>> of argument parsers. It provides many features required by the >>>> diagnostic command framework (generation of the help message or >>>> the argument descriptions for the JMX interface) but all these >>>> features can easily be re-implemented if a developer decides not >>>> to use the DCmdParser framework. >>>> >>>> The DCmdParser class is relying on the DCmdArgument template. >>>> This template must be used to define the different types of >>>> argument the parser will have to handle. When a new >>>> specialization of the template is done, three methods have to be >>>> provided: >>>> >>>> void parse_value(const char *str,size_t len,TRAPS); void >>>> init_value(TRAPS); void destroy_value(); >>>> >>>> The parse_value() method is used to convert a string into an >>>> argument value. The print_value() method is used to display the >>>> default value (support for the detailed help message). The >>>> init_value() method is used to initialize or reset the argument >>>> value. The destroy_value() method is a clean-up method (useful >>>> when the argument has allocated some C-Heap memory to store its >>>> value and this memory has to be freed before destroying the >>>> DCmdArgument instance). >>>> >>>> The DCmdParser makes a distinction between options and >>>> arguments. Options are identified by a key name that must appear >>>> on the command line, while argument are identified just by the >>>> position of the argument on the command line. Options use >>>> the= syntax. In case of boolean options, the >>>> '=' part of the syntax can be omitted to set the option to >>>> true. Arguments are just sequences characters delimited by a >>>> separator character. This separator can be specified at runtime >>>> when invoking the diagnostic command framework. If an argument >>>> contain a character that could be used as a delimiter, it's >>>> possible to enclose the argument between single or double quotes. >>>> Options are arguments are instantiated using the same >>>> DCmdArgument class but they're registered differently to the >>>> DCmdParser. >>>> >>>> The way to use the DCmdParser is to declare the parser and the >>>> option/arguments as fields of the diagnostic command class (which >>>> is itself a sub-class of the DCmd class), like this: >>>> >>>> >>>> class EchoDCmd : public DCmd { protected: DCmdParser >>>> _dcmdparser; >>>> >>>> DCmdArgument _required; >>>> >>>> DCmdArgument _intval; >>>> >>>> DCmdArgument _boolval; >>>> >>>> DCmdArgument _stringval; >>>> >>>> DCmdArgument _first_arg; >>>> >>>> DCmdArgument _second_arg; >>>> >>>> DCmdArgument _optional_arg; >>>> >>>> } >>>> >>>> The parser and the options/arguments must be initialized before >>>> the diagnostic command class, and the options/arguments have to >>>> be registered to the parser like this: >>>> >>>> EchoDCmd(outputStream *output) : DCmd(output), >>>> _stringval("-strval","a string argument","STRING",false), >>>> >>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>> >>>> _intval("-intval","an integer argument","INTEGER",false), >>>> >>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>> >>>> _fist_arg("first argument","a string argument","STRING",true), >>>> >>>> _second_arg("second argument,"an integer >>>> argument,"INTEGER",true), >>>> >>>> _optional_arg("optional argument","an optional string >>>> argument","STRING","false") >>>> >>>> { >>>> >>>> _dcmdparser.add_dcmd_option(&_stringval) >>>> >>>> _dcmdparser.add_dcmd_option(&_boolval); >>>> >>>> _dcmdparser.add_dcmd_option(&_intval); >>>> >>>> _dcmdparser.add_dcmd_option(&_required); >>>> >>>> _dcmdparser.add_argument(&_first_arg); >>>> >>>> _dcmdparser.add_argument(&_second_arg); >>>> >>>> _dcmdparser.add_argument(&_optional_arg); }; >>>> >>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add >>>> an argument/option to the parser. The option/argument constructor >>>> takes the name of the option/argument, its description, a string >>>> describing its type and a boolean to specify if the >>>> option/argument is mandatory or not. The parser doesn't support >>>> option/argument duplicates (having the same name) but the code >>>> currently doesn't check for duplicates.The order used to register >>>> options has no impact on the parser. However, the order used to >>>> register arguments is critical because the parser will use the >>>> same order to parse the command line. In the example above, the >>>> parser expects to have a first argument of type STRING (parsed >>>> using _first_arg), then a second argument of type INTEGER (parsed >>>> using _second_arg) and optionally a third parameter of type >>>> STRING (parsed using _optional_arg). A mandatory option or >>>> argument has to be specify every time the command is invoked. If >>>> it is missing, an exception is thrown at the end of the parsing. >>>> Optional arguments have to be registered after mandatory >>>> arguments. An optional argument will be considered for parsing >>>> only if all arguments before it (mandatory or not) have already >>>> been used to parse the command line. >>>> >>>> The DCmdParser and its DCmdArgument instances are embedded in the >>>> DCmd instance. The rational for this design is to limit the >>>> number of C-heap allocations but also to be able to pre-allocate >>>> diagnostic command instances for critical situations. If the >>>> process is running out of C-heap space, it's not possible to >>>> instantiate new diagnostic commands to troubleshoot the >>>> situation. By pre-allocating some diagnostic commands, it will be >>>> possible to run them even in this critical situation. Of course, >>>> the diagnostic command itself should not try to allocate memory >>>> during its execution, this prevents the diagnostic command to use >>>> variable length arguments like strings. By nature, pre-allocated >>>> diagnostic commands aim to be re-usable, this is the purpose of >>>> the reset() method which restores the default status of all >>>> arguments. >>>> >>>> 1-4 Internal invocation >>>> >>>> Using a diagnostic command from the JVM itself is pretty easy: >>>> instantiate the class and invoke the parse() method then the >>>> execute() method. A diagnostic command can be instantiated from >>>> inside the JVM even it is not registered. This is a difference >>>> with the external invocations (from jcmd or JMX) that require the >>>> command to be >>> registered. >>>> >>>> 2 - The JCmd interface >>>> >>>> Diagnostic commands can also be invoked from outside the JVM >>>> process, using the new 'jcmd' utility. The jcmd program uses the >>>> attach API to connect to the JVM, send requests and receive >>>> results. The jcmd utility must be launched on the same machine >>>> than the one running the JVM (its a local tool). Launched without >>>> arguments, jcmd displays a list of all JVMs running on the >>>> machine. The jcmd source code is in the jdk repository like other >>>> existing j* tools. >>>> >>>> To execute a diagnostic command in a particular JVM, the generic >>>> syntax is: >>>> >>>> jcmd [arguments] >>>> >>>> The attachListener has been modified to recognized the jcmd >>>> requests. When a jcmd request is identified, it is parsed to >>>> extract the command name. The JVM performs a look up of this >>>> command in a list of registered commands. To be executable by an >>>> external request, a diagnostic command has to be registered. The >>>> registration is performed with the DCmdFactory class (see >>>> services/management.cpp). >>>> >>>> 3 - The JMX interface >>>> >>>> The framework provides a JMX based interface to the diagnostic >>>> commands. This interface allows remote invocation of diagnostic >>>> commands through a JMX connection. >>>> >>>> 3-1 The interface >>>> >>>> The information related to the diagnostic commands are >>>> accessible through new methods added to the >>>> com.sun.management.HotspotDiagnosticMXBean: >>>> >>>> public List getDiagnosticCommands(); >>>> >>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String >>>> command); >>>> >>>> public List >>>> getDiagnosticCommandInfo(List command); >>>> >>>> public List getDiagnosticCommandInfo(); >>>> >>>> public String execute(String commandLine) throws >>>> IllegalArgumentException ; >>>> >>>> public String execute(String cmd, String... arguments) throws >>>> IllegalArgumentException; >>>> >>>> >>>> The getDiagnosticCommands() method returns an array containing >>>> the names of the not-hidden registered diagnostic commands. >>>> >>>> The three getDiagnosticCommandInfo() methods return one or >>>> several diagnostic command descriptions using the >>>> DiagnosticCommandInfo class. >>>> >>>> The two execute() methods allow the user the invoke a diagnostic >>>> command in different ways. >>>> >>>> The DiagnosticCommandInfo class is describing a diagnostic >>>> command with the following information: >>>> >>>> public class DiagnosticCommandInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getImpact(); >>>> >>>> public boolean isEnabled(); >>>> >>>> public List getArgumentsInfo(); >>>> } >>>> >>>> The getName() method returns the name of the diagnostic command. >>>> This name is the one to use in execute() methods to invoke the >>>> diagnostic command. >>>> >>>> The getDescription() method returns a general description of the >>>> diagnostic command. >>>> >>>> The getImpact() method returns a description of the intrusiveness >>>> of diagnostic command. >>>> >>>> The isEnabled() method returns true if the method is enabled, >>>> false if it is disabled. A disabled method cannot be executed. >>>> >>>> The getArgumentsInfo() returns a list of descriptions for the >>>> options or arguments recognized by the diagnostic command. Each >>>> option/argument is described by a DiagnosticCommandArgumentInfo >>>> instance: >>>> >>>> public class DiagnosticCommandArgumentInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getType(); >>>> >>>> public String getDefault(); >>>> >>>> public boolean isMandatory(); >>>> >>>> public boolean isOption(); >>>> >>>> public int getPosition(); } >>>> >>>> If the DiagnosticCommandArgumentInfo instance describes an >>>> option, isOption() returns true and getPosition() returns -1. >>>> Otherwise, when the DiagnosticCommandArgumentInfo instance >>>> describes an argument, isOption() returns false and getPosition() >>>> returns the expected position for this argument. The position of >>>> an argument is defined relatively to all arguments passed on the >>>> command line, options are not considered when defining an >>>> argument position. The getDefault() method returns the default >>>> value of the argument if a default has been defined, otherwise it >>>> returns null. >>>> >>>> 3-2 The implementation >>>> >>>> The framework has been designed in a way that prevents >>>> diagnostic command developers to worry about the JMX interface. >>>> In addition to the methods described in section 1-2, a diagnostic >>>> command developer has to provide three methods: >>>> >>>> int get_num_arguments() >>>> >>>> which returns the number of option and arguments supported by >>>> the command. >>>> >>>> GrowableArray* get_argument_name_array() >>>> >>>> which provides the name of the arguments supported by the >>>> command. >>>> >>>> GrowableyArray* get_argument_info_array() >>>> >>>> which provides the description of each argument with a >>>> DCmdArgumentInfo instance. DCmdArgumentInfo is a C++ class used >>>> by the framework to generate the >>>> sun.com.management.DcmdArgumentInfo instances. This is done >>>> automatically and the diagnostic command developer doesn't need >>>> to know how to create Java objects from the runtime. >>>> >>>> 4 - The Diagnostic Commands >>>> >>>> To avoid name collisions between diagnostic commands coming from >>>> different projects, use of a flat name space should be avoided >>>> and a more structured organization is recommended. The framework >>>> itself doesn't depend on this organization, so it will be a set >>>> of rules defining a convention in the way commands are named. >>>> >>>> Diagnostic commands can easily organized in a hierarchical way, >>>> so the template for a command name can be: >>>> >>>> .[sub-domain.] >>>> >>>> This template can be extended with sub-sub-domains and so on. >>>> >>>> A special set of commands without domain will be reserved for >>>> the commands related to the diagnostic framework itself, like the >>>> "help" command. >>>> >>>> >>>> Thanks, >>>> >>>> Fred >>>> > From frederic.parain at oracle.com Tue Dec 13 06:04:56 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 13 Dec 2011 15:04:56 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE65F4D.7040109@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> <4EE60FD4.3040404@oracle.com> <4EE6243B.6070200@oracle.com> <4EE65F4D.7040109@oracle.com> Message-ID: <4EE75B88.3070509@oracle.com> Hi Dan, Thank you for the review. The new webrev is here: http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.05/ And my answers are in-lined below. On 12/12/11 09:08 PM, Daniel D. Daugherty wrote: > src/share/vm/services/attachListener.cpp > The new include should be in alpha-order (between lines 36 & 37). > I'm pretty sure that's the new style... Fixed > Block comment on lines 152-155 should be in '//' style and not > in JavaDoc style (/** ... */) Fixed > src/share/vm/services/jmm.h > lines 192-208 - HotSpot convention is to mimic the existing style > in a file. For these structs, the field names should all be > lined up (see 181-188 for an example). Fixed > src/share/vm/services/management.cpp > line 2126 calls JNIHandles::make_local(), but this is a JVM_ENTRY > wrapped function which means it depends on VM_ENTRY_BASE which > has a HandleMarkCleaner in it. Since this is a make_local() > call, won't the local JNIHandle get scrubbed on the way back > to the caller? Threads have two areas to store handles, one for internal handles and one for JNI handles. The HandleMarkCleaner applies only to the internal handles. The purpose of the make_local() is to create a JNI handle from the internal handle, so when the internal area is cleaned up by the HandleMarkCleaner, the JNI handle is still valid in the context of the caller. > src/share/vm/services/diagnosticArgument.hpp > lines 45-50 - too much indent; should be 4 spaces Fixed > src/share/vm/services/diagnosticArgument.cpp > HotSpot style is generally 'if (' and not 'if(' Fixed > src/share/vm/services/diagnosticCommand.hpp > lines 28-36 - includes should be in alpha order Fixed > lines 44, 64 - Parameter defaults in new code is generally frowned > upon in HotSpot. They're used when adding a parameter to existing > code to avoid changing existing calls where the default is OK. > (I happen to disagree with that last part and I think that all > calls should be updated just to make sure your reviewers see > all uses, but I'm just one cranky voice... :-)) I've removed all default parameters I found. > src/share/vm/services/diagnosticCommand.cpp > line 28: includes should be in alpha order Fixed > lines 31-33 - should be some indent here Fixed > line 74: It would be useful to display the command that > can't be found: > > help foo > Help unavailable: 'foo': No such command Done. > line 101: just FYI, a ResourceMark without a Thread parameter can > be expensive. Not an issue for HelpDCmd::num_arguments(). I was not aware of the performance penalty. However, this method is called only once in the lifetime of the VM, so I didn't fixed it. > line 103: HotSpot style is generally 'if (' and not 'if(' Fixed > src/share/vm/services/diagnosticFramework.hpp > line 38: typo: 'provides method' -> 'provides methods' > line 40: typo: 'keywor' -> 'keyword' Fixed. > lines 43-46 - fields nicely indented here, but not in other new > header files. Any particular reason? Yes, I got several reviews about the style :-) > lines 48, 154, 218, 286, 324 - Parameter defaults again. Removed > line 55: is_stop should be: > return !is_empty() && strncmp("stop", _cmd, _cmd_len) == 0; > !strncmp() is frowned upon and spaces between params OK. Fixed > line 82 - returns a local variable; that shouldn't work. The method doesn't really return a local variable, this is a return by value. The return statement invokes the copy constructor to duplicate the local object into the caller context. Here, the default copy constructor is called but it's okay because the CmdLine class has be designed to work this way. I've added a comment in the code to make this mechanism more explicit. > line 155: missing a space after '=' Fixed > lines 256, 258: HotSpot style is generally 'if (' and not 'if(' Fixed > line 304: typo: 'DCmdFActory' -> 'DCmdFactory' Fixed > line 306: typo: 'command to be executed' -> 'command from being executed' Fixed > src/share/vm/services/diagnosticFramework.cpp > line 55: _cmd_len = cmd_end - line; > This length includes any leading white space that was skipped > on lines 42-44. It seems odd that '_cmd' points to the first > non-whitespace in the command, but _cmd_len includes the > leading white space. If you change the _cmd_len calculation, > then you have to also change the logic on line 58 so that > args_len is also not too long. You're right, this is definitively odd. I've fixed _cmd_len and updated line 58. > lines 79, 104: typo: 'simple' -> 'single' Fixed > line 318 - what is 'idx' used for? Remaining code from a previous version. Unused now, so I removed it. > line 367: HotSpot style is generally 'if (' and not 'if(' > lines 371, 372, 380, 403, 416: space after comma Fixed Thank you, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Tue Dec 13 06:05:54 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 13 Dec 2011 15:05:54 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE71E3F.9010703@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> <4EE60FD4.3040404@oracle.com> <4EE6243B.6070200@oracle.com> <4EE71E3F.9010703@oracle.com> Message-ID: <4EE75BC2.5000401@oracle.com> Hi Serguei, Thanks for the review. I've applied the changes and the new webrev is here: http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.05/ Regards, Fred On 12/13/11 10:43 AM, serguei.spitsyn at oracle.com wrote: > Hi Frederik, > > Your fix is already in a good shape! > > src/share/vm/services/management.cpp: > > It is better to have different diagnostic messages at lines 2181 and 2186 > so that it is easy to find out what of the two lines caused an exception. > The messages would be better to be more specific. > The same applies to the lines 2221 and 2226. > Indent must be aligned with the first argument above. > > 2178 oop cmd = JNIHandles::resolve_external_guard(command); > 2179 if (cmd == NULL) { > 2180 THROW_MSG(vmSymbols::java_lang_NullPointerException(), > 2181 "Command line cannot be null."); > 2182 } > 2183 char* cmd_name = java_lang_String::as_utf8_string(cmd); > 2184 if (cmd_name == NULL) { > 2185 THROW_MSG(vmSymbols::java_lang_NullPointerException(), > 2186 "Command line cannot be null."); > 2187 } > ... > 2219 if (cmd == NULL) { > 2220 THROW_MSG_NULL(vmSymbols::java_lang_NullPointerException(), > 2221 "Command line cannot be null."); > 2222 } > 2223 char* cmdline = java_lang_String::as_utf8_string(cmd); > 2224 if (cmdline == NULL) { > > 2225 THROW_MSG_NULL(vmSymbols::java_lang_NullPointerException(), > 2226 "Command line cannot be null."); > 2227 } > > The lines 2189 and 2194 look redundant: > > src/share/vm/services/diagnosticFramework.cpp: > > 2188 DCmd* dcmd = NULL; > 2189 { > 2190 DCmdFactory*factory = DCmdFactory::factory(cmd_name, strlen(cmd_name)); > 2191 if (factory != NULL) { > 2192 dcmd = factory->create_resource_instance(NULL); > 2193 } > 2194 } > > Indent is not correct at the lines 2205-2211: > > 2204 for (int i = 0; i< array->length(); i++) { > 2205 infoArray[i].name = array->at(i)->name(); > 2206 infoArray[i].description = array->at(i)->description(); > 2207 infoArray[i].type = array->at(i)->type(); > 2208 infoArray[i].default_string = array->at(i)->default_string(); > 2209 infoArray[i].mandatory = array->at(i)->is_mandatory(); > 2210 infoArray[i].option = array->at(i)->is_option(); > 2211 infoArray[i].position = array->at(i)->position(); > 2212 } > > > Space is missed after 'while': > > 320 while(arg != NULL) { > 326 while(arg != NULL) { > > > Thanks, > Serguei > > > > On 12/12/11 7:56 AM, Frederic Parain wrote: >> Minor updates: >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.04/ >> >> Fred >> >> On 12/12/11 03:29 PM, Frederic Parain wrote: >>> Hi Paul, >>> >>> Thank you for the review. >>> I've applied all your recommendations except the refactoring >>> in diagnosticCommandFramework.cpp (too few lines can be really >>> factored out without passing many arguments). >>> >>> New webrev is here: >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ >>> >>> Regards, >>> >>> Fred >>> >>> On 12/ 8/11 07:26 PM, Paul Hohensee wrote: >>>> For the hotspot part at >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>> >>>> Most of my comments are style-related. Nice job on the implementation >>>> architecture. >>>> >>>> In attachListener.cpp: >>>> >>>> You might want to delete the first "return JNI_OK;" line, since the >>>> code >>>> under >>>> HAS_PENDING_EXCEPTION just falls through. >>>> >>>> In jmm.h: >>>> >>>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the >>>> existing declarations. Add a newline just before it on line 322. >>>> >>>> >>>> In diagnosticFramework.hpp: >>>> >>>> Fix indenting for lines 63-66, insert blank before "size_t" on line 48. >>>> >>>> Hotspot convention is that getter method names don't include a "get_" >>>> prefix. >>>> So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). >>>> Similarly, getters such as is_enabled() should retrieve a field named >>>> "_is_enabled" >>>> rather than one named "enabled". You follow the "_is_enabled" >>>> convention >>>> in other places such as GenDCmdArgument. Or you could use enabled() to >>>> get the value of the _enabled field. >>>> >>>> Also generally, I'd use accessor methods in the implementation of more >>>> complex member methods rather than access the underlying fields >>>> directly. >>>> E.g. in GenDCmdArgument::read_value, I'd use is_set() and >>>> set_is_set(true), >>>> (set_is_set() is not actually defined, but should be) rather than >>>> directly >>>> accessing _is_set. Though sometimes doing this is too much of a pain >>>> with fields whose type is a template argument, as in the >>>> DCmdArggument::parse_value() method in diagnosticArgument.cpp. >>>> >>>> For easy readability, it'd be nice to line up field names (the ones >>>> with an >>>> _ prefix) at the same column. >>>> >>>> On line 200, "instanciated" -> "instantiated" >>>> >>>> On line 218, I'd use "heap_allocated" rather than "heap" for the formal >>>> arg name. >>>> >>>> On line 248, you could indent the text to start underneath >>>> "outputStream". >>>> I generally find that indenting arguments lines (formal or actual) so >>>> they line >>>> up with the first argument position make the code more readable, but >>>> I'm >>>> not >>>> religious about it. >>>> >>>> On line 265, "instanciated" -> "instantiated" >>>> >>>> DCmdFactorys are members of a singly-linked list, right? If so, it'd be >>>> good to >>>> have a comment to that effect on the declaration of _next. >>>> >>>> On line 322, insert a blank before "true". You might fix this in other >>>> places >>>> where there's no blank between a comma in an argument list and the >>>> following parameter value. >>>> >>>> >>>> In diagnosticCommandFramework.cpp: >>>> >>>> The code from lines 80-95 and 105-120 is identical. Factor out? >>>> >>>> >>>> In diagnosticArgument.cpp: >>>> >>>> On line 41, insert blanks before the actual arguments. (see above >>>> generic comment) >>>> >>>> On line 77, the "if" is indented one space too many. >>>> >>>> >>>> In management.cpp: >>>> >>>> I'd be consistent with having or not having a space between "while", >>>> "if" and "for" >>>> and the following "(" in this and your other code. Most hotspot code >>>> has >>>> a space. >>>> >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> >>>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>>> Hi All, >>>>> >>>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>>> because changes are pretty big and touch all these areas] >>>>> >>>>> Here's a framework for issuing diagnostics commands to the JVM. >>>>> Diagnostic commands are actions executed inside the JVM mainly >>>>> for monitoring or management purpose. This work has two parts. >>>>> The first part is in the hotspot repository and contains the >>>>> framework itself with two diagnostic commands. The second >>>>> part is in the JDK repository and contains the command line >>>>> utility to invoke diagnostic commands as well as the >>>>> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >>>>> extensions allow a remote client to discover and invoke >>>>> diagnostic commands using a JMX connection. >>>>> >>>>> This changeset only contains two diagnostic commands, more >>>>> commands will be added in the future, as a standalone effort >>>>> to improve the monitoring and management services of the >>>>> JVM, or as part of other projects. >>>>> >>>>> Webrevs are here: >>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>>> >>>>> Here's a technical description of this work: >>>>> >>>>> 1 - The Diagnostic Command Framework >>>>> 1-1 Overview >>>>> >>>>> The diagnostic command framework is fully implemented in native code >>>>> and relies on the HotSpot's internal exception mechanism. >>>>> The rational of a pure native implementation is to be able to execute >>>>> diagnostic commands even in critical situations like an OutOfMemory >>>>> error. All diagnostic commands are registered in a single list, and >>>>> two >>>>> flags control the way a user can interact with them. The "hidden" flag >>>>> prevents a diagnostic command from appearing in the list of available >>>>> commands returned by the "help" command. However, it's still >>>>> possible to >>>>> get the detailed help message for a hidden command with the "help >>>>> " syntax (but it requires to know the name of the hidden >>>>> command). The second flag is "enabled" and it controls if a command >>>>> can >>>>> be invoked or not. When listed with the "help" commands, disabled >>>>> commands appear with a "[disabled]" label in their description. If the >>>>> user tries to invoke a disabled command, an error message is returned >>>>> and the command is not run. This error message can be customized on a >>>>> per command base. The framework just provides these two flags with >>>>> their >>>>> semantic, it doesn't provide any policy or mechanism to set or modify >>>>> these flags. These actions will be delegated to the JVM or special >>>>> diagnostic commands. >>>>> >>>>> 1-2 Implementation >>>>> >>>>> All diagnostic commands are implemented as subclasses of the DCmd >>>>> class >>>>> defined in services/diagnosticFramework.hpp. Here's the layout of the >>>>> DCmd class and the list of methods that a new command has to define or >>>>> overwrite: >>>>> >>>>> class DCmd { >>>>> DCmd(outputStream *output); >>>>> >>>>> static const char *get_name(); >>>>> >>>>> static const char *get_description(); >>>>> >>>>> static const char *get_disabled_message(); >>>>> >>>>> static const char *get_impact(); >>>>> >>>>> static int get_num_arguments(); >>>>> >>>>> virtual void print_help(outputStream* out); >>>>> >>>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>>> >>>>> virtual void execute(TRAPS); >>>>> >>>>> virtual void reset(TRAPS); >>>>> >>>>> virtual void cleanup(); >>>>> >>>>> virtual GrowableArray* get_argument_name_array(); >>>>> >>>>> virtual GrowableArray* get_argument_info_array(); >>>>> } >>>>> >>>>> A diagnostic command is always instantiated with an outputStream in >>>>> parameter. This outputStream can point either to a file, a buffer or a >>>>> socket (see the ostream.hpp file). >>>>> >>>>> The get_name() method returns the string that will identify the >>>>> command >>>>> (i.e. the string to put on the command line to invoke it). >>>>> >>>>> The get_description() methods returns the global description of the >>>>> command. >>>>> >>>>> The get_disabled_message() returns the customized message to return >>>>> when >>>>> the command is disabled, without having to instantiate the command. >>>>> >>>>> The get_impact() returns a description of the intrusiveness of the >>>>> diagnostic command on the Java Virtual Machine behavior. The rational >>>>> for this method is that some diagnostic commands can seriously disrupt >>>>> the behavior of the Java Virtual Machine (for instance a Thread >>>>> Dump for >>>>> an application with several tens of thousands of threads, or a Head >>>>> Dump >>>>> with a 40GB+ heap size) and other diagnostic commands have no serious >>>>> impact on the JVM (for instance, getting the command line arguments or >>>>> the JVM version). The recommended format for the description is >>>>> >>>> level>: [longer description], where the impact level is selected among >>>>> this list: {low, medium, high}. The optional longer description can >>>>> provide more specific details like the fact that Thread Dump impact >>>>> depends on the heap size. >>>>> >>>>> The get_num_arguments() returns the number of options/arguments >>>>> recognized by the diagnostic command. This method is only used by the >>>>> JMX interface support (see below). >>>>> >>>>> The print_help() methods prints a detailed help on the outputStream >>>>> passed in argument. The detailed help contains the list of all >>>>> supported >>>>> options with their type and description. >>>>> >>>>> The parse() method is in charge of parsing the command arguments. Each >>>>> command is free to implement its own argument parser. However, an >>>>> argument parser framework is provided (see section 1-3) to ease the >>>>> implementation, but its use is optional. The parse method takes a >>>>> delimiter character in argument, which is used to mark the limit >>>>> between >>>>> two arguments (typically invocation from jcmd will use a space >>>>> character >>>>> as a delimiter while invocation from the JVM command line parsing code >>>>> will use a comma as a delimiter). >>>>> >>>>> The execute() method is naturally the one to invoke to get the >>>>> diagnostic command executed. The parse() and the execute() methods are >>>>> dissociated, so it's a possible perform the argument parsing in one >>>>> thread, and delegate the execution to another thread, as long as the >>>>> diagnostic command doesn't reference thread local variables. The >>>>> framework allows several instances of the same diagnostic command >>>>> to be >>>>> executed in parallel. If for some reasons concurrent executions should >>>>> not be allowed for a given diagnostic command, this is the >>>>> responsibility of the diagnostic command implementor to enforce this >>>>> rule, for instance by protecting the body of the execute() method >>>>> with a >>>>> global lock. >>>>> >>>>> The reset() method is used to initialize the internal fields of the >>>>> diagnostic command or to reset the internal fields to their initial >>>>> value to be able to re-use an already allocated diagnostic command >>>>> instance. >>>>> >>>>> The cleanup() method is used to perform perform cleanup (like >>>>> freeing of >>>>> all memory allocated to store internal data). The DCmd extends the >>>>> ResourceObj class, so when allocated in a ResourceArea, destructors >>>>> cannot be used to perform cleanup. To ensure that cleanup is performed >>>>> in all cases, it is recommended to create a DCmdMark instance for each >>>>> DCmd instance. DCmdMark is a stack allocated object with a pointer >>>>> to a >>>>> DCmd instance. When the DCmdMark is destroyed, its destructor calls >>>>> the >>>>> cleanup() method of the DCmd instance it points to. If the DCmd >>>>> instance >>>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>>> memory >>>>> allocated to store the DCmd instance. >>>>> >>>>> The get_argument_name_array() and get_argument_info_array() are >>>>> related >>>>> to the JMX interface of the diagnostic command framework, so they are >>>>> described in section 3. >>>>> >>>>> 1-3 DCmdParser framework >>>>> >>>>> The DCmdParser class is an optional framework to help development of >>>>> argument parsers. It provides many features required by the diagnostic >>>>> command framework (generation of the help message or the argument >>>>> descriptions for the JMX interface) but all these features can >>>>> easily be >>>>> re-implemented if a developer decides not to use the DCmdParser >>>>> framework. >>>>> >>>>> The DCmdParser class is relying on the DCmdArgument template. This >>>>> template must be used to define the different types of argument the >>>>> parser will have to handle. When a new specialization of the >>>>> template is >>>>> done, three methods have to be provided: >>>>> >>>>> void parse_value(const char *str,size_t len,TRAPS); >>>>> void init_value(TRAPS); >>>>> void destroy_value(); >>>>> >>>>> The parse_value() method is used to convert a string into an argument >>>>> value. The print_value() method is used to display the default value >>>>> (support for the detailed help message). The init_value() method is >>>>> used >>>>> to initialize or reset the argument value. The destroy_value() >>>>> method is >>>>> a clean-up method (useful when the argument has allocated some C-Heap >>>>> memory to store its value and this memory has to be freed before >>>>> destroying the DCmdArgument instance). >>>>> >>>>> The DCmdParser makes a distinction between options and arguments. >>>>> Options are identified by a key name that must appear on the command >>>>> line, while argument are identified just by the position of the >>>>> argument >>>>> on the command line. Options use the = syntax. In case of >>>>> boolean options, the '=' part of the syntax can be omitted >>>>> to set >>>>> the option to true. Arguments are just sequences characters >>>>> delimited by >>>>> a separator character. This separator can be specified at runtime when >>>>> invoking the diagnostic command framework. If an argument contain a >>>>> character that could be used as a delimiter, it's possible to enclose >>>>> the argument between single or double quotes. Options are arguments >>>>> are >>>>> instantiated using the same DCmdArgument class but they're registered >>>>> differently to the DCmdParser. >>>>> >>>>> The way to use the DCmdParser is to declare the parser and the >>>>> option/arguments as fields of the diagnostic command class (which is >>>>> itself a sub-class of the DCmd class), like this: >>>>> >>>>> >>>>> class EchoDCmd : public DCmd { >>>>> protected: >>>>> DCmdParser _dcmdparser; >>>>> >>>>> DCmdArgument _required; >>>>> >>>>> DCmdArgument _intval; >>>>> >>>>> DCmdArgument _boolval; >>>>> >>>>> DCmdArgument _stringval; >>>>> >>>>> DCmdArgument _first_arg; >>>>> >>>>> DCmdArgument _second_arg; >>>>> >>>>> DCmdArgument _optional_arg; >>>>> >>>>> } >>>>> >>>>> The parser and the options/arguments must be initialized before the >>>>> diagnostic command class, and the options/arguments have to be >>>>> registered to the parser like this: >>>>> >>>>> EchoDCmd(outputStream *output) : DCmd(output), >>>>> _stringval("-strval","a string argument","STRING",false), >>>>> >>>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>>> >>>>> _intval("-intval","an integer argument","INTEGER",false), >>>>> >>>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>>> >>>>> _fist_arg("first argument","a string argument","STRING",true), >>>>> >>>>> _second_arg("second argument,"an integer argument,"INTEGER",true), >>>>> >>>>> _optional_arg("optional argument","an optional string >>>>> argument","STRING","false") >>>>> >>>>> { >>>>> >>>>> _dcmdparser.add_dcmd_option(&_stringval) >>>>> >>>>> _dcmdparser.add_dcmd_option(&_boolval); >>>>> >>>>> _dcmdparser.add_dcmd_option(&_intval); >>>>> >>>>> _dcmdparser.add_dcmd_option(&_required); >>>>> >>>>> _dcmdparser.add_argument(&_first_arg); >>>>> >>>>> _dcmdparser.add_argument(&_second_arg); >>>>> >>>>> _dcmdparser.add_argument(&_optional_arg); >>>>> }; >>>>> >>>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >>>>> argument/option to the parser. The option/argument constructor >>>>> takes the >>>>> name of the option/argument, its description, a string describing its >>>>> type and a boolean to specify if the option/argument is mandatory or >>>>> not. The parser doesn't support option/argument duplicates (having the >>>>> same name) but the code currently doesn't check for duplicates.The >>>>> order >>>>> used to register options has no impact on the parser. However, the >>>>> order >>>>> used to register arguments is critical because the parser will use the >>>>> same order to parse the command line. In the example above, the parser >>>>> expects to have a first argument of type STRING (parsed using >>>>> _first_arg), then a second argument of type INTEGER (parsed using >>>>> _second_arg) and optionally a third parameter of type STRING (parsed >>>>> using _optional_arg). A mandatory option or argument has to be specify >>>>> every time the command is invoked. If it is missing, an exception is >>>>> thrown at the end of the parsing. Optional arguments have to be >>>>> registered after mandatory arguments. An optional argument will be >>>>> considered for parsing only if all arguments before it (mandatory or >>>>> not) have already been used to parse the command line. >>>>> >>>>> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >>>>> instance. The rational for this design is to limit the number of >>>>> C-heap >>>>> allocations but also to be able to pre-allocate diagnostic command >>>>> instances for critical situations. If the process is running out of >>>>> C-heap space, it's not possible to instantiate new diagnostic commands >>>>> to troubleshoot the situation. By pre-allocating some diagnostic >>>>> commands, it will be possible to run them even in this critical >>>>> situation. Of course, the diagnostic command itself should not try to >>>>> allocate memory during its execution, this prevents the diagnostic >>>>> command to use variable length arguments like strings. By nature, >>>>> pre-allocated diagnostic commands aim to be re-usable, this is the >>>>> purpose of the reset() method which restores the default status of all >>>>> arguments. >>>>> >>>>> 1-4 Internal invocation >>>>> >>>>> Using a diagnostic command from the JVM itself is pretty easy: >>>>> instantiate the class and invoke the parse() method then the execute() >>>>> method. A diagnostic command can be instantiated from inside the JVM >>>>> even it is not registered. This is a difference with the external >>>>> invocations (from jcmd or JMX) that require the command to be >>>>> registered. >>>>> >>>>> 2 - The JCmd interface >>>>> >>>>> Diagnostic commands can also be invoked from outside the JVM process, >>>>> using the new 'jcmd' utility. The jcmd program uses the attach API >>>>> to connect to the JVM, send requests and receive results. The >>>>> jcmd utility must be launched on the same machine than the one running >>>>> the JVM (its a local tool). Launched without arguments, jcmd >>>>> displays a >>>>> list of all JVMs running on the machine. The jcmd source code is in >>>>> the jdk repository like other existing j* tools. >>>>> >>>>> To execute a diagnostic command in a particular JVM, the generic >>>>> syntax is: >>>>> >>>>> jcmd [arguments] >>>>> >>>>> The attachListener has been modified to recognized the jcmd requests. >>>>> When a jcmd request is identified, it is parsed to extract the command >>>>> name. The JVM performs a look up of this command in a list of >>>>> registered >>>>> commands. To be executable by an external request, a diagnostic >>>>> command >>>>> has to be registered. The registration is performed with the >>>>> DCmdFactory >>>>> class (see services/management.cpp). >>>>> >>>>> 3 - The JMX interface >>>>> >>>>> The framework provides a JMX based interface to the diagnostic >>>>> commands. >>>>> This interface allows remote invocation of diagnostic commands >>>>> through a >>>>> JMX connection. >>>>> >>>>> 3-1 The interface >>>>> >>>>> The information related to the diagnostic commands are accessible >>>>> through new methods added to the >>>>> com.sun.management.HotspotDiagnosticMXBean: >>>>> >>>>> public List getDiagnosticCommands(); >>>>> >>>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >>>>> >>>>> public List >>>>> getDiagnosticCommandInfo(List >>>>> command); >>>>> >>>>> public List getDiagnosticCommandInfo(); >>>>> >>>>> public String execute(String commandLine) throws >>>>> IllegalArgumentException ; >>>>> >>>>> public String execute(String cmd, String... arguments) >>>>> throws IllegalArgumentException; >>>>> >>>>> >>>>> The getDiagnosticCommands() method returns an array containing the >>>>> names >>>>> of the not-hidden registered diagnostic commands. >>>>> >>>>> The three getDiagnosticCommandInfo() methods return one or several >>>>> diagnostic command descriptions using the DiagnosticCommandInfo class. >>>>> >>>>> The two execute() methods allow the user the invoke a diagnostic >>>>> command >>>>> in different ways. >>>>> >>>>> The DiagnosticCommandInfo class is describing a diagnostic command >>>>> with >>>>> the following information: >>>>> >>>>> public class DiagnosticCommandInfo { >>>>> >>>>> public String getName(); >>>>> >>>>> public String getDescription(); >>>>> >>>>> public String getImpact(); >>>>> >>>>> public boolean isEnabled(); >>>>> >>>>> public List getArgumentsInfo(); >>>>> } >>>>> >>>>> The getName() method returns the name of the diagnostic command. This >>>>> name is the one to use in execute() methods to invoke the diagnostic >>>>> command. >>>>> >>>>> The getDescription() method returns a general description of the >>>>> diagnostic command. >>>>> >>>>> The getImpact() method returns a description of the intrusiveness of >>>>> diagnostic command. >>>>> >>>>> The isEnabled() method returns true if the method is enabled, false if >>>>> it is disabled. A disabled method cannot be executed. >>>>> >>>>> The getArgumentsInfo() returns a list of descriptions for the >>>>> options or >>>>> arguments recognized by the diagnostic command. Each >>>>> option/argument is >>>>> described by a DiagnosticCommandArgumentInfo instance: >>>>> >>>>> public class DiagnosticCommandArgumentInfo { >>>>> >>>>> public String getName(); >>>>> >>>>> public String getDescription(); >>>>> >>>>> public String getType(); >>>>> >>>>> public String getDefault(); >>>>> >>>>> public boolean isMandatory(); >>>>> >>>>> public boolean isOption(); >>>>> >>>>> public int getPosition(); >>>>> } >>>>> >>>>> If the DiagnosticCommandArgumentInfo instance describes an option, >>>>> isOption() returns true and getPosition() returns -1. Otherwise, when >>>>> the DiagnosticCommandArgumentInfo instance describes an argument, >>>>> isOption() returns false and getPosition() returns the expected >>>>> position >>>>> for this argument. The position of an argument is defined >>>>> relatively to >>>>> all arguments passed on the command line, options are not considered >>>>> when defining an argument position. The getDefault() method returns >>>>> the >>>>> default value of the argument if a default has been defined, otherwise >>>>> it returns null. >>>>> >>>>> 3-2 The implementation >>>>> >>>>> The framework has been designed in a way that prevents diagnostic >>>>> command developers to worry about the JMX interface. In addition to >>>>> the methods described in section 1-2, a diagnostic command >>>>> developer has >>>>> to provide three methods: >>>>> >>>>> int get_num_arguments() >>>>> >>>>> which returns the number of option and arguments supported by the >>>>> command. >>>>> >>>>> GrowableArray* get_argument_name_array() >>>>> >>>>> which provides the name of the arguments supported by the command. >>>>> >>>>> GrowableyArray* get_argument_info_array() >>>>> >>>>> which provides the description of each argument with a >>>>> DCmdArgumentInfo >>>>> instance. DCmdArgumentInfo is a C++ class used by the framework to >>>>> generate the sun.com.management.DcmdArgumentInfo instances. This is >>>>> done >>>>> automatically and the diagnostic command developer doesn't need to >>>>> know >>>>> how to create Java objects from the runtime. >>>>> >>>>> 4 - The Diagnostic Commands >>>>> >>>>> To avoid name collisions between diagnostic commands coming from >>>>> different projects, use of a flat name space should be avoided and >>>>> a more structured organization is recommended. The framework itself >>>>> doesn't depend on this organization, so it will be a set of rules >>>>> defining a convention in the way commands are named. >>>>> >>>>> Diagnostic commands can easily organized in a hierarchical way, so the >>>>> template for a command name can be: >>>>> >>>>> .[sub-domain.] >>>>> >>>>> This template can be extended with sub-sub-domains and so on. >>>>> >>>>> A special set of commands without domain will be reserved for the >>>>> commands related to the diagnostic framework itself, like the "help" >>>>> command. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>> >> > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From frederic.parain at oracle.com Tue Dec 13 06:32:33 2011 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 13 Dec 2011 15:32:33 +0100 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE6F573.4040802@oracle.com> References: <4ED8D93A.5050600@oracle.com 4EE10139.8020905@oracle.com> <34278e49-efbc-4370-ab36-a50331a9ff65@default> <4EE61040.5040704@oracle.com> <4EE6F573.4040802@oracle.com> Message-ID: <4EE76201.9010004@oracle.com> Hi David, Thanks for the review. Changes have been applied to this new webrev: http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.05/ My answers are in-lined below. Fred On 12/13/11 07:49 AM, David Holmes wrote: > Hi Fred, > > A couple of minor comments on the JDK side: > > HotSpotDiagnosticMXBean.java: > > Sorry if this is old ground but a query on the API design: is there a > specific reason to use Lists rather than the arrays the VM will provide? List are more convenient to use. The VM returns a jobjectArray to avoid the creation of a new dependency between the VM code and the java.util.List class. > HotSpotDiagnostic.java: > > 139 public List getDiagnosticCommandInfo( > 140 List commands) { > 141 if (commands == null) { > 142 throw new NullPointerException(); > 143 } > 144 return Arrays.asList(getDiagnosticCommandInfo0( > 145 commands.toArray(new String[commands.size()]))); > 146 } > > The explicit null check is redundant as commands.size() will be the > first thing invoked. Right. The null check has been removed. > --- > > jmm.h: > > The structs should use an indent of 2 to match the style of the file. Fixed > --- > > hotspotDiagnostic.c: > > 39 Java_sun_management_HotSpotDiagnostic_getDiagnosticCommands0 > 40 (JNIEnv *env, jobject dummy) > > Put on one line. But then it goes over the 80 columns limit. I used a formatting consistent with the dumpHeap method above. > 42 if((jmm_version > JMM_VERSION_1_2_1) > > Space after 'if' Fixed > 50 jobject getDiagnosticCommandArgumentInfoArray(JNIEnv *env, jstring > command, > 51 int num_arg) { > > Align arg with opening parentheses Fixed > 52-59, 107-112 > It is not necessary with modern C compilers to declare all variables at > the start of a block/function. You can declare them in the scope they > will be used. I agree. But I've tried to be consistent with existing code in the directory, like GcInfoBuilder.c > 61 dcmd_arg_info_array = (dcmdArgInfo*) malloc(num_arg * > sizeof(dcmdArgInfo)); > > Cast is not needed. All calls to malloc in this directory have a cast. > --- > > General: I suggest generating the javadoc for your new classes and > having an editorial check done. I spotted a couple of typos eg: > > DiagnosticCommandArgumentInfo.java: > 32 * of one parameter of diagnostic command. > ^the > DiagnosticCommandInfo.java > 89 * Returns the a list of the > ^^^^ typo These two typos have been fixed. I'm re-re-re-reading the javadoc looking for more :-) Thanks, Fred > On 13/12/2011 12:31 AM, Frederic Parain wrote: >> Hi Robert, >> >> These issues should be solved with the new webrevs: >> >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ >> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.03/ >> >> Regards, >> >> Fred >> >> On 12/ 9/11 03:17 PM, Robert Ottenhag wrote: >>> Adding to the review of jmm.h, that is modified in both the jdk part >>> and the hotspot part, these files should be identical, without any >>> differences in whitespace. >>> >>> Also, regarding whitespace and indentation, the use TAB characters in >>> many files in the jdk patch makes jcheck complain (when trying to >>> import your patch locally), and should be replaced by spaces. >>> >>> Best regards, >>> >>> /Robert >>> >>> >>>> -----Original Message----- From: Paul Hohensee Sent: Thursday, >>>> December 08, 2011 7:26 PM To: Frederic Parain Cc: >>>> serviceability-dev at openjdk.java.net; >>>> core-libs-dev at openjdk.java.net; >>>> hotspot-runtime-dev at openjdk.java.net Subject: Re: Request for >>>> Review (XXL): 7104647: Adding a diagnostic command framework >>>> >>>> For the hotspot part at >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>> >>>> Most of my comments are style-related. Nice job on the >>>> implementation architecture. >>>> >>>> In attachListener.cpp: >>>> >>>> You might want to delete the first "return JNI_OK;" line, since the >>>> code under HAS_PENDING_EXCEPTION just falls through. >>>> >>>> In jmm.h: >>>> >>>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as >>>> the existing declarations. Add a newline just before it on line >>>> 322. >>>> >>>> >>>> In diagnosticFramework.hpp: >>>> >>>> Fix indenting for lines 63-66, insert blank before "size_t" on line >>>> 48. >>>> >>>> Hotspot convention is that getter method names don't include a >>>> "get_" prefix. So, e.g., DCmdArgIter::get_key_addr() s/b >>>> DCmdArgIter::key_addr(). Similarly, getters such as is_enabled() >>>> should retrieve a field named "_is_enabled" rather than one named >>>> "enabled". You follow the "_is_enabled" convention in other places >>>> such as GenDCmdArgument. Or you could use enabled() to get the >>>> value of the _enabled field. >>>> >>>> Also generally, I'd use accessor methods in the implementation of >>>> more complex member methods rather than access the underlying >>>> fields directly. E.g. in GenDCmdArgument::read_value, I'd use >>>> is_set() and set_is_set(true), (set_is_set() is not actually >>>> defined, but should be) rather than directly accessing _is_set. >>>> Though sometimes doing this is too much of a pain with fields whose >>>> type is a template argument, as in the >>>> DCmdArggument::parse_value() method in >>>> diagnosticArgument.cpp. >>>> >>>> For easy readability, it'd be nice to line up field names (the ones >>>> with an _ prefix) at the same column. >>>> >>>> On line 200, "instanciated" -> "instantiated" >>>> >>>> On line 218, I'd use "heap_allocated" rather than "heap" for the >>>> formal arg name. >>>> >>>> On line 248, you could indent the text to start underneath >>>> "outputStream". I generally find that indenting arguments lines >>>> (formal or actual) so they line up with the first argument position >>>> make the code more readable, but I'm not religious about it. >>>> >>>> On line 265, "instanciated" -> "instantiated" >>>> >>>> DCmdFactorys are members of a singly-linked list, right? If so, >>>> it'd be good to have a comment to that effect on the declaration of >>>> _next. >>>> >>>> On line 322, insert a blank before "true". You might fix this in >>>> other places where there's no blank between a comma in an argument >>>> list and the following parameter value. >>>> >>>> >>>> In diagnosticCommandFramework.cpp: >>>> >>>> The code from lines 80-95 and 105-120 is identical. Factor out? >>>> >>>> >>>> In diagnosticArgument.cpp: >>>> >>>> On line 41, insert blanks before the actual arguments. (see above >>>> generic comment) >>>> >>>> On line 77, the "if" is indented one space too many. >>>> >>>> >>>> In management.cpp: >>>> >>>> I'd be consistent with having or not having a space between >>>> "while", "if" and "for" and the following "(" in this and your >>>> other code. Most hotspot code has a space. >>>> >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> >>>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>>> Hi All, >>>>> >>>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>>> because changes are pretty big and touch all these areas] >>>>> >>>>> Here's a framework for issuing diagnostics commands to the JVM. >>>>> Diagnostic commands are actions executed inside the JVM mainly >>>>> for monitoring or management purpose. This work has two parts. >>>>> The first part is in the hotspot repository and contains the >>>>> framework itself with two diagnostic commands. The second part is >>>>> in the JDK repository and contains the command line utility to >>>>> invoke diagnostic commands as well as the HotSpotDiagnosticMXBean >>>>> extensions. The HotSpotDiagnosticMXBean extensions allow a remote >>>>> client to discover and invoke diagnostic commands using a JMX >>>>> connection. >>>>> >>>>> This changeset only contains two diagnostic commands, more >>>>> commands will be added in the future, as a standalone effort to >>>>> improve the monitoring and management services of the JVM, or as >>>>> part of other projects. >>>>> >>>>> Webrevs are here: >>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>>> >>>>> Here's a technical description of this work: >>>>> >>>>> 1 - The Diagnostic Command Framework 1-1 Overview >>>>> >>>>> The diagnostic command framework is fully implemented in native >>>>> code and relies on the HotSpot's internal exception mechanism. >>>>> The rational of a pure native implementation is to be able to >>>>> execute diagnostic commands even in critical situations like an >>>>> OutOfMemory error. All diagnostic commands are registered in a >>>>> single list, and two flags control the way a user can interact >>>>> with them. The "hidden" flag prevents a diagnostic command from >>>>> appearing in the list of available commands returned by the >>>>> "help" command. However, it's still possible to get the detailed >>>>> help message for a hidden command with the "help " >>>>> syntax (but it requires to know the name of the hidden command). >>>>> The second flag is "enabled" and it controls if a command can be >>>>> invoked or not. When listed with the "help" commands, disabled >>>>> commands appear with a "[disabled]" label in their description. >>>>> If the user tries to invoke a disabled command, an error message >>>>> is returned and the command is not run. This error message can be >>>>> customized on a per command base. The framework just provides >>>>> these two flags with their semantic, it doesn't provide any >>>>> policy or mechanism to set or modify these flags. These actions >>>>> will be delegated to the JVM or special diagnostic commands. >>>>> >>>>> 1-2 Implementation >>>>> >>>>> All diagnostic commands are implemented as subclasses of the DCmd >>>>> class defined in services/diagnosticFramework.hpp. Here's the >>>>> layout of the DCmd class and the list of methods that a new >>>>> command has to define or overwrite: >>>>> >>>>> class DCmd { DCmd(outputStream *output); >>>>> >>>>> static const char *get_name(); >>>>> >>>>> static const char *get_description(); >>>>> >>>>> static const char *get_disabled_message(); >>>>> >>>>> static const char *get_impact(); >>>>> >>>>> static int get_num_arguments(); >>>>> >>>>> virtual void print_help(outputStream* out); >>>>> >>>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>>> >>>>> virtual void execute(TRAPS); >>>>> >>>>> virtual void reset(TRAPS); >>>>> >>>>> virtual void cleanup(); >>>>> >>>>> virtual GrowableArray* get_argument_name_array(); >>>>> >>>>> virtual GrowableArray* >>>>> get_argument_info_array(); } >>>>> >>>>> A diagnostic command is always instantiated with an outputStream >>>>> in parameter. This outputStream can point either to a file, a >>>>> buffer or a socket (see the ostream.hpp file). >>>>> >>>>> The get_name() method returns the string that will identify the >>>>> command (i.e. the string to put on the command line to invoke >>>>> it). >>>>> >>>>> The get_description() methods returns the global description of >>>>> the command. >>>>> >>>>> The get_disabled_message() returns the customized message to >>>>> return when the command is disabled, without having to >>>>> instantiate the command. >>>>> >>>>> The get_impact() returns a description of the intrusiveness of >>>>> the diagnostic command on the Java Virtual Machine behavior. The >>>>> rational for this method is that some diagnostic commands can >>>>> seriously disrupt the behavior of the Java Virtual Machine (for >>>>> instance a Thread Dump for an application with several tens of >>>>> thousands of threads, or a Head Dump with a 40GB+ heap size) and >>>>> other diagnostic commands have no serious impact on the JVM (for >>>>> instance, getting the command line arguments or the JVM version). >>>>> The recommended format for the description is: >>>>> [longer description], where the impact level is selected among >>>>> this list: {low, medium, high}. The optional longer description >>>>> can provide more specific details like the fact that Thread Dump >>>>> impact depends on the heap size. >>>>> >>>>> The get_num_arguments() returns the number of options/arguments >>>>> recognized by the diagnostic command. This method is only used by >>>>> the JMX interface support (see below). >>>>> >>>>> The print_help() methods prints a detailed help on the >>>>> outputStream passed in argument. The detailed help contains the >>>>> list of all supported options with their type and description. >>>>> >>>>> The parse() method is in charge of parsing the command arguments. >>>>> Each command is free to implement its own argument parser. >>>>> However, an argument parser framework is provided (see section >>>>> 1-3) to ease the implementation, but its use is optional. The >>>>> parse method takes a delimiter character in argument, which is >>>>> used to mark the limit between two arguments (typically >>>>> invocation from jcmd will use a space character as a delimiter >>>>> while invocation from the JVM command line parsing code will use >>>>> a comma as a delimiter). >>>>> >>>>> The execute() method is naturally the one to invoke to get the >>>>> diagnostic command executed. The parse() and the execute() >>>>> methods are dissociated, so it's a possible perform the argument >>>>> parsing in one thread, and delegate the execution to another >>>>> thread, as long as the diagnostic command doesn't reference >>>>> thread local variables. The framework allows several instances of >>>>> the same diagnostic command to be executed in parallel. If for >>>>> some reasons concurrent executions should not be allowed for a >>>>> given diagnostic command, this is the responsibility of the >>>>> diagnostic command implementor to enforce this rule, for instance >>>>> by protecting the body of the execute() method with a global >>>>> lock. >>>>> >>>>> The reset() method is used to initialize the internal fields of >>>>> the diagnostic command or to reset the internal fields to their >>>>> initial value to be able to re-use an already allocated >>>>> diagnostic command instance. >>>>> >>>>> The cleanup() method is used to perform perform cleanup (like >>>>> freeing of all memory allocated to store internal data). The DCmd >>>>> extends the ResourceObj class, so when allocated in a >>>>> ResourceArea, destructors cannot be used to perform cleanup. To >>>>> ensure that cleanup is performed in all cases, it is recommended >>>>> to create a DCmdMark instance for each DCmd instance. DCmdMark is >>>>> a stack allocated object with a pointer to a DCmd instance. When >>>>> the DCmdMark is destroyed, its destructor calls the cleanup() >>>>> method of the DCmd instance it points to. If the DCmd instance >>>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>>> memory allocated to store the DCmd instance. >>>>> >>>>> The get_argument_name_array() and get_argument_info_array() are >>>>> related to the JMX interface of the diagnostic command framework, >>>>> so they are described in section 3. >>>>> >>>>> 1-3 DCmdParser framework >>>>> >>>>> The DCmdParser class is an optional framework to help development >>>>> of argument parsers. It provides many features required by the >>>>> diagnostic command framework (generation of the help message or >>>>> the argument descriptions for the JMX interface) but all these >>>>> features can easily be re-implemented if a developer decides not >>>>> to use the DCmdParser framework. >>>>> >>>>> The DCmdParser class is relying on the DCmdArgument template. >>>>> This template must be used to define the different types of >>>>> argument the parser will have to handle. When a new >>>>> specialization of the template is done, three methods have to be >>>>> provided: >>>>> >>>>> void parse_value(const char *str,size_t len,TRAPS); void >>>>> init_value(TRAPS); void destroy_value(); >>>>> >>>>> The parse_value() method is used to convert a string into an >>>>> argument value. The print_value() method is used to display the >>>>> default value (support for the detailed help message). The >>>>> init_value() method is used to initialize or reset the argument >>>>> value. The destroy_value() method is a clean-up method (useful >>>>> when the argument has allocated some C-Heap memory to store its >>>>> value and this memory has to be freed before destroying the >>>>> DCmdArgument instance). >>>>> >>>>> The DCmdParser makes a distinction between options and >>>>> arguments. Options are identified by a key name that must appear >>>>> on the command line, while argument are identified just by the >>>>> position of the argument on the command line. Options use >>>>> the= syntax. In case of boolean options, the >>>>> '=' part of the syntax can be omitted to set the option to >>>>> true. Arguments are just sequences characters delimited by a >>>>> separator character. This separator can be specified at runtime >>>>> when invoking the diagnostic command framework. If an argument >>>>> contain a character that could be used as a delimiter, it's >>>>> possible to enclose the argument between single or double quotes. >>>>> Options are arguments are instantiated using the same >>>>> DCmdArgument class but they're registered differently to the >>>>> DCmdParser. >>>>> >>>>> The way to use the DCmdParser is to declare the parser and the >>>>> option/arguments as fields of the diagnostic command class (which >>>>> is itself a sub-class of the DCmd class), like this: >>>>> >>>>> >>>>> class EchoDCmd : public DCmd { protected: DCmdParser >>>>> _dcmdparser; >>>>> >>>>> DCmdArgument _required; >>>>> >>>>> DCmdArgument _intval; >>>>> >>>>> DCmdArgument _boolval; >>>>> >>>>> DCmdArgument _stringval; >>>>> >>>>> DCmdArgument _first_arg; >>>>> >>>>> DCmdArgument _second_arg; >>>>> >>>>> DCmdArgument _optional_arg; >>>>> >>>>> } >>>>> >>>>> The parser and the options/arguments must be initialized before >>>>> the diagnostic command class, and the options/arguments have to >>>>> be registered to the parser like this: >>>>> >>>>> EchoDCmd(outputStream *output) : DCmd(output), >>>>> _stringval("-strval","a string argument","STRING",false), >>>>> >>>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>>> >>>>> _intval("-intval","an integer argument","INTEGER",false), >>>>> >>>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>>> >>>>> _fist_arg("first argument","a string argument","STRING",true), >>>>> >>>>> _second_arg("second argument,"an integer >>>>> argument,"INTEGER",true), >>>>> >>>>> _optional_arg("optional argument","an optional string >>>>> argument","STRING","false") >>>>> >>>>> { >>>>> >>>>> _dcmdparser.add_dcmd_option(&_stringval) >>>>> >>>>> _dcmdparser.add_dcmd_option(&_boolval); >>>>> >>>>> _dcmdparser.add_dcmd_option(&_intval); >>>>> >>>>> _dcmdparser.add_dcmd_option(&_required); >>>>> >>>>> _dcmdparser.add_argument(&_first_arg); >>>>> >>>>> _dcmdparser.add_argument(&_second_arg); >>>>> >>>>> _dcmdparser.add_argument(&_optional_arg); }; >>>>> >>>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add >>>>> an argument/option to the parser. The option/argument constructor >>>>> takes the name of the option/argument, its description, a string >>>>> describing its type and a boolean to specify if the >>>>> option/argument is mandatory or not. The parser doesn't support >>>>> option/argument duplicates (having the same name) but the code >>>>> currently doesn't check for duplicates.The order used to register >>>>> options has no impact on the parser. However, the order used to >>>>> register arguments is critical because the parser will use the >>>>> same order to parse the command line. In the example above, the >>>>> parser expects to have a first argument of type STRING (parsed >>>>> using _first_arg), then a second argument of type INTEGER (parsed >>>>> using _second_arg) and optionally a third parameter of type >>>>> STRING (parsed using _optional_arg). A mandatory option or >>>>> argument has to be specify every time the command is invoked. If >>>>> it is missing, an exception is thrown at the end of the parsing. >>>>> Optional arguments have to be registered after mandatory >>>>> arguments. An optional argument will be considered for parsing >>>>> only if all arguments before it (mandatory or not) have already >>>>> been used to parse the command line. >>>>> >>>>> The DCmdParser and its DCmdArgument instances are embedded in the >>>>> DCmd instance. The rational for this design is to limit the >>>>> number of C-heap allocations but also to be able to pre-allocate >>>>> diagnostic command instances for critical situations. If the >>>>> process is running out of C-heap space, it's not possible to >>>>> instantiate new diagnostic commands to troubleshoot the >>>>> situation. By pre-allocating some diagnostic commands, it will be >>>>> possible to run them even in this critical situation. Of course, >>>>> the diagnostic command itself should not try to allocate memory >>>>> during its execution, this prevents the diagnostic command to use >>>>> variable length arguments like strings. By nature, pre-allocated >>>>> diagnostic commands aim to be re-usable, this is the purpose of >>>>> the reset() method which restores the default status of all >>>>> arguments. >>>>> >>>>> 1-4 Internal invocation >>>>> >>>>> Using a diagnostic command from the JVM itself is pretty easy: >>>>> instantiate the class and invoke the parse() method then the >>>>> execute() method. A diagnostic command can be instantiated from >>>>> inside the JVM even it is not registered. This is a difference >>>>> with the external invocations (from jcmd or JMX) that require the >>>>> command to be >>>> registered. >>>>> >>>>> 2 - The JCmd interface >>>>> >>>>> Diagnostic commands can also be invoked from outside the JVM >>>>> process, using the new 'jcmd' utility. The jcmd program uses the >>>>> attach API to connect to the JVM, send requests and receive >>>>> results. The jcmd utility must be launched on the same machine >>>>> than the one running the JVM (its a local tool). Launched without >>>>> arguments, jcmd displays a list of all JVMs running on the >>>>> machine. The jcmd source code is in the jdk repository like other >>>>> existing j* tools. >>>>> >>>>> To execute a diagnostic command in a particular JVM, the generic >>>>> syntax is: >>>>> >>>>> jcmd [arguments] >>>>> >>>>> The attachListener has been modified to recognized the jcmd >>>>> requests. When a jcmd request is identified, it is parsed to >>>>> extract the command name. The JVM performs a look up of this >>>>> command in a list of registered commands. To be executable by an >>>>> external request, a diagnostic command has to be registered. The >>>>> registration is performed with the DCmdFactory class (see >>>>> services/management.cpp). >>>>> >>>>> 3 - The JMX interface >>>>> >>>>> The framework provides a JMX based interface to the diagnostic >>>>> commands. This interface allows remote invocation of diagnostic >>>>> commands through a JMX connection. >>>>> >>>>> 3-1 The interface >>>>> >>>>> The information related to the diagnostic commands are >>>>> accessible through new methods added to the >>>>> com.sun.management.HotspotDiagnosticMXBean: >>>>> >>>>> public List getDiagnosticCommands(); >>>>> >>>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String >>>>> command); >>>>> >>>>> public List >>>>> getDiagnosticCommandInfo(List command); >>>>> >>>>> public List getDiagnosticCommandInfo(); >>>>> >>>>> public String execute(String commandLine) throws >>>>> IllegalArgumentException ; >>>>> >>>>> public String execute(String cmd, String... arguments) throws >>>>> IllegalArgumentException; >>>>> >>>>> >>>>> The getDiagnosticCommands() method returns an array containing >>>>> the names of the not-hidden registered diagnostic commands. >>>>> >>>>> The three getDiagnosticCommandInfo() methods return one or >>>>> several diagnostic command descriptions using the >>>>> DiagnosticCommandInfo class. >>>>> >>>>> The two execute() methods allow the user the invoke a diagnostic >>>>> command in different ways. >>>>> >>>>> The DiagnosticCommandInfo class is describing a diagnostic >>>>> command with the following information: >>>>> >>>>> public class DiagnosticCommandInfo { >>>>> >>>>> public String getName(); >>>>> >>>>> public String getDescription(); >>>>> >>>>> public String getImpact(); >>>>> >>>>> public boolean isEnabled(); >>>>> >>>>> public List getArgumentsInfo(); >>>>> } >>>>> >>>>> The getName() method returns the name of the diagnostic command. >>>>> This name is the one to use in execute() methods to invoke the >>>>> diagnostic command. >>>>> >>>>> The getDescription() method returns a general description of the >>>>> diagnostic command. >>>>> >>>>> The getImpact() method returns a description of the intrusiveness >>>>> of diagnostic command. >>>>> >>>>> The isEnabled() method returns true if the method is enabled, >>>>> false if it is disabled. A disabled method cannot be executed. >>>>> >>>>> The getArgumentsInfo() returns a list of descriptions for the >>>>> options or arguments recognized by the diagnostic command. Each >>>>> option/argument is described by a DiagnosticCommandArgumentInfo >>>>> instance: >>>>> >>>>> public class DiagnosticCommandArgumentInfo { >>>>> >>>>> public String getName(); >>>>> >>>>> public String getDescription(); >>>>> >>>>> public String getType(); >>>>> >>>>> public String getDefault(); >>>>> >>>>> public boolean isMandatory(); >>>>> >>>>> public boolean isOption(); >>>>> >>>>> public int getPosition(); } >>>>> >>>>> If the DiagnosticCommandArgumentInfo instance describes an >>>>> option, isOption() returns true and getPosition() returns -1. >>>>> Otherwise, when the DiagnosticCommandArgumentInfo instance >>>>> describes an argument, isOption() returns false and getPosition() >>>>> returns the expected position for this argument. The position of >>>>> an argument is defined relatively to all arguments passed on the >>>>> command line, options are not considered when defining an >>>>> argument position. The getDefault() method returns the default >>>>> value of the argument if a default has been defined, otherwise it >>>>> returns null. >>>>> >>>>> 3-2 The implementation >>>>> >>>>> The framework has been designed in a way that prevents >>>>> diagnostic command developers to worry about the JMX interface. >>>>> In addition to the methods described in section 1-2, a diagnostic >>>>> command developer has to provide three methods: >>>>> >>>>> int get_num_arguments() >>>>> >>>>> which returns the number of option and arguments supported by >>>>> the command. >>>>> >>>>> GrowableArray* get_argument_name_array() >>>>> >>>>> which provides the name of the arguments supported by the >>>>> command. >>>>> >>>>> GrowableyArray* get_argument_info_array() >>>>> >>>>> which provides the description of each argument with a >>>>> DCmdArgumentInfo instance. DCmdArgumentInfo is a C++ class used >>>>> by the framework to generate the >>>>> sun.com.management.DcmdArgumentInfo instances. This is done >>>>> automatically and the diagnostic command developer doesn't need >>>>> to know how to create Java objects from the runtime. >>>>> >>>>> 4 - The Diagnostic Commands >>>>> >>>>> To avoid name collisions between diagnostic commands coming from >>>>> different projects, use of a flat name space should be avoided >>>>> and a more structured organization is recommended. The framework >>>>> itself doesn't depend on this organization, so it will be a set >>>>> of rules defining a convention in the way commands are named. >>>>> >>>>> Diagnostic commands can easily organized in a hierarchical way, >>>>> so the template for a command name can be: >>>>> >>>>> .[sub-domain.] >>>>> >>>>> This template can be extended with sub-sub-domains and so on. >>>>> >>>>> A special set of commands without domain will be reserved for >>>>> the commands related to the diagnostic framework itself, like the >>>>> "help" command. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >> -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From serguei.spitsyn at oracle.com Tue Dec 13 01:43:27 2011 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 13 Dec 2011 01:43:27 -0800 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE6243B.6070200@oracle.com> References: <4ED8D93A.5050600@oracle.com> <4EE10139.8020905@oracle.com> <4EE60FD4.3040404@oracle.com> <4EE6243B.6070200@oracle.com> Message-ID: <4EE71E3F.9010703@oracle.com> Hi Frederik, Your fix is already in a good shape! src/share/vm/services/management.cpp: It is better to have different diagnostic messages at lines 2181 and 2186 so that it is easy to find out what of the two lines caused an exception. The messages would be better to be more specific. The same applies to the lines 2221 and 2226. Indent must be aligned with the first argument above. 2178 oop cmd = JNIHandles::resolve_external_guard(command); 2179 if (cmd == NULL) { 2180 THROW_MSG(vmSymbols::java_lang_NullPointerException(), 2181 "Command line cannot be null."); 2182 } 2183 char* cmd_name = java_lang_String::as_utf8_string(cmd); 2184 if (cmd_name == NULL) { 2185 THROW_MSG(vmSymbols::java_lang_NullPointerException(), 2186 "Command line cannot be null."); 2187 } ... 2219 if (cmd == NULL) { 2220 THROW_MSG_NULL(vmSymbols::java_lang_NullPointerException(), 2221 "Command line cannot be null."); 2222 } 2223 char* cmdline = java_lang_String::as_utf8_string(cmd); 2224 if (cmdline == NULL) { 2225 THROW_MSG_NULL(vmSymbols::java_lang_NullPointerException(), 2226 "Command line cannot be null."); 2227 } The lines 2189 and 2194 look redundant: src/share/vm/services/diagnosticFramework.cpp: 2188 DCmd* dcmd = NULL; 2189 { 2190 DCmdFactory*factory = DCmdFactory::factory(cmd_name, strlen(cmd_name)); 2191 if (factory != NULL) { 2192 dcmd = factory->create_resource_instance(NULL); 2193 } 2194 } Indent is not correct at the lines 2205-2211: 2204 for (int i = 0; i< array->length(); i++) { 2205 infoArray[i].name = array->at(i)->name(); 2206 infoArray[i].description = array->at(i)->description(); 2207 infoArray[i].type = array->at(i)->type(); 2208 infoArray[i].default_string = array->at(i)->default_string(); 2209 infoArray[i].mandatory = array->at(i)->is_mandatory(); 2210 infoArray[i].option = array->at(i)->is_option(); 2211 infoArray[i].position = array->at(i)->position(); 2212 } Space is missed after 'while': 320 while(arg != NULL) { 326 while(arg != NULL) { Thanks, Serguei On 12/12/11 7:56 AM, Frederic Parain wrote: > Minor updates: > http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.04/ > > Fred > > On 12/12/11 03:29 PM, Frederic Parain wrote: >> Hi Paul, >> >> Thank you for the review. >> I've applied all your recommendations except the refactoring >> in diagnosticCommandFramework.cpp (too few lines can be really >> factored out without passing many arguments). >> >> New webrev is here: >> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ >> >> Regards, >> >> Fred >> >> On 12/ 8/11 07:26 PM, Paul Hohensee wrote: >>> For the hotspot part at >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>> >>> Most of my comments are style-related. Nice job on the implementation >>> architecture. >>> >>> In attachListener.cpp: >>> >>> You might want to delete the first "return JNI_OK;" line, since the >>> code >>> under >>> HAS_PENDING_EXCEPTION just falls through. >>> >>> In jmm.h: >>> >>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as the >>> existing declarations. Add a newline just before it on line 322. >>> >>> >>> In diagnosticFramework.hpp: >>> >>> Fix indenting for lines 63-66, insert blank before "size_t" on line 48. >>> >>> Hotspot convention is that getter method names don't include a "get_" >>> prefix. >>> So, e.g., DCmdArgIter::get_key_addr() s/b DCmdArgIter::key_addr(). >>> Similarly, getters such as is_enabled() should retrieve a field named >>> "_is_enabled" >>> rather than one named "enabled". You follow the "_is_enabled" >>> convention >>> in other places such as GenDCmdArgument. Or you could use enabled() to >>> get the value of the _enabled field. >>> >>> Also generally, I'd use accessor methods in the implementation of more >>> complex member methods rather than access the underlying fields >>> directly. >>> E.g. in GenDCmdArgument::read_value, I'd use is_set() and >>> set_is_set(true), >>> (set_is_set() is not actually defined, but should be) rather than >>> directly >>> accessing _is_set. Though sometimes doing this is too much of a pain >>> with fields whose type is a template argument, as in the >>> DCmdArggument::parse_value() method in diagnosticArgument.cpp. >>> >>> For easy readability, it'd be nice to line up field names (the ones >>> with an >>> _ prefix) at the same column. >>> >>> On line 200, "instanciated" -> "instantiated" >>> >>> On line 218, I'd use "heap_allocated" rather than "heap" for the formal >>> arg name. >>> >>> On line 248, you could indent the text to start underneath >>> "outputStream". >>> I generally find that indenting arguments lines (formal or actual) so >>> they line >>> up with the first argument position make the code more readable, but >>> I'm >>> not >>> religious about it. >>> >>> On line 265, "instanciated" -> "instantiated" >>> >>> DCmdFactorys are members of a singly-linked list, right? If so, it'd be >>> good to >>> have a comment to that effect on the declaration of _next. >>> >>> On line 322, insert a blank before "true". You might fix this in other >>> places >>> where there's no blank between a comma in an argument list and the >>> following parameter value. >>> >>> >>> In diagnosticCommandFramework.cpp: >>> >>> The code from lines 80-95 and 105-120 is identical. Factor out? >>> >>> >>> In diagnosticArgument.cpp: >>> >>> On line 41, insert blanks before the actual arguments. (see above >>> generic comment) >>> >>> On line 77, the "if" is indented one space too many. >>> >>> >>> In management.cpp: >>> >>> I'd be consistent with having or not having a space between "while", >>> "if" and "for" >>> and the following "(" in this and your other code. Most hotspot code >>> has >>> a space. >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>> Hi All, >>>> >>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>> because changes are pretty big and touch all these areas] >>>> >>>> Here's a framework for issuing diagnostics commands to the JVM. >>>> Diagnostic commands are actions executed inside the JVM mainly >>>> for monitoring or management purpose. This work has two parts. >>>> The first part is in the hotspot repository and contains the >>>> framework itself with two diagnostic commands. The second >>>> part is in the JDK repository and contains the command line >>>> utility to invoke diagnostic commands as well as the >>>> HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean >>>> extensions allow a remote client to discover and invoke >>>> diagnostic commands using a JMX connection. >>>> >>>> This changeset only contains two diagnostic commands, more >>>> commands will be added in the future, as a standalone effort >>>> to improve the monitoring and management services of the >>>> JVM, or as part of other projects. >>>> >>>> Webrevs are here: >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>> >>>> Here's a technical description of this work: >>>> >>>> 1 - The Diagnostic Command Framework >>>> 1-1 Overview >>>> >>>> The diagnostic command framework is fully implemented in native code >>>> and relies on the HotSpot's internal exception mechanism. >>>> The rational of a pure native implementation is to be able to execute >>>> diagnostic commands even in critical situations like an OutOfMemory >>>> error. All diagnostic commands are registered in a single list, and >>>> two >>>> flags control the way a user can interact with them. The "hidden" flag >>>> prevents a diagnostic command from appearing in the list of available >>>> commands returned by the "help" command. However, it's still >>>> possible to >>>> get the detailed help message for a hidden command with the "help >>>> " syntax (but it requires to know the name of the hidden >>>> command). The second flag is "enabled" and it controls if a command >>>> can >>>> be invoked or not. When listed with the "help" commands, disabled >>>> commands appear with a "[disabled]" label in their description. If the >>>> user tries to invoke a disabled command, an error message is returned >>>> and the command is not run. This error message can be customized on a >>>> per command base. The framework just provides these two flags with >>>> their >>>> semantic, it doesn't provide any policy or mechanism to set or modify >>>> these flags. These actions will be delegated to the JVM or special >>>> diagnostic commands. >>>> >>>> 1-2 Implementation >>>> >>>> All diagnostic commands are implemented as subclasses of the DCmd >>>> class >>>> defined in services/diagnosticFramework.hpp. Here's the layout of the >>>> DCmd class and the list of methods that a new command has to define or >>>> overwrite: >>>> >>>> class DCmd { >>>> DCmd(outputStream *output); >>>> >>>> static const char *get_name(); >>>> >>>> static const char *get_description(); >>>> >>>> static const char *get_disabled_message(); >>>> >>>> static const char *get_impact(); >>>> >>>> static int get_num_arguments(); >>>> >>>> virtual void print_help(outputStream* out); >>>> >>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>> >>>> virtual void execute(TRAPS); >>>> >>>> virtual void reset(TRAPS); >>>> >>>> virtual void cleanup(); >>>> >>>> virtual GrowableArray* get_argument_name_array(); >>>> >>>> virtual GrowableArray* get_argument_info_array(); >>>> } >>>> >>>> A diagnostic command is always instantiated with an outputStream in >>>> parameter. This outputStream can point either to a file, a buffer or a >>>> socket (see the ostream.hpp file). >>>> >>>> The get_name() method returns the string that will identify the >>>> command >>>> (i.e. the string to put on the command line to invoke it). >>>> >>>> The get_description() methods returns the global description of the >>>> command. >>>> >>>> The get_disabled_message() returns the customized message to return >>>> when >>>> the command is disabled, without having to instantiate the command. >>>> >>>> The get_impact() returns a description of the intrusiveness of the >>>> diagnostic command on the Java Virtual Machine behavior. The rational >>>> for this method is that some diagnostic commands can seriously disrupt >>>> the behavior of the Java Virtual Machine (for instance a Thread >>>> Dump for >>>> an application with several tens of thousands of threads, or a Head >>>> Dump >>>> with a 40GB+ heap size) and other diagnostic commands have no serious >>>> impact on the JVM (for instance, getting the command line arguments or >>>> the JVM version). The recommended format for the description is >>>> >>> level>: [longer description], where the impact level is selected among >>>> this list: {low, medium, high}. The optional longer description can >>>> provide more specific details like the fact that Thread Dump impact >>>> depends on the heap size. >>>> >>>> The get_num_arguments() returns the number of options/arguments >>>> recognized by the diagnostic command. This method is only used by the >>>> JMX interface support (see below). >>>> >>>> The print_help() methods prints a detailed help on the outputStream >>>> passed in argument. The detailed help contains the list of all >>>> supported >>>> options with their type and description. >>>> >>>> The parse() method is in charge of parsing the command arguments. Each >>>> command is free to implement its own argument parser. However, an >>>> argument parser framework is provided (see section 1-3) to ease the >>>> implementation, but its use is optional. The parse method takes a >>>> delimiter character in argument, which is used to mark the limit >>>> between >>>> two arguments (typically invocation from jcmd will use a space >>>> character >>>> as a delimiter while invocation from the JVM command line parsing code >>>> will use a comma as a delimiter). >>>> >>>> The execute() method is naturally the one to invoke to get the >>>> diagnostic command executed. The parse() and the execute() methods are >>>> dissociated, so it's a possible perform the argument parsing in one >>>> thread, and delegate the execution to another thread, as long as the >>>> diagnostic command doesn't reference thread local variables. The >>>> framework allows several instances of the same diagnostic command >>>> to be >>>> executed in parallel. If for some reasons concurrent executions should >>>> not be allowed for a given diagnostic command, this is the >>>> responsibility of the diagnostic command implementor to enforce this >>>> rule, for instance by protecting the body of the execute() method >>>> with a >>>> global lock. >>>> >>>> The reset() method is used to initialize the internal fields of the >>>> diagnostic command or to reset the internal fields to their initial >>>> value to be able to re-use an already allocated diagnostic command >>>> instance. >>>> >>>> The cleanup() method is used to perform perform cleanup (like >>>> freeing of >>>> all memory allocated to store internal data). The DCmd extends the >>>> ResourceObj class, so when allocated in a ResourceArea, destructors >>>> cannot be used to perform cleanup. To ensure that cleanup is performed >>>> in all cases, it is recommended to create a DCmdMark instance for each >>>> DCmd instance. DCmdMark is a stack allocated object with a pointer >>>> to a >>>> DCmd instance. When the DCmdMark is destroyed, its destructor calls >>>> the >>>> cleanup() method of the DCmd instance it points to. If the DCmd >>>> instance >>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>> memory >>>> allocated to store the DCmd instance. >>>> >>>> The get_argument_name_array() and get_argument_info_array() are >>>> related >>>> to the JMX interface of the diagnostic command framework, so they are >>>> described in section 3. >>>> >>>> 1-3 DCmdParser framework >>>> >>>> The DCmdParser class is an optional framework to help development of >>>> argument parsers. It provides many features required by the diagnostic >>>> command framework (generation of the help message or the argument >>>> descriptions for the JMX interface) but all these features can >>>> easily be >>>> re-implemented if a developer decides not to use the DCmdParser >>>> framework. >>>> >>>> The DCmdParser class is relying on the DCmdArgument template. This >>>> template must be used to define the different types of argument the >>>> parser will have to handle. When a new specialization of the >>>> template is >>>> done, three methods have to be provided: >>>> >>>> void parse_value(const char *str,size_t len,TRAPS); >>>> void init_value(TRAPS); >>>> void destroy_value(); >>>> >>>> The parse_value() method is used to convert a string into an argument >>>> value. The print_value() method is used to display the default value >>>> (support for the detailed help message). The init_value() method is >>>> used >>>> to initialize or reset the argument value. The destroy_value() >>>> method is >>>> a clean-up method (useful when the argument has allocated some C-Heap >>>> memory to store its value and this memory has to be freed before >>>> destroying the DCmdArgument instance). >>>> >>>> The DCmdParser makes a distinction between options and arguments. >>>> Options are identified by a key name that must appear on the command >>>> line, while argument are identified just by the position of the >>>> argument >>>> on the command line. Options use the = syntax. In case of >>>> boolean options, the '=' part of the syntax can be omitted >>>> to set >>>> the option to true. Arguments are just sequences characters >>>> delimited by >>>> a separator character. This separator can be specified at runtime when >>>> invoking the diagnostic command framework. If an argument contain a >>>> character that could be used as a delimiter, it's possible to enclose >>>> the argument between single or double quotes. Options are arguments >>>> are >>>> instantiated using the same DCmdArgument class but they're registered >>>> differently to the DCmdParser. >>>> >>>> The way to use the DCmdParser is to declare the parser and the >>>> option/arguments as fields of the diagnostic command class (which is >>>> itself a sub-class of the DCmd class), like this: >>>> >>>> >>>> class EchoDCmd : public DCmd { >>>> protected: >>>> DCmdParser _dcmdparser; >>>> >>>> DCmdArgument _required; >>>> >>>> DCmdArgument _intval; >>>> >>>> DCmdArgument _boolval; >>>> >>>> DCmdArgument _stringval; >>>> >>>> DCmdArgument _first_arg; >>>> >>>> DCmdArgument _second_arg; >>>> >>>> DCmdArgument _optional_arg; >>>> >>>> } >>>> >>>> The parser and the options/arguments must be initialized before the >>>> diagnostic command class, and the options/arguments have to be >>>> registered to the parser like this: >>>> >>>> EchoDCmd(outputStream *output) : DCmd(output), >>>> _stringval("-strval","a string argument","STRING",false), >>>> >>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>> >>>> _intval("-intval","an integer argument","INTEGER",false), >>>> >>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>> >>>> _fist_arg("first argument","a string argument","STRING",true), >>>> >>>> _second_arg("second argument,"an integer argument,"INTEGER",true), >>>> >>>> _optional_arg("optional argument","an optional string >>>> argument","STRING","false") >>>> >>>> { >>>> >>>> _dcmdparser.add_dcmd_option(&_stringval) >>>> >>>> _dcmdparser.add_dcmd_option(&_boolval); >>>> >>>> _dcmdparser.add_dcmd_option(&_intval); >>>> >>>> _dcmdparser.add_dcmd_option(&_required); >>>> >>>> _dcmdparser.add_argument(&_first_arg); >>>> >>>> _dcmdparser.add_argument(&_second_arg); >>>> >>>> _dcmdparser.add_argument(&_optional_arg); >>>> }; >>>> >>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add an >>>> argument/option to the parser. The option/argument constructor >>>> takes the >>>> name of the option/argument, its description, a string describing its >>>> type and a boolean to specify if the option/argument is mandatory or >>>> not. The parser doesn't support option/argument duplicates (having the >>>> same name) but the code currently doesn't check for duplicates.The >>>> order >>>> used to register options has no impact on the parser. However, the >>>> order >>>> used to register arguments is critical because the parser will use the >>>> same order to parse the command line. In the example above, the parser >>>> expects to have a first argument of type STRING (parsed using >>>> _first_arg), then a second argument of type INTEGER (parsed using >>>> _second_arg) and optionally a third parameter of type STRING (parsed >>>> using _optional_arg). A mandatory option or argument has to be specify >>>> every time the command is invoked. If it is missing, an exception is >>>> thrown at the end of the parsing. Optional arguments have to be >>>> registered after mandatory arguments. An optional argument will be >>>> considered for parsing only if all arguments before it (mandatory or >>>> not) have already been used to parse the command line. >>>> >>>> The DCmdParser and its DCmdArgument instances are embedded in the DCmd >>>> instance. The rational for this design is to limit the number of >>>> C-heap >>>> allocations but also to be able to pre-allocate diagnostic command >>>> instances for critical situations. If the process is running out of >>>> C-heap space, it's not possible to instantiate new diagnostic commands >>>> to troubleshoot the situation. By pre-allocating some diagnostic >>>> commands, it will be possible to run them even in this critical >>>> situation. Of course, the diagnostic command itself should not try to >>>> allocate memory during its execution, this prevents the diagnostic >>>> command to use variable length arguments like strings. By nature, >>>> pre-allocated diagnostic commands aim to be re-usable, this is the >>>> purpose of the reset() method which restores the default status of all >>>> arguments. >>>> >>>> 1-4 Internal invocation >>>> >>>> Using a diagnostic command from the JVM itself is pretty easy: >>>> instantiate the class and invoke the parse() method then the execute() >>>> method. A diagnostic command can be instantiated from inside the JVM >>>> even it is not registered. This is a difference with the external >>>> invocations (from jcmd or JMX) that require the command to be >>>> registered. >>>> >>>> 2 - The JCmd interface >>>> >>>> Diagnostic commands can also be invoked from outside the JVM process, >>>> using the new 'jcmd' utility. The jcmd program uses the attach API >>>> to connect to the JVM, send requests and receive results. The >>>> jcmd utility must be launched on the same machine than the one running >>>> the JVM (its a local tool). Launched without arguments, jcmd >>>> displays a >>>> list of all JVMs running on the machine. The jcmd source code is in >>>> the jdk repository like other existing j* tools. >>>> >>>> To execute a diagnostic command in a particular JVM, the generic >>>> syntax is: >>>> >>>> jcmd [arguments] >>>> >>>> The attachListener has been modified to recognized the jcmd requests. >>>> When a jcmd request is identified, it is parsed to extract the command >>>> name. The JVM performs a look up of this command in a list of >>>> registered >>>> commands. To be executable by an external request, a diagnostic >>>> command >>>> has to be registered. The registration is performed with the >>>> DCmdFactory >>>> class (see services/management.cpp). >>>> >>>> 3 - The JMX interface >>>> >>>> The framework provides a JMX based interface to the diagnostic >>>> commands. >>>> This interface allows remote invocation of diagnostic commands >>>> through a >>>> JMX connection. >>>> >>>> 3-1 The interface >>>> >>>> The information related to the diagnostic commands are accessible >>>> through new methods added to the >>>> com.sun.management.HotspotDiagnosticMXBean: >>>> >>>> public List getDiagnosticCommands(); >>>> >>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String command); >>>> >>>> public List >>>> getDiagnosticCommandInfo(List >>>> command); >>>> >>>> public List getDiagnosticCommandInfo(); >>>> >>>> public String execute(String commandLine) throws >>>> IllegalArgumentException ; >>>> >>>> public String execute(String cmd, String... arguments) >>>> throws IllegalArgumentException; >>>> >>>> >>>> The getDiagnosticCommands() method returns an array containing the >>>> names >>>> of the not-hidden registered diagnostic commands. >>>> >>>> The three getDiagnosticCommandInfo() methods return one or several >>>> diagnostic command descriptions using the DiagnosticCommandInfo class. >>>> >>>> The two execute() methods allow the user the invoke a diagnostic >>>> command >>>> in different ways. >>>> >>>> The DiagnosticCommandInfo class is describing a diagnostic command >>>> with >>>> the following information: >>>> >>>> public class DiagnosticCommandInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getImpact(); >>>> >>>> public boolean isEnabled(); >>>> >>>> public List getArgumentsInfo(); >>>> } >>>> >>>> The getName() method returns the name of the diagnostic command. This >>>> name is the one to use in execute() methods to invoke the diagnostic >>>> command. >>>> >>>> The getDescription() method returns a general description of the >>>> diagnostic command. >>>> >>>> The getImpact() method returns a description of the intrusiveness of >>>> diagnostic command. >>>> >>>> The isEnabled() method returns true if the method is enabled, false if >>>> it is disabled. A disabled method cannot be executed. >>>> >>>> The getArgumentsInfo() returns a list of descriptions for the >>>> options or >>>> arguments recognized by the diagnostic command. Each >>>> option/argument is >>>> described by a DiagnosticCommandArgumentInfo instance: >>>> >>>> public class DiagnosticCommandArgumentInfo { >>>> >>>> public String getName(); >>>> >>>> public String getDescription(); >>>> >>>> public String getType(); >>>> >>>> public String getDefault(); >>>> >>>> public boolean isMandatory(); >>>> >>>> public boolean isOption(); >>>> >>>> public int getPosition(); >>>> } >>>> >>>> If the DiagnosticCommandArgumentInfo instance describes an option, >>>> isOption() returns true and getPosition() returns -1. Otherwise, when >>>> the DiagnosticCommandArgumentInfo instance describes an argument, >>>> isOption() returns false and getPosition() returns the expected >>>> position >>>> for this argument. The position of an argument is defined >>>> relatively to >>>> all arguments passed on the command line, options are not considered >>>> when defining an argument position. The getDefault() method returns >>>> the >>>> default value of the argument if a default has been defined, otherwise >>>> it returns null. >>>> >>>> 3-2 The implementation >>>> >>>> The framework has been designed in a way that prevents diagnostic >>>> command developers to worry about the JMX interface. In addition to >>>> the methods described in section 1-2, a diagnostic command >>>> developer has >>>> to provide three methods: >>>> >>>> int get_num_arguments() >>>> >>>> which returns the number of option and arguments supported by the >>>> command. >>>> >>>> GrowableArray* get_argument_name_array() >>>> >>>> which provides the name of the arguments supported by the command. >>>> >>>> GrowableyArray* get_argument_info_array() >>>> >>>> which provides the description of each argument with a >>>> DCmdArgumentInfo >>>> instance. DCmdArgumentInfo is a C++ class used by the framework to >>>> generate the sun.com.management.DcmdArgumentInfo instances. This is >>>> done >>>> automatically and the diagnostic command developer doesn't need to >>>> know >>>> how to create Java objects from the runtime. >>>> >>>> 4 - The Diagnostic Commands >>>> >>>> To avoid name collisions between diagnostic commands coming from >>>> different projects, use of a flat name space should be avoided and >>>> a more structured organization is recommended. The framework itself >>>> doesn't depend on this organization, so it will be a set of rules >>>> defining a convention in the way commands are named. >>>> >>>> Diagnostic commands can easily organized in a hierarchical way, so the >>>> template for a command name can be: >>>> >>>> .[sub-domain.] >>>> >>>> This template can be extended with sub-sub-domains and so on. >>>> >>>> A special set of commands without domain will be reserved for the >>>> commands related to the diagnostic framework itself, like the "help" >>>> command. >>>> >>>> >>>> Thanks, >>>> >>>> Fred >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111213/8d3bb98f/attachment-0001.html From david.holmes at oracle.com Tue Dec 13 17:02:40 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2011 11:02:40 +1000 Subject: Request for Review (XXL): 7104647: Adding a diagnostic command framework In-Reply-To: <4EE76201.9010004@oracle.com> References: <4ED8D93A.5050600@oracle.com 4EE10139.8020905@oracle.com> <34278e49-efbc-4370-ab36-a50331a9ff65@default> <4EE61040.5040704@oracle.com> <4EE6F573.4040802@oracle.com> <4EE76201.9010004@oracle.com> Message-ID: <4EE7F5B0.90405@oracle.com> Thanks Fred. I don't think maintaining the style of existing code needs to extend to all aspects of that code but is more about general layout, spacing and naming. So adding unnecessary casts to malloc, or declaring all variables at the start of the method are not things that need to be repeated forever in my opinion. But I won't push for further changes. Cheers, David On 14/12/2011 12:32 AM, Frederic Parain wrote: > Hi David, > > Thanks for the review. > > Changes have been applied to this new webrev: > http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.05/ > > My answers are in-lined below. > > Fred > > On 12/13/11 07:49 AM, David Holmes wrote: >> Hi Fred, >> >> A couple of minor comments on the JDK side: >> >> HotSpotDiagnosticMXBean.java: >> >> Sorry if this is old ground but a query on the API design: is there a >> specific reason to use Lists rather than the arrays the VM will provide? > > List are more convenient to use. > The VM returns a jobjectArray to avoid the creation of a new dependency > between the VM code and the java.util.List class. > >> HotSpotDiagnostic.java: >> >> 139 public List getDiagnosticCommandInfo( >> 140 List commands) { >> 141 if (commands == null) { >> 142 throw new NullPointerException(); >> 143 } >> 144 return Arrays.asList(getDiagnosticCommandInfo0( >> 145 commands.toArray(new String[commands.size()]))); >> 146 } >> >> The explicit null check is redundant as commands.size() will be the >> first thing invoked. > > Right. The null check has been removed. > >> --- >> >> jmm.h: >> >> The structs should use an indent of 2 to match the style of the file. > > Fixed > >> --- >> >> hotspotDiagnostic.c: >> >> 39 Java_sun_management_HotSpotDiagnostic_getDiagnosticCommands0 >> 40 (JNIEnv *env, jobject dummy) >> >> Put on one line. > > But then it goes over the 80 columns limit. I used a formatting > consistent with the dumpHeap method above. > >> 42 if((jmm_version > JMM_VERSION_1_2_1) >> >> Space after 'if' > > Fixed > >> 50 jobject getDiagnosticCommandArgumentInfoArray(JNIEnv *env, jstring >> command, >> 51 int num_arg) { >> >> Align arg with opening parentheses > > Fixed > >> 52-59, 107-112 >> It is not necessary with modern C compilers to declare all variables at >> the start of a block/function. You can declare them in the scope they >> will be used. > > I agree. But I've tried to be consistent with existing code in the > directory, like GcInfoBuilder.c > >> 61 dcmd_arg_info_array = (dcmdArgInfo*) malloc(num_arg * >> sizeof(dcmdArgInfo)); >> >> Cast is not needed. > > All calls to malloc in this directory have a cast. > >> --- >> >> General: I suggest generating the javadoc for your new classes and >> having an editorial check done. I spotted a couple of typos eg: >> >> DiagnosticCommandArgumentInfo.java: >> 32 * of one parameter of diagnostic command. >> ^the >> DiagnosticCommandInfo.java >> 89 * Returns the a list of the >> ^^^^ typo > > These two typos have been fixed. I'm re-re-re-reading the javadoc > looking for more :-) > > Thanks, > > Fred > >> On 13/12/2011 12:31 AM, Frederic Parain wrote: >>> Hi Robert, >>> >>> These issues should be solved with the new webrevs: >>> >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/ >>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.03/ >>> >>> Regards, >>> >>> Fred >>> >>> On 12/ 9/11 03:17 PM, Robert Ottenhag wrote: >>>> Adding to the review of jmm.h, that is modified in both the jdk part >>>> and the hotspot part, these files should be identical, without any >>>> differences in whitespace. >>>> >>>> Also, regarding whitespace and indentation, the use TAB characters in >>>> many files in the jdk patch makes jcheck complain (when trying to >>>> import your patch locally), and should be replaced by spaces. >>>> >>>> Best regards, >>>> >>>> /Robert >>>> >>>> >>>>> -----Original Message----- From: Paul Hohensee Sent: Thursday, >>>>> December 08, 2011 7:26 PM To: Frederic Parain Cc: >>>>> serviceability-dev at openjdk.java.net; >>>>> core-libs-dev at openjdk.java.net; >>>>> hotspot-runtime-dev at openjdk.java.net Subject: Re: Request for >>>>> Review (XXL): 7104647: Adding a diagnostic command framework >>>>> >>>>> For the hotspot part at >>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>>> >>>>> Most of my comments are style-related. Nice job on the >>>>> implementation architecture. >>>>> >>>>> In attachListener.cpp: >>>>> >>>>> You might want to delete the first "return JNI_OK;" line, since the >>>>> code under HAS_PENDING_EXCEPTION just falls through. >>>>> >>>>> In jmm.h: >>>>> >>>>> Be nice to indent "(JNIEnv" on lines 318, 319 and 325 the same as >>>>> the existing declarations. Add a newline just before it on line >>>>> 322. >>>>> >>>>> >>>>> In diagnosticFramework.hpp: >>>>> >>>>> Fix indenting for lines 63-66, insert blank before "size_t" on line >>>>> 48. >>>>> >>>>> Hotspot convention is that getter method names don't include a >>>>> "get_" prefix. So, e.g., DCmdArgIter::get_key_addr() s/b >>>>> DCmdArgIter::key_addr(). Similarly, getters such as is_enabled() >>>>> should retrieve a field named "_is_enabled" rather than one named >>>>> "enabled". You follow the "_is_enabled" convention in other places >>>>> such as GenDCmdArgument. Or you could use enabled() to get the >>>>> value of the _enabled field. >>>>> >>>>> Also generally, I'd use accessor methods in the implementation of >>>>> more complex member methods rather than access the underlying >>>>> fields directly. E.g. in GenDCmdArgument::read_value, I'd use >>>>> is_set() and set_is_set(true), (set_is_set() is not actually >>>>> defined, but should be) rather than directly accessing _is_set. >>>>> Though sometimes doing this is too much of a pain with fields whose >>>>> type is a template argument, as in the >>>>> DCmdArggument::parse_value() method in >>>>> diagnosticArgument.cpp. >>>>> >>>>> For easy readability, it'd be nice to line up field names (the ones >>>>> with an _ prefix) at the same column. >>>>> >>>>> On line 200, "instanciated" -> "instantiated" >>>>> >>>>> On line 218, I'd use "heap_allocated" rather than "heap" for the >>>>> formal arg name. >>>>> >>>>> On line 248, you could indent the text to start underneath >>>>> "outputStream". I generally find that indenting arguments lines >>>>> (formal or actual) so they line up with the first argument position >>>>> make the code more readable, but I'm not religious about it. >>>>> >>>>> On line 265, "instanciated" -> "instantiated" >>>>> >>>>> DCmdFactorys are members of a singly-linked list, right? If so, >>>>> it'd be good to have a comment to that effect on the declaration of >>>>> _next. >>>>> >>>>> On line 322, insert a blank before "true". You might fix this in >>>>> other places where there's no blank between a comma in an argument >>>>> list and the following parameter value. >>>>> >>>>> >>>>> In diagnosticCommandFramework.cpp: >>>>> >>>>> The code from lines 80-95 and 105-120 is identical. Factor out? >>>>> >>>>> >>>>> In diagnosticArgument.cpp: >>>>> >>>>> On line 41, insert blanks before the actual arguments. (see above >>>>> generic comment) >>>>> >>>>> On line 77, the "if" is indented one space too many. >>>>> >>>>> >>>>> In management.cpp: >>>>> >>>>> I'd be consistent with having or not having a space between >>>>> "while", "if" and "for" and the following "(" in this and your >>>>> other code. Most hotspot code has a space. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Paul >>>>> >>>>> >>>>> On 12/2/11 8:57 AM, Frederic Parain wrote: >>>>>> Hi All, >>>>>> >>>>>> [Posting to serviceability-dev, runtime-dev and core-libs-dev >>>>>> because changes are pretty big and touch all these areas] >>>>>> >>>>>> Here's a framework for issuing diagnostics commands to the JVM. >>>>>> Diagnostic commands are actions executed inside the JVM mainly >>>>>> for monitoring or management purpose. This work has two parts. >>>>>> The first part is in the hotspot repository and contains the >>>>>> framework itself with two diagnostic commands. The second part is >>>>>> in the JDK repository and contains the command line utility to >>>>>> invoke diagnostic commands as well as the HotSpotDiagnosticMXBean >>>>>> extensions. The HotSpotDiagnosticMXBean extensions allow a remote >>>>>> client to discover and invoke diagnostic commands using a JMX >>>>>> connection. >>>>>> >>>>>> This changeset only contains two diagnostic commands, more >>>>>> commands will be added in the future, as a standalone effort to >>>>>> improve the monitoring and management services of the JVM, or as >>>>>> part of other projects. >>>>>> >>>>>> Webrevs are here: >>>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/ >>>>>> http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/ >>>>>> >>>>>> Here's a technical description of this work: >>>>>> >>>>>> 1 - The Diagnostic Command Framework 1-1 Overview >>>>>> >>>>>> The diagnostic command framework is fully implemented in native >>>>>> code and relies on the HotSpot's internal exception mechanism. >>>>>> The rational of a pure native implementation is to be able to >>>>>> execute diagnostic commands even in critical situations like an >>>>>> OutOfMemory error. All diagnostic commands are registered in a >>>>>> single list, and two flags control the way a user can interact >>>>>> with them. The "hidden" flag prevents a diagnostic command from >>>>>> appearing in the list of available commands returned by the >>>>>> "help" command. However, it's still possible to get the detailed >>>>>> help message for a hidden command with the "help " >>>>>> syntax (but it requires to know the name of the hidden command). >>>>>> The second flag is "enabled" and it controls if a command can be >>>>>> invoked or not. When listed with the "help" commands, disabled >>>>>> commands appear with a "[disabled]" label in their description. >>>>>> If the user tries to invoke a disabled command, an error message >>>>>> is returned and the command is not run. This error message can be >>>>>> customized on a per command base. The framework just provides >>>>>> these two flags with their semantic, it doesn't provide any >>>>>> policy or mechanism to set or modify these flags. These actions >>>>>> will be delegated to the JVM or special diagnostic commands. >>>>>> >>>>>> 1-2 Implementation >>>>>> >>>>>> All diagnostic commands are implemented as subclasses of the DCmd >>>>>> class defined in services/diagnosticFramework.hpp. Here's the >>>>>> layout of the DCmd class and the list of methods that a new >>>>>> command has to define or overwrite: >>>>>> >>>>>> class DCmd { DCmd(outputStream *output); >>>>>> >>>>>> static const char *get_name(); >>>>>> >>>>>> static const char *get_description(); >>>>>> >>>>>> static const char *get_disabled_message(); >>>>>> >>>>>> static const char *get_impact(); >>>>>> >>>>>> static int get_num_arguments(); >>>>>> >>>>>> virtual void print_help(outputStream* out); >>>>>> >>>>>> virtual void parse(CmdLine* line, char delim, TRAPS); >>>>>> >>>>>> virtual void execute(TRAPS); >>>>>> >>>>>> virtual void reset(TRAPS); >>>>>> >>>>>> virtual void cleanup(); >>>>>> >>>>>> virtual GrowableArray* get_argument_name_array(); >>>>>> >>>>>> virtual GrowableArray* >>>>>> get_argument_info_array(); } >>>>>> >>>>>> A diagnostic command is always instantiated with an outputStream >>>>>> in parameter. This outputStream can point either to a file, a >>>>>> buffer or a socket (see the ostream.hpp file). >>>>>> >>>>>> The get_name() method returns the string that will identify the >>>>>> command (i.e. the string to put on the command line to invoke >>>>>> it). >>>>>> >>>>>> The get_description() methods returns the global description of >>>>>> the command. >>>>>> >>>>>> The get_disabled_message() returns the customized message to >>>>>> return when the command is disabled, without having to >>>>>> instantiate the command. >>>>>> >>>>>> The get_impact() returns a description of the intrusiveness of >>>>>> the diagnostic command on the Java Virtual Machine behavior. The >>>>>> rational for this method is that some diagnostic commands can >>>>>> seriously disrupt the behavior of the Java Virtual Machine (for >>>>>> instance a Thread Dump for an application with several tens of >>>>>> thousands of threads, or a Head Dump with a 40GB+ heap size) and >>>>>> other diagnostic commands have no serious impact on the JVM (for >>>>>> instance, getting the command line arguments or the JVM version). >>>>>> The recommended format for the description is: >>>>>> [longer description], where the impact level is selected among >>>>>> this list: {low, medium, high}. The optional longer description >>>>>> can provide more specific details like the fact that Thread Dump >>>>>> impact depends on the heap size. >>>>>> >>>>>> The get_num_arguments() returns the number of options/arguments >>>>>> recognized by the diagnostic command. This method is only used by >>>>>> the JMX interface support (see below). >>>>>> >>>>>> The print_help() methods prints a detailed help on the >>>>>> outputStream passed in argument. The detailed help contains the >>>>>> list of all supported options with their type and description. >>>>>> >>>>>> The parse() method is in charge of parsing the command arguments. >>>>>> Each command is free to implement its own argument parser. >>>>>> However, an argument parser framework is provided (see section >>>>>> 1-3) to ease the implementation, but its use is optional. The >>>>>> parse method takes a delimiter character in argument, which is >>>>>> used to mark the limit between two arguments (typically >>>>>> invocation from jcmd will use a space character as a delimiter >>>>>> while invocation from the JVM command line parsing code will use >>>>>> a comma as a delimiter). >>>>>> >>>>>> The execute() method is naturally the one to invoke to get the >>>>>> diagnostic command executed. The parse() and the execute() >>>>>> methods are dissociated, so it's a possible perform the argument >>>>>> parsing in one thread, and delegate the execution to another >>>>>> thread, as long as the diagnostic command doesn't reference >>>>>> thread local variables. The framework allows several instances of >>>>>> the same diagnostic command to be executed in parallel. If for >>>>>> some reasons concurrent executions should not be allowed for a >>>>>> given diagnostic command, this is the responsibility of the >>>>>> diagnostic command implementor to enforce this rule, for instance >>>>>> by protecting the body of the execute() method with a global >>>>>> lock. >>>>>> >>>>>> The reset() method is used to initialize the internal fields of >>>>>> the diagnostic command or to reset the internal fields to their >>>>>> initial value to be able to re-use an already allocated >>>>>> diagnostic command instance. >>>>>> >>>>>> The cleanup() method is used to perform perform cleanup (like >>>>>> freeing of all memory allocated to store internal data). The DCmd >>>>>> extends the ResourceObj class, so when allocated in a >>>>>> ResourceArea, destructors cannot be used to perform cleanup. To >>>>>> ensure that cleanup is performed in all cases, it is recommended >>>>>> to create a DCmdMark instance for each DCmd instance. DCmdMark is >>>>>> a stack allocated object with a pointer to a DCmd instance. When >>>>>> the DCmdMark is destroyed, its destructor calls the cleanup() >>>>>> method of the DCmd instance it points to. If the DCmd instance >>>>>> has been allocated on the C-Heap, the DCmdMark will also free the >>>>>> memory allocated to store the DCmd instance. >>>>>> >>>>>> The get_argument_name_array() and get_argument_info_array() are >>>>>> related to the JMX interface of the diagnostic command framework, >>>>>> so they are described in section 3. >>>>>> >>>>>> 1-3 DCmdParser framework >>>>>> >>>>>> The DCmdParser class is an optional framework to help development >>>>>> of argument parsers. It provides many features required by the >>>>>> diagnostic command framework (generation of the help message or >>>>>> the argument descriptions for the JMX interface) but all these >>>>>> features can easily be re-implemented if a developer decides not >>>>>> to use the DCmdParser framework. >>>>>> >>>>>> The DCmdParser class is relying on the DCmdArgument template. >>>>>> This template must be used to define the different types of >>>>>> argument the parser will have to handle. When a new >>>>>> specialization of the template is done, three methods have to be >>>>>> provided: >>>>>> >>>>>> void parse_value(const char *str,size_t len,TRAPS); void >>>>>> init_value(TRAPS); void destroy_value(); >>>>>> >>>>>> The parse_value() method is used to convert a string into an >>>>>> argument value. The print_value() method is used to display the >>>>>> default value (support for the detailed help message). The >>>>>> init_value() method is used to initialize or reset the argument >>>>>> value. The destroy_value() method is a clean-up method (useful >>>>>> when the argument has allocated some C-Heap memory to store its >>>>>> value and this memory has to be freed before destroying the >>>>>> DCmdArgument instance). >>>>>> >>>>>> The DCmdParser makes a distinction between options and >>>>>> arguments. Options are identified by a key name that must appear >>>>>> on the command line, while argument are identified just by the >>>>>> position of the argument on the command line. Options use >>>>>> the= syntax. In case of boolean options, the >>>>>> '=' part of the syntax can be omitted to set the option to >>>>>> true. Arguments are just sequences characters delimited by a >>>>>> separator character. This separator can be specified at runtime >>>>>> when invoking the diagnostic command framework. If an argument >>>>>> contain a character that could be used as a delimiter, it's >>>>>> possible to enclose the argument between single or double quotes. >>>>>> Options are arguments are instantiated using the same >>>>>> DCmdArgument class but they're registered differently to the >>>>>> DCmdParser. >>>>>> >>>>>> The way to use the DCmdParser is to declare the parser and the >>>>>> option/arguments as fields of the diagnostic command class (which >>>>>> is itself a sub-class of the DCmd class), like this: >>>>>> >>>>>> >>>>>> class EchoDCmd : public DCmd { protected: DCmdParser >>>>>> _dcmdparser; >>>>>> >>>>>> DCmdArgument _required; >>>>>> >>>>>> DCmdArgument _intval; >>>>>> >>>>>> DCmdArgument _boolval; >>>>>> >>>>>> DCmdArgument _stringval; >>>>>> >>>>>> DCmdArgument _first_arg; >>>>>> >>>>>> DCmdArgument _second_arg; >>>>>> >>>>>> DCmdArgument _optional_arg; >>>>>> >>>>>> } >>>>>> >>>>>> The parser and the options/arguments must be initialized before >>>>>> the diagnostic command class, and the options/arguments have to >>>>>> be registered to the parser like this: >>>>>> >>>>>> EchoDCmd(outputStream *output) : DCmd(output), >>>>>> _stringval("-strval","a string argument","STRING",false), >>>>>> >>>>>> _boolval("-boolval","a boolean argument","BOOLEAN",false), >>>>>> >>>>>> _intval("-intval","an integer argument","INTEGER",false), >>>>>> >>>>>> _required("-req","a mandatory integer argument","INTEGER",true), >>>>>> >>>>>> _fist_arg("first argument","a string argument","STRING",true), >>>>>> >>>>>> _second_arg("second argument,"an integer >>>>>> argument,"INTEGER",true), >>>>>> >>>>>> _optional_arg("optional argument","an optional string >>>>>> argument","STRING","false") >>>>>> >>>>>> { >>>>>> >>>>>> _dcmdparser.add_dcmd_option(&_stringval) >>>>>> >>>>>> _dcmdparser.add_dcmd_option(&_boolval); >>>>>> >>>>>> _dcmdparser.add_dcmd_option(&_intval); >>>>>> >>>>>> _dcmdparser.add_dcmd_option(&_required); >>>>>> >>>>>> _dcmdparser.add_argument(&_first_arg); >>>>>> >>>>>> _dcmdparser.add_argument(&_second_arg); >>>>>> >>>>>> _dcmdparser.add_argument(&_optional_arg); }; >>>>>> >>>>>> The add_dcmd_argument()/ add_dcmd_option() method is used to add >>>>>> an argument/option to the parser. The option/argument constructor >>>>>> takes the name of the option/argument, its description, a string >>>>>> describing its type and a boolean to specify if the >>>>>> option/argument is mandatory or not. The parser doesn't support >>>>>> option/argument duplicates (having the same name) but the code >>>>>> currently doesn't check for duplicates.The order used to register >>>>>> options has no impact on the parser. However, the order used to >>>>>> register arguments is critical because the parser will use the >>>>>> same order to parse the command line. In the example above, the >>>>>> parser expects to have a first argument of type STRING (parsed >>>>>> using _first_arg), then a second argument of type INTEGER (parsed >>>>>> using _second_arg) and optionally a third parameter of type >>>>>> STRING (parsed using _optional_arg). A mandatory option or >>>>>> argument has to be specify every time the command is invoked. If >>>>>> it is missing, an exception is thrown at the end of the parsing. >>>>>> Optional arguments have to be registered after mandatory >>>>>> arguments. An optional argument will be considered for parsing >>>>>> only if all arguments before it (mandatory or not) have already >>>>>> been used to parse the command line. >>>>>> >>>>>> The DCmdParser and its DCmdArgument instances are embedded in the >>>>>> DCmd instance. The rational for this design is to limit the >>>>>> number of C-heap allocations but also to be able to pre-allocate >>>>>> diagnostic command instances for critical situations. If the >>>>>> process is running out of C-heap space, it's not possible to >>>>>> instantiate new diagnostic commands to troubleshoot the >>>>>> situation. By pre-allocating some diagnostic commands, it will be >>>>>> possible to run them even in this critical situation. Of course, >>>>>> the diagnostic command itself should not try to allocate memory >>>>>> during its execution, this prevents the diagnostic command to use >>>>>> variable length arguments like strings. By nature, pre-allocated >>>>>> diagnostic commands aim to be re-usable, this is the purpose of >>>>>> the reset() method which restores the default status of all >>>>>> arguments. >>>>>> >>>>>> 1-4 Internal invocation >>>>>> >>>>>> Using a diagnostic command from the JVM itself is pretty easy: >>>>>> instantiate the class and invoke the parse() method then the >>>>>> execute() method. A diagnostic command can be instantiated from >>>>>> inside the JVM even it is not registered. This is a difference >>>>>> with the external invocations (from jcmd or JMX) that require the >>>>>> command to be >>>>> registered. >>>>>> >>>>>> 2 - The JCmd interface >>>>>> >>>>>> Diagnostic commands can also be invoked from outside the JVM >>>>>> process, using the new 'jcmd' utility. The jcmd program uses the >>>>>> attach API to connect to the JVM, send requests and receive >>>>>> results. The jcmd utility must be launched on the same machine >>>>>> than the one running the JVM (its a local tool). Launched without >>>>>> arguments, jcmd displays a list of all JVMs running on the >>>>>> machine. The jcmd source code is in the jdk repository like other >>>>>> existing j* tools. >>>>>> >>>>>> To execute a diagnostic command in a particular JVM, the generic >>>>>> syntax is: >>>>>> >>>>>> jcmd [arguments] >>>>>> >>>>>> The attachListener has been modified to recognized the jcmd >>>>>> requests. When a jcmd request is identified, it is parsed to >>>>>> extract the command name. The JVM performs a look up of this >>>>>> command in a list of registered commands. To be executable by an >>>>>> external request, a diagnostic command has to be registered. The >>>>>> registration is performed with the DCmdFactory class (see >>>>>> services/management.cpp). >>>>>> >>>>>> 3 - The JMX interface >>>>>> >>>>>> The framework provides a JMX based interface to the diagnostic >>>>>> commands. This interface allows remote invocation of diagnostic >>>>>> commands through a JMX connection. >>>>>> >>>>>> 3-1 The interface >>>>>> >>>>>> The information related to the diagnostic commands are >>>>>> accessible through new methods added to the >>>>>> com.sun.management.HotspotDiagnosticMXBean: >>>>>> >>>>>> public List getDiagnosticCommands(); >>>>>> >>>>>> public DiagnosticCommandInfo getDiagnosticCommandInfo(String >>>>>> command); >>>>>> >>>>>> public List >>>>>> getDiagnosticCommandInfo(List command); >>>>>> >>>>>> public List getDiagnosticCommandInfo(); >>>>>> >>>>>> public String execute(String commandLine) throws >>>>>> IllegalArgumentException ; >>>>>> >>>>>> public String execute(String cmd, String... arguments) throws >>>>>> IllegalArgumentException; >>>>>> >>>>>> >>>>>> The getDiagnosticCommands() method returns an array containing >>>>>> the names of the not-hidden registered diagnostic commands. >>>>>> >>>>>> The three getDiagnosticCommandInfo() methods return one or >>>>>> several diagnostic command descriptions using the >>>>>> DiagnosticCommandInfo class. >>>>>> >>>>>> The two execute() methods allow the user the invoke a diagnostic >>>>>> command in different ways. >>>>>> >>>>>> The DiagnosticCommandInfo class is describing a diagnostic >>>>>> command with the following information: >>>>>> >>>>>> public class DiagnosticCommandInfo { >>>>>> >>>>>> public String getName(); >>>>>> >>>>>> public String getDescription(); >>>>>> >>>>>> public String getImpact(); >>>>>> >>>>>> public boolean isEnabled(); >>>>>> >>>>>> public List getArgumentsInfo(); >>>>>> } >>>>>> >>>>>> The getName() method returns the name of the diagnostic command. >>>>>> This name is the one to use in execute() methods to invoke the >>>>>> diagnostic command. >>>>>> >>>>>> The getDescription() method returns a general description of the >>>>>> diagnostic command. >>>>>> >>>>>> The getImpact() method returns a description of the intrusiveness >>>>>> of diagnostic command. >>>>>> >>>>>> The isEnabled() method returns true if the method is enabled, >>>>>> false if it is disabled. A disabled method cannot be executed. >>>>>> >>>>>> The getArgumentsInfo() returns a list of descriptions for the >>>>>> options or arguments recognized by the diagnostic command. Each >>>>>> option/argument is described by a DiagnosticCommandArgumentInfo >>>>>> instance: >>>>>> >>>>>> public class DiagnosticCommandArgumentInfo { >>>>>> >>>>>> public String getName(); >>>>>> >>>>>> public String getDescription(); >>>>>> >>>>>> public String getType(); >>>>>> >>>>>> public String getDefault(); >>>>>> >>>>>> public boolean isMandatory(); >>>>>> >>>>>> public boolean isOption(); >>>>>> >>>>>> public int getPosition(); } >>>>>> >>>>>> If the DiagnosticCommandArgumentInfo instance describes an >>>>>> option, isOption() returns true and getPosition() returns -1. >>>>>> Otherwise, when the DiagnosticCommandArgumentInfo instance >>>>>> describes an argument, isOption() returns false and getPosition() >>>>>> returns the expected position for this argument. The position of >>>>>> an argument is defined relatively to all arguments passed on the >>>>>> command line, options are not considered when defining an >>>>>> argument position. The getDefault() method returns the default >>>>>> value of the argument if a default has been defined, otherwise it >>>>>> returns null. >>>>>> >>>>>> 3-2 The implementation >>>>>> >>>>>> The framework has been designed in a way that prevents >>>>>> diagnostic command developers to worry about the JMX interface. >>>>>> In addition to the methods described in section 1-2, a diagnostic >>>>>> command developer has to provide three methods: >>>>>> >>>>>> int get_num_arguments() >>>>>> >>>>>> which returns the number of option and arguments supported by >>>>>> the command. >>>>>> >>>>>> GrowableArray* get_argument_name_array() >>>>>> >>>>>> which provides the name of the arguments supported by the >>>>>> command. >>>>>> >>>>>> GrowableyArray* get_argument_info_array() >>>>>> >>>>>> which provides the description of each argument with a >>>>>> DCmdArgumentInfo instance. DCmdArgumentInfo is a C++ class used >>>>>> by the framework to generate the >>>>>> sun.com.management.DcmdArgumentInfo instances. This is done >>>>>> automatically and the diagnostic command developer doesn't need >>>>>> to know how to create Java objects from the runtime. >>>>>> >>>>>> 4 - The Diagnostic Commands >>>>>> >>>>>> To avoid name collisions between diagnostic commands coming from >>>>>> different projects, use of a flat name space should be avoided >>>>>> and a more structured organization is recommended. The framework >>>>>> itself doesn't depend on this organization, so it will be a set >>>>>> of rules defining a convention in the way commands are named. >>>>>> >>>>>> Diagnostic commands can easily organized in a hierarchical way, >>>>>> so the template for a command name can be: >>>>>> >>>>>> .[sub-domain.] >>>>>> >>>>>> This template can be extended with sub-sub-domains and so on. >>>>>> >>>>>> A special set of commands without domain will be reserved for >>>>>> the commands related to the diagnostic framework itself, like the >>>>>> "help" command. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>> > From frederic.parain at oracle.com Wed Dec 14 13:13:20 2011 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 14 Dec 2011 21:13:20 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7104647: Adding a diagnostic command framework Message-ID: <20111214211324.DC8E6476BD@hg.openjdk.java.net> Changeset: 3b688d6ff3d0 Author: fparain Date: 2011-12-14 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 From bob.vandette at oracle.com Wed Dec 14 19:53:32 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Thu, 15 Dec 2011 03:53:32 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 45 new changesets Message-ID: <20111215035504.569B1476C9@hg.openjdk.java.net> Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/hotspot/rev/81a08cd7f6a1 Merge Changeset: a88de71c4e3a Author: tonyp Date: 2011-11-18 12:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/hotspot/rev/3a298e04d914 Merge Changeset: bca17e38de00 Author: jmasa Date: 2011-08-09 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/hotspot/rev/1bbf5b6fb7b0 Merge ! src/share/vm/runtime/globals.hpp Changeset: d1f29d4e0bc6 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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/hotspot-emb/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-emb/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-emb/hotspot/rev/41cce03b29a8 Merge Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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/hotspot-emb/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-emb/hotspot/rev/e37aedaedccd Merge Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/hotspot/rev/e9b91fd07263 Merge Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp From john.cuthbertson at oracle.com Thu Dec 15 10:44:59 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 15 Dec 2011 10:44:59 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE6E28C.6080501@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65EDA.80300@oracle.com> <4EE6E28C.6080501@oracle.com> Message-ID: <4EEA402B.7030002@oracle.com> Hi David, On 12/12/11 21:28, David Holmes wrote: > On 13/12/2011 6:06 AM, John Cuthbertson wrote: >> Thanks for looking at the code changes and for the suggestions. >> >> Extending the os API is a good idea. Not sure about the name though - >> how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp >> already has an internal monotonic version of javaTimeMillis() so there >> are alternatives to using javaTimeNanos() in the implementation. > > I'm somewhat opposed to extending the API simply because there are > already too many time functions. What about a TO_MILLIS macro? > > #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC > > jlong start = TO_MILLIS(javaTimeNanos()); I'm not a fan of this approach - to me it's just hiding the division and is really no different from the posted webrev. I'd rather go with what's in the webrev. > > BTW the "java" in javaTimeMillis and javaTimeNanos identifies these > methods as being part of the Java API (System.currentTimeMillis and > System.nanoTime respectively) - so javaMonotonicTimeMillis would not > be appropriate. I see. Thanks for the heads up. No java in the routine name (if it's decided that's the best approach). > > John: you have a recurrent typo in the comments: monton instead of > monoton (and I mistyped it myself writing that!) OK. Thanks. I correct those. > >> Thanks for the heads up about the other CR. I'll check. > > See 4741166. It wanted to make javaTimeMillis monotonic, which it can > not be. Pretty much all internal uses of javaTimeMillis (those not > part of implementing System.currentTimeMillis()) should really be > using a monotonic time source. To achieve that goal - I think an additional routine might be needed (say clockTimeMillis_monotonic) but I think a significant portion of the calls to javaTimeMillis is outside the scope of this CR. Unless there's any objection - I'll go with the posted webrev. Thanks, JohnC From john.coomes at oracle.com Thu Dec 15 20:47:56 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:47:56 +0000 Subject: hg: hsx/hotspot-emb: 3 new changesets Message-ID: <20111216044756.C3FA647704@hg.openjdk.java.net> Changeset: 8606f4ab62dc Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/rev/7010bd24cdd0 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:48:03 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:48:03 +0000 Subject: hg: hsx/hotspot-emb/corba: 3 new changesets Message-ID: <20111216044806.BA3C047705@hg.openjdk.java.net> Changeset: 05f47d29b438 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/corba/rev/312cf15d1657 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:48:16 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:48:16 +0000 Subject: hg: hsx/hotspot-emb/jaxp: 5 new changesets Message-ID: <20111216044816.52C4047706@hg.openjdk.java.net> Changeset: e32444f13774 Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/jaxp/rev/09eb517404b0 Merge Changeset: db44484a9d6e Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/jaxp/rev/ebec6a7e8d4e Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:48:23 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:48:23 +0000 Subject: hg: hsx/hotspot-emb/jaxws: 5 new changesets Message-ID: <20111216044823.7B18747707@hg.openjdk.java.net> Changeset: 23c42f40fd3e Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/jaxws/rev/3d45ab79643d Merge Changeset: b38846b9974c Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/jaxws/rev/54928c8850f5 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:59:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:59:53 +0000 Subject: hg: hsx/hotspot-rt: 3 new changesets Message-ID: <20111216045953.BF3B14770E@hg.openjdk.java.net> Changeset: 8606f4ab62dc Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/rev/7010bd24cdd0 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 21:00:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 05:00:00 +0000 Subject: hg: hsx/hotspot-rt/corba: 3 new changesets Message-ID: <20111216050004.4DD4E4770F@hg.openjdk.java.net> Changeset: 05f47d29b438 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/corba/rev/312cf15d1657 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 21:00:11 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 05:00:11 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 5 new changesets Message-ID: <20111216050011.35F2D47710@hg.openjdk.java.net> Changeset: e32444f13774 Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/jaxp/rev/09eb517404b0 Merge Changeset: db44484a9d6e Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/jaxp/rev/ebec6a7e8d4e Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 21:00:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 05:00:17 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 5 new changesets Message-ID: <20111216050017.CEB7047711@hg.openjdk.java.net> Changeset: 23c42f40fd3e Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/jaxws/rev/3d45ab79643d Merge Changeset: b38846b9974c Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/jaxws/rev/54928c8850f5 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:49:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:49:51 +0000 Subject: hg: hsx/hotspot-emb/jdk: 64 new changesets Message-ID: <20111216050602.31ACC47712@hg.openjdk.java.net> Changeset: 23acf34c80b0 Author: neugens Date: 2011-12-03 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/jdk/rev/4075d524fa46 Merge Changeset: e53a078c2840 Author: anthony Date: 2011-11-09 13:43 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/1df53949945d Merge Changeset: 90d33a64a404 Author: rupashka Date: 2011-11-21 18:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/45eb5a61da07 Merge Changeset: 79b5c5a8c7e9 Author: serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a3edcdff37e1 Merge Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/da28826c5672 Merge Changeset: f352dd3cdff8 Author: dl Date: 2011-12-05 13:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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 Thu Dec 15 21:01:40 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 05:01:40 +0000 Subject: hg: hsx/hotspot-rt/jdk: 64 new changesets Message-ID: <20111216051547.27BB547714@hg.openjdk.java.net> Changeset: 23acf34c80b0 Author: neugens Date: 2011-12-03 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/jdk/rev/4075d524fa46 Merge Changeset: e53a078c2840 Author: anthony Date: 2011-11-09 13:43 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/1df53949945d Merge Changeset: 90d33a64a404 Author: rupashka Date: 2011-11-21 18:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/45eb5a61da07 Merge Changeset: 79b5c5a8c7e9 Author: serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a3edcdff37e1 Merge Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/da28826c5672 Merge Changeset: f352dd3cdff8 Author: dl Date: 2011-12-05 13:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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 volker.simonis at gmail.com Fri Dec 16 09:20:07 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Dec 2011 18:20:07 +0100 Subject: Request for review (XXS): -XX:+TraceBytecodes does not work with -XX:+UseCompressedOops Message-ID: Hi, I've just realized that -XX:+TraceBytecodes does not work anymore if -XX:+UseCompressedOops is set. This is because TemplateInterpreterGenerator::trace_bytecode() uses 'r12' which holds the heap base for temporary saving the 'sp' before calling the Interpreter::trace_code() template: __ mov(r12, rsp); // remember sp (can only use r12 if not using call_VM) __ andptr(rsp, -16); // align stack as required by ABI __ call(RuntimeAddress(Interpreter::trace_code(t->tos_in()))); __ mov(rsp, r12); // restore sp __ reinit_heapbase(); Notice that the comment explicitly mentions that 'r12' can only be used if 'call_VM' will not be used subsequently. But this is exactly what Interpreter::trace_code() does: address TemplateInterpreterGenerator::generate_trace_code(TosState state) { ... __ call_VM(noreg,... void MacroAssembler::call_VM(Register oop_result, ... call_VM_helper(oop_result, entry_point, 3, check_exceptions); void MacroAssembler::call_VM_helper(Register oop_result, address entry_point, int number_of_arguments, bool check_exceptions) { ... call_VM_base(oop_result, noreg, rax, entry_point, number_of_arguments, check_exceptions); void MacroAssembler::call_VM_base(Register oop_result, ... LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) This finally leads to a call to 'verify_heapbase()' which will fail because 'r12' has been overwritten. The proposed fix is trivial: don't do the check if we are running with -XX:+TraceBytecodes: diff -r 86cbe939f0c7 src/cpu/x86/vm/assembler_x86.cpp --- a/src/cpu/x86/vm/assembler_x86.cpp Mon Sep 19 12:18:46 2011 -0700 +++ b/src/cpu/x86/vm/assembler_x86.cpp Fri Dec 16 18:01:31 2011 +0100 @@ -5967,7 +5967,7 @@ assert(number_of_arguments >= 0 , "cannot have negative number of arguments"); LP64_ONLY(assert(java_thread == r15_thread, "unexpected register")); #ifdef ASSERT - LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) + LP64_ONLY(if (UseCompressedOops && !TraceBytecodes) verify_heapbase("call_VM_base");) #endif // ASSERT assert(java_thread != oop_result , "cannot use the same register for java_thread & oop_result"); For your convenience I've also attached the patch as a file to this message. Regards, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: TraceBytecodes.patch Type: text/x-patch Size: 666 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111216/6ced5449/TraceBytecodes.patch From coleen.phillimore at oracle.com Fri Dec 16 10:00:57 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Dec 2011 13:00:57 -0500 Subject: Request for review (XXS): -XX:+TraceBytecodes does not work with -XX:+UseCompressedOops In-Reply-To: References: Message-ID: <4EEB8759.3020001@oracle.com> Volker, Thank you for fixing this. It looks good to me. I can check it in this contribution, pending additional comments. Coleen On 12/16/2011 12:20 PM, Volker Simonis wrote: > Hi, > > I've just realized that -XX:+TraceBytecodes does not work anymore if > -XX:+UseCompressedOops is set. > > This is because TemplateInterpreterGenerator::trace_bytecode() uses > 'r12' which holds the heap base for temporary saving the 'sp' before > calling the Interpreter::trace_code() template: > > __ mov(r12, rsp); // remember sp (can only use r12 if not using call_VM) > __ andptr(rsp, -16); // align stack as required by ABI > __ call(RuntimeAddress(Interpreter::trace_code(t->tos_in()))); > __ mov(rsp, r12); // restore sp > __ reinit_heapbase(); > > Notice that the comment explicitly mentions that 'r12' can only be > used if 'call_VM' will not be used subsequently. > > But this is exactly what Interpreter::trace_code() does: > > > address TemplateInterpreterGenerator::generate_trace_code(TosState state) { > ... > __ call_VM(noreg,... > > void MacroAssembler::call_VM(Register oop_result, > ... > call_VM_helper(oop_result, entry_point, 3, check_exceptions); > > void MacroAssembler::call_VM_helper(Register oop_result, address > entry_point, int number_of_arguments, bool check_exceptions) { > ... > call_VM_base(oop_result, noreg, rax, entry_point, > number_of_arguments, check_exceptions); > > void MacroAssembler::call_VM_base(Register oop_result, > ... > LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) > > > This finally leads to a call to 'verify_heapbase()' which will fail > because 'r12' has been overwritten. > > The proposed fix is trivial: don't do the check if we are running with > -XX:+TraceBytecodes: > > diff -r 86cbe939f0c7 src/cpu/x86/vm/assembler_x86.cpp > --- a/src/cpu/x86/vm/assembler_x86.cpp Mon Sep 19 12:18:46 2011 -0700 > +++ b/src/cpu/x86/vm/assembler_x86.cpp Fri Dec 16 18:01:31 2011 +0100 > @@ -5967,7 +5967,7 @@ > assert(number_of_arguments>= 0 , "cannot have negative number of > arguments"); > LP64_ONLY(assert(java_thread == r15_thread, "unexpected register")); > #ifdef ASSERT > - LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) > + LP64_ONLY(if (UseCompressedOops&& !TraceBytecodes) > verify_heapbase("call_VM_base");) > #endif // ASSERT > > assert(java_thread != oop_result , "cannot use the same register > for java_thread& oop_result"); > > For your convenience I've also attached the patch as a file to this message. > > Regards, > Volker From volker.simonis at gmail.com Fri Dec 16 15:57:35 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 17 Dec 2011 00:57:35 +0100 Subject: Request for review (XXS): -XX:+TraceBytecodes does not work with -XX:+UseCompressedOops In-Reply-To: <4EEB8759.3020001@oracle.com> References: <4EEB8759.3020001@oracle.com> Message-ID: Thank you Coleen. Regards, Volker On Fri, Dec 16, 2011 at 7:00 PM, Coleen Phillimore wrote: > Volker, Thank you for fixing this. ?It looks good to me. ? I can check it in > this contribution, pending additional comments. > > Coleen > > > On 12/16/2011 12:20 PM, Volker Simonis wrote: >> >> Hi, >> >> I've just realized that -XX:+TraceBytecodes does not work anymore if >> -XX:+UseCompressedOops is set. >> >> This is because TemplateInterpreterGenerator::trace_bytecode() uses >> 'r12' which holds the heap base for temporary saving the 'sp' before >> calling the Interpreter::trace_code() template: >> >> ? __ mov(r12, rsp); // remember sp (can only use r12 if not using call_VM) >> ? __ andptr(rsp, -16); // align stack as required by ABI >> ? __ call(RuntimeAddress(Interpreter::trace_code(t->tos_in()))); >> ? __ mov(rsp, r12); // restore sp >> ? __ reinit_heapbase(); >> >> Notice that the comment explicitly mentions that 'r12' can only be >> used if 'call_VM' will not be used subsequently. >> >> But this is exactly what Interpreter::trace_code() does: >> >> >> address TemplateInterpreterGenerator::generate_trace_code(TosState state) >> { >> ... >> ? __ call_VM(noreg,... >> >> void MacroAssembler::call_VM(Register oop_result, >> ... >> ? call_VM_helper(oop_result, entry_point, 3, check_exceptions); >> >> void MacroAssembler::call_VM_helper(Register oop_result, address >> entry_point, int number_of_arguments, bool check_exceptions) { >> ... >> ? call_VM_base(oop_result, noreg, rax, entry_point, >> number_of_arguments, check_exceptions); >> >> void MacroAssembler::call_VM_base(Register oop_result, >> ... >> ? LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) >> >> >> This finally leads to a call to 'verify_heapbase()' which will fail >> because 'r12' has been overwritten. >> >> The proposed fix is trivial: don't do the check if we are running with >> -XX:+TraceBytecodes: >> >> diff -r 86cbe939f0c7 src/cpu/x86/vm/assembler_x86.cpp >> --- a/src/cpu/x86/vm/assembler_x86.cpp ?Mon Sep 19 12:18:46 2011 -0700 >> +++ b/src/cpu/x86/vm/assembler_x86.cpp ?Fri Dec 16 18:01:31 2011 +0100 >> @@ -5967,7 +5967,7 @@ >> ? ?assert(number_of_arguments>= 0 ? , "cannot have negative number of >> arguments"); >> ? ?LP64_ONLY(assert(java_thread == r15_thread, "unexpected register")); >> ?#ifdef ASSERT >> - ?LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) >> + ?LP64_ONLY(if (UseCompressedOops&& ?!TraceBytecodes) >> >> verify_heapbase("call_VM_base");) >> ?#endif // ASSERT >> >> ? ?assert(java_thread != oop_result ?, "cannot use the same register >> for java_thread& ?oop_result"); >> >> >> For your convenience I've also attached the patch as a file to this >> message. >> >> Regards, >> Volker From vladimir.danushevsky at oracle.com Mon Dec 19 09:30:39 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Mon, 19 Dec 2011 17:30:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8 new changesets Message-ID: <20111219173055.9A81747758@hg.openjdk.java.net> Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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: 31f6f10e4379 Author: vladidan Date: 2011-12-14 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/31f6f10e4379 Merge Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version From paul.hohensee at oracle.com Mon Dec 19 09:24:32 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 19 Dec 2011 12:24:32 -0500 Subject: Pls review 7124880 (XS) Message-ID: <4EEF7350.7070102@oracle.com> The framework implemented for 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot did not include support for vendor-specific manageable-by-JMX switches. This change adds new methods Flag::is_external_ext() and Flag::is_writeable_ext() that return false, and uses them in Flag::is_external() and Flag::is_writeable(). Somewhat relatedly, management.cpp didn't include globals.hpp, even though it uses Flag methods. I added globals.hpp to its #include list for completeness, even though it was being included indirectly. Webrev here http://cr.openjdk.java.net/~phh/7122880.00/ Thanks, Paul From coleen.phillimore at oracle.com Mon Dec 19 11:56:01 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 19 Dec 2011 14:56:01 -0500 Subject: Request for review (XXS): -XX:+TraceBytecodes does not work with -XX:+UseCompressedOops In-Reply-To: References: <4EEB8759.3020001@oracle.com> Message-ID: <4EEF96D1.7030300@oracle.com> I haven't seen any other feedback, so I assume this is non-controversial. I filed bug 7122939 and start the checkin. Thanks, Coleen On 12/16/2011 6:57 PM, Volker Simonis wrote: > Thank you Coleen. > > Regards, > Volker > > On Fri, Dec 16, 2011 at 7:00 PM, Coleen Phillimore > wrote: >> Volker, Thank you for fixing this. It looks good to me. I can check it in >> this contribution, pending additional comments. >> >> Coleen >> >> >> On 12/16/2011 12:20 PM, Volker Simonis wrote: >>> Hi, >>> >>> I've just realized that -XX:+TraceBytecodes does not work anymore if >>> -XX:+UseCompressedOops is set. >>> >>> This is because TemplateInterpreterGenerator::trace_bytecode() uses >>> 'r12' which holds the heap base for temporary saving the 'sp' before >>> calling the Interpreter::trace_code() template: >>> >>> __ mov(r12, rsp); // remember sp (can only use r12 if not using call_VM) >>> __ andptr(rsp, -16); // align stack as required by ABI >>> __ call(RuntimeAddress(Interpreter::trace_code(t->tos_in()))); >>> __ mov(rsp, r12); // restore sp >>> __ reinit_heapbase(); >>> >>> Notice that the comment explicitly mentions that 'r12' can only be >>> used if 'call_VM' will not be used subsequently. >>> >>> But this is exactly what Interpreter::trace_code() does: >>> >>> >>> address TemplateInterpreterGenerator::generate_trace_code(TosState state) >>> { >>> ... >>> __ call_VM(noreg,... >>> >>> void MacroAssembler::call_VM(Register oop_result, >>> ... >>> call_VM_helper(oop_result, entry_point, 3, check_exceptions); >>> >>> void MacroAssembler::call_VM_helper(Register oop_result, address >>> entry_point, int number_of_arguments, bool check_exceptions) { >>> ... >>> call_VM_base(oop_result, noreg, rax, entry_point, >>> number_of_arguments, check_exceptions); >>> >>> void MacroAssembler::call_VM_base(Register oop_result, >>> ... >>> LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) >>> >>> >>> This finally leads to a call to 'verify_heapbase()' which will fail >>> because 'r12' has been overwritten. >>> >>> The proposed fix is trivial: don't do the check if we are running with >>> -XX:+TraceBytecodes: >>> >>> diff -r 86cbe939f0c7 src/cpu/x86/vm/assembler_x86.cpp >>> --- a/src/cpu/x86/vm/assembler_x86.cpp Mon Sep 19 12:18:46 2011 -0700 >>> +++ b/src/cpu/x86/vm/assembler_x86.cpp Fri Dec 16 18:01:31 2011 +0100 >>> @@ -5967,7 +5967,7 @@ >>> assert(number_of_arguments>= 0 , "cannot have negative number of >>> arguments"); >>> LP64_ONLY(assert(java_thread == r15_thread, "unexpected register")); >>> #ifdef ASSERT >>> - LP64_ONLY(if (UseCompressedOops) verify_heapbase("call_VM_base");) >>> + LP64_ONLY(if (UseCompressedOops&& !TraceBytecodes) >>> >>> verify_heapbase("call_VM_base");) >>> #endif // ASSERT >>> >>> assert(java_thread != oop_result , "cannot use the same register >>> for java_thread& oop_result"); >>> >>> >>> For your convenience I've also attached the patch as a file to this >>> message. >>> >>> Regards, >>> Volker From Peter.B.Kessler at Oracle.COM Mon Dec 19 14:58:47 2011 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Mon, 19 Dec 2011 14:58:47 -0800 Subject: Duplicated lines in src/share/vm/interpreter/linkResolver.cpp Message-ID: <4EEFC1A7.3000105@Oracle.COM> I was reading src/share/vm/interpreter/linkResolver.cpp, and noticed 789 void LinkResolver::runtime_resolve_virtual_method(CallInfo& result, 790 methodHandle resolved_method, 791 KlassHandle resolved_klass, 792 Handle recv, 793 KlassHandle recv_klass, 794 bool check_null_and_abstract, 795 TRAPS) { .... 808 // Virtual methods cannot be resolved before its klass has been linked, for otherwise the methodOop's 809 // has not been rewritten, and the vtable initialized. 810 assert(instanceKlass::cast(resolved_method->method_holder())->is_linked(), "must be linked"); 811 812 // Virtual methods cannot be resolved before its klass has been linked, for otherwise the methodOop's 813 // has not been rewritten, and the vtable initialized. Make sure to do this after the nullcheck, since 814 // a missing receiver might result in a bogus lookup. 815 assert(instanceKlass::cast(resolved_method->method_holder())->is_linked(), "must be linked"); The comments are different, but the asserts are the same. Nothing happens between them that could change the value of the predicate, so one assert is enough. (I don't actually see the nullcheck that the second comment refers to, but maybe I just missed it.) Fixing this is really low priority, but if someone found themselves in this code they could clean it up. ... peter From david.holmes at oracle.com Mon Dec 19 15:55:00 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Dec 2011 09:55:00 +1000 Subject: Pls review 7124880 (XS) In-Reply-To: <4EEF7350.7070102@oracle.com> References: <4EEF7350.7070102@oracle.com> Message-ID: <4EEFCED4.3060900@oracle.com> Looks fine to me. David On 20/12/2011 3:24 AM, Paul Hohensee wrote: > The framework implemented for > > 7117389: Add a framework for vendor-specific command line switch > extensions to Hotspot > > did not include support for vendor-specific manageable-by-JMX switches. > This change adds new methods Flag::is_external_ext() and > Flag::is_writeable_ext() that > return false, and uses them in Flag::is_external() and > Flag::is_writeable(). Somewhat > relatedly, management.cpp didn't include globals.hpp, even though it > uses Flag methods. > I added globals.hpp to its #include list for completeness, even though > it was being > included indirectly. > > Webrev here > > http://cr.openjdk.java.net/~phh/7122880.00/ > > Thanks, > > Paul > From coleen.phillimore at oracle.com Mon Dec 19 16:18:39 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 20 Dec 2011 00:18:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7122939: TraceBytecodes broken with UseCompressedOops Message-ID: <20111220001841.D62E247760@hg.openjdk.java.net> Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 From paul.hohensee at oracle.com Mon Dec 19 16:33:36 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 19 Dec 2011 19:33:36 -0500 Subject: Pls review 7124880 (XS) In-Reply-To: <4EEFCED4.3060900@oracle.com> References: <4EEF7350.7070102@oracle.com> <4EEFCED4.3060900@oracle.com> Message-ID: <4EEFD7E0.5090102@oracle.com> Thank you for the review. Paul On 12/19/11 6:55 PM, David Holmes wrote: > Looks fine to me. > > David > > On 20/12/2011 3:24 AM, Paul Hohensee wrote: >> The framework implemented for >> >> 7117389: Add a framework for vendor-specific command line switch >> extensions to Hotspot >> >> did not include support for vendor-specific manageable-by-JMX switches. >> This change adds new methods Flag::is_external_ext() and >> Flag::is_writeable_ext() that >> return false, and uses them in Flag::is_external() and >> Flag::is_writeable(). Somewhat >> relatedly, management.cpp didn't include globals.hpp, even though it >> uses Flag methods. >> I added globals.hpp to its #include list for completeness, even though >> it was being >> included indirectly. >> >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7122880.00/ >> >> Thanks, >> >> Paul >> From rednaxelafx at gmail.com Mon Dec 19 16:34:09 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 20 Dec 2011 08:34:09 +0800 Subject: Pls review 7124880 (XS) In-Reply-To: <4EEF7350.7070102@oracle.com> References: <4EEF7350.7070102@oracle.com> Message-ID: Hi Paul, I've used 7117389 and added a few manageable flags in globals_ext.hpp in my local experiment builds, and they all seem to work fine (jinfo -flag can correctly query and set the new flags; didn't try JConsole). Does 7124880 change any behaviors of the manageable flags? Or is it just for explicitness that management.cpp includes globals.hpp? Regards, Kris Mok On Tue, Dec 20, 2011 at 1:24 AM, Paul Hohensee wrote: > The framework implemented for > > 7117389: Add a framework for vendor-specific command line switch > extensions to Hotspot > > did not include support for vendor-specific manageable-by-JMX switches. > This change adds new methods Flag::is_external_ext() and > Flag::is_writeable_ext() that > return false, and uses them in Flag::is_external() and > Flag::is_writeable(). Somewhat > relatedly, management.cpp didn't include globals.hpp, even though it uses > Flag methods. > I added globals.hpp to its #include list for completeness, even though it > was being > included indirectly. > > Webrev here > > http://cr.openjdk.java.net/~**phh/7122880.00/ > > Thanks, > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111220/87559b31/attachment.html From paul.hohensee at oracle.com Mon Dec 19 16:43:23 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 19 Dec 2011 19:43:23 -0500 Subject: Pls review 7124880 (XS) In-Reply-To: References: <4EEF7350.7070102@oracle.com> Message-ID: <4EEFDA2B.1030702@oracle.com> On 12/19/11 7:34 PM, Krystal Mok wrote: > Hi Paul, > > I've used 7117389 and added a few manageable flags in globals_ext.hpp > in my local experiment builds, and they all seem to work fine (jinfo > -flag can correctly query and set the new flags; didn't try JConsole). :) > > Does 7124880 change any behaviors of the manageable flags? Or is it > just for explicitness that management.cpp includes globals.hpp? No, 7124880 doesn't change any manageable flag behavior. As you say, it's just for completeness: globals.hpp was being included indirectly, but the Flag class is being used directly, so it's good practice to explicitly include globals.hpp directly. Paul > > Regards, > Kris Mok > > On Tue, Dec 20, 2011 at 1:24 AM, Paul Hohensee > > wrote: > > The framework implemented for > > 7117389: Add a framework for vendor-specific command line switch > extensions to Hotspot > > did not include support for vendor-specific manageable-by-JMX > switches. > This change adds new methods Flag::is_external_ext() and > Flag::is_writeable_ext() that > return false, and uses them in Flag::is_external() and > Flag::is_writeable(). Somewhat > relatedly, management.cpp didn't include globals.hpp, even though > it uses Flag methods. > I added globals.hpp to its #include list for completeness, even > though it was being > included indirectly. > > Webrev here > > http://cr.openjdk.java.net/~phh/7122880.00/ > > > Thanks, > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111219/9c00789f/attachment.html From rednaxelafx at gmail.com Mon Dec 19 16:55:42 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 20 Dec 2011 08:55:42 +0800 Subject: Pls review 7124880 (XS) In-Reply-To: <4EEFDA2B.1030702@oracle.com> References: <4EEF7350.7070102@oracle.com> <4EEFDA2B.1030702@oracle.com> Message-ID: Got it. Thank you very much :-) Regards, Kris Mok On Tue, Dec 20, 2011 at 8:43 AM, Paul Hohensee wrote: > On 12/19/11 7:34 PM, Krystal Mok wrote: > > Hi Paul, > > I've used 7117389 and added a few manageable flags in globals_ext.hpp in > my local experiment builds, and they all seem to work fine (jinfo -flag can > correctly query and set the new flags; didn't try JConsole). > > > :) > > > > Does 7124880 change any behaviors of the manageable flags? Or is it just > for explicitness that management.cpp includes globals.hpp? > > > No, 7124880 doesn't change any manageable flag behavior. As you say, > it's just for completeness: globals.hpp was being included indirectly, but > the Flag class is being used directly, so it's good practice to explicitly > include > globals.hpp directly. > > Paul > > > > Regards, > Kris Mok > > On Tue, Dec 20, 2011 at 1:24 AM, Paul Hohensee wrote: > >> The framework implemented for >> >> 7117389: Add a framework for vendor-specific command line switch >> extensions to Hotspot >> >> did not include support for vendor-specific manageable-by-JMX switches. >> This change adds new methods Flag::is_external_ext() and >> Flag::is_writeable_ext() that >> return false, and uses them in Flag::is_external() and >> Flag::is_writeable(). Somewhat >> relatedly, management.cpp didn't include globals.hpp, even though it uses >> Flag methods. >> I added globals.hpp to its #include list for completeness, even though it >> was being >> included indirectly. >> >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7122880.00/ >> >> Thanks, >> >> Paul >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111220/ccd5e4d9/attachment-0001.html From ahughes at redhat.com Mon Dec 19 17:38:43 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 20 Dec 2011 01:38:43 +0000 Subject: Duplicated lines in src/share/vm/interpreter/linkResolver.cpp In-Reply-To: <4EEFC1A7.3000105@Oracle.COM> References: <4EEFC1A7.3000105@Oracle.COM> Message-ID: <20111220013843.GM21819@rivendell.middle-earth.co.uk> On 14:58 Mon 19 Dec , Peter B. Kessler wrote: > I was reading src/share/vm/interpreter/linkResolver.cpp, and noticed > > 789 void LinkResolver::runtime_resolve_virtual_method(CallInfo& result, > 790 methodHandle resolved_method, > 791 KlassHandle resolved_klass, > 792 Handle recv, > 793 KlassHandle recv_klass, > 794 bool check_null_and_abstract, > 795 TRAPS) { > .... > 808 // Virtual methods cannot be resolved before its klass has been linked, for otherwise the methodOop's > 809 // has not been rewritten, and the vtable initialized. > 810 assert(instanceKlass::cast(resolved_method->method_holder())->is_linked(), "must be linked"); > 811 > 812 // Virtual methods cannot be resolved before its klass has been linked, for otherwise the methodOop's > 813 // has not been rewritten, and the vtable initialized. Make sure to do this after the nullcheck, since > 814 // a missing receiver might result in a bogus lookup. > 815 assert(instanceKlass::cast(resolved_method->method_holder())->is_linked(), "must be linked"); > > The comments are different, but the asserts are the same. Nothing happens between them that could change the value of the predicate, so one assert is enough. (I don't actually see the nullcheck that the second comment refers to, but maybe I just missed it.) > > Fixing this is really low priority, but if someone found themselves in this code they could clean it up. > > ... peter My guess would be it's probably a merge issue, where a slightly different version of the same fix has come in from two different places. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111220/e467cfa8/attachment.bin From bob.vandette at oracle.com Mon Dec 19 21:01:02 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Tue, 20 Dec 2011 05:01:02 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 4 new changesets Message-ID: <20111220050114.AA04F47769@hg.openjdk.java.net> Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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/hotspot-emb/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-emb/hotspot/rev/31f6f10e4379 Merge Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8fdf463085e1 Merge From paul.hohensee at oracle.com Tue Dec 20 03:46:31 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Tue, 20 Dec 2011 11:46:31 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20111220114639.711B44776D@hg.openjdk.java.net> Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/4502fd5c7698 Merge From paul.hohensee at oracle.com Tue Dec 20 06:19:47 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 20 Dec 2011 09:19:47 -0500 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) Message-ID: <4EF09983.7050405@oracle.com> This is actually a bit broader scope than the Summary suggests, in that it takes into account the possibility that socklen_t might not be the same bit width as int and jint (which latter two are assumed synonymous in the jvm). I spent a bit of time with socket.h on linux/bsd/solaris to verify the actual argument types of the socket methods used by the jvm. I changed the os methods so that their formal argument types match socket.h and put that adapter code in jvm.cpp so as to have only a single copy of it. Webrev here http://cr.openjdk.java.net/~phh/7091417.00/ Thanks, Paul From jiangli.zhou at oracle.com Tue Dec 20 11:58:42 2011 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 20 Dec 2011 11:58:42 -0800 Subject: Request for review: 7123315 instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type Message-ID: <4EF0E8F2.6040704@oracle.com> The instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count are defined as int type currently. The VM spec specifies the 'field_count' as u2. Based on that, these two fields can be defined as u2. That would save 4-byte for each loaded class when placing the two fields next to each other. http://cr.openjdk.java.net/~jiangli/7123315/webrev.00/ Tested with runThese -jdk and UTE nsk/sajdi/ tests. Ran jprt. Performance testing with specjvm98 and specjbb2005 didn't show any performance degradation. Thanks, Jiangli From david.holmes at oracle.com Tue Dec 20 16:20:47 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Dec 2011 10:20:47 +1000 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) In-Reply-To: <4EF09983.7050405@oracle.com> References: <4EF09983.7050405@oracle.com> Message-ID: <4EF1265F.5080701@oracle.com> Hi Paul, A few comments below. Cheers, David On 21/12/2011 12:19 AM, Paul Hohensee wrote: > This is actually a bit broader scope than the Summary suggests, in that > it takes into > account the possibility that socklen_t might not be the same bit width as > int and jint (which latter two are assumed synonymous in the jvm). I spent > a bit of time with socket.h on linux/bsd/solaris to verify the actual > argument > types of the socket methods used by the jvm. I changed the os methods > so that their formal argument types match socket.h and put that adapter > code in jvm.cpp so as to have only a single copy of it. > > Webrev here > > http://cr.openjdk.java.net/~phh/7091417.00/ jvm.cpp: I would have expected this to need explicit casts on some platforms, else I'd expect compiler warnings if a socklen_t is not an int: 3557 JVM_LEAF(jint, JVM_Accept(jint fd, struct sockaddr *him, jint *len)) 3558 JVMWrapper2("JVM_Accept (0x%x)", fd); 3559 //%note jvm_r6 3560 socklen_t socklen = *len; 3561 jint result = os::accept(fd, him, &socklen); 3562 *len = socklen; 3563 return result; 3564 JVM_END and similarly for JVM_Recvfrom / JVM_GetSockName / JVM_GetSockOpt --- jvm_bsd.h: I think the include for sys/socket.h needs to be moved to where the other includes start. It seems reasonable to me that its inclusion may be affected by the STDC macro stuff. --- os_bsd.inline.hpp I was wondering about the issue of the flags being int or uint. The linux manpage for recv: http://linux.die.net/man/2/recv sheds some light: "The prototypes given above follow glibc2. The Single UNIX Specification agrees, except that it has return values of type ssize_t (while 4.x BSD and libc4 and libc5 all have int). The flags argument is int in 4.x BSD, but unsigned int in libc4 and libc5. The len argument is int in 4.x BSD, but size_t in libc4 and libc5. The addrlen argument is int * in 4.x BSD, libc4 and libc5. The present socklen_t * was invented by POSIX. See also accept(2). " I'm assuming from this that libc4 and libc5 pre-date glibc2 and that we no longer have to worry about them? --- os_.inline.hpp These files redundantly include sys/socket.h directly when it is now coming in via jvm_.hpp via os.hpp --- os_solaris.cpp In recv/send etc do we have a potential issue with the casts from ssize_t to int on 64-bit systems? --- jvm_windows.h Shouldn't you include ws2tcpip.h to get socklen_t? That's what the JDK networking code uses. (Though as all this sock stuff is unused on win32 I guess it doesn't really matter.) > Thanks, > > Paul > From paul.hohensee at oracle.com Wed Dec 21 06:03:31 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 21 Dec 2011 09:03:31 -0500 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) In-Reply-To: <4EF1265F.5080701@oracle.com> References: <4EF09983.7050405@oracle.com> <4EF1265F.5080701@oracle.com> Message-ID: <4EF1E733.8030905@oracle.com> Thank you for the thorough review. New webrev here http://cr.openjdk.java.net/~phh/7091417.01/ Any other takers? I'd like to push this today in time for next week's promotion. Response inline. On 12/20/11 7:20 PM, David Holmes wrote: > Hi Paul, > > A few comments below. > > Cheers, > David > > On 21/12/2011 12:19 AM, Paul Hohensee wrote: >> This is actually a bit broader scope than the Summary suggests, in that >> it takes into >> account the possibility that socklen_t might not be the same bit >> width as >> int and jint (which latter two are assumed synonymous in the jvm). I >> spent >> a bit of time with socket.h on linux/bsd/solaris to verify the actual >> argument >> types of the socket methods used by the jvm. I changed the os methods >> so that their formal argument types match socket.h and put that adapter >> code in jvm.cpp so as to have only a single copy of it. >> >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7091417.00/ > > jvm.cpp: > > I would have expected this to need explicit casts on some platforms, > else I'd expect compiler warnings if a socklen_t is not an int: > > 3557 JVM_LEAF(jint, JVM_Accept(jint fd, struct sockaddr *him, jint *len)) > 3558 JVMWrapper2("JVM_Accept (0x%x)", fd); > 3559 //%note jvm_r6 > 3560 socklen_t socklen = *len; > 3561 jint result = os::accept(fd, him, &socklen); > 3562 *len = socklen; > 3563 return result; > 3564 JVM_END > > and similarly for JVM_Recvfrom / JVM_GetSockName / JVM_GetSockOpt > Fixed. > --- > > jvm_bsd.h: > > I think the include for sys/socket.h needs to be moved to where the > other includes start. It seems reasonable to me that its inclusion may > be affected by the STDC macro stuff. Moved down to just after the include of sys/param.h. Ditto in jvm_solaris/ linux/windows.h All the jvm_.h files seem to be kludges, but fixing that is something for another time. > > --- > > os_bsd.inline.hpp > > I was wondering about the issue of the flags being int or uint. The > linux manpage for recv: > > http://linux.die.net/man/2/recv > > sheds some light: > > "The prototypes given above follow glibc2. The Single UNIX > Specification agrees, except that it has return values of type ssize_t > (while 4.x BSD and libc4 and libc5 all have int). The flags argument > is int in 4.x BSD, but unsigned int in libc4 and libc5. The len > argument is int in 4.x BSD, but size_t in libc4 and libc5. The addrlen > argument is int * in 4.x BSD, libc4 and libc5. The present socklen_t * > was invented by POSIX. See also accept(2). " > > I'm assuming from this that libc4 and libc5 pre-date glibc2 and that > we no longer have to worry about them? That's what I'm assuming. But thinking about it a bit more, it would be a good idea to cast the flags arguments to uint so that whether or not the formal flags argument types in the OS include files are signed or unsigned, the value will be zero-extended if it's wider. Done in the new webrev. > > --- > > os_.inline.hpp > > These files redundantly include sys/socket.h directly when it is now > coming in via jvm_.hpp via os.hpp Yes, but the jvm_.h files seem to be a hack, so I'd prefer to leave the includes in the os_.inline.hpp files. > > --- > > os_solaris.cpp > > In recv/send etc do we have a potential issue with the casts from > ssize_t to int on 64-bit systems? We do, but since the jdk interfaces return ints, there's nothing we can do unless we change those interfaces, so I didn't bother fixing it in the jvm. I'll file a CR against the jdk. > > --- > > jvm_windows.h > > Shouldn't you include ws2tcpip.h to get socklen_t? That's what the JDK > networking code uses. (Though as all this sock stuff is unused on > win32 I guess it doesn't really matter.) Done. Thanks again, Paul > > >> Thanks, >> >> Paul >> From bertrand.delsart at oracle.com Wed Dec 21 06:48:57 2011 From: bertrand.delsart at oracle.com (bertrand.delsart at oracle.com) Date: Wed, 21 Dec 2011 14:48:57 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 7116216: StackOverflow GC crash Message-ID: <20111221144902.381BE4777A@hg.openjdk.java.net> Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java From coleen.phillimore at oracle.com Wed Dec 21 08:56:12 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Dec 2011 11:56:12 -0500 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) In-Reply-To: <4EF1E733.8030905@oracle.com> References: <4EF09983.7050405@oracle.com> <4EF1265F.5080701@oracle.com> <4EF1E733.8030905@oracle.com> Message-ID: <4EF20FAC.9050003@oracle.com> looks good to me! coleenp On 12/21/2011 9:03 AM, Paul Hohensee wrote: > Thank you for the thorough review. New webrev here > > http://cr.openjdk.java.net/~phh/7091417.01/ > > Any other takers? I'd like to push this today in time for next week's > promotion. > > Response inline. > > On 12/20/11 7:20 PM, David Holmes wrote: >> Hi Paul, >> >> A few comments below. >> >> Cheers, >> David >> >> On 21/12/2011 12:19 AM, Paul Hohensee wrote: >>> This is actually a bit broader scope than the Summary suggests, in that >>> it takes into >>> account the possibility that socklen_t might not be the same bit >>> width as >>> int and jint (which latter two are assumed synonymous in the jvm). I >>> spent >>> a bit of time with socket.h on linux/bsd/solaris to verify the actual >>> argument >>> types of the socket methods used by the jvm. I changed the os methods >>> so that their formal argument types match socket.h and put that adapter >>> code in jvm.cpp so as to have only a single copy of it. >>> >>> Webrev here >>> >>> http://cr.openjdk.java.net/~phh/7091417.00/ >> >> jvm.cpp: >> >> I would have expected this to need explicit casts on some platforms, >> else I'd expect compiler warnings if a socklen_t is not an int: >> >> 3557 JVM_LEAF(jint, JVM_Accept(jint fd, struct sockaddr *him, jint >> *len)) >> 3558 JVMWrapper2("JVM_Accept (0x%x)", fd); >> 3559 //%note jvm_r6 >> 3560 socklen_t socklen = *len; >> 3561 jint result = os::accept(fd, him, &socklen); >> 3562 *len = socklen; >> 3563 return result; >> 3564 JVM_END >> >> and similarly for JVM_Recvfrom / JVM_GetSockName / JVM_GetSockOpt >> > > Fixed. > >> --- >> >> jvm_bsd.h: >> >> I think the include for sys/socket.h needs to be moved to where the >> other includes start. It seems reasonable to me that its inclusion >> may be affected by the STDC macro stuff. > > Moved down to just after the include of sys/param.h. Ditto in > jvm_solaris/ > linux/windows.h All the jvm_.h files seem to be kludges, but fixing > that is something for another time. > >> >> --- >> >> os_bsd.inline.hpp >> >> I was wondering about the issue of the flags being int or uint. The >> linux manpage for recv: >> >> http://linux.die.net/man/2/recv >> >> sheds some light: >> >> "The prototypes given above follow glibc2. The Single UNIX >> Specification agrees, except that it has return values of type >> ssize_t (while 4.x BSD and libc4 and libc5 all have int). The flags >> argument is int in 4.x BSD, but unsigned int in libc4 and libc5. The >> len argument is int in 4.x BSD, but size_t in libc4 and libc5. The >> addrlen argument is int * in 4.x BSD, libc4 and libc5. The present >> socklen_t * was invented by POSIX. See also accept(2). " >> >> I'm assuming from this that libc4 and libc5 pre-date glibc2 and that >> we no longer have to worry about them? > > That's what I'm assuming. But thinking about it a bit more, it would > be a > good idea to cast the flags arguments to uint so that whether or not the > formal flags argument types in the OS include files are signed or > unsigned, > the value will be zero-extended if it's wider. Done in the new webrev. > >> >> --- >> >> os_.inline.hpp >> >> These files redundantly include sys/socket.h directly when it is now >> coming in via jvm_.hpp via os.hpp > > Yes, but the jvm_.h files seem to be a hack, so I'd prefer to leave > the includes in the os_.inline.hpp files. > >> >> --- >> >> os_solaris.cpp >> >> In recv/send etc do we have a potential issue with the casts from >> ssize_t to int on 64-bit systems? > > We do, but since the jdk interfaces return ints, there's nothing we > can do > unless we change those interfaces, so I didn't bother fixing it in the > jvm. > I'll file a CR against the jdk. > >> >> --- >> >> jvm_windows.h >> >> Shouldn't you include ws2tcpip.h to get socklen_t? That's what the >> JDK networking code uses. (Though as all this sock stuff is unused on >> win32 I guess it doesn't really matter.) > > Done. > > Thanks again, > > Paul > >> >> >>> Thanks, >>> >>> Paul >>> From paul.hohensee at oracle.com Wed Dec 21 09:24:22 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 21 Dec 2011 12:24:22 -0500 Subject: test, pls ignore Message-ID: <4EF21646.2090301@oracle.com> From paul.hohensee at oracle.com Wed Dec 21 10:10:45 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 21 Dec 2011 13:10:45 -0500 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) In-Reply-To: <4EF20FAC.9050003@oracle.com> References: <4EF09983.7050405@oracle.com> <4EF1265F.5080701@oracle.com> <4EF1E733.8030905@oracle.com> <4EF20FAC.9050003@oracle.com> Message-ID: <4EF22125.60500@oracle.com> Thank you, Coleen. Paul On 12/21/11 11:56 AM, Coleen Phillimore wrote: > looks good to me! > coleenp > > On 12/21/2011 9:03 AM, Paul Hohensee wrote: >> Thank you for the thorough review. New webrev here >> >> http://cr.openjdk.java.net/~phh/7091417.01/ >> >> Any other takers? I'd like to push this today in time for next >> week's promotion. >> >> Response inline. >> >> On 12/20/11 7:20 PM, David Holmes wrote: >>> Hi Paul, >>> >>> A few comments below. >>> >>> Cheers, >>> David >>> >>> On 21/12/2011 12:19 AM, Paul Hohensee wrote: >>>> This is actually a bit broader scope than the Summary suggests, in >>>> that >>>> it takes into >>>> account the possibility that socklen_t might not be the same bit >>>> width as >>>> int and jint (which latter two are assumed synonymous in the jvm). >>>> I spent >>>> a bit of time with socket.h on linux/bsd/solaris to verify the actual >>>> argument >>>> types of the socket methods used by the jvm. I changed the os methods >>>> so that their formal argument types match socket.h and put that >>>> adapter >>>> code in jvm.cpp so as to have only a single copy of it. >>>> >>>> Webrev here >>>> >>>> http://cr.openjdk.java.net/~phh/7091417.00/ >>> >>> jvm.cpp: >>> >>> I would have expected this to need explicit casts on some platforms, >>> else I'd expect compiler warnings if a socklen_t is not an int: >>> >>> 3557 JVM_LEAF(jint, JVM_Accept(jint fd, struct sockaddr *him, jint >>> *len)) >>> 3558 JVMWrapper2("JVM_Accept (0x%x)", fd); >>> 3559 //%note jvm_r6 >>> 3560 socklen_t socklen = *len; >>> 3561 jint result = os::accept(fd, him, &socklen); >>> 3562 *len = socklen; >>> 3563 return result; >>> 3564 JVM_END >>> >>> and similarly for JVM_Recvfrom / JVM_GetSockName / JVM_GetSockOpt >>> >> >> Fixed. >> >>> --- >>> >>> jvm_bsd.h: >>> >>> I think the include for sys/socket.h needs to be moved to where the >>> other includes start. It seems reasonable to me that its inclusion >>> may be affected by the STDC macro stuff. >> >> Moved down to just after the include of sys/param.h. Ditto in >> jvm_solaris/ >> linux/windows.h All the jvm_.h files seem to be kludges, but fixing >> that is something for another time. >> >>> >>> --- >>> >>> os_bsd.inline.hpp >>> >>> I was wondering about the issue of the flags being int or uint. The >>> linux manpage for recv: >>> >>> http://linux.die.net/man/2/recv >>> >>> sheds some light: >>> >>> "The prototypes given above follow glibc2. The Single UNIX >>> Specification agrees, except that it has return values of type >>> ssize_t (while 4.x BSD and libc4 and libc5 all have int). The flags >>> argument is int in 4.x BSD, but unsigned int in libc4 and libc5. The >>> len argument is int in 4.x BSD, but size_t in libc4 and libc5. The >>> addrlen argument is int * in 4.x BSD, libc4 and libc5. The present >>> socklen_t * was invented by POSIX. See also accept(2). " >>> >>> I'm assuming from this that libc4 and libc5 pre-date glibc2 and that >>> we no longer have to worry about them? >> >> That's what I'm assuming. But thinking about it a bit more, it would >> be a >> good idea to cast the flags arguments to uint so that whether or not the >> formal flags argument types in the OS include files are signed or >> unsigned, >> the value will be zero-extended if it's wider. Done in the new webrev. >> >>> >>> --- >>> >>> os_.inline.hpp >>> >>> These files redundantly include sys/socket.h directly when it is now >>> coming in via jvm_.hpp via os.hpp >> >> Yes, but the jvm_.h files seem to be a hack, so I'd prefer to leave >> the includes in the os_.inline.hpp files. >> >>> >>> --- >>> >>> os_solaris.cpp >>> >>> In recv/send etc do we have a potential issue with the casts from >>> ssize_t to int on 64-bit systems? >> >> We do, but since the jdk interfaces return ints, there's nothing we >> can do >> unless we change those interfaces, so I didn't bother fixing it in >> the jvm. >> I'll file a CR against the jdk. >> >>> >>> --- >>> >>> jvm_windows.h >>> >>> Shouldn't you include ws2tcpip.h to get socklen_t? That's what the >>> JDK networking code uses. (Though as all this sock stuff is unused >>> on win32 I guess it doesn't really matter.) >> >> Done. >> >> Thanks again, >> >> Paul >> >>> >>> >>>> Thanks, >>>> >>>> Paul >>>> From daniel.daugherty at oracle.com Wed Dec 21 11:09:08 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 12:09:08 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) Message-ID: <4EF22ED4.30804@oracle.com> Greetings, This is a code review request for "day one" memory leaks in the java.lang.instrument.Instrumentation.redefineClasses() and JVM/TI RetransformClasses() APIs. Since one leak is in the JDK and the other leak is in the VM, I'm sending out separate webrevs for each repo. I'm also attacking these leaks in three releases in parallel so there is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm trying to get this all done before Christmas! Here are the bug links: 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 I don't know why the bugs.sun.com links aren't showing up yet... I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ I expect the OpenJDK6 version of the fixes to very similar if not identical to the JDK6u29 version. I haven't been tracking the OpenJDK6 project as closely as I used to so I don't know whether these fixes should go back there also. Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ The JDK7u4 JLI code has some other, unrelated fixes relative to the JDK6u29 JLI code. That required a very minor change in my fix to JPLISAgent.c to insulate against unexpected JVM/TI phase values in a slightly different way than the original JDK7u4 code. Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but I baselined and tested the fix against HSX-23-B06 so I'm sending out the webrev for what I actually used. Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are also identical. I've run the following test suites: - VM/NSK jvmti, VM/NSK jvmti_unit - VM/NSK jdwp - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi - SDK/JDK java/lang/instrument - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi - VM/NSK heapdump - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools on the following configs: - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} - Solaris X86 JDK6u29/HSX-20 (done - no regressions) - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) - Solaris X86 JDK8/HSX-23-B08 (just started) - WinXP JDK8/HSX-23-B08 (not yet started) Thanks, in advance, for any feedback... Dan From coleen.phillimore at oracle.com Wed Dec 21 13:06:17 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Dec 2011 16:06:17 -0500 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF22ED4.30804@oracle.com> References: <4EF22ED4.30804@oracle.com> Message-ID: <4EF24A49.7000903@oracle.com> Dan, I reviewed one of the hotspot versions and it looks good to me. I have one request that the code in parseClassFile in the conditional JvmtiExport::should_post_class_file_load_hook() { ... } be made into it's own function because it's not the straight line case and is getting to be a larger block of code. If it's not hard to do. We still want to know how you found it... very impressive! Thanks, Coleen On 12/21/2011 2:09 PM, Daniel D. Daugherty wrote: > Greetings, > > This is a code review request for "day one" memory leaks in > the java.lang.instrument.Instrumentation.redefineClasses() > and JVM/TI RetransformClasses() APIs. > > Since one leak is in the JDK and the other leak is in the > VM, I'm sending out separate webrevs for each repo. I'm also > attacking these leaks in three releases in parallel so there > is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm > trying to get this all done before Christmas! > > Here are the bug links: > > 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 > http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 > > 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 > http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 > > I don't know why the bugs.sun.com links aren't showing up yet... > > I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. > > Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: > > http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ > http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ > > I expect the OpenJDK6 version of the fixes to very similar if not > identical to the JDK6u29 version. I haven't been tracking the > OpenJDK6 project as closely as I used to so I don't know whether > these fixes should go back there also. > > Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: > > http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ > http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ > > The JDK7u4 JLI code has some other, unrelated fixes relative to > the JDK6u29 JLI code. That required a very minor change in my fix > to JPLISAgent.c to insulate against unexpected JVM/TI phase values > in a slightly different way than the original JDK7u4 code. > > Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but > I baselined and tested the fix against HSX-23-B06 so I'm sending out > the webrev for what I actually used. > > Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: > > http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ > http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ > > The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. > The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are > also identical. > > I've run the following test suites: > > - VM/NSK jvmti, VM/NSK jvmti_unit > - VM/NSK jdwp > - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi > - SDK/JDK java/lang/instrument > - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi > - VM/NSK heapdump > - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools > > on the following configs: > > - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} > - Solaris X86 JDK6u29/HSX-20 (done - no regressions) > - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) > - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) > - Solaris X86 JDK8/HSX-23-B08 (just started) > - WinXP JDK8/HSX-23-B08 (not yet started) > > Thanks, in advance, for any feedback... > > Dan > From daniel.daugherty at oracle.com Wed Dec 21 13:25:11 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 14:25:11 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF24A49.7000903@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF24A49.7000903@oracle.com> Message-ID: <4EF24EB7.2020006@oracle.com> Coleen, Thanks for the quick review! I don't think it would be too hard to refactor that code, but I would prefer not to for a couple of reasons: - the JDK6u29 version will likely be pushed as an escalation fix and refactoring is frowned upon unless absolutely necessary - for ease of determining correctness with all three versions, they should remain as similar as possible Are you OK with this resolution? Please let me know. Dan On 12/21/11 2:06 PM, Coleen Phillimore wrote: > > Dan, I reviewed one of the hotspot versions and it looks good to me. > I have one request that the code in parseClassFile in the conditional > JvmtiExport::should_post_class_file_load_hook() { ... } be made into > it's own function because it's not the straight line case and is > getting to be a larger block of code. If it's not hard to do. > We still want to know how you found it... very impressive! > > Thanks, > Coleen > > On 12/21/2011 2:09 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> This is a code review request for "day one" memory leaks in >> the java.lang.instrument.Instrumentation.redefineClasses() >> and JVM/TI RetransformClasses() APIs. >> >> Since one leak is in the JDK and the other leak is in the >> VM, I'm sending out separate webrevs for each repo. I'm also >> attacking these leaks in three releases in parallel so there >> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >> trying to get this all done before Christmas! >> >> Here are the bug links: >> >> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >> >> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >> >> I don't know why the bugs.sun.com links aren't showing up yet... >> >> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >> >> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >> >> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >> >> I expect the OpenJDK6 version of the fixes to very similar if not >> identical to the JDK6u29 version. I haven't been tracking the >> OpenJDK6 project as closely as I used to so I don't know whether >> these fixes should go back there also. >> >> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >> >> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >> >> The JDK7u4 JLI code has some other, unrelated fixes relative to >> the JDK6u29 JLI code. That required a very minor change in my fix >> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >> in a slightly different way than the original JDK7u4 code. >> >> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >> I baselined and tested the fix against HSX-23-B06 so I'm sending out >> the webrev for what I actually used. >> >> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >> >> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >> >> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >> also identical. >> >> I've run the following test suites: >> >> - VM/NSK jvmti, VM/NSK jvmti_unit >> - VM/NSK jdwp >> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >> - SDK/JDK java/lang/instrument >> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >> - VM/NSK heapdump >> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >> >> on the following configs: >> >> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >> - Solaris X86 JDK8/HSX-23-B08 (just started) >> - WinXP JDK8/HSX-23-B08 (not yet started) >> >> Thanks, in advance, for any feedback... >> >> Dan >> From coleen.phillimore at oracle.com Wed Dec 21 13:32:05 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Dec 2011 16:32:05 -0500 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF24EB7.2020006@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF24A49.7000903@oracle.com> <4EF24EB7.2020006@oracle.com> Message-ID: <4EF25055.8090004@oracle.com> Sure, that's okay then. Coleen On 12/21/2011 4:25 PM, Daniel D. Daugherty wrote: > Coleen, > > Thanks for the quick review! > > I don't think it would be too hard to refactor that code, but > I would prefer not to for a couple of reasons: > > - the JDK6u29 version will likely be pushed as an escalation fix > and refactoring is frowned upon unless absolutely necessary > - for ease of determining correctness with all three versions, > they should remain as similar as possible > > Are you OK with this resolution? Please let me know. > > Dan > > > On 12/21/11 2:06 PM, Coleen Phillimore wrote: >> >> Dan, I reviewed one of the hotspot versions and it looks good to me. >> I have one request that the code in parseClassFile in the >> conditional JvmtiExport::should_post_class_file_load_hook() { ... } >> be made into it's own function because it's not the straight line >> case and is getting to be a larger block of code. If it's not hard >> to do. >> We still want to know how you found it... very impressive! >> >> Thanks, >> Coleen >> >> On 12/21/2011 2:09 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> This is a code review request for "day one" memory leaks in >>> the java.lang.instrument.Instrumentation.redefineClasses() >>> and JVM/TI RetransformClasses() APIs. >>> >>> Since one leak is in the JDK and the other leak is in the >>> VM, I'm sending out separate webrevs for each repo. I'm also >>> attacking these leaks in three releases in parallel so there >>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>> trying to get this all done before Christmas! >>> >>> Here are the bug links: >>> >>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>> >>> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>> >>> I don't know why the bugs.sun.com links aren't showing up yet... >>> >>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>> >>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>> >>> I expect the OpenJDK6 version of the fixes to very similar if not >>> identical to the JDK6u29 version. I haven't been tracking the >>> OpenJDK6 project as closely as I used to so I don't know whether >>> these fixes should go back there also. >>> >>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>> >>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>> the JDK6u29 JLI code. That required a very minor change in my fix >>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>> in a slightly different way than the original JDK7u4 code. >>> >>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>> the webrev for what I actually used. >>> >>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>> >>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>> also identical. >>> >>> I've run the following test suites: >>> >>> - VM/NSK jvmti, VM/NSK jvmti_unit >>> - VM/NSK jdwp >>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>> - SDK/JDK java/lang/instrument >>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>> - VM/NSK heapdump >>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>> >>> on the following configs: >>> >>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>> - WinXP JDK8/HSX-23-B08 (not yet started) >>> >>> Thanks, in advance, for any feedback... >>> >>> Dan >>> From karen.kinnear at oracle.com Wed Dec 21 13:47:44 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 21 Dec 2011 16:47:44 -0500 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF22ED4.30804@oracle.com> References: <4EF22ED4.30804@oracle.com> Message-ID: Dan, All versions of hotspot changes look good. For the JDK and test side: 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { 2) new lines 1311-1312 Why do you break if an error occurred? If there is a reason to stop freeing memory, would that also apply if you already had had an error? So you would want to check a new cleanuperrorOccurred regardless of pre-existing error? But I suspect leaving out the break would make more sense. thanks, Karen On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: > Greetings, > > This is a code review request for "day one" memory leaks in > the java.lang.instrument.Instrumentation.redefineClasses() > and JVM/TI RetransformClasses() APIs. > > Since one leak is in the JDK and the other leak is in the > VM, I'm sending out separate webrevs for each repo. I'm also > attacking these leaks in three releases in parallel so there > is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm > trying to get this all done before Christmas! > > Here are the bug links: > > 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 > http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 > > 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 > http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 > > I don't know why the bugs.sun.com links aren't showing up yet... > > I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. > > Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: > > http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ > http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ > > I expect the OpenJDK6 version of the fixes to very similar if not > identical to the JDK6u29 version. I haven't been tracking the > OpenJDK6 project as closely as I used to so I don't know whether > these fixes should go back there also. > > Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: > > http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ > http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ > > The JDK7u4 JLI code has some other, unrelated fixes relative to > the JDK6u29 JLI code. That required a very minor change in my fix > to JPLISAgent.c to insulate against unexpected JVM/TI phase values > in a slightly different way than the original JDK7u4 code. > > Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but > I baselined and tested the fix against HSX-23-B06 so I'm sending out > the webrev for what I actually used. > > Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: > > http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ > http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ > > The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. > The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are > also identical. > > I've run the following test suites: > > - VM/NSK jvmti, VM/NSK jvmti_unit > - VM/NSK jdwp > - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi > - SDK/JDK java/lang/instrument > - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi > - VM/NSK heapdump > - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools > > on the following configs: > > - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} > - Solaris X86 JDK6u29/HSX-20 (done - no regressions) > - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) > - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) > - Solaris X86 JDK8/HSX-23-B08 (just started) > - WinXP JDK8/HSX-23-B08 (not yet started) > > Thanks, in advance, for any feedback... > > Dan > From daniel.daugherty at oracle.com Wed Dec 21 14:41:05 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 15:41:05 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: References: <4EF22ED4.30804@oracle.com> Message-ID: <4EF26081.6020201@oracle.com> Karen, Thanks for the quick review! Replies in-lined below... On 12/21/11 2:47 PM, Karen Kinnear wrote: > Dan, > > All versions of hotspot changes look good. Thanks! Are you OK if I don't wait for someone from the new Serviceability team on this review? Serguei has already left for the holidays... and I told him to ignore any e-mails from me :-) > For the JDK and test side: > 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { Nice catch! This line: 1212 if (!errorOccurred) { should change back to: 1212 else { I missed that when I was backing out some more complicated stuff that I gave up on. Fixed in all three versions. > 2) new lines 1311-1312 > Why do you break if an error occurred? Because I was trying to match the existing style too much. The for-loop from lines 1235-1276 does that: if I have an error, then break... > If there is a reason to stop freeing memory, would that also apply if > you already had had an error? So you would want to check a new cleanuperrorOccurred > regardless of pre-existing error? > But I suspect leaving out the break would make more sense. For this block: 1304 /* 1305 * Only check for error if we didn't already have one 1306 * so we don't overwrite errorOccurred. 1307 */ 1308 if (!errorOccurred) { 1309 errorOccurred = checkForThrowable(jnienv); 1310 jplis_assert(!errorOccurred); 1311 if (errorOccurred) { 1312 break; 1313 } 1314 } I'm going to delete lines 1311-1313 so we'll just try to keep freeing as many of the memory arrays as we can... Fixed in all three versions. On a related note, jplis_assert() appears to be enabled even in product bits. Which means if one of the many jplis_assert() calls fails, then the agent terminates. I don't know the history behind it being enabled in all bits, but I figure that's a different issue for the Serviceability team to mull on... Thanks again for the review. Dan > thanks, > Karen > > On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> This is a code review request for "day one" memory leaks in >> the java.lang.instrument.Instrumentation.redefineClasses() >> and JVM/TI RetransformClasses() APIs. >> >> Since one leak is in the JDK and the other leak is in the >> VM, I'm sending out separate webrevs for each repo. I'm also >> attacking these leaks in three releases in parallel so there >> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >> trying to get this all done before Christmas! >> >> Here are the bug links: >> >> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >> >> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >> >> I don't know why the bugs.sun.com links aren't showing up yet... >> >> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >> >> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >> >> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >> >> I expect the OpenJDK6 version of the fixes to very similar if not >> identical to the JDK6u29 version. I haven't been tracking the >> OpenJDK6 project as closely as I used to so I don't know whether >> these fixes should go back there also. >> >> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >> >> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >> >> The JDK7u4 JLI code has some other, unrelated fixes relative to >> the JDK6u29 JLI code. That required a very minor change in my fix >> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >> in a slightly different way than the original JDK7u4 code. >> >> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >> I baselined and tested the fix against HSX-23-B06 so I'm sending out >> the webrev for what I actually used. >> >> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >> >> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >> >> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >> also identical. >> >> I've run the following test suites: >> >> - VM/NSK jvmti, VM/NSK jvmti_unit >> - VM/NSK jdwp >> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >> - SDK/JDK java/lang/instrument >> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >> - VM/NSK heapdump >> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >> >> on the following configs: >> >> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >> - Solaris X86 JDK8/HSX-23-B08 (just started) >> - WinXP JDK8/HSX-23-B08 (not yet started) >> >> Thanks, in advance, for any feedback... >> >> Dan >> From karen.kinnear at oracle.com Wed Dec 21 15:07:43 2011 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 21 Dec 2011 18:07:43 -0500 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF26081.6020201@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> Message-ID: Dan, Thank you for the quick fix - I echo Coleen's sentiments of wondering how you managed to find the problem(s). On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: > Karen, > > Thanks for the quick review! Replies in-lined below... > > > On 12/21/11 2:47 PM, Karen Kinnear wrote: >> Dan, >> >> All versions of hotspot changes look good. > > Thanks! Are you OK if I don't wait for someone from the new > Serviceability team on this review? Serguei has already left > for the holidays... and I told him to ignore any e-mails from > me :-) Yes - go for it. Given the holiday timing and how critical this fix is - you have reviews from Coleen and from me. > > >> For the JDK and test side: >> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { > > Nice catch! This line: > > 1212 if (!errorOccurred) { > > should change back to: > > 1212 else { > > I missed that when I was backing out some more complicated > stuff that I gave up on. > > Fixed in all three versions. > > >> 2) new lines 1311-1312 >> Why do you break if an error occurred? > > Because I was trying to match the existing style > too much. The for-loop from lines 1235-1276 does > that: if I have an error, then break... > > >> If there is a reason to stop freeing memory, would that also apply if >> you already had had an error? So you would want to check a new cleanuperrorOccurred >> regardless of pre-existing error? >> But I suspect leaving out the break would make more sense. > > For this block: > > 1304 /* > 1305 * Only check for error if we didn't already have one > 1306 * so we don't overwrite errorOccurred. > 1307 */ > 1308 if (!errorOccurred) { > 1309 errorOccurred = checkForThrowable(jnienv); > 1310 jplis_assert(!errorOccurred); > 1311 if (errorOccurred) { > 1312 break; > 1313 } > 1314 } > > I'm going to delete lines 1311-1313 so we'll just try to keep > freeing as many of the memory arrays as we can... Thanks - I prefer that solution. > > Fixed in all three versions. > > On a related note, jplis_assert() appears to be enabled even > in product bits. Which means if one of the many jplis_assert() > calls fails, then the agent terminates. I don't know the history > behind it being enabled in all bits, but I figure that's a > different issue for the Serviceability team to mull on... I wondered about that, but it seemed consistent with existing usage - so I agree. > > Thanks again for the review. > > Dan thanks, Karen > > > > >> thanks, >> Karen >> >> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> This is a code review request for "day one" memory leaks in >>> the java.lang.instrument.Instrumentation.redefineClasses() >>> and JVM/TI RetransformClasses() APIs. >>> >>> Since one leak is in the JDK and the other leak is in the >>> VM, I'm sending out separate webrevs for each repo. I'm also >>> attacking these leaks in three releases in parallel so there >>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>> trying to get this all done before Christmas! >>> >>> Here are the bug links: >>> >>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>> >>> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>> >>> I don't know why the bugs.sun.com links aren't showing up yet... >>> >>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>> >>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>> >>> I expect the OpenJDK6 version of the fixes to very similar if not >>> identical to the JDK6u29 version. I haven't been tracking the >>> OpenJDK6 project as closely as I used to so I don't know whether >>> these fixes should go back there also. >>> >>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>> >>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>> the JDK6u29 JLI code. That required a very minor change in my fix >>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>> in a slightly different way than the original JDK7u4 code. >>> >>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>> the webrev for what I actually used. >>> >>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>> >>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>> also identical. >>> >>> I've run the following test suites: >>> >>> - VM/NSK jvmti, VM/NSK jvmti_unit >>> - VM/NSK jdwp >>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>> - SDK/JDK java/lang/instrument >>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>> - VM/NSK heapdump >>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>> >>> on the following configs: >>> >>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>> - WinXP JDK8/HSX-23-B08 (not yet started) >>> >>> Thanks, in advance, for any feedback... >>> >>> Dan >>> From daniel.daugherty at oracle.com Wed Dec 21 15:16:08 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 16:16:08 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> Message-ID: <4EF268B8.8010601@oracle.com> On 12/21/11 4:07 PM, Karen Kinnear wrote: > Dan, > > Thank you for the quick fix - You're welcome. I'm trying to get this off my plate before I leave for the holidays... so not exactly altruistic... :-) > I echo Coleen's sentiments of wondering how > you managed to find the problem(s). I'll send a reply on that topic later... > On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: > >> Karen, >> >> Thanks for the quick review! Replies in-lined below... >> >> >> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>> Dan, >>> >>> All versions of hotspot changes look good. >> Thanks! Are you OK if I don't wait for someone from the new >> Serviceability team on this review? Serguei has already left >> for the holidays... and I told him to ignore any e-mails from >> me :-) > Yes - go for it. Given the holiday timing and how critical this fix > is - you have reviews from Coleen and from me. I have two HSX reviews (yeah!) and I have one JDK review. I need one more JDK review... >> >>> For the JDK and test side: >>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { >> Nice catch! This line: >> >> 1212 if (!errorOccurred) { >> >> should change back to: >> >> 1212 else { >> >> I missed that when I was backing out some more complicated >> stuff that I gave up on. >> >> Fixed in all three versions. >> >> >>> 2) new lines 1311-1312 >>> Why do you break if an error occurred? >> Because I was trying to match the existing style >> too much. The for-loop from lines 1235-1276 does >> that: if I have an error, then break... >> >> >>> If there is a reason to stop freeing memory, would that also apply if >>> you already had had an error? So you would want to check a new cleanuperrorOccurred >>> regardless of pre-existing error? >>> But I suspect leaving out the break would make more sense. >> For this block: >> >> 1304 /* >> 1305 * Only check for error if we didn't already have one >> 1306 * so we don't overwrite errorOccurred. >> 1307 */ >> 1308 if (!errorOccurred) { >> 1309 errorOccurred = checkForThrowable(jnienv); >> 1310 jplis_assert(!errorOccurred); >> 1311 if (errorOccurred) { >> 1312 break; >> 1313 } >> 1314 } >> >> I'm going to delete lines 1311-1313 so we'll just try to keep >> freeing as many of the memory arrays as we can... > Thanks - I prefer that solution. I figured you might... >> Fixed in all three versions. >> >> On a related note, jplis_assert() appears to be enabled even >> in product bits. Which means if one of the many jplis_assert() >> calls fails, then the agent terminates. I don't know the history >> behind it being enabled in all bits, but I figure that's a >> different issue for the Serviceability team to mull on... > I wondered about that, but it seemed consistent with existing > usage - so I agree. Glad we're on the same page! Dan >> Thanks again for the review. >> >> Dan > thanks, > Karen >> >> >> >>> thanks, >>> Karen >>> >>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> This is a code review request for "day one" memory leaks in >>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>> and JVM/TI RetransformClasses() APIs. >>>> >>>> Since one leak is in the JDK and the other leak is in the >>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>> attacking these leaks in three releases in parallel so there >>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>> trying to get this all done before Christmas! >>>> >>>> Here are the bug links: >>>> >>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>> >>>> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>> >>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>> >>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>> >>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>> >>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>> identical to the JDK6u29 version. I haven't been tracking the >>>> OpenJDK6 project as closely as I used to so I don't know whether >>>> these fixes should go back there also. >>>> >>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>> >>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>> in a slightly different way than the original JDK7u4 code. >>>> >>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>>> the webrev for what I actually used. >>>> >>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>> >>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>> also identical. >>>> >>>> I've run the following test suites: >>>> >>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>> - VM/NSK jdwp >>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>> - SDK/JDK java/lang/instrument >>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>> - VM/NSK heapdump >>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>> >>>> on the following configs: >>>> >>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>> >>>> Thanks, in advance, for any feedback... >>>> >>>> Dan >>>> From david.holmes at oracle.com Wed Dec 21 16:53:05 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Dec 2011 10:53:05 +1000 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) In-Reply-To: <4EF1E733.8030905@oracle.com> References: <4EF09983.7050405@oracle.com> <4EF1265F.5080701@oracle.com> <4EF1E733.8030905@oracle.com> Message-ID: <4EF27F71.9040508@oracle.com> Responses inline ... On 22/12/2011 12:03 AM, Paul Hohensee wrote: > Thank you for the thorough review. New webrev here > > http://cr.openjdk.java.net/~phh/7091417.01/ >> os_bsd.inline.hpp >> >> I was wondering about the issue of the flags being int or uint. The >> linux manpage for recv: >> >> http://linux.die.net/man/2/recv >> >> sheds some light: >> >> "The prototypes given above follow glibc2. The Single UNIX >> Specification agrees, except that it has return values of type ssize_t >> (while 4.x BSD and libc4 and libc5 all have int). The flags argument >> is int in 4.x BSD, but unsigned int in libc4 and libc5. The len >> argument is int in 4.x BSD, but size_t in libc4 and libc5. The addrlen >> argument is int * in 4.x BSD, libc4 and libc5. The present socklen_t * >> was invented by POSIX. See also accept(2). " >> >> I'm assuming from this that libc4 and libc5 pre-date glibc2 and that >> we no longer have to worry about them? > > That's what I'm assuming. But thinking about it a bit more, it would be a > good idea to cast the flags arguments to uint so that whether or not the > formal flags argument types in the OS include files are signed or unsigned, > the value will be zero-extended if it's wider. Done in the new webrev. This confuses me. The current system APIs are defined to take int, but we're passing in uint. But at least this change means that in effect there is no change to this code (uint before, uint now). >> os_.inline.hpp >> >> These files redundantly include sys/socket.h directly when it is now >> coming in via jvm_.hpp via os.hpp > > Yes, but the jvm_.h files seem to be a hack, so I'd prefer to leave > the includes in the os_.inline.hpp files. I don't quite follow the reasoning. Whether a hack or not the jvm_* files exist and are used and so the pre-existing includes are now redundant. Not a big deal. >> os_solaris.cpp >> >> In recv/send etc do we have a potential issue with the casts from >> ssize_t to int on 64-bit systems? > > We do, but since the jdk interfaces return ints, there's nothing we can do > unless we change those interfaces, so I didn't bother fixing it in the jvm. > I'll file a CR against the jdk. Ok. >> jvm_windows.h >> >> Shouldn't you include ws2tcpip.h to get socklen_t? That's what the JDK >> networking code uses. (Though as all this sock stuff is unused on >> win32 I guess it doesn't really matter.) I understand this change has been backed out as ws2tcpip.h caused additional problems. Using an explicit typedef here (whether int or uint) is fine as it is unused code. David ----- > > Done. > > Thanks again, > > Paul > >> >> >>> Thanks, >>> >>> Paul >>> From paul.hohensee at oracle.com Wed Dec 21 17:02:20 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 21 Dec 2011 20:02:20 -0500 Subject: Pls review 7091417: recvfrom's 6th input should be of type socklen_t (M) In-Reply-To: <4EF27F71.9040508@oracle.com> References: <4EF09983.7050405@oracle.com> <4EF1265F.5080701@oracle.com> <4EF1E733.8030905@oracle.com> <4EF27F71.9040508@oracle.com> Message-ID: <4EF2819C.1080904@oracle.com> Thank you for the re-review. Inline... On 12/21/11 7:53 PM, David Holmes wrote: > Responses inline ... > > On 22/12/2011 12:03 AM, Paul Hohensee wrote: >> Thank you for the thorough review. New webrev here >> >> http://cr.openjdk.java.net/~phh/7091417.01/ > >>> os_bsd.inline.hpp >>> >>> I was wondering about the issue of the flags being int or uint. The >>> linux manpage for recv: >>> >>> http://linux.die.net/man/2/recv >>> >>> sheds some light: >>> >>> "The prototypes given above follow glibc2. The Single UNIX >>> Specification agrees, except that it has return values of type ssize_t >>> (while 4.x BSD and libc4 and libc5 all have int). The flags argument >>> is int in 4.x BSD, but unsigned int in libc4 and libc5. The len >>> argument is int in 4.x BSD, but size_t in libc4 and libc5. The addrlen >>> argument is int * in 4.x BSD, libc4 and libc5. The present socklen_t * >>> was invented by POSIX. See also accept(2). " >>> >>> I'm assuming from this that libc4 and libc5 pre-date glibc2 and that >>> we no longer have to worry about them? >> >> That's what I'm assuming. But thinking about it a bit more, it would >> be a >> good idea to cast the flags arguments to uint so that whether or not the >> formal flags argument types in the OS include files are signed or >> unsigned, >> the value will be zero-extended if it's wider. Done in the new webrev. > > This confuses me. The current system APIs are defined to take int, but > we're passing in uint. But at least this change means that in effect > there is no change to this code (uint before, uint now). Yes. I now think it's a good idea to start with an equal-to-int-width unsigned rather than signed type in case the OS interface ever changes flags to a wider unsigned type. Overkill, I guess. > >>> os_.inline.hpp >>> >>> These files redundantly include sys/socket.h directly when it is now >>> coming in via jvm_.hpp via os.hpp >> >> Yes, but the jvm_.h files seem to be a hack, so I'd prefer to leave >> the includes in the os_.inline.hpp files. > > I don't quite follow the reasoning. Whether a hack or not the jvm_* > files exist and are used and so the pre-existing includes are now > redundant. Not a big deal. Thanks. > >>> os_solaris.cpp >>> >>> In recv/send etc do we have a potential issue with the casts from >>> ssize_t to int on 64-bit systems? >> >> We do, but since the jdk interfaces return ints, there's nothing we >> can do >> unless we change those interfaces, so I didn't bother fixing it in >> the jvm. >> I'll file a CR against the jdk. > > Ok. > >>> jvm_windows.h >>> >>> Shouldn't you include ws2tcpip.h to get socklen_t? That's what the JDK >>> networking code uses. (Though as all this sock stuff is unused on >>> win32 I guess it doesn't really matter.) > > I understand this change has been backed out as ws2tcpip.h caused > additional problems. Using an explicit typedef here (whether int or > uint) is fine as it is unused code. Ok. Paul > > > David > ----- > > >> >> Done. >> >> Thanks again, >> >> Paul >> >>> >>> >>>> Thanks, >>>> >>>> Paul >>>> From paul.hohensee at oracle.com Wed Dec 21 18:19:01 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Thu, 22 Dec 2011 02:19:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7091417: recvfrom's 6th input should be of type socklen_t Message-ID: <20111222021905.3327647782@hg.openjdk.java.net> Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 From poonam.bajaj at oracle.com Wed Dec 21 19:05:00 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 22 Dec 2011 08:35:00 +0530 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF268B8.8010601@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> Message-ID: <4EF29E5C.30404@oracle.com> Hi Dan, In the following block (in JPLISAgent.c): /1278 if (!errorOccurred) { 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; 1280 errorCode = (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { 1282 /* insulate caller from the wrong phase error */ 1283 errorCode = JVMTI_ERROR_NONE; 1284 } else { 1285 errorOccurred = (errorCode != JVMTI_ERROR_NONE); 1286 if ( errorOccurred ) { 1287 createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); 1288 } 1289 } 1290 }/ If RedefineClasses() fails here then createAndThrowThrowableFromJVMTIErrorCode() is being called. At the point we would have filled data (upto the value of index 'i') into classDefs and targetFiles but in case of RedefineClasses failure, those will not get freed. Is that correct ? Thanks, Poonam On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: > On 12/21/11 4:07 PM, Karen Kinnear wrote: >> Dan, >> >> Thank you for the quick fix - > > You're welcome. I'm trying to get this off my plate before > I leave for the holidays... so not exactly altruistic... :-) > > >> I echo Coleen's sentiments of wondering how >> you managed to find the problem(s). > > I'll send a reply on that topic later... > > >> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >> >>> Karen, >>> >>> Thanks for the quick review! Replies in-lined below... >>> >>> >>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>> Dan, >>>> >>>> All versions of hotspot changes look good. >>> Thanks! Are you OK if I don't wait for someone from the new >>> Serviceability team on this review? Serguei has already left >>> for the holidays... and I told him to ignore any e-mails from >>> me :-) >> Yes - go for it. Given the holiday timing and how critical this fix >> is - you have reviews from Coleen and from me. > > I have two HSX reviews (yeah!) and I have one JDK review. > I need one more JDK review... > > >>> >>>> For the JDK and test side: >>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { >>> Nice catch! This line: >>> >>> 1212 if (!errorOccurred) { >>> >>> should change back to: >>> >>> 1212 else { >>> >>> I missed that when I was backing out some more complicated >>> stuff that I gave up on. >>> >>> Fixed in all three versions. >>> >>> >>>> 2) new lines 1311-1312 >>>> Why do you break if an error occurred? >>> Because I was trying to match the existing style >>> too much. The for-loop from lines 1235-1276 does >>> that: if I have an error, then break... >>> >>> >>>> If there is a reason to stop freeing memory, would that also >>>> apply if >>>> you already had had an error? So you would want to check a new >>>> cleanuperrorOccurred >>>> regardless of pre-existing error? >>>> But I suspect leaving out the break would make more sense. >>> For this block: >>> >>> 1304 /* >>> 1305 * Only check for error if we didn't >>> already have one >>> 1306 * so we don't overwrite errorOccurred. >>> 1307 */ >>> 1308 if (!errorOccurred) { >>> 1309 errorOccurred = >>> checkForThrowable(jnienv); >>> 1310 jplis_assert(!errorOccurred); >>> 1311 if (errorOccurred) { >>> 1312 break; >>> 1313 } >>> 1314 } >>> >>> I'm going to delete lines 1311-1313 so we'll just try to keep >>> freeing as many of the memory arrays as we can... >> Thanks - I prefer that solution. > > I figured you might... > > >>> Fixed in all three versions. >>> >>> On a related note, jplis_assert() appears to be enabled even >>> in product bits. Which means if one of the many jplis_assert() >>> calls fails, then the agent terminates. I don't know the history >>> behind it being enabled in all bits, but I figure that's a >>> different issue for the Serviceability team to mull on... >> I wondered about that, but it seemed consistent with existing >> usage - so I agree. > > Glad we're on the same page! > > Dan > > >>> Thanks again for the review. >>> >>> Dan >> thanks, >> Karen >>> >>> >>> >>>> thanks, >>>> Karen >>>> >>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>> >>>>> Greetings, >>>>> >>>>> This is a code review request for "day one" memory leaks in >>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>> and JVM/TI RetransformClasses() APIs. >>>>> >>>>> Since one leak is in the JDK and the other leak is in the >>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>> attacking these leaks in three releases in parallel so there >>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>> trying to get this all done before Christmas! >>>>> >>>>> Here are the bug links: >>>>> >>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>> >>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks class >>>>> bytes >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>> >>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>> >>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>> >>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>> >>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>> these fixes should go back there also. >>>>> >>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>> >>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>>> in a slightly different way than the original JDK7u4 code. >>>>> >>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>>>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>>>> the webrev for what I actually used. >>>>> >>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>> >>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>> also identical. >>>>> >>>>> I've run the following test suites: >>>>> >>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>> - VM/NSK jdwp >>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>> - SDK/JDK java/lang/instrument >>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>> - VM/NSK heapdump >>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>> >>>>> on the following configs: >>>>> >>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>> >>>>> Thanks, in advance, for any feedback... >>>>> >>>>> Dan >>>>> -- Best regards, Poonam Oracle Poonam Bajaj | Principal Member of Technical Staff Phone: +91 80 66937451 | Mobile: +91 9844511366 Oracle JVM Sustaining Engineering ORACLE India | 560102 Bangalore Green Oracle Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/2600ab44/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/2600ab44/oracle_sig_logo-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/2600ab44/green-for-email-sig_0-0001.gif From daniel.daugherty at oracle.com Wed Dec 21 19:22:13 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 20:22:13 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF29E5C.30404@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> Message-ID: <4EF2A265.8010606@oracle.com> On 12/21/11 8:05 PM, Poonam Bajaj wrote: > Hi Dan, > > In the following block (in JPLISAgent.c): > > /1278 if (!errorOccurred) { > 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; > 1280 errorCode = > (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); > 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { > 1282 /* insulate caller from the wrong phase > error */ > 1283 errorCode = JVMTI_ERROR_NONE; > 1284 } else { > 1285 errorOccurred = (errorCode != > JVMTI_ERROR_NONE); > 1286 if ( errorOccurred ) { > 1287 > createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); > 1288 } > 1289 } > 1290 }/ > > If RedefineClasses() fails here then > createAndThrowThrowableFromJVMTIErrorCode() is being called. At the > point we would have filled data (upto the value of index 'i') into > classDefs and targetFiles but in case of RedefineClasses failure, > those will not get freed. Is that correct ? No that is not correct and it fooled me also! The createAndThrowThrowableFromJVMTIErrorCode() call does create and throw a throwable Java object, but the redefineClasses() function does not stop executing at that point. It finishes what it was doing, freeing memory that needs to be freed before returning at the end of the function. Darn C-code doesn't behave like Java code. :-) Dan > > > Thanks, > Poonam > > > On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>> Dan, >>> >>> Thank you for the quick fix - >> >> You're welcome. I'm trying to get this off my plate before >> I leave for the holidays... so not exactly altruistic... :-) >> >> >>> I echo Coleen's sentiments of wondering how >>> you managed to find the problem(s). >> >> I'll send a reply on that topic later... >> >> >>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>> >>>> Karen, >>>> >>>> Thanks for the quick review! Replies in-lined below... >>>> >>>> >>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>> Dan, >>>>> >>>>> All versions of hotspot changes look good. >>>> Thanks! Are you OK if I don't wait for someone from the new >>>> Serviceability team on this review? Serguei has already left >>>> for the holidays... and I told him to ignore any e-mails from >>>> me :-) >>> Yes - go for it. Given the holiday timing and how critical this fix >>> is - you have reviews from Coleen and from me. >> >> I have two HSX reviews (yeah!) and I have one JDK review. >> I need one more JDK review... >> >> >>>> >>>>> For the JDK and test side: >>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } >>>>> else { >>>> Nice catch! This line: >>>> >>>> 1212 if (!errorOccurred) { >>>> >>>> should change back to: >>>> >>>> 1212 else { >>>> >>>> I missed that when I was backing out some more complicated >>>> stuff that I gave up on. >>>> >>>> Fixed in all three versions. >>>> >>>> >>>>> 2) new lines 1311-1312 >>>>> Why do you break if an error occurred? >>>> Because I was trying to match the existing style >>>> too much. The for-loop from lines 1235-1276 does >>>> that: if I have an error, then break... >>>> >>>> >>>>> If there is a reason to stop freeing memory, would that also >>>>> apply if >>>>> you already had had an error? So you would want to check a >>>>> new cleanuperrorOccurred >>>>> regardless of pre-existing error? >>>>> But I suspect leaving out the break would make more sense. >>>> For this block: >>>> >>>> 1304 /* >>>> 1305 * Only check for error if we didn't >>>> already have one >>>> 1306 * so we don't overwrite errorOccurred. >>>> 1307 */ >>>> 1308 if (!errorOccurred) { >>>> 1309 errorOccurred = >>>> checkForThrowable(jnienv); >>>> 1310 jplis_assert(!errorOccurred); >>>> 1311 if (errorOccurred) { >>>> 1312 break; >>>> 1313 } >>>> 1314 } >>>> >>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>> freeing as many of the memory arrays as we can... >>> Thanks - I prefer that solution. >> >> I figured you might... >> >> >>>> Fixed in all three versions. >>>> >>>> On a related note, jplis_assert() appears to be enabled even >>>> in product bits. Which means if one of the many jplis_assert() >>>> calls fails, then the agent terminates. I don't know the history >>>> behind it being enabled in all bits, but I figure that's a >>>> different issue for the Serviceability team to mull on... >>> I wondered about that, but it seemed consistent with existing >>> usage - so I agree. >> >> Glad we're on the same page! >> >> Dan >> >> >>>> Thanks again for the review. >>>> >>>> Dan >>> thanks, >>> Karen >>>> >>>> >>>> >>>>> thanks, >>>>> Karen >>>>> >>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>> >>>>>> Greetings, >>>>>> >>>>>> This is a code review request for "day one" memory leaks in >>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>> and JVM/TI RetransformClasses() APIs. >>>>>> >>>>>> Since one leak is in the JDK and the other leak is in the >>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>> attacking these leaks in three releases in parallel so there >>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>> trying to get this all done before Christmas! >>>>>> >>>>>> Here are the bug links: >>>>>> >>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>> >>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks class >>>>>> bytes >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>> >>>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>>> >>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>>> >>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>> >>>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>>> these fixes should go back there also. >>>>>> >>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>> >>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>>>> in a slightly different way than the original JDK7u4 code. >>>>>> >>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>>>>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>>>>> the webrev for what I actually used. >>>>>> >>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>> >>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>>> also identical. >>>>>> >>>>>> I've run the following test suites: >>>>>> >>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>> - VM/NSK jdwp >>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>> - SDK/JDK java/lang/instrument >>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>> - VM/NSK heapdump >>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>> >>>>>> on the following configs: >>>>>> >>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>> >>>>>> Thanks, in advance, for any feedback... >>>>>> >>>>>> Dan >>>>>> > > -- > Best regards, Poonam > > Oracle > Poonam Bajaj | Principal Member of Technical Staff > Phone: +91 80 66937451 | Mobile: +91 > 9844511366 > Oracle JVM Sustaining Engineering > > ORACLE India | 560102 Bangalore > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/92f8bfa3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/92f8bfa3/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 356 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/92f8bfa3/attachment-0003.gif From daniel.daugherty at oracle.com Wed Dec 21 19:23:25 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 20:23:25 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF2A265.8010606@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> <4EF2A265.8010606@oracle.com> Message-ID: <4EF2A2AD.7010408@oracle.com> Poonam, I forgot to ask whether to put you down as a reviewer for both the JDK fix and the HSX fix... so JDK only or both JDK and HSX? Dan On 12/21/11 8:22 PM, Daniel D. Daugherty wrote: > On 12/21/11 8:05 PM, Poonam Bajaj wrote: >> Hi Dan, >> >> In the following block (in JPLISAgent.c): >> >> /1278 if (!errorOccurred) { >> 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; >> 1280 errorCode = >> (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); >> 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { >> 1282 /* insulate caller from the wrong phase >> error */ >> 1283 errorCode = JVMTI_ERROR_NONE; >> 1284 } else { >> 1285 errorOccurred = (errorCode != >> JVMTI_ERROR_NONE); >> 1286 if ( errorOccurred ) { >> 1287 >> createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); >> 1288 } >> 1289 } >> 1290 }/ >> >> If RedefineClasses() fails here then >> createAndThrowThrowableFromJVMTIErrorCode() is being called. At the >> point we would have filled data (upto the value of index 'i') into >> classDefs and targetFiles but in case of RedefineClasses failure, >> those will not get freed. Is that correct ? > > No that is not correct and it fooled me also! > > The createAndThrowThrowableFromJVMTIErrorCode() call > does create and throw a throwable Java object, but the > redefineClasses() function does not stop executing at > that point. It finishes what it was doing, freeing > memory that needs to be freed before returning at the > end of the function. Darn C-code doesn't behave like > Java code. :-) > > Dan > > >> >> >> Thanks, >> Poonam >> >> >> On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >>> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>>> Dan, >>>> >>>> Thank you for the quick fix - >>> >>> You're welcome. I'm trying to get this off my plate before >>> I leave for the holidays... so not exactly altruistic... :-) >>> >>> >>>> I echo Coleen's sentiments of wondering how >>>> you managed to find the problem(s). >>> >>> I'll send a reply on that topic later... >>> >>> >>>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>>> >>>>> Karen, >>>>> >>>>> Thanks for the quick review! Replies in-lined below... >>>>> >>>>> >>>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>>> Dan, >>>>>> >>>>>> All versions of hotspot changes look good. >>>>> Thanks! Are you OK if I don't wait for someone from the new >>>>> Serviceability team on this review? Serguei has already left >>>>> for the holidays... and I told him to ignore any e-mails from >>>>> me :-) >>>> Yes - go for it. Given the holiday timing and how critical this fix >>>> is - you have reviews from Coleen and from me. >>> >>> I have two HSX reviews (yeah!) and I have one JDK review. >>> I need one more JDK review... >>> >>> >>>>> >>>>>> For the JDK and test side: >>>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } >>>>>> else { >>>>> Nice catch! This line: >>>>> >>>>> 1212 if (!errorOccurred) { >>>>> >>>>> should change back to: >>>>> >>>>> 1212 else { >>>>> >>>>> I missed that when I was backing out some more complicated >>>>> stuff that I gave up on. >>>>> >>>>> Fixed in all three versions. >>>>> >>>>> >>>>>> 2) new lines 1311-1312 >>>>>> Why do you break if an error occurred? >>>>> Because I was trying to match the existing style >>>>> too much. The for-loop from lines 1235-1276 does >>>>> that: if I have an error, then break... >>>>> >>>>> >>>>>> If there is a reason to stop freeing memory, would that also >>>>>> apply if >>>>>> you already had had an error? So you would want to check a >>>>>> new cleanuperrorOccurred >>>>>> regardless of pre-existing error? >>>>>> But I suspect leaving out the break would make more sense. >>>>> For this block: >>>>> >>>>> 1304 /* >>>>> 1305 * Only check for error if we didn't >>>>> already have one >>>>> 1306 * so we don't overwrite errorOccurred. >>>>> 1307 */ >>>>> 1308 if (!errorOccurred) { >>>>> 1309 errorOccurred = >>>>> checkForThrowable(jnienv); >>>>> 1310 jplis_assert(!errorOccurred); >>>>> 1311 if (errorOccurred) { >>>>> 1312 break; >>>>> 1313 } >>>>> 1314 } >>>>> >>>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>>> freeing as many of the memory arrays as we can... >>>> Thanks - I prefer that solution. >>> >>> I figured you might... >>> >>> >>>>> Fixed in all three versions. >>>>> >>>>> On a related note, jplis_assert() appears to be enabled even >>>>> in product bits. Which means if one of the many jplis_assert() >>>>> calls fails, then the agent terminates. I don't know the history >>>>> behind it being enabled in all bits, but I figure that's a >>>>> different issue for the Serviceability team to mull on... >>>> I wondered about that, but it seemed consistent with existing >>>> usage - so I agree. >>> >>> Glad we're on the same page! >>> >>> Dan >>> >>> >>>>> Thanks again for the review. >>>>> >>>>> Dan >>>> thanks, >>>> Karen >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> This is a code review request for "day one" memory leaks in >>>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>>> and JVM/TI RetransformClasses() APIs. >>>>>>> >>>>>>> Since one leak is in the JDK and the other leak is in the >>>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>>> attacking these leaks in three releases in parallel so there >>>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>>> trying to get this all done before Christmas! >>>>>>> >>>>>>> Here are the bug links: >>>>>>> >>>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>>> >>>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks class >>>>>>> bytes >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>>> >>>>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>>>> >>>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>>>> >>>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>>> >>>>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>>>> these fixes should go back there also. >>>>>>> >>>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the >>>>>>> fixes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>>> >>>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>>>>> in a slightly different way than the original JDK7u4 code. >>>>>>> >>>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>>>>>> I baselined and tested the fix against HSX-23-B06 so I'm sending >>>>>>> out >>>>>>> the webrev for what I actually used. >>>>>>> >>>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>>> >>>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>>>> also identical. >>>>>>> >>>>>>> I've run the following test suites: >>>>>>> >>>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>>> - VM/NSK jdwp >>>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>>> - SDK/JDK java/lang/instrument >>>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>>> - VM/NSK heapdump >>>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>>> >>>>>>> on the following configs: >>>>>>> >>>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>>> >>>>>>> Thanks, in advance, for any feedback... >>>>>>> >>>>>>> Dan >>>>>>> >> >> -- >> Best regards, Poonam >> >> Oracle >> Poonam Bajaj | Principal Member of Technical Staff >> Phone: +91 80 66937451 | Mobile: +91 >> 9844511366 >> Oracle JVM Sustaining Engineering >> >> ORACLE India | 560102 Bangalore >> Green Oracle Oracle is committed >> to developing practices and products that help protect the environment >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/a5b79abe/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/a5b79abe/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 356 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/a5b79abe/attachment-0003.gif From coleen.phillimore at oracle.com Wed Dec 21 20:10:30 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 22 Dec 2011 04:10:30 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20111222041034.879A347784@hg.openjdk.java.net> Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/d532160c55f7 Merge From poonam.bajaj at oracle.com Wed Dec 21 20:40:45 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 22 Dec 2011 10:10:45 +0530 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF2A2AD.7010408@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> <4EF2A265.8010606@oracle.com> <4EF2A2AD.7010408@oracle.com> Message-ID: <4EF2B4CD.5080403@oracle.com> Hi Dan, I have looked at both the JDK and the Hotspot changes, so you can add me as reviewer for both. I especially like the class_load_kind addition to the following trace. 856 RC_TRACE_WITH_THREAD(0x00000001, THREAD, 857 ("loading name=%s kind=%d (avail_mem=" UINT64_FORMAT "K)", 858 the_class->external_name(), _class_load_kind, 859 os::available_memory() >> 10)); Thanks, Poonam On 12/22/2011 8:53 AM, Daniel D. Daugherty wrote: > Poonam, > > I forgot to ask whether to put you down as a reviewer for both > the JDK fix and the HSX fix... so JDK only or both JDK and HSX? > > Dan > > > On 12/21/11 8:22 PM, Daniel D. Daugherty wrote: >> On 12/21/11 8:05 PM, Poonam Bajaj wrote: >>> Hi Dan, >>> >>> In the following block (in JPLISAgent.c): >>> >>> /1278 if (!errorOccurred) { >>> 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; >>> 1280 errorCode = >>> (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); >>> 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { >>> 1282 /* insulate caller from the wrong phase >>> error */ >>> 1283 errorCode = JVMTI_ERROR_NONE; >>> 1284 } else { >>> 1285 errorOccurred = (errorCode != >>> JVMTI_ERROR_NONE); >>> 1286 if ( errorOccurred ) { >>> 1287 >>> createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); >>> 1288 } >>> 1289 } >>> 1290 }/ >>> >>> If RedefineClasses() fails here then >>> createAndThrowThrowableFromJVMTIErrorCode() is being called. At the >>> point we would have filled data (upto the value of index 'i') into >>> classDefs and targetFiles but in case of RedefineClasses failure, >>> those will not get freed. Is that correct ? >> >> No that is not correct and it fooled me also! >> >> The createAndThrowThrowableFromJVMTIErrorCode() call >> does create and throw a throwable Java object, but the >> redefineClasses() function does not stop executing at >> that point. It finishes what it was doing, freeing >> memory that needs to be freed before returning at the >> end of the function. Darn C-code doesn't behave like >> Java code. :-) >> >> Dan >> >> >>> >>> >>> Thanks, >>> Poonam >>> >>> >>> On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >>>> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>>>> Dan, >>>>> >>>>> Thank you for the quick fix - >>>> >>>> You're welcome. I'm trying to get this off my plate before >>>> I leave for the holidays... so not exactly altruistic... :-) >>>> >>>> >>>>> I echo Coleen's sentiments of wondering how >>>>> you managed to find the problem(s). >>>> >>>> I'll send a reply on that topic later... >>>> >>>> >>>>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>>>> >>>>>> Karen, >>>>>> >>>>>> Thanks for the quick review! Replies in-lined below... >>>>>> >>>>>> >>>>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>>>> Dan, >>>>>>> >>>>>>> All versions of hotspot changes look good. >>>>>> Thanks! Are you OK if I don't wait for someone from the new >>>>>> Serviceability team on this review? Serguei has already left >>>>>> for the holidays... and I told him to ignore any e-mails from >>>>>> me :-) >>>>> Yes - go for it. Given the holiday timing and how critical this fix >>>>> is - you have reviews from Coleen and from me. >>>> >>>> I have two HSX reviews (yeah!) and I have one JDK review. >>>> I need one more JDK review... >>>> >>>> >>>>>> >>>>>>> For the JDK and test side: >>>>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } >>>>>>> else { >>>>>> Nice catch! This line: >>>>>> >>>>>> 1212 if (!errorOccurred) { >>>>>> >>>>>> should change back to: >>>>>> >>>>>> 1212 else { >>>>>> >>>>>> I missed that when I was backing out some more complicated >>>>>> stuff that I gave up on. >>>>>> >>>>>> Fixed in all three versions. >>>>>> >>>>>> >>>>>>> 2) new lines 1311-1312 >>>>>>> Why do you break if an error occurred? >>>>>> Because I was trying to match the existing style >>>>>> too much. The for-loop from lines 1235-1276 does >>>>>> that: if I have an error, then break... >>>>>> >>>>>> >>>>>>> If there is a reason to stop freeing memory, would that >>>>>>> also apply if >>>>>>> you already had had an error? So you would want to check a >>>>>>> new cleanuperrorOccurred >>>>>>> regardless of pre-existing error? >>>>>>> But I suspect leaving out the break would make more sense. >>>>>> For this block: >>>>>> >>>>>> 1304 /* >>>>>> 1305 * Only check for error if we didn't >>>>>> already have one >>>>>> 1306 * so we don't overwrite errorOccurred. >>>>>> 1307 */ >>>>>> 1308 if (!errorOccurred) { >>>>>> 1309 errorOccurred = >>>>>> checkForThrowable(jnienv); >>>>>> 1310 jplis_assert(!errorOccurred); >>>>>> 1311 if (errorOccurred) { >>>>>> 1312 break; >>>>>> 1313 } >>>>>> 1314 } >>>>>> >>>>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>>>> freeing as many of the memory arrays as we can... >>>>> Thanks - I prefer that solution. >>>> >>>> I figured you might... >>>> >>>> >>>>>> Fixed in all three versions. >>>>>> >>>>>> On a related note, jplis_assert() appears to be enabled even >>>>>> in product bits. Which means if one of the many jplis_assert() >>>>>> calls fails, then the agent terminates. I don't know the history >>>>>> behind it being enabled in all bits, but I figure that's a >>>>>> different issue for the Serviceability team to mull on... >>>>> I wondered about that, but it seemed consistent with existing >>>>> usage - so I agree. >>>> >>>> Glad we're on the same page! >>>> >>>> Dan >>>> >>>> >>>>>> Thanks again for the review. >>>>>> >>>>>> Dan >>>>> thanks, >>>>> Karen >>>>>> >>>>>> >>>>>> >>>>>>> thanks, >>>>>>> Karen >>>>>>> >>>>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>>>> >>>>>>>> Greetings, >>>>>>>> >>>>>>>> This is a code review request for "day one" memory leaks in >>>>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>>>> and JVM/TI RetransformClasses() APIs. >>>>>>>> >>>>>>>> Since one leak is in the JDK and the other leak is in the >>>>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>>>> attacking these leaks in three releases in parallel so there >>>>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>>>> trying to get this all done before Christmas! >>>>>>>> >>>>>>>> Here are the bug links: >>>>>>>> >>>>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class >>>>>>>> bytes >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>>>> >>>>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks >>>>>>>> class bytes >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>>>> >>>>>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>>>>> >>>>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>>>>> >>>>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>>>> >>>>>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>>>>> these fixes should go back there also. >>>>>>>> >>>>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the >>>>>>>> fixes: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>>>> >>>>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>>>>>> in a slightly different way than the original JDK7u4 code. >>>>>>>> >>>>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, >>>>>>>> but >>>>>>>> I baselined and tested the fix against HSX-23-B06 so I'm >>>>>>>> sending out >>>>>>>> the webrev for what I actually used. >>>>>>>> >>>>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>>>> >>>>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>>>>> also identical. >>>>>>>> >>>>>>>> I've run the following test suites: >>>>>>>> >>>>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>>>> - VM/NSK jdwp >>>>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>>>> - SDK/JDK java/lang/instrument >>>>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>>>> - VM/NSK heapdump >>>>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>>>> >>>>>>>> on the following configs: >>>>>>>> >>>>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, >>>>>>>> -Xcomp} >>>>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>>>> >>>>>>>> Thanks, in advance, for any feedback... >>>>>>>> >>>>>>>> Dan >>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/428d0475/attachment-0001.html From poonam.bajaj at oracle.com Wed Dec 21 20:42:13 2011 From: poonam.bajaj at oracle.com (Poonam Bajaj) Date: Thu, 22 Dec 2011 10:12:13 +0530 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF2A265.8010606@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> <4EF2A265.8010606@oracle.com> Message-ID: <4EF2B525.7060705@oracle.com> Hi Dan, On 12/22/2011 8:52 AM, Daniel D. Daugherty wrote: > On 12/21/11 8:05 PM, Poonam Bajaj wrote: >> Hi Dan, >> >> In the following block (in JPLISAgent.c): >> >> /1278 if (!errorOccurred) { >> 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; >> 1280 errorCode = >> (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); >> 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { >> 1282 /* insulate caller from the wrong phase >> error */ >> 1283 errorCode = JVMTI_ERROR_NONE; >> 1284 } else { >> 1285 errorOccurred = (errorCode != >> JVMTI_ERROR_NONE); >> 1286 if ( errorOccurred ) { >> 1287 >> createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); >> 1288 } >> 1289 } >> 1290 }/ >> >> If RedefineClasses() fails here then >> createAndThrowThrowableFromJVMTIErrorCode() is being called. At the >> point we would have filled data (upto the value of index 'i') into >> classDefs and targetFiles but in case of RedefineClasses failure, >> those will not get freed. Is that correct ? > > No that is not correct and it fooled me also! > > The createAndThrowThrowableFromJVMTIErrorCode() call > does create and throw a throwable Java object, but the > redefineClasses() function does not stop executing at > that point. It finishes what it was doing, freeing > memory that needs to be freed before returning at the > end of the function. Darn C-code doesn't behave like > Java code. :-) > Thanks for clarification! regards, Poonam > Dan > > >> >> >> Thanks, >> Poonam >> >> >> On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >>> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>>> Dan, >>>> >>>> Thank you for the quick fix - >>> >>> You're welcome. I'm trying to get this off my plate before >>> I leave for the holidays... so not exactly altruistic... :-) >>> >>> >>>> I echo Coleen's sentiments of wondering how >>>> you managed to find the problem(s). >>> >>> I'll send a reply on that topic later... >>> >>> >>>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>>> >>>>> Karen, >>>>> >>>>> Thanks for the quick review! Replies in-lined below... >>>>> >>>>> >>>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>>> Dan, >>>>>> >>>>>> All versions of hotspot changes look good. >>>>> Thanks! Are you OK if I don't wait for someone from the new >>>>> Serviceability team on this review? Serguei has already left >>>>> for the holidays... and I told him to ignore any e-mails from >>>>> me :-) >>>> Yes - go for it. Given the holiday timing and how critical this fix >>>> is - you have reviews from Coleen and from me. >>> >>> I have two HSX reviews (yeah!) and I have one JDK review. >>> I need one more JDK review... >>> >>> >>>>> >>>>>> For the JDK and test side: >>>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } >>>>>> else { >>>>> Nice catch! This line: >>>>> >>>>> 1212 if (!errorOccurred) { >>>>> >>>>> should change back to: >>>>> >>>>> 1212 else { >>>>> >>>>> I missed that when I was backing out some more complicated >>>>> stuff that I gave up on. >>>>> >>>>> Fixed in all three versions. >>>>> >>>>> >>>>>> 2) new lines 1311-1312 >>>>>> Why do you break if an error occurred? >>>>> Because I was trying to match the existing style >>>>> too much. The for-loop from lines 1235-1276 does >>>>> that: if I have an error, then break... >>>>> >>>>> >>>>>> If there is a reason to stop freeing memory, would that also >>>>>> apply if >>>>>> you already had had an error? So you would want to check a >>>>>> new cleanuperrorOccurred >>>>>> regardless of pre-existing error? >>>>>> But I suspect leaving out the break would make more sense. >>>>> For this block: >>>>> >>>>> 1304 /* >>>>> 1305 * Only check for error if we didn't >>>>> already have one >>>>> 1306 * so we don't overwrite errorOccurred. >>>>> 1307 */ >>>>> 1308 if (!errorOccurred) { >>>>> 1309 errorOccurred = >>>>> checkForThrowable(jnienv); >>>>> 1310 jplis_assert(!errorOccurred); >>>>> 1311 if (errorOccurred) { >>>>> 1312 break; >>>>> 1313 } >>>>> 1314 } >>>>> >>>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>>> freeing as many of the memory arrays as we can... >>>> Thanks - I prefer that solution. >>> >>> I figured you might... >>> >>> >>>>> Fixed in all three versions. >>>>> >>>>> On a related note, jplis_assert() appears to be enabled even >>>>> in product bits. Which means if one of the many jplis_assert() >>>>> calls fails, then the agent terminates. I don't know the history >>>>> behind it being enabled in all bits, but I figure that's a >>>>> different issue for the Serviceability team to mull on... >>>> I wondered about that, but it seemed consistent with existing >>>> usage - so I agree. >>> >>> Glad we're on the same page! >>> >>> Dan >>> >>> >>>>> Thanks again for the review. >>>>> >>>>> Dan >>>> thanks, >>>> Karen >>>>> >>>>> >>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> This is a code review request for "day one" memory leaks in >>>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>>> and JVM/TI RetransformClasses() APIs. >>>>>>> >>>>>>> Since one leak is in the JDK and the other leak is in the >>>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>>> attacking these leaks in three releases in parallel so there >>>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>>> trying to get this all done before Christmas! >>>>>>> >>>>>>> Here are the bug links: >>>>>>> >>>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>>> >>>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks class >>>>>>> bytes >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>>> >>>>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>>>> >>>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>>>> >>>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>>> >>>>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>>>> these fixes should go back there also. >>>>>>> >>>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the >>>>>>> fixes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>>> >>>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>>>>> in a slightly different way than the original JDK7u4 code. >>>>>>> >>>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>>>>>> I baselined and tested the fix against HSX-23-B06 so I'm sending >>>>>>> out >>>>>>> the webrev for what I actually used. >>>>>>> >>>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>>> >>>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>>>> also identical. >>>>>>> >>>>>>> I've run the following test suites: >>>>>>> >>>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>>> - VM/NSK jdwp >>>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>>> - SDK/JDK java/lang/instrument >>>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>>> - VM/NSK heapdump >>>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>>> >>>>>>> on the following configs: >>>>>>> >>>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>>> >>>>>>> Thanks, in advance, for any feedback... >>>>>>> >>>>>>> Dan >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/d2d2563d/attachment-0001.html From daniel.daugherty at oracle.com Wed Dec 21 20:47:28 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2011 21:47:28 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF2B4CD.5080403@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> <4EF2A265.8010606@oracle.com> <4EF2A2AD.7010408@oracle.com> <4EF2B4CD.5080403@oracle.com> Message-ID: <4EF2B660.3080407@oracle.com> Thanks for reviewing both! I haven't thought of any good tracing additions to the ClassFileLoadHook code path... but when I do... Dan On 12/21/11 9:40 PM, Poonam Bajaj wrote: > Hi Dan, > > I have looked at both the JDK and the Hotspot changes, so you can add > me as reviewer for both. > > I especially like the class_load_kind addition to the following trace. > > 856 RC_TRACE_WITH_THREAD(0x00000001, THREAD, > 857 ("loading name=%s kind=%d (avail_mem=" UINT64_FORMAT "K)", > 858 the_class->external_name(), _class_load_kind, > 859 os::available_memory() >> 10)); > > Thanks, > Poonam > > On 12/22/2011 8:53 AM, Daniel D. Daugherty wrote: >> Poonam, >> >> I forgot to ask whether to put you down as a reviewer for both >> the JDK fix and the HSX fix... so JDK only or both JDK and HSX? >> >> Dan >> >> >> On 12/21/11 8:22 PM, Daniel D. Daugherty wrote: >>> On 12/21/11 8:05 PM, Poonam Bajaj wrote: >>>> Hi Dan, >>>> >>>> In the following block (in JPLISAgent.c): >>>> >>>> /1278 if (!errorOccurred) { >>>> 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; >>>> 1280 errorCode = >>>> (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); >>>> 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { >>>> 1282 /* insulate caller from the wrong >>>> phase error */ >>>> 1283 errorCode = JVMTI_ERROR_NONE; >>>> 1284 } else { >>>> 1285 errorOccurred = (errorCode != >>>> JVMTI_ERROR_NONE); >>>> 1286 if ( errorOccurred ) { >>>> 1287 >>>> createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); >>>> 1288 } >>>> 1289 } >>>> 1290 }/ >>>> >>>> If RedefineClasses() fails here then >>>> createAndThrowThrowableFromJVMTIErrorCode() is being called. At the >>>> point we would have filled data (upto the value of index 'i') into >>>> classDefs and targetFiles but in case of RedefineClasses failure, >>>> those will not get freed. Is that correct ? >>> >>> No that is not correct and it fooled me also! >>> >>> The createAndThrowThrowableFromJVMTIErrorCode() call >>> does create and throw a throwable Java object, but the >>> redefineClasses() function does not stop executing at >>> that point. It finishes what it was doing, freeing >>> memory that needs to be freed before returning at the >>> end of the function. Darn C-code doesn't behave like >>> Java code. :-) >>> >>> Dan >>> >>> >>>> >>>> >>>> Thanks, >>>> Poonam >>>> >>>> >>>> On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >>>>> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>>>>> Dan, >>>>>> >>>>>> Thank you for the quick fix - >>>>> >>>>> You're welcome. I'm trying to get this off my plate before >>>>> I leave for the holidays... so not exactly altruistic... :-) >>>>> >>>>> >>>>>> I echo Coleen's sentiments of wondering how >>>>>> you managed to find the problem(s). >>>>> >>>>> I'll send a reply on that topic later... >>>>> >>>>> >>>>>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>>>>> >>>>>>> Karen, >>>>>>> >>>>>>> Thanks for the quick review! Replies in-lined below... >>>>>>> >>>>>>> >>>>>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>>>>> Dan, >>>>>>>> >>>>>>>> All versions of hotspot changes look good. >>>>>>> Thanks! Are you OK if I don't wait for someone from the new >>>>>>> Serviceability team on this review? Serguei has already left >>>>>>> for the holidays... and I told him to ignore any e-mails from >>>>>>> me :-) >>>>>> Yes - go for it. Given the holiday timing and how critical this fix >>>>>> is - you have reviews from Coleen and from me. >>>>> >>>>> I have two HSX reviews (yeah!) and I have one JDK review. >>>>> I need one more JDK review... >>>>> >>>>> >>>>>>> >>>>>>>> For the JDK and test side: >>>>>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } >>>>>>>> else { >>>>>>> Nice catch! This line: >>>>>>> >>>>>>> 1212 if (!errorOccurred) { >>>>>>> >>>>>>> should change back to: >>>>>>> >>>>>>> 1212 else { >>>>>>> >>>>>>> I missed that when I was backing out some more complicated >>>>>>> stuff that I gave up on. >>>>>>> >>>>>>> Fixed in all three versions. >>>>>>> >>>>>>> >>>>>>>> 2) new lines 1311-1312 >>>>>>>> Why do you break if an error occurred? >>>>>>> Because I was trying to match the existing style >>>>>>> too much. The for-loop from lines 1235-1276 does >>>>>>> that: if I have an error, then break... >>>>>>> >>>>>>> >>>>>>>> If there is a reason to stop freeing memory, would that >>>>>>>> also apply if >>>>>>>> you already had had an error? So you would want to check a >>>>>>>> new cleanuperrorOccurred >>>>>>>> regardless of pre-existing error? >>>>>>>> But I suspect leaving out the break would make more sense. >>>>>>> For this block: >>>>>>> >>>>>>> 1304 /* >>>>>>> 1305 * Only check for error if we >>>>>>> didn't already have one >>>>>>> 1306 * so we don't overwrite >>>>>>> errorOccurred. >>>>>>> 1307 */ >>>>>>> 1308 if (!errorOccurred) { >>>>>>> 1309 errorOccurred = >>>>>>> checkForThrowable(jnienv); >>>>>>> 1310 jplis_assert(!errorOccurred); >>>>>>> 1311 if (errorOccurred) { >>>>>>> 1312 break; >>>>>>> 1313 } >>>>>>> 1314 } >>>>>>> >>>>>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>>>>> freeing as many of the memory arrays as we can... >>>>>> Thanks - I prefer that solution. >>>>> >>>>> I figured you might... >>>>> >>>>> >>>>>>> Fixed in all three versions. >>>>>>> >>>>>>> On a related note, jplis_assert() appears to be enabled even >>>>>>> in product bits. Which means if one of the many jplis_assert() >>>>>>> calls fails, then the agent terminates. I don't know the history >>>>>>> behind it being enabled in all bits, but I figure that's a >>>>>>> different issue for the Serviceability team to mull on... >>>>>> I wondered about that, but it seemed consistent with existing >>>>>> usage - so I agree. >>>>> >>>>> Glad we're on the same page! >>>>> >>>>> Dan >>>>> >>>>> >>>>>>> Thanks again for the review. >>>>>>> >>>>>>> Dan >>>>>> thanks, >>>>>> Karen >>>>>>> >>>>>>> >>>>>>> >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>> >>>>>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> This is a code review request for "day one" memory leaks in >>>>>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>>>>> and JVM/TI RetransformClasses() APIs. >>>>>>>>> >>>>>>>>> Since one leak is in the JDK and the other leak is in the >>>>>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>>>>> attacking these leaks in three releases in parallel so there >>>>>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>>>>> trying to get this all done before Christmas! >>>>>>>>> >>>>>>>>> Here are the bug links: >>>>>>>>> >>>>>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class >>>>>>>>> bytes >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>>>>> >>>>>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks >>>>>>>>> class bytes >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>>>>> >>>>>>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>>>>>> >>>>>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>>>>>> >>>>>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>>>>> >>>>>>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>>>>>> these fixes should go back there also. >>>>>>>>> >>>>>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the >>>>>>>>> fixes: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>>>>> >>>>>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase >>>>>>>>> values >>>>>>>>> in a slightly different way than the original JDK7u4 code. >>>>>>>>> >>>>>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last >>>>>>>>> night, but >>>>>>>>> I baselined and tested the fix against HSX-23-B06 so I'm >>>>>>>>> sending out >>>>>>>>> the webrev for what I actually used. >>>>>>>>> >>>>>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the >>>>>>>>> fixes: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>>>>> >>>>>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are >>>>>>>>> identical. >>>>>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>>>>>> also identical. >>>>>>>>> >>>>>>>>> I've run the following test suites: >>>>>>>>> >>>>>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>>>>> - VM/NSK jdwp >>>>>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>>>>> - SDK/JDK java/lang/instrument >>>>>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>>>>> - VM/NSK heapdump >>>>>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>>>>> >>>>>>>>> on the following configs: >>>>>>>>> >>>>>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, >>>>>>>>> -Xcomp} >>>>>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>>>>> >>>>>>>>> Thanks, in advance, for any feedback... >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111221/ccd6ae73/attachment-0001.html From kelly.ohair at oracle.com Thu Dec 22 08:48:19 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 22 Dec 2011 08:48:19 -0800 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF2B660.3080407@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> <4EF2A265.8010606@oracle.com> <4EF2A2AD.7010408@oracle.com> <4EF2B4CD.5080403@oracle.com> <4EF2B660.3080407@oracle.com> Message-ID: Just a short non critical observation, what happens when numDefs==0? -kto On Dec 21, 2011, at 8:47 PM, Daniel D. Daugherty wrote: > Thanks for reviewing both! > > I haven't thought of any good tracing additions to the > ClassFileLoadHook code path... but when I do... > > Dan > > On 12/21/11 9:40 PM, Poonam Bajaj wrote: >> >> Hi Dan, >> >> I have looked at both the JDK and the Hotspot changes, so you can add me as reviewer for both. >> >> I especially like the class_load_kind addition to the following trace. >> >> 856 RC_TRACE_WITH_THREAD(0x00000001, THREAD, >> 857 ("loading name=%s kind=%d (avail_mem=" UINT64_FORMAT "K)", >> 858 the_class->external_name(), _class_load_kind, >> 859 os::available_memory() >> 10)); >> >> Thanks, >> Poonam >> >> On 12/22/2011 8:53 AM, Daniel D. Daugherty wrote: >>> >>> Poonam, >>> >>> I forgot to ask whether to put you down as a reviewer for both >>> the JDK fix and the HSX fix... so JDK only or both JDK and HSX? >>> >>> Dan >>> >>> >>> On 12/21/11 8:22 PM, Daniel D. Daugherty wrote: >>>> >>>> On 12/21/11 8:05 PM, Poonam Bajaj wrote: >>>>> >>>>> Hi Dan, >>>>> >>>>> In the following block (in JPLISAgent.c): >>>>> >>>>> 1278 if (!errorOccurred) { >>>>> 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; >>>>> 1280 errorCode = (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); >>>>> 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { >>>>> 1282 /* insulate caller from the wrong phase error */ >>>>> 1283 errorCode = JVMTI_ERROR_NONE; >>>>> 1284 } else { >>>>> 1285 errorOccurred = (errorCode != JVMTI_ERROR_NONE); >>>>> 1286 if ( errorOccurred ) { >>>>> 1287 createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); >>>>> 1288 } >>>>> 1289 } >>>>> 1290 } >>>>> >>>>> If RedefineClasses() fails here then createAndThrowThrowableFromJVMTIErrorCode() is being called. At the point we would have filled data (upto the value of index 'i') into classDefs and targetFiles but in case of RedefineClasses failure, those will not get freed. Is that correct ? >>>> >>>> No that is not correct and it fooled me also! >>>> >>>> The createAndThrowThrowableFromJVMTIErrorCode() call >>>> does create and throw a throwable Java object, but the >>>> redefineClasses() function does not stop executing at >>>> that point. It finishes what it was doing, freeing >>>> memory that needs to be freed before returning at the >>>> end of the function. Darn C-code doesn't behave like >>>> Java code. :-) >>>> >>>> Dan >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Poonam >>>>> >>>>> >>>>> On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >>>>>> >>>>>> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>>>>>> Dan, >>>>>>> >>>>>>> Thank you for the quick fix - >>>>>> >>>>>> You're welcome. I'm trying to get this off my plate before >>>>>> I leave for the holidays... so not exactly altruistic... :-) >>>>>> >>>>>> >>>>>>> I echo Coleen's sentiments of wondering how >>>>>>> you managed to find the problem(s). >>>>>> >>>>>> I'll send a reply on that topic later... >>>>>> >>>>>> >>>>>>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>>>>>> >>>>>>>> Karen, >>>>>>>> >>>>>>>> Thanks for the quick review! Replies in-lined below... >>>>>>>> >>>>>>>> >>>>>>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>>>>>> Dan, >>>>>>>>> >>>>>>>>> All versions of hotspot changes look good. >>>>>>>> Thanks! Are you OK if I don't wait for someone from the new >>>>>>>> Serviceability team on this review? Serguei has already left >>>>>>>> for the holidays... and I told him to ignore any e-mails from >>>>>>>> me :-) >>>>>>> Yes - go for it. Given the holiday timing and how critical this fix >>>>>>> is - you have reviews from Coleen and from me. >>>>>> >>>>>> I have two HSX reviews (yeah!) and I have one JDK review. >>>>>> I need one more JDK review... >>>>>> >>>>>> >>>>>>>> >>>>>>>>> For the JDK and test side: >>>>>>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { >>>>>>>> Nice catch! This line: >>>>>>>> >>>>>>>> 1212 if (!errorOccurred) { >>>>>>>> >>>>>>>> should change back to: >>>>>>>> >>>>>>>> 1212 else { >>>>>>>> >>>>>>>> I missed that when I was backing out some more complicated >>>>>>>> stuff that I gave up on. >>>>>>>> >>>>>>>> Fixed in all three versions. >>>>>>>> >>>>>>>> >>>>>>>>> 2) new lines 1311-1312 >>>>>>>>> Why do you break if an error occurred? >>>>>>>> Because I was trying to match the existing style >>>>>>>> too much. The for-loop from lines 1235-1276 does >>>>>>>> that: if I have an error, then break... >>>>>>>> >>>>>>>> >>>>>>>>> If there is a reason to stop freeing memory, would that also apply if >>>>>>>>> you already had had an error? So you would want to check a new cleanuperrorOccurred >>>>>>>>> regardless of pre-existing error? >>>>>>>>> But I suspect leaving out the break would make more sense. >>>>>>>> For this block: >>>>>>>> >>>>>>>> 1304 /* >>>>>>>> 1305 * Only check for error if we didn't already have one >>>>>>>> 1306 * so we don't overwrite errorOccurred. >>>>>>>> 1307 */ >>>>>>>> 1308 if (!errorOccurred) { >>>>>>>> 1309 errorOccurred = checkForThrowable(jnienv); >>>>>>>> 1310 jplis_assert(!errorOccurred); >>>>>>>> 1311 if (errorOccurred) { >>>>>>>> 1312 break; >>>>>>>> 1313 } >>>>>>>> 1314 } >>>>>>>> >>>>>>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>>>>>> freeing as many of the memory arrays as we can... >>>>>>> Thanks - I prefer that solution. >>>>>> >>>>>> I figured you might... >>>>>> >>>>>> >>>>>>>> Fixed in all three versions. >>>>>>>> >>>>>>>> On a related note, jplis_assert() appears to be enabled even >>>>>>>> in product bits. Which means if one of the many jplis_assert() >>>>>>>> calls fails, then the agent terminates. I don't know the history >>>>>>>> behind it being enabled in all bits, but I figure that's a >>>>>>>> different issue for the Serviceability team to mull on... >>>>>>> I wondered about that, but it seemed consistent with existing >>>>>>> usage - so I agree. >>>>>> >>>>>> Glad we're on the same page! >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>>> Thanks again for the review. >>>>>>>> >>>>>>>> Dan >>>>>>> thanks, >>>>>>> Karen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Karen >>>>>>>>> >>>>>>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> This is a code review request for "day one" memory leaks in >>>>>>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>>>>>> and JVM/TI RetransformClasses() APIs. >>>>>>>>>> >>>>>>>>>> Since one leak is in the JDK and the other leak is in the >>>>>>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>>>>>> attacking these leaks in three releases in parallel so there >>>>>>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>>>>>> trying to get this all done before Christmas! >>>>>>>>>> >>>>>>>>>> Here are the bug links: >>>>>>>>>> >>>>>>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>>>>>> >>>>>>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>>>>>> >>>>>>>>>> I don't know why the bugs.sun.com links aren't showing up yet... >>>>>>>>>> >>>>>>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>>>>>>>>> >>>>>>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>>>>>> >>>>>>>>>> I expect the OpenJDK6 version of the fixes to very similar if not >>>>>>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>>>>>> OpenJDK6 project as closely as I used to so I don't know whether >>>>>>>>>> these fixes should go back there also. >>>>>>>>>> >>>>>>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>>>>>> >>>>>>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>>>>>> the JDK6u29 JLI code. That required a very minor change in my fix >>>>>>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>>>>>>>>> in a slightly different way than the original JDK7u4 code. >>>>>>>>>> >>>>>>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>>>>>>>>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>>>>>>>>> the webrev for what I actually used. >>>>>>>>>> >>>>>>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>>>>>> >>>>>>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>>>>>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>>>>>>>>> also identical. >>>>>>>>>> >>>>>>>>>> I've run the following test suites: >>>>>>>>>> >>>>>>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>>>>>> - VM/NSK jdwp >>>>>>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>>>>>> - SDK/JDK java/lang/instrument >>>>>>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>>>>>> - VM/NSK heapdump >>>>>>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>>>>>> >>>>>>>>>> on the following configs: >>>>>>>>>> >>>>>>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>>>>>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>>>>>> >>>>>>>>>> Thanks, in advance, for any feedback... >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/90156ba7/attachment-0001.html From daniel.daugherty at oracle.com Thu Dec 22 09:12:54 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 22 Dec 2011 10:12:54 -0700 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> <4EF268B8.8010601@oracle.com> <4EF29E5C.30404@oracle.com> <4EF2A265.8010606@oracle.com> <4EF2A2AD.7010408@oracle.com> <4EF2B4CD.5080403@oracle.com> <4EF2B660.3080407@oracle.com> Message-ID: <4EF36516.6050003@oracle.com> On 12/22/11 9:48 AM, Kelly O'Hair wrote: > Just a short non critical observation, what happens when numDefs==0? Boom! Note comment on line 1157. 1156 /* 1157 * Java code must not call this with a null list or a zero-length list. 1158 */ 1159 void 1160 redefineClasses(JNIEnv * jnienv, JPLISAgent * agent, jobjectArray classDefinitions) { 1161 jvmtiEnv* jvmtienv = jvmti(agent); 1162 jboolean errorOccurred = JNI_FALSE; 1163 jclass classDefClass = NULL; 1164 jmethodID getDefinitionClassMethodID = NULL; 1165 jmethodID getDefinitionClassFileMethodID = NULL; 1166 jvmtiClassDefinition* classDefs = NULL; 1167 jbyteArray* targetFiles = NULL; 1168 jsize numDefs = 0; 1169 1170 jplis_assert(classDefinitions != NULL); 1171 1172 numDefs = (*jnienv)->GetArrayLength(jnienv, classDefinitions); 1173 errorOccurred = checkForThrowable(jnienv); 1174 jplis_assert(!errorOccurred); 1175 1176 if (!errorOccurred) { 1177 jplis_assert(numDefs > 0); 1178 /* get method IDs for methods to call on class definitions */ 1179 classDefClass = (*jnienv)->FindClass(jnienv, "java/lang/instrument/ClassDefinition"); 1180 errorOccurred = checkForThrowable(jnienv); 1181 jplis_assert(!errorOccurred); 1182 } For some reason, jplis_assert() is enabled in product bits so line 1170 will fire with a NULL classDefinitions and with a numDefs == 0, line 1177 will fire. However, all that is on the C-code side... The Java side is more polite: src/share/classes/sun/instrument/InstrumentationImpl.java 132 public void 133 redefineClasses(ClassDefinition[] definitions) 134 throws ClassNotFoundException { 135 if (!isRedefineClassesSupported()) { 136 throw new UnsupportedOperationException("redefineClasses is not supported in this environment"); 137 } 138 if (definitions == null) { 139 throw new NullPointerException("null passed as 'definitions' in redefineClasses"); 140 } 141 for (int i = 0; i < definitions.length; ++i) { 142 if (definitions[i] == null) { 143 throw new NullPointerException("element of 'definitions' is null in redefineClasses"); 144 } 145 } 146 if (definitions.length == 0) { 147 return; // short-circuit if there are no changes requested 148 } 149 150 redefineClasses0(mNativeAgent, definitions); 151 } If you pass in a null definitions array, you get a nice NPE. If the definitions array is empty, then we don't call into the native side... Dan > > -kto > > On Dec 21, 2011, at 8:47 PM, Daniel D. Daugherty wrote: > >> Thanks for reviewing both! >> >> I haven't thought of any good tracing additions to the >> ClassFileLoadHook code path... but when I do... >> >> Dan >> >> On 12/21/11 9:40 PM, Poonam Bajaj wrote: >>> Hi Dan, >>> >>> I have looked at both the JDK and the Hotspot changes, so you can >>> add me as reviewer for both. >>> >>> I especially like the class_load_kind addition to the following trace. >>> >>> 856 RC_TRACE_WITH_THREAD(0x00000001, THREAD, >>> 857 ("loading name=%s kind=%d (avail_mem=" UINT64_FORMAT "K)", >>> 858 the_class->external_name(), _class_load_kind, >>> 859 os::available_memory() >> 10)); >>> >>> Thanks, >>> Poonam >>> >>> On 12/22/2011 8:53 AM, Daniel D. Daugherty wrote: >>>> Poonam, >>>> >>>> I forgot to ask whether to put you down as a reviewer for both >>>> the JDK fix and the HSX fix... so JDK only or both JDK and HSX? >>>> >>>> Dan >>>> >>>> >>>> On 12/21/11 8:22 PM, Daniel D. Daugherty wrote: >>>>> On 12/21/11 8:05 PM, Poonam Bajaj wrote: >>>>>> Hi Dan, >>>>>> >>>>>> In the following block (in JPLISAgent.c): >>>>>> >>>>>> /1278 if (!errorOccurred) { >>>>>> 1279 jvmtiError errorCode = JVMTI_ERROR_NONE; >>>>>> 1280 errorCode = >>>>>> (*jvmtienv)->RedefineClasses(jvmtienv, numDefs, classDefs); >>>>>> 1281 if (errorCode == JVMTI_ERROR_WRONG_PHASE) { >>>>>> 1282 /* insulate caller from the wrong >>>>>> phase error */ >>>>>> 1283 errorCode = JVMTI_ERROR_NONE; >>>>>> 1284 } else { >>>>>> 1285 errorOccurred = (errorCode != >>>>>> JVMTI_ERROR_NONE); >>>>>> 1286 if ( errorOccurred ) { >>>>>> 1287 >>>>>> createAndThrowThrowableFromJVMTIErrorCode(jnienv, errorCode); >>>>>> 1288 } >>>>>> 1289 } >>>>>> 1290 }/ >>>>>> >>>>>> If RedefineClasses() fails here then >>>>>> createAndThrowThrowableFromJVMTIErrorCode() is being called. At >>>>>> the point we would have filled data (upto the value of index 'i') >>>>>> into classDefs and targetFiles but in case of RedefineClasses >>>>>> failure, those will not get freed. Is that correct ? >>>>> >>>>> No that is not correct and it fooled me also! >>>>> >>>>> The createAndThrowThrowableFromJVMTIErrorCode() call >>>>> does create and throw a throwable Java object, but the >>>>> redefineClasses() function does not stop executing at >>>>> that point. It finishes what it was doing, freeing >>>>> memory that needs to be freed before returning at the >>>>> end of the function. Darn C-code doesn't behave like >>>>> Java code. :-) >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Poonam >>>>>> >>>>>> >>>>>> On 12/22/2011 4:46 AM, Daniel D. Daugherty wrote: >>>>>>> On 12/21/11 4:07 PM, Karen Kinnear wrote: >>>>>>>> Dan, >>>>>>>> >>>>>>>> Thank you for the quick fix - >>>>>>> >>>>>>> You're welcome. I'm trying to get this off my plate before >>>>>>> I leave for the holidays... so not exactly altruistic... :-) >>>>>>> >>>>>>> >>>>>>>> I echo Coleen's sentiments of wondering how >>>>>>>> you managed to find the problem(s). >>>>>>> >>>>>>> I'll send a reply on that topic later... >>>>>>> >>>>>>> >>>>>>>> On Dec 21, 2011, at 5:41 PM, Daniel D. Daugherty wrote: >>>>>>>> >>>>>>>>> Karen, >>>>>>>>> >>>>>>>>> Thanks for the quick review! Replies in-lined below... >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/21/11 2:47 PM, Karen Kinnear wrote: >>>>>>>>>> Dan, >>>>>>>>>> >>>>>>>>>> All versions of hotspot changes look good. >>>>>>>>> Thanks! Are you OK if I don't wait for someone from the new >>>>>>>>> Serviceability team on this review? Serguei has already left >>>>>>>>> for the holidays... and I told him to ignore any e-mails from >>>>>>>>> me :-) >>>>>>>> Yes - go for it. Given the holiday timing and how critical this >>>>>>>> fix >>>>>>>> is - you have reviews from Coleen and from me. >>>>>>> >>>>>>> I have two HSX reviews (yeah!) and I have one JDK review. >>>>>>> I need one more JDK review... >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>>> For the JDK and test side: >>>>>>>>>> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an >>>>>>>>>> } else { >>>>>>>>> Nice catch! This line: >>>>>>>>> >>>>>>>>> 1212 if (!errorOccurred) { >>>>>>>>> >>>>>>>>> should change back to: >>>>>>>>> >>>>>>>>> 1212 else { >>>>>>>>> >>>>>>>>> I missed that when I was backing out some more complicated >>>>>>>>> stuff that I gave up on. >>>>>>>>> >>>>>>>>> Fixed in all three versions. >>>>>>>>> >>>>>>>>> >>>>>>>>>> 2) new lines 1311-1312 >>>>>>>>>> Why do you break if an error occurred? >>>>>>>>> Because I was trying to match the existing style >>>>>>>>> too much. The for-loop from lines 1235-1276 does >>>>>>>>> that: if I have an error, then break... >>>>>>>>> >>>>>>>>> >>>>>>>>>> If there is a reason to stop freeing memory, would that >>>>>>>>>> also apply if >>>>>>>>>> you already had had an error? So you would want to check >>>>>>>>>> a new cleanuperrorOccurred >>>>>>>>>> regardless of pre-existing error? >>>>>>>>>> But I suspect leaving out the break would make more sense. >>>>>>>>> For this block: >>>>>>>>> >>>>>>>>> 1304 /* >>>>>>>>> 1305 * Only check for error if we >>>>>>>>> didn't already have one >>>>>>>>> 1306 * so we don't overwrite >>>>>>>>> errorOccurred. >>>>>>>>> 1307 */ >>>>>>>>> 1308 if (!errorOccurred) { >>>>>>>>> 1309 errorOccurred = >>>>>>>>> checkForThrowable(jnienv); >>>>>>>>> 1310 jplis_assert(!errorOccurred); >>>>>>>>> 1311 if (errorOccurred) { >>>>>>>>> 1312 break; >>>>>>>>> 1313 } >>>>>>>>> 1314 } >>>>>>>>> >>>>>>>>> I'm going to delete lines 1311-1313 so we'll just try to keep >>>>>>>>> freeing as many of the memory arrays as we can... >>>>>>>> Thanks - I prefer that solution. >>>>>>> >>>>>>> I figured you might... >>>>>>> >>>>>>> >>>>>>>>> Fixed in all three versions. >>>>>>>>> >>>>>>>>> On a related note, jplis_assert() appears to be enabled even >>>>>>>>> in product bits. Which means if one of the many jplis_assert() >>>>>>>>> calls fails, then the agent terminates. I don't know the history >>>>>>>>> behind it being enabled in all bits, but I figure that's a >>>>>>>>> different issue for the Serviceability team to mull on... >>>>>>>> I wondered about that, but it seemed consistent with existing >>>>>>>> usage - so I agree. >>>>>>> >>>>>>> Glad we're on the same page! >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>>> Thanks again for the review. >>>>>>>>> >>>>>>>>> Dan >>>>>>>> thanks, >>>>>>>> Karen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Karen >>>>>>>>>> >>>>>>>>>> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >>>>>>>>>> >>>>>>>>>>> Greetings, >>>>>>>>>>> >>>>>>>>>>> This is a code review request for "day one" memory leaks in >>>>>>>>>>> the java.lang.instrument.Instrumentation.redefineClasses() >>>>>>>>>>> and JVM/TI RetransformClasses() APIs. >>>>>>>>>>> >>>>>>>>>>> Since one leak is in the JDK and the other leak is in the >>>>>>>>>>> VM, I'm sending out separate webrevs for each repo. I'm also >>>>>>>>>>> attacking these leaks in three releases in parallel so there >>>>>>>>>>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>>>>>>>>>> trying to get this all done before Christmas! >>>>>>>>>>> >>>>>>>>>>> Here are the bug links: >>>>>>>>>>> >>>>>>>>>>> 7121600 2/3 Instrumentation.redefineClasses() leaks >>>>>>>>>>> class bytes >>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>>>>>>>>>> >>>>>>>>>>> 7122253 2/3 Instrumentation.retransformClasses() leaks >>>>>>>>>>> class bytes >>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>>>>>>>>>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>>>>>>>>>> >>>>>>>>>>> I don't know why the bugs.sun.com >>>>>>>>>>> links aren't showing up yet... >>>>>>>>>>> >>>>>>>>>>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs >>>>>>>>>>> first. >>>>>>>>>>> >>>>>>>>>>> Here are the webrevs for the JDK6u29/HSX-20 version of the >>>>>>>>>>> fixes: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>>>>>>>>>> >>>>>>>>>>> I expect the OpenJDK6 version of the fixes to very similar >>>>>>>>>>> if not >>>>>>>>>>> identical to the JDK6u29 version. I haven't been tracking the >>>>>>>>>>> OpenJDK6 project as closely as I used to so I don't know >>>>>>>>>>> whether >>>>>>>>>>> these fixes should go back there also. >>>>>>>>>>> >>>>>>>>>>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of >>>>>>>>>>> the fixes: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>>>>>>>>>> >>>>>>>>>>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>>>>>>>>>> the JDK6u29 JLI code. That required a very minor change in >>>>>>>>>>> my fix >>>>>>>>>>> to JPLISAgent.c to insulate against unexpected JVM/TI phase >>>>>>>>>>> values >>>>>>>>>>> in a slightly different way than the original JDK7u4 code. >>>>>>>>>>> >>>>>>>>>>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last >>>>>>>>>>> night, but >>>>>>>>>>> I baselined and tested the fix against HSX-23-B06 so I'm >>>>>>>>>>> sending out >>>>>>>>>>> the webrev for what I actually used. >>>>>>>>>>> >>>>>>>>>>> Here are the webrevs for the JDK8/HSX-23-B08 version of the >>>>>>>>>>> fixes: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>>>>>>>>>> >>>>>>>>>>> The JDK7u4 and JDK8 versions of the fix for 7121600 are >>>>>>>>>>> identical. >>>>>>>>>>> The HSX-23-B06 and HSX-23-B08 versions of the fix for >>>>>>>>>>> 7122253 are >>>>>>>>>>> also identical. >>>>>>>>>>> >>>>>>>>>>> I've run the following test suites: >>>>>>>>>>> >>>>>>>>>>> - VM/NSK jvmti, VM/NSK jvmti_unit >>>>>>>>>>> - VM/NSK jdwp >>>>>>>>>>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>>>>>>>>>> - SDK/JDK java/lang/instrument >>>>>>>>>>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>>>>>>>>>> - VM/NSK heapdump >>>>>>>>>>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>>>>>>>>>> >>>>>>>>>>> on the following configs: >>>>>>>>>>> >>>>>>>>>>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, >>>>>>>>>>> -Xcomp} >>>>>>>>>>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>>>>>>>>>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>>>>>>>>>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>>>>>>>>>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>>>>>>>>>> - WinXP JDK8/HSX-23-B08 (not yet started) >>>>>>>>>>> >>>>>>>>>>> Thanks, in advance, for any feedback... >>>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111222/b9b643c6/attachment-0001.html From daniel.daugherty at oracle.com Thu Dec 22 13:50:44 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 22 Dec 2011 21:50:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7122253: Instrumentation.retransformClasses() leaks class bytes Message-ID: <20111222215046.2C09547799@hg.openjdk.java.net> Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 From john.coomes at oracle.com Thu Dec 22 21:06:24 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:06:24 +0000 Subject: hg: hsx/hotspot-emb: Added tag jdk8-b18 for changeset 7010bd24cdd0 Message-ID: <20111223050624.48C6F477B3@hg.openjdk.java.net> Changeset: e1fc13802e0c Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/e1fc13802e0c Added tag jdk8-b18 for changeset 7010bd24cdd0 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:06:31 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:06:31 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b18 for changeset 312cf15d1657 Message-ID: <20111223050633.219D5477B4@hg.openjdk.java.net> Changeset: 46bd4a46a5a8 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/46bd4a46a5a8 Added tag jdk8-b18 for changeset 312cf15d1657 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:06:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:06:39 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b18 for changeset ebec6a7e8d4e Message-ID: <20111223050639.A68FE477B5@hg.openjdk.java.net> Changeset: 5fb25931f1c2 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/5fb25931f1c2 Added tag jdk8-b18 for changeset ebec6a7e8d4e ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:06:46 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:06:46 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b18 for changeset 54928c8850f5 Message-ID: <20111223050646.32187477B6@hg.openjdk.java.net> Changeset: 72d410c3bab1 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/72d410c3bab1 Added tag jdk8-b18 for changeset 54928c8850f5 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:07:41 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:07:41 +0000 Subject: hg: hsx/hotspot-emb/jdk: 6 new changesets Message-ID: <20111223050858.28F1C477B7@hg.openjdk.java.net> Changeset: 134420afe9c2 Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/c6fab5332075 Added tag jdk8-b18 for changeset 334bd51fb3f3 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:12:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:12:00 +0000 Subject: hg: hsx/hotspot-emb/langtools: 14 new changesets Message-ID: <20111223051232.AEE74477B8@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/langtools/rev/2584f5358cba Merge Changeset: abfa0d8ea803 Author: ksrini Date: 2011-12-07 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/langtools/rev/3c71fcc22b99 Added tag jdk8-b18 for changeset ab1b1cc78577 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:36:04 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:36:04 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b18 for changeset 7010bd24cdd0 Message-ID: <20111223053604.1ACC1477BF@hg.openjdk.java.net> Changeset: e1fc13802e0c Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/e1fc13802e0c Added tag jdk8-b18 for changeset 7010bd24cdd0 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:36:10 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:36:10 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b18 for changeset 312cf15d1657 Message-ID: <20111223053612.CB812477C0@hg.openjdk.java.net> Changeset: 46bd4a46a5a8 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/46bd4a46a5a8 Added tag jdk8-b18 for changeset 312cf15d1657 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:36:19 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:36:19 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b18 for changeset ebec6a7e8d4e Message-ID: <20111223053619.C83C0477C1@hg.openjdk.java.net> Changeset: 5fb25931f1c2 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/5fb25931f1c2 Added tag jdk8-b18 for changeset ebec6a7e8d4e ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:36:26 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:36:26 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b18 for changeset 54928c8850f5 Message-ID: <20111223053626.7F017477C2@hg.openjdk.java.net> Changeset: 72d410c3bab1 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/72d410c3bab1 Added tag jdk8-b18 for changeset 54928c8850f5 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:37:20 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:37:20 +0000 Subject: hg: hsx/hotspot-rt/jdk: 6 new changesets Message-ID: <20111223053842.1F8AC477C3@hg.openjdk.java.net> Changeset: 134420afe9c2 Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/c6fab5332075 Added tag jdk8-b18 for changeset 334bd51fb3f3 ! .hgtags From john.coomes at oracle.com Thu Dec 22 21:41:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:41:49 +0000 Subject: hg: hsx/hotspot-rt/langtools: 14 new changesets Message-ID: <20111223054221.C8747477C4@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/langtools/rev/2584f5358cba Merge Changeset: abfa0d8ea803 Author: ksrini Date: 2011-12-07 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/langtools/rev/3c71fcc22b99 Added tag jdk8-b18 for changeset ab1b1cc78577 ! .hgtags From vladimir.danushevsky at oracle.com Tue Dec 27 16:34:28 2011 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Wed, 28 Dec 2011 00:34:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 12 new changesets Message-ID: <20111228003502.75631477E6@hg.openjdk.java.net> Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/hotspot/rev/129cd462ae89 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4b18532913c7 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 7e075537835d Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4ec93d767458 Merge From bob.vandette at oracle.com Wed Dec 28 13:18:46 2011 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Wed, 28 Dec 2011 21:18:46 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Message-ID: <20111228211854.16A95477FE@hg.openjdk.java.net> Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp From serguei.spitsyn at oracle.com Wed Dec 28 15:13:36 2011 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 28 Dec 2011 15:13:36 -0800 Subject: code review request for Redefine and Retransform Classes memory leak (7121600, 7122253) In-Reply-To: <4EF26081.6020201@oracle.com> References: <4EF22ED4.30804@oracle.com> <4EF26081.6020201@oracle.com> Message-ID: <4EFBA2A0.2000601@oracle.com> On 12/21/11 2:41 PM, Daniel D. Daugherty wrote: > Karen, > > Thanks for the quick review! Replies in-lined below... > > > On 12/21/11 2:47 PM, Karen Kinnear wrote: >> Dan, >> >> All versions of hotspot changes look good. > > Thanks! Are you OK if I don't wait for someone from the new > Serviceability team on this review? Serguei has already left > for the holidays... and I told him to ignore any e-mails from > me :-) Dan, I honestly ignored all emails from you while was on vacation. :) But reviewed your fixes upon return anyway. The fixes look good. I can't give you any new comment. Great work! Thanks, Serguei >> For the JDK and test side: >> 1) minor: JPLISAgent.c - new lines 1210-1212 might just be an } else { > > Nice catch! This line: > > 1212 if (!errorOccurred) { > > should change back to: > > 1212 else { > > I missed that when I was backing out some more complicated > stuff that I gave up on. > > Fixed in all three versions. > > >> 2) new lines 1311-1312 >> Why do you break if an error occurred? > > Because I was trying to match the existing style > too much. The for-loop from lines 1235-1276 does > that: if I have an error, then break... > > >> If there is a reason to stop freeing memory, would that also >> apply if >> you already had had an error? So you would want to check a new >> cleanuperrorOccurred >> regardless of pre-existing error? >> But I suspect leaving out the break would make more sense. > > For this block: > > 1304 /* > 1305 * Only check for error if we didn't > already have one > 1306 * so we don't overwrite errorOccurred. > 1307 */ > 1308 if (!errorOccurred) { > 1309 errorOccurred = > checkForThrowable(jnienv); > 1310 jplis_assert(!errorOccurred); > 1311 if (errorOccurred) { > 1312 break; > 1313 } > 1314 } > > I'm going to delete lines 1311-1313 so we'll just try to keep > freeing as many of the memory arrays as we can... > > Fixed in all three versions. > > On a related note, jplis_assert() appears to be enabled even > in product bits. Which means if one of the many jplis_assert() > calls fails, then the agent terminates. I don't know the history > behind it being enabled in all bits, but I figure that's a > different issue for the Serviceability team to mull on... > > Thanks again for the review. > > Dan > > > > >> thanks, >> Karen >> >> On Dec 21, 2011, at 2:09 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> This is a code review request for "day one" memory leaks in >>> the java.lang.instrument.Instrumentation.redefineClasses() >>> and JVM/TI RetransformClasses() APIs. >>> >>> Since one leak is in the JDK and the other leak is in the >>> VM, I'm sending out separate webrevs for each repo. I'm also >>> attacking these leaks in three releases in parallel so there >>> is a pair of webrevs for: JDK6u29, JDK7u4 and JDK8. Yes, I'm >>> trying to get this all done before Christmas! >>> >>> Here are the bug links: >>> >>> 7121600 2/3 Instrumentation.redefineClasses() leaks class bytes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>> http://monaco.sfbay.sun.com/detail.jsp?cr=7121600 >>> >>> 7122253 2/3 Instrumentation.retransformClasses() leaks class bytes >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121600 >>> http://monaco.sfbay.sun.com/detail.jsp?cr=7122253 >>> >>> I don't know why the bugs.sun.com links aren't showing up yet... >>> >>> I think it is best to review the JDK7u4/HSX-23-B06 webrevs first. >>> >>> Here are the webrevs for the JDK6u29/HSX-20 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk6u29/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx20/ >>> >>> I expect the OpenJDK6 version of the fixes to very similar if not >>> identical to the JDK6u29 version. I haven't been tracking the >>> OpenJDK6 project as closely as I used to so I don't know whether >>> these fixes should go back there also. >>> >>> Here are the webrevs for the JDK7u4/HSX-23-B06 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk7u4/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b06/ >>> >>> The JDK7u4 JLI code has some other, unrelated fixes relative to >>> the JDK6u29 JLI code. That required a very minor change in my fix >>> to JPLISAgent.c to insulate against unexpected JVM/TI phase values >>> in a slightly different way than the original JDK7u4 code. >>> >>> Also, JDK7u4 was updated to the HSX-23-B08 snapshot last night, but >>> I baselined and tested the fix against HSX-23-B06 so I'm sending out >>> the webrev for what I actually used. >>> >>> Here are the webrevs for the JDK8/HSX-23-B08 version of the fixes: >>> >>> http://cr.openjdk.java.net/~dcubed/7121600-webrev/1-jdk8/ >>> http://cr.openjdk.java.net/~dcubed/7122253-webrev/0-hsx23-b08/ >>> >>> The JDK7u4 and JDK8 versions of the fix for 7121600 are identical. >>> The HSX-23-B06 and HSX-23-B08 versions of the fix for 7122253 are >>> also identical. >>> >>> I've run the following test suites: >>> >>> - VM/NSK jvmti, VM/NSK jvmti_unit >>> - VM/NSK jdwp >>> - SDK/JDK com/sun/jdi, SDK/JDK closed/com/sun/jdi, VM/NSK jdi >>> - SDK/JDK java/lang/instrument >>> - VM/NSK hprof, VM/NSK jdb, VM/NSK sajdi >>> - VM/NSK heapdump >>> - SDK/JDK misc_attach, SDK/JDK misc_jvmstat, SDK/JDK misc_tools >>> >>> on the following configs: >>> >>> - {Client VM, Server VM} x {product, fastdebug} x {-Xmixed, -Xcomp} >>> - Solaris X86 JDK6u29/HSX-20 (done - no regressions) >>> - Solaris X86 JDK7u4/HSX-23-B06 (done - no regressions) >>> - WinXP JDK7u4/HSX-23-B06 (in process, no regressions so far) >>> - Solaris X86 JDK8/HSX-23-B08 (just started) >>> - WinXP JDK8/HSX-23-B08 (not yet started) >>> >>> Thanks, in advance, for any feedback... >>> >>> Dan >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111228/fe8af3af/attachment.html From john.coomes at oracle.com Thu Dec 29 20:47:10 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:47:10 +0000 Subject: hg: hsx/hotspot-emb: 4 new changesets Message-ID: <20111230044711.117F84783E@hg.openjdk.java.net> Changeset: 9acd7374ff8a Author: ohair Date: 2011-12-12 08:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/rev/00d13c40d7a7 Merge Changeset: 237bc29afbfc Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/237bc29afbfc Merge Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:47:18 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:47:18 +0000 Subject: hg: hsx/hotspot-emb/corba: 5 new changesets Message-ID: <20111230044723.29F154783F@hg.openjdk.java.net> Changeset: 75529c21094f Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/corba/rev/0289a94d653b Merge Changeset: 052dda3b5ce3 Author: dmeetry Date: 2011-12-18 22:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/corba/rev/e1366c5d84ef Merge Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:47:30 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:47:30 +0000 Subject: hg: hsx/hotspot-emb/jaxp: 5 new changesets Message-ID: <20111230044730.4664B47840@hg.openjdk.java.net> Changeset: a482d45c93e9 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/jaxp/rev/f26e2ab2c2c7 Merge Changeset: dffeb62b1a7f Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/dffeb62b1a7f Merge Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:47:37 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:47:37 +0000 Subject: hg: hsx/hotspot-emb/jaxws: 5 new changesets Message-ID: <20111230044737.62ABD47841@hg.openjdk.java.net> Changeset: 6d622b1b4db0 Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/jaxws/rev/b2e4ab8b5fa3 Merge Changeset: b73b733214aa Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/b73b733214aa Merge Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:48:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:48:36 +0000 Subject: hg: hsx/hotspot-emb/jdk: 30 new changesets Message-ID: <20111230045556.90F0E47847@hg.openjdk.java.net> Changeset: 7dbc53242c2a Author: art Date: 2011-12-07 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/d4f9d7e86a92 Merge Changeset: 9c0a6185188f Author: ohair Date: 2011-12-12 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/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-emb/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:58:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:58:36 +0000 Subject: hg: hsx/hotspot-rt: 4 new changesets Message-ID: <20111230045836.B86BC47848@hg.openjdk.java.net> Changeset: 9acd7374ff8a Author: ohair Date: 2011-12-12 08:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/rev/00d13c40d7a7 Merge Changeset: 237bc29afbfc Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/237bc29afbfc Merge Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:58:44 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:58:44 +0000 Subject: hg: hsx/hotspot-rt/corba: 5 new changesets Message-ID: <20111230045848.90D9947849@hg.openjdk.java.net> Changeset: 75529c21094f Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/corba/rev/0289a94d653b Merge Changeset: 052dda3b5ce3 Author: dmeetry Date: 2011-12-18 22:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/corba/rev/e1366c5d84ef Merge Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:59:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:59:00 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 5 new changesets Message-ID: <20111230045900.DC6714784A@hg.openjdk.java.net> Changeset: a482d45c93e9 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/jaxp/rev/f26e2ab2c2c7 Merge Changeset: dffeb62b1a7f Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/dffeb62b1a7f Merge Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:59:09 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:59:09 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 5 new changesets Message-ID: <20111230045909.9E3D04784B@hg.openjdk.java.net> Changeset: 6d622b1b4db0 Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/jaxws/rev/b2e4ab8b5fa3 Merge Changeset: b73b733214aa Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/b73b733214aa Merge Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags From john.coomes at oracle.com Thu Dec 29 21:00:01 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 05:00:01 +0000 Subject: hg: hsx/hotspot-rt/jdk: 30 new changesets Message-ID: <20111230050542.16E5E4784D@hg.openjdk.java.net> Changeset: 7dbc53242c2a Author: art Date: 2011-12-07 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/d4f9d7e86a92 Merge Changeset: 9c0a6185188f Author: ohair Date: 2011-12-12 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags