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:40:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:40:36 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b15 for changeset a4f28069d44a Message-ID: <20111202044037.0AFD3474FE@hg.openjdk.java.net> Changeset: 4e06ae613e99 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4e06ae613e99 Added tag jdk8-b15 for changeset a4f28069d44a ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:40:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:40:43 +0000 Subject: hg: hsx/hotspot-comp/corba: 3 new changesets Message-ID: <20111202044046.415AC474FF@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/7da69e7175a7 Merge Changeset: 82dc033975bb Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/82dc033975bb Added tag jdk8-b15 for changeset 7da69e7175a7 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:40:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:40:51 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b15 for changeset 804f666d6d44 Message-ID: <20111202044051.C40E347500@hg.openjdk.java.net> Changeset: 8181f7634e4a Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/8181f7634e4a Added tag jdk8-b15 for changeset 804f666d6d44 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:40:57 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:40:57 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b15 for changeset c9ab96ff23d5 Message-ID: <20111202044057.9997047501@hg.openjdk.java.net> Changeset: 76e37e606354 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/76e37e606354 Added tag jdk8-b15 for changeset c9ab96ff23d5 ! .hgtags From john.coomes at oracle.com Thu Dec 1 20:41:51 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:41:51 +0000 Subject: hg: hsx/hotspot-comp/jdk: 34 new changesets Message-ID: <20111202044751.2AF3647507@hg.openjdk.java.net> Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jdk/rev/60331bbcf4ad Merge Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/e5d65a583c15 Merge Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/1266e72f7896 Merge Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/b4d7020c2a40 Merge Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/929597c6e777 Added tag jdk8-b15 for changeset 3c248d0e2c48 ! .hgtags 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 john.coomes at oracle.com Fri Dec 2 13:00:55 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 21:00:55 +0000 Subject: hg: hsx/hotspot-comp/langtools: 34 new changesets Message-ID: <20111202210207.93A6047523@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/langtools/rev/11c184155128 Merge Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/f07d6f55d39a Merge Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/langtools/rev/ec2c0973cc31 Added tag jdk8-b15 for changeset 07599bd780ca ! .hgtags From vladimir.kozlov at oracle.com Fri Dec 2 15:12:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Dec 2011 15:12:58 -0800 Subject: Request for reviews (S): 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Message-ID: <4ED95B7A.60506@oracle.com> http://cr.openjdk.java.net/~kvn/7117282/webrev 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Memory slice is dead and memory node (Store) is processed before its memory is processed. Delay memory node transformation until the memory is processed. From igor.veresov at oracle.com Fri Dec 2 17:02:55 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 2 Dec 2011 17:02:55 -0800 Subject: Request for reviews (S): 7117282: assert(base =?utf-8?Q?=3D=3D_?=NULL || t_adr->isa_rawptr() || !phase->type(base) In-Reply-To: <4ED95B7A.60506@oracle.com> References: <4ED95B7A.60506@oracle.com> Message-ID: Looks good! Thanks! igor On Friday, December 2, 2011 at 3:12 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7117282/webrev > > 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) > > Memory slice is dead and memory node (Store) is processed before its memory is > processed. > Delay memory node transformation until the memory is processed. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111202/418d721c/attachment.html From tom.rodriguez at oracle.com Fri Dec 2 17:10:13 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 2 Dec 2011 17:10:13 -0800 Subject: Request for reviews (S): 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) In-Reply-To: <4ED95B7A.60506@oracle.com> References: <4ED95B7A.60506@oracle.com> Message-ID: <6B7168AD-8750-4424-8B71-FB26E443FF64@oracle.com> Looks good. tom On Dec 2, 2011, at 3:12 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7117282/webrev > > 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) > > Memory slice is dead and memory node (Store) is processed before its memory is processed. > Delay memory node transformation until the memory is processed. > From vladimir.kozlov at oracle.com Fri Dec 2 17:18:49 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Dec 2011 17:18:49 -0800 Subject: Request for reviews (S): 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) In-Reply-To: <6B7168AD-8750-4424-8B71-FB26E443FF64@oracle.com> References: <4ED95B7A.60506@oracle.com> <6B7168AD-8750-4424-8B71-FB26E443FF64@oracle.com> Message-ID: <4ED978F9.6010107@oracle.com> Thank you, Tom and Igor Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Dec 2, 2011, at 3:12 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7117282/webrev >> >> 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) >> >> Memory slice is dead and memory node (Store) is processed before its memory is processed. >> Delay memory node transformation until the memory is processed. >> > From vladimir.kozlov at oracle.com Sat Dec 3 01:23:48 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 03 Dec 2011 09:23:48 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Message-ID: <20111203092350.4A9F247550@hg.openjdk.java.net> Changeset: f745b2be3737 Author: kvn Date: 2011-12-02 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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 From john.r.rose at oracle.com Sat Dec 3 19:59:25 2011 From: john.r.rose at oracle.com (John Rose) Date: Sat, 3 Dec 2011 19:59:25 -0800 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> Message-ID: <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> The caching ClassValue is still under review. I took the opportunity to remove -Xlint warnings (adding type parameters) and refactor for better readability. Also, Mike Duigou pointed out that there was still a dependency on ClassValue.equals == Object.equals, which could create a side-channel between independent CVs. I removed this by replacing ClassValue with ClassValue.Identity as the hash table key. The cache access is racy, for speed, but all races are (thought to be) benign. For cache hits, end-user values are obtained from non-racing accesses. All cache state changes happen either under a per-class lock or during GC (nulling of weak references). Could I have a re-review? Thanks, -- John On Sep 20, 2011, at 4:10 PM, John Rose wrote: > On Sep 19, 2011, at 2:58 PM, John Rose wrote: > >> http://cr.openjdk.java.net/~jrose/7030453/webrev.00 > > After some comments from David Holmes (thanks David!) I added internal comments about race conditions. > > I refreshed the webrev with the additional comments. I also changed one variable to be volatile, with a paragraph of comments explaining why. > > (The change to volatile will inhibit CSE of ClassValue.get calls, but I think such CSE was unlikely anyway. There should be no other performance effects.) > > -- John From forax at univ-mlv.fr Sun Dec 4 14:13:39 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 04 Dec 2011 23:13:39 +0100 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <4EDBCC2F.7030907@oracle.com> References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> <4EDBCC2F.7030907@oracle.com> Message-ID: <4EDBF093.1000801@univ-mlv.fr> On 12/04/2011 08:38 PM, Joe Darcy wrote: > Hi John, > > Are there alternatives to adding two new fields to java.lang.Class? I > assume most Class'es won't have ClassValue information associated with > them. > > -Joe If you use Groovy, JRuby or Nashorn in your code, all visible classes will use this two fields. Any alternative will slow down the access to the class value. BTW, if we had to remove some fields, I vote for moving all fields related to the reflection in a delegate class. Looking up for members is slow so most of the code that call reflection methods use their own cache, so the performance impact will be small in my opinion (I have no data to prove that :) R?mi From forax at univ-mlv.fr Sun Dec 4 17:03:13 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 05 Dec 2011 02:03:13 +0100 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <4EDC0FFE.2080805@oracle.com> References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> <4EDBCC2F.7030907@oracle.com> <4EDBF093.1000801@univ-mlv.fr> <4EDC0FFE.2080805@oracle.com> Message-ID: <4EDC1851.4060508@univ-mlv.fr> On 12/05/2011 01:27 AM, Joe Darcy wrote: > On 12/4/2011 2:13 PM, R?mi Forax wrote: >> On 12/04/2011 08:38 PM, Joe Darcy wrote: >>> Hi John, >>> >>> Are there alternatives to adding two new fields to java.lang.Class? >>> I assume most Class'es won't have ClassValue information associated >>> with them. >>> >>> -Joe >> >> If you use Groovy, JRuby or Nashorn in your code, all visible classes >> will use this two fields. >> >> Any alternative will slow down the access to the class value. > > In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc. > uses of class Class and all the classes not visible in those > environments when they are being used will be larger. > > Adding the fields may be the right time/space trade-off, but I think > the point merits some discussion given how many Class objects get > created and the relative proportion of Java executions where > ClassValue is currently used. > > The more reasonable time/space trade-off can change over time of course. > > -Joe > I agree but as I said, in that case, I think it's better to take a look to the big picture and see if not only class values fields but also annotations related fields or reflection related fields can be moved. Also, if we don't provide a fast ClassValue, people will create their own concurrent weak hash map using class as key that will be worst because it seems that only few people knows how to do that right. Personally, I don't. R?mi 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 david.holmes at oracle.com Sun Dec 4 18:25:28 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Dec 2011 12:25:28 +1000 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <4EDC1851.4060508@univ-mlv.fr> References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> <4EDBCC2F.7030907@oracle.com> <4EDBF093.1000801@univ-mlv.fr> <4EDC0FFE.2080805@oracle.com> <4EDC1851.4060508@univ-mlv.fr> Message-ID: <4EDC2B98.6020101@oracle.com> On 5/12/2011 11:03 AM, R?mi Forax wrote: > On 12/05/2011 01:27 AM, Joe Darcy wrote: >> On 12/4/2011 2:13 PM, R?mi Forax wrote: >>> On 12/04/2011 08:38 PM, Joe Darcy wrote: >>>> >>>> Are there alternatives to adding two new fields to java.lang.Class? >>>> I assume most Class'es won't have ClassValue information associated >>>> with them. >>> >>> If you use Groovy, JRuby or Nashorn in your code, all visible classes >>> will use this two fields. >>> >>> Any alternative will slow down the access to the class value. >> >> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc. >> uses of class Class and all the classes not visible in those >> environments when they are being used will be larger. >> >> Adding the fields may be the right time/space trade-off, but I think >> the point merits some discussion given how many Class objects get >> created and the relative proportion of Java executions where >> ClassValue is currently used. >> >> The more reasonable time/space trade-off can change over time of course. >> > > I agree but as I said, in that case, I think it's better to take a look > to the big picture > and see if not only class values fields but also annotations related > fields or reflection related fields can be moved. This is currently being looked at with a general aim of reducing the size of Class instances. So adding back some size would need strong justification. David ----- > Also, if we don't provide a fast ClassValue, people will create their > own concurrent weak hash map > using class as key that will be worst because it seems that only few > people knows > how to do that right. Personally, I don't. > > R?mi > 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 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 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 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 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 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 volker.simonis at gmail.com Wed Dec 7 01:45:41 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Dec 2011 10:45:41 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: References: Message-ID: There's now a bug report for this issue: 7116216: StackOverflow GC crash http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 so could somebody please have a look at the fix proposed by Yang? Regards, Volker On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: > Hi folks, > > ?? We found two problems during throwing an StackOverflow exception from > interpreter. > > 1.?????? Before preparing to throw a StackOverflow exception, the last Java > frame is set to the current sp. This is problematic when the StackOverflow > is thrown on top of c2i adapter. Solution : the real caller frame(unextended > sp) should be set as last Java frame. > > 2.?????? When Garbage collection happens during throwing StackOverflow > exception, and callee-saved register(or "never-saved" register which behaves > alike) happens to be an OOP, GC is unable to locate the OOP in C > frame(generated by VM calls), and hence fails to process the OOP. Solution : > We build a runtime stub frame before doing a VM call, which guarantees the > location of Callee-saved registers are always recognizable by GC. > > ???Detailed descriptions and tests could be found in webrev > ?http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ > > ?? I don?t have a bugID yet. Please kindly open one bug for this issue. > > > > Thanks, > > Yang > > > > > > Yang Wang > Software Engineer > > TIP Core AS&VM Technology (AG) > SAP JVM JIT Compiler > > SAP AG > Dietmar-Hopp-Allee 16 > 69190 Walldorf, Germany > > T +49 6227 7-50320 > F +49 6227 78-48541 > Email : yang02.wang at sap.com > www.sap.com > > > Pflichtangaben/Mandatory Disclosure Statements: > http://www.sap.com/company/legal/impressum.epx > > Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte > benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen > Dank. > > This e-mail may contain trade secrets or privileged, undisclosed, or > otherwise confidential information. If you have received this e-mail in > error, you are hereby notified that any review, copying, or distribution of > it is strictly prohibited. Please inform us immediately and destroy the > original transmittal. Thank you for your cooperation. > > 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.r.rose at oracle.com Wed Dec 7 13:14:33 2011 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Dec 2011 13:14:33 -0800 (PST) Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <4EDC2B98.6020101@oracle.com> References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> <4EDBCC2F.7030907@oracle.com> <4EDBF093.1000801@univ-mlv.fr> <4EDC0FFE.2080805@oracle.com> <4EDC1851.4060508@univ-mlv.fr> <4EDC2B98.6020101@oracle.com> Message-ID: <2C2A1E0C-876C-4DC6-9812-E53E2619D272@oracle.com> On Dec 4, 2011, at 6:25 PM, David Holmes wrote: >>> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc. >>> uses of class Class and all the classes not visible in those >>> environments when they are being used will be larger. >>> >>> Adding the fields may be the right time/space trade-off, but I think >>> the point merits some discussion given how many Class objects get >>> created and the relative proportion of Java executions where >>> ClassValue is currently used. >>> >>> The more reasonable time/space trade-off can change over time of course. >>> >> >> I agree but as I said, in that case, I think it's better to take a look >> to the big picture >> and see if not only class values fields but also annotations related >> fields or reflection related fields can be moved. > > This is currently being looked at with a general aim of reducing the size of Class instances. So adding back some size would need strong justification. At a minimum we need a single word to root the lookup in the Class itself, in order to avoid (a) many extra branches and indirections per lookup and (b) scaling problems associated with centralized hash tables. (This is the same reasoning as with Thread.threadLocals.) Since the number of classes in apps is typically in the range 10^3 to 10^4, the extra word is not going to hurt anybody. The proof of this is that nobody has needed to touch the highly expansive implementation of reflective caches on Class, which was noted by Remi. These things have existed since March of 2001 without causing enough pain to require fixing, and in those years memory has shrunk in cost by orders of magnitude. But, in order to respect the "general aim" you are mentioning, I have unhoisted one of the two words from the Class instance itself. This will cause a minor slowdown in JSR 292 use cases. This is tolerable, since the next level of speedup will probably come from compiler optimizations, not data structure reorganization. I have updated the webrev in place with this additional change: http://cr.openjdk.java.net/~jrose/7030453/webrev.01 There is a separate mini-diff for the unhoisting, which is trivial: http://cr.openjdk.java.net/~jrose/7030453/unhoist-cache.patch -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111207/18720b50/attachment.html 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 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 fweimer at bfk.de Thu Dec 8 01:55:00 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 08 Dec 2011 09:55:00 +0000 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <2C2A1E0C-876C-4DC6-9812-E53E2619D272@oracle.com> (John Rose's message of "Wed, 7 Dec 2011 13:14:33 -0800 (PST)") References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> <4EDBCC2F.7030907@oracle.com> <4EDBF093.1000801@univ-mlv.fr> <4EDC0FFE.2080805@oracle.com> <4EDC1851.4060508@univ-mlv.fr> <4EDC2B98.6020101@oracle.com> <2C2A1E0C-876C-4DC6-9812-E53E2619D272@oracle.com> Message-ID: <821usf2xsb.fsf@mid.bfk.de> * John Rose: > But, in order to respect the "general aim" you are mentioning, I have > unhoisted one of the two words from the Class instance itself. This > will cause a minor slowdown in JSR 292 use cases. What about using ClassValue for the various caches instead? enumConstants and enumConstantDirectory seem good candidates (callers cache the value anyway or do additional work while accessing the field). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From 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.r.rose at oracle.com Thu Dec 8 11:57:17 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Dec 2011 11:57:17 -0800 Subject: review request (L): 7030453: JSR 292 ClassValue.get method is too slow In-Reply-To: <821usf2xsb.fsf@mid.bfk.de> References: <5AF69B9B-D7A9-47B0-8452-06308D824D70@oracle.com> <1A25D30F-204C-4CEE-95A1-F6FDB7925B7D@oracle.com> <4EDBCC2F.7030907@oracle.com> <4EDBF093.1000801@univ-mlv.fr> <4EDC0FFE.2080805@oracle.com> <4EDC1851.4060508@univ-mlv.fr> <4EDC2B98.6020101@oracle.com> <2C2A1E0C-876C-4DC6-9812-E53E2619D272@oracle.com> <821usf2xsb.fsf@mid.bfk.de> Message-ID: On Dec 8, 2011, at 1:55 AM, Florian Weimer wrote: > * John Rose: > >> But, in order to respect the "general aim" you are mentioning, I have >> unhoisted one of the two words from the Class instance itself. This >> will cause a minor slowdown in JSR 292 use cases. > > What about using ClassValue for the various caches instead? > enumConstants and enumConstantDirectory seem good candidates (callers > cache the value anyway or do additional work while accessing the field). That's a fine idea, Florian, especially when we are counting every word of fixed overhead. (The alternative is keeping one root pointer in Class for the whole block of caches.) Even the reflective caches are candidates for ClassValue treatment, since only a minority of classes are subjected to reflective operations. ClassValue is good for any set of values associated sparsely with classes, as long as the query does not happen in a very tight loop. The trade-off is whether to add another 4-5 cache line touches per use to buy the extra compactness. To compare queries: Class cls = ...; Object val1 = cls.cache1; if (val1 != null) ... // fill cache test1(val1); load $t1, [$cls + #Class::cache1] test $t1 jump,zero Lfillcache call test1($t1) ClassValue cval = ... Object val2 = cval.get(cls); test2(val2); load $t1, [$cls + #Class::classValueMap] load $t2array, [$t1 + #ClassValueMap::cacheArray] & implicit { test $t1; jump,zero Lfillcache } // via trap handler load $t3, [$t2array + #Object[]::length] sub $t3, 1 jump,negative Lfatal // never taken; software invariant load $t4a, [$cval + #ClassValue::hashCodeForCache] load $t4b, [$cval + #ClassValue::version] and $t4a, $t3 load $t5entry, [$t2array + $t4a*wordSize + #Object[]::base] load $t6a, [$t5entry + #Entry::value] load $t6b, [$t5entry + #Entry::version] cmp $t6b, $t5b jump,notEqual Lfillcache call test2($t6a) The pointer dependencies for cache references are: ClassValue -> t4:{hashCodeForCache,version} Class -> t1:ClassValueMap -> t2:cacheArray -> ( t3:length, t5:Entry -> t6:{value,version} ) The bracketed items are likely to be on a single cache line, so there are six cache references. For a constant ClassValue, the t4 references can (in principle) be hoisted as constants into the code. And the first indirection ($t1) could be removed by hoisting the cache array back into Class. All this reminds me... Somebody should experiment with re-implementing reflection and proxy creation on top of method handles. It would let us cut out a bunch of old code (both C++ and Java), and standardize on a single high-leverage mechanism for runtime method composition. (Look in the current JDK core where bytecode spinning is happening... Those places are all candidates for refactoring with method handles.) We are working on tuning up method handle invocation performance (e.g., 7023639). When method handles are robustly performant, we will have the attractive option of refactoring older APIs on top of MHs. It's not too early to start experimenting with a POC for this. It would be a nice big open-source project. Any takers? -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111208/67feaf51/attachment-0001.html From vladimir.kozlov at oracle.com Thu Dec 8 15:53:02 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Dec 2011 15:53:02 -0800 Subject: Request for reviews (XL): 7116452: Add support for AVX instructions Message-ID: <4EE14DDE.8020307@oracle.com> http://cr.openjdk.java.net/~kvn/7116452/webrev.01 7116452: Add support for AVX instructions Initial changes were submitted by Intel. I refactored it to simplify prefix usage in instructions codding (added simd_prefix methods) and VEX encoding was fixed to generate 2bytes prefix when possible. Changes in .ad files were not complete (especially in 32-bit .ad) and were not aggressive as I want. I changed more mach nodes encoding to use macroassembler instructions. Added missing decoding parts in Assembler::locate_operand() and NativeMovRegMem::instruction_start(). Note: no new AVX instructions were added in these changes. And no 3 operands format was added to MacroAssembler. It will be other changes. Destination operand is used as second source in current implementation where applicable. Float compare implementation in x86_32.ad was replaced with implementation from x86_64.ad. It uses less branches and does not destroy EAX register. Note: ucomiss instruction produces the same result as comiss since we masking numeric exceptions. Also ucomiss could be a little faster since it does not need to check control word for QNaN values. Vector instructions with VEX prefix use unaligned load for memory operands where with old REX prefix it require 16 bytes alignment. Instructions version with memory operand were added for that but they should be used only with VEX prefix, assert was added. ANDPD and XORPD with memory operand were used before with 16 bytes aligned memory (we have special code to do it). I added assert to check address alignment for these instructions. As part of these changes REX.W prefix was removed from instructions where it was not needed: MOVDQA, MOVDQU, PCMPESTRI, PSRLQ, PSRLDQ, PTEST. Tested with UseAVX=1|0, UseSSE=4|2|1|0, CTW, VM regression tests, nsk. Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Dec 9 15:20:33 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 09 Dec 2011 23:20:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 52 new changesets Message-ID: <20111209232216.2CCED47654@hg.openjdk.java.net> Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! 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/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b1754f3fbbd8 Merge Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags Changeset: da4182086289 Author: jcoomes Date: 2011-11-18 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/da4182086289 7113503: Bump the hs23 build number to 07 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 36b057451829 Author: dholmes Date: 2011-11-16 20:38 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/36b057451829 7110017: is_headless_jre should be updated to reflect the new location of awt toolkit libraries Reviewed-by: dholmes, dsamersoff Contributed-by: Chris Hegarty ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 002cb3fc8256 Author: coleenp Date: 2011-11-18 17:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/002cb3fc8256 Merge Changeset: c17bc65648de Author: brutisso Date: 2011-11-21 08:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c17bc65648de 7112308: Fix Visual Studio build for precompiled header Summary: Add the new path to precompiled.hpp in the project make file Reviewed-by: coleenp, dholmes, brutisso Contributed-by: rbackman ! make/windows/makefiles/projectcreator.make Changeset: 1d090cf33da6 Author: coleenp Date: 2011-11-21 10:22 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d090cf33da6 Merge Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/hotspot/rev/81a08cd7f6a1 Merge Changeset: a88de71c4e3a Author: tonyp Date: 2011-11-18 12:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/hotspot/rev/3a298e04d914 Merge Changeset: bca17e38de00 Author: jmasa Date: 2011-08-09 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/hotspot/rev/41cce03b29a8 Merge Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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: 81f7362f7bed Author: kvn Date: 2011-12-08 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/e37aedaedccd Merge Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/hotspot/rev/e9b91fd07263 Merge From igor.veresov at oracle.com Fri Dec 9 19:02:12 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 9 Dec 2011 19:02:12 -0800 Subject: review(XS): 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Message-ID: <40C690985249471A9871494B0E2D4BE8@oracle.com> Tiered can remove compile tasks that are stale from the queue and since this process involves locks it can safepoint. Because of that handles are required for heap references. Webrev: http://cr.openjdk.java.net/~iveresov/7119730/webrev.00/ Thanks!igor From christian.thalinger at oracle.com Mon Dec 12 03:54:34 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Dec 2011 12:54:34 +0100 Subject: review(XS): 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) In-Reply-To: <40C690985249471A9871494B0E2D4BE8@oracle.com> References: <40C690985249471A9871494B0E2D4BE8@oracle.com> Message-ID: Looks good. -- Chris On Dec 10, 2011, at 4:02 AM, Igor Veresov wrote: > Tiered can remove compile tasks that are stale from the queue and since this process involves locks it can safepoint. Because of that handles are required for heap references. > > Webrev: http://cr.openjdk.java.net/~iveresov/7119730/webrev.00/ > > Thanks!igor > > From roland.westrelin at oracle.com Mon Dec 12 08:48:38 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 12 Dec 2011 17:48:38 +0100 Subject: review request (S): 7114106 C1: assert(goto_state->is_same(sux_state)) failed: states must match now Message-ID: <8CE365C8-C891-41F9-8DE1-9684FBDE8CB4@oracle.com> http://cr.openjdk.java.net/~roland/7114106/webrev.00/ 6986046 (C1 valuestack cleanup) broke this. C1 tries to performs a conditional expression elimination where, before 6986046, it would find that required conditions are not met for such an optimization. As part of the checks that C1 does to verify whether it can perform CEE, the stack size after the true/false blocks (in the common successor) is checked to be greater than the stack size before the true/false blocks (after the If node). This test now succeeds and permits CEE where, before 6986046, it failed. The problem here is that the state after the If is at inlining depth 1 while the state in the common successor is at inlining depth 0 so the stack sizes from the states before and after the true/false blocks can't simply be compared now that 6986046 fixed handling of inlining in states. Inlining depth needs to match. From vladimir.kozlov at oracle.com Mon Dec 12 09:52:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2011 09:52:09 -0800 Subject: review(XS): 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) In-Reply-To: <40C690985249471A9871494B0E2D4BE8@oracle.com> References: <40C690985249471A9871494B0E2D4BE8@oracle.com> Message-ID: <4EE63F49.9010308@oracle.com> Looks good. Vladimir Igor Veresov wrote: > Tiered can remove compile tasks that are stale from the queue and since this process involves locks it can safepoint. Because of that handles are required for heap references. > > Webrev: http://cr.openjdk.java.net/~iveresov/7119730/webrev.00/ > > Thanks!igor > > From igor.veresov at oracle.com Mon Dec 12 10:16:16 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Dec 2011 10:16:16 -0800 Subject: review(XS): 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) In-Reply-To: <4EE63F49.9010308@oracle.com> References: <40C690985249471A9871494B0E2D4BE8@oracle.com> <4EE63F49.9010308@oracle.com> Message-ID: Thanks Chris and Vladimir! igor On Monday, December 12, 2011 at 9:52 AM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Igor Veresov wrote: > > Tiered can remove compile tasks that are stale from the queue and since this process involves locks it can safepoint. Because of that handles are required for heap references. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7119730/webrev.00/ > > > > Thanks!igor From tom.rodriguez at oracle.com Mon Dec 12 14:20:01 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 12 Dec 2011 14:20:01 -0800 Subject: review request (S): 7114106 C1: assert(goto_state->is_same(sux_state)) failed: states must match now In-Reply-To: <8CE365C8-C891-41F9-8DE1-9684FBDE8CB4@oracle.com> References: <8CE365C8-C891-41F9-8DE1-9684FBDE8CB4@oracle.com> Message-ID: Looks good. tom On Dec 12, 2011, at 8:48 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7114106/webrev.00/ > > 6986046 (C1 valuestack cleanup) broke this. > C1 tries to performs a conditional expression elimination where, before 6986046, it would find that required conditions are not met for such an optimization. > As part of the checks that C1 does to verify whether it can perform CEE, the stack size after the true/false blocks (in the common successor) is checked to be greater than the stack size before the true/false blocks (after the If node). This test now succeeds and permits CEE where, before 6986046, it failed. The problem here is that the state after the If is at inlining depth 1 while the state in the common successor is at inlining depth 0 so the stack sizes from the states before and after the true/false blocks can't simply be compared now that 6986046 fixed handling of inlining in states. Inlining depth needs to match. From igor.veresov at oracle.com Mon Dec 12 15:41:59 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Dec 2011 15:41:59 -0800 Subject: review request (S): 7114106 C1: assert(goto_state->is_same(sux_state)) failed: states must match now In-Reply-To: <8CE365C8-C891-41F9-8DE1-9684FBDE8CB4@oracle.com> References: <8CE365C8-C891-41F9-8DE1-9684FBDE8CB4@oracle.com> Message-ID: <5446BE1D18B24656AE8D7C391694C1A0@oracle.com> Looks good! igor On Monday, December 12, 2011 at 8:48 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7114106/webrev.00/ > > 6986046 (C1 valuestack cleanup) broke this. > C1 tries to performs a conditional expression elimination where, before 6986046, it would find that required conditions are not met for such an optimization. > As part of the checks that C1 does to verify whether it can perform CEE, the stack size after the true/false blocks (in the common successor) is checked to be greater than the stack size before the true/false blocks (after the If node). This test now succeeds and permits CEE where, before 6986046, it failed. The problem here is that the state after the If is at inlining depth 1 while the state in the common successor is at inlining depth 0 so the stack sizes from the states before and after the true/false blocks can't simply be compared now that 6986046 fixed handling of inlining in states. Inlining depth needs to match. From igor.veresov at oracle.com Mon Dec 12 16:01:38 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 13 Dec 2011 00:01:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Message-ID: <20111213000142.A2FD04767D@hg.openjdk.java.net> Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp From roland.westrelin at oracle.com Tue Dec 13 04:19:21 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 13 Dec 2011 12:19:21 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Message-ID: <20111213121926.85A464768A@hg.openjdk.java.net> Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp From christian.thalinger at oracle.com Tue Dec 13 12:19:59 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Dec 2011 21:19:59 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: References: Message-ID: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: > There's now a bug report for this issue: > > 7116216: StackOverflow GC crash > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 > > so could somebody please have a look at the fix proposed by Yang? Sorry, I will have a look tomorrow. -- Chris > > Regards, > Volker > > On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >> Hi folks, >> >> We found two problems during throwing an StackOverflow exception from >> interpreter. >> >> 1. Before preparing to throw a StackOverflow exception, the last Java >> frame is set to the current sp. This is problematic when the StackOverflow >> is thrown on top of c2i adapter. Solution : the real caller frame(unextended >> sp) should be set as last Java frame. >> >> 2. When Garbage collection happens during throwing StackOverflow >> exception, and callee-saved register(or "never-saved" register which behaves >> alike) happens to be an OOP, GC is unable to locate the OOP in C >> frame(generated by VM calls), and hence fails to process the OOP. Solution : >> We build a runtime stub frame before doing a VM call, which guarantees the >> location of Callee-saved registers are always recognizable by GC. >> >> Detailed descriptions and tests could be found in webrev >> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >> >> I don?t have a bugID yet. Please kindly open one bug for this issue. >> >> >> >> Thanks, >> >> Yang >> >> >> >> >> >> Yang Wang >> Software Engineer >> >> TIP Core AS&VM Technology (AG) >> SAP JVM JIT Compiler >> >> SAP AG >> Dietmar-Hopp-Allee 16 >> 69190 Walldorf, Germany >> >> T +49 6227 7-50320 >> F +49 6227 78-48541 >> Email : yang02.wang at sap.com >> www.sap.com >> >> >> Pflichtangaben/Mandatory Disclosure Statements: >> http://www.sap.com/company/legal/impressum.epx >> >> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich >> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte >> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >> Dank. >> >> This e-mail may contain trade secrets or privileged, undisclosed, or >> otherwise confidential information. If you have received this e-mail in >> error, you are hereby notified that any review, copying, or distribution of >> it is strictly prohibited. Please inform us immediately and destroy the >> original transmittal. Thank you for your cooperation. >> >> From igor.veresov at oracle.com Tue Dec 13 15:58:58 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 13 Dec 2011 15:58:58 -0800 Subject: review(XS): 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Message-ID: <63EEE8C75B934A5DBDAF80D631097AFB@oracle.com> We should be more aggressive in tiered mode with -Xcomp and exercise C2 more. With this change will first compile a level 3 version, then do one invocation of it and compile a level 4 and then continue executing it. Webrev: http://cr.openjdk.java.net/~iveresov/7121111/webrev.00 igor From vladimir.kozlov at oracle.com Tue Dec 13 16:16:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Dec 2011 16:16:32 -0800 Subject: review(XS): 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler In-Reply-To: <63EEE8C75B934A5DBDAF80D631097AFB@oracle.com> References: <63EEE8C75B934A5DBDAF80D631097AFB@oracle.com> Message-ID: <4EE7EAE0.1070206@oracle.com> Looks good. Thanks, Vladimir Igor Veresov wrote: > We should be more aggressive in tiered mode with -Xcomp and exercise C2 more. > With this change will first compile a level 3 version, then do one invocation of it and compile a level 4 and then continue executing it. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7121111/webrev.00 > > igor > > From tom.rodriguez at oracle.com Tue Dec 13 16:36:31 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 13 Dec 2011 16:36:31 -0800 Subject: review(XS): 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler In-Reply-To: <63EEE8C75B934A5DBDAF80D631097AFB@oracle.com> References: <63EEE8C75B934A5DBDAF80D631097AFB@oracle.com> Message-ID: <32492AA6-F516-440B-BDB4-8A5E551EDFEC@oracle.com> Looks good. tom On Dec 13, 2011, at 3:58 PM, Igor Veresov wrote: > We should be more aggressive in tiered mode with -Xcomp and exercise C2 more. > With this change will first compile a level 3 version, then do one invocation of it and compile a level 4 and then continue executing it. > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7121111/webrev.00 > > igor > > From igor.veresov at oracle.com Tue Dec 13 16:45:09 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 13 Dec 2011 16:45:09 -0800 Subject: review(XS): 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler In-Reply-To: <32492AA6-F516-440B-BDB4-8A5E551EDFEC@oracle.com> References: <63EEE8C75B934A5DBDAF80D631097AFB@oracle.com> <32492AA6-F516-440B-BDB4-8A5E551EDFEC@oracle.com> Message-ID: <9A31F50C13854B1BA4E5889057D88029@oracle.com> Thanks Vladimir and Tom! igor On Tuesday, December 13, 2011 at 4:36 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Dec 13, 2011, at 3:58 PM, Igor Veresov wrote: > > > We should be more aggressive in tiered mode with -Xcomp and exercise C2 more. > > With this change will first compile a level 3 version, then do one invocation of it and compile a level 4 and then continue executing it. > > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7121111/webrev.00 > > > > igor From vladimir.kozlov at oracle.com Tue Dec 13 18:30:36 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Dec 2011 18:30:36 -0800 Subject: Request for reviews (XL): 7116452: Add support for AVX instructions In-Reply-To: <4EE14DDE.8020307@oracle.com> References: <4EE14DDE.8020307@oracle.com> Message-ID: <4EE80A4C.9030104@oracle.com> Per Tom's request I compared generated code (before and after these changes) on non AVX machine to verify that generated code stays the same. I found few differences with 64-bit VM because of this change: > As part of these changes REX.W prefix was removed from instructions > where it was not needed: MOVDQA, MOVDQU, PCMPESTRI, PSRLQ, PSRLDQ, PTEST. and also because I removed incorrect prefix 0x66 when I replaced next code in Push_SrcXD: // fldd [rsp] emit_opcode(cbuf, 0x66); emit_opcode(cbuf, 0xDD); encode_RegMem(cbuf, 0x0, RSP_enc, 0x4, 0, 0, false); Difference with 32-bit VM is mostly due to switching from comiss to ucomiss instructions. Also movapd is used instead of movsd to move between XMM registers because I replaced direct encoding with movdbl() and movflt(). But I did screwed up when replaced enc_copy_wide() in x86_64.ad since I did not noticed that it does not generate instruction if source and destination registers are the same. I fixed it. thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7116452/webrev.01 > > 7116452: Add support for AVX instructions > > Initial changes were submitted by Intel. I refactored it to simplify > prefix usage in instructions codding (added simd_prefix methods) and VEX > encoding was fixed to generate 2bytes prefix when possible. Changes in > .ad files were not complete (especially in 32-bit .ad) and were not > aggressive as I want. I changed more mach nodes encoding to use > macroassembler instructions. Added missing decoding parts in > Assembler::locate_operand() and NativeMovRegMem::instruction_start(). > > Note: no new AVX instructions were added in these changes. And no 3 > operands format was added to MacroAssembler. It will be other changes. > Destination operand is used as second source in current implementation > where applicable. > > Float compare implementation in x86_32.ad was replaced with > implementation from x86_64.ad. It uses less branches and does not > destroy EAX register. Note: ucomiss instruction produces the same result > as comiss since we masking numeric exceptions. Also ucomiss could be a > little faster since it does not need to check control word for QNaN values. > > Vector instructions with VEX prefix use unaligned load for memory > operands where with old REX prefix it require 16 bytes alignment. > Instructions version with memory operand were added for that but they > should be used only with VEX prefix, assert was added. ANDPD and XORPD > with memory operand were used before with 16 bytes aligned memory (we > have special code to do it). I added assert to check address alignment > for these instructions. > > As part of these changes REX.W prefix was removed from instructions > where it was not needed: MOVDQA, MOVDQU, PCMPESTRI, PSRLQ, PSRLDQ, PTEST. > > > Tested with UseAVX=1|0, UseSSE=4|2|1|0, CTW, VM regression tests, nsk. > > Thanks, > Vladimir From igor.veresov at oracle.com Tue Dec 13 23:37:59 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 14 Dec 2011 07:37:59 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Message-ID: <20111214073803.C724D476A5@hg.openjdk.java.net> Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp From bertrand.delsart at oracle.com Wed Dec 14 04:36:05 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 14 Dec 2011 13:36:05 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> Message-ID: <4EE89835.3070604@oracle.com> Sorry, I was notified of the CR and got involved in the bug because we were wondering whether the bug was impacting our embedded ports. I sent my own review in an internal alias but should have let you know. FYI, we were still discussing it because I raised some issues about the proposed fix. First, thanks for spotting the bug! We do agree with the first problem. We should indeed ensure that SP is correct. My concerns were about the second part. First, the change is doing more that just going through the stub. It seems that your are trying to solve a third problem. x86 was already using the throw_StackOverflowError_entry stub. What your proposed change seems to imply is that you encountered a case where the stub had not yet been generated and hence you had to delay the loading of its address. Is that correct ? In addition, the explanations about why we have to go through that stub did not fit my knowledge of HotSpot and I was trying to clarify that internally (thanks Tom for your confirmations). With our Java ABI, none of the registers allocated by the compiler are callee-saved. Hence, at call sites, the GC should not have to update any OOP in callee-saved registers (but might have to update arguments). If fixing SP is not sufficient to solve your test case on SPARC then the problem is not exactly what you describe. Now, that does not mean the fix would not be correct :-) Going through that stub might be safer anyway, particularly since we are doing it on x86. My issues are about the comments themselves (and the third problem mentioned above). Thanks, Bertrand. On 12/13/11 09:19 PM, Christian Thalinger wrote: > > On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: > >> There's now a bug report for this issue: >> >> 7116216: StackOverflow GC crash >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >> >> so could somebody please have a look at the fix proposed by Yang? > > Sorry, I will have a look tomorrow. > > -- Chris > >> >> Regards, >> Volker >> >> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>> Hi folks, >>> >>> We found two problems during throwing an StackOverflow exception from >>> interpreter. >>> >>> 1. Before preparing to throw a StackOverflow exception, the last Java >>> frame is set to the current sp. This is problematic when the StackOverflow >>> is thrown on top of c2i adapter. Solution : the real caller frame(unextended >>> sp) should be set as last Java frame. >>> >>> 2. When Garbage collection happens during throwing StackOverflow >>> exception, and callee-saved register(or "never-saved" register which behaves >>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>> frame(generated by VM calls), and hence fails to process the OOP. Solution : >>> We build a runtime stub frame before doing a VM call, which guarantees the >>> location of Callee-saved registers are always recognizable by GC. >>> >>> Detailed descriptions and tests could be found in webrev >>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>> >>> I don?t have a bugID yet. Please kindly open one bug for this issue. >>> >>> >>> >>> Thanks, >>> >>> Yang >>> >>> >>> >>> >>> >>> Yang Wang >>> Software Engineer >>> >>> TIP Core AS&VM Technology (AG) >>> SAP JVM JIT Compiler >>> >>> SAP AG >>> Dietmar-Hopp-Allee 16 >>> 69190 Walldorf, Germany >>> >>> T +49 6227 7-50320 >>> F +49 6227 78-48541 >>> Email : yang02.wang at sap.com >>> www.sap.com >>> >>> >>> Pflichtangaben/Mandatory Disclosure Statements: >>> http://www.sap.com/company/legal/impressum.epx >>> >>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich >>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte >>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >>> Dank. >>> >>> This e-mail may contain trade secrets or privileged, undisclosed, or >>> otherwise confidential information. If you have received this e-mail in >>> error, you are hereby notified that any review, copying, or distribution of >>> it is strictly prohibited. Please inform us immediately and destroy the >>> original transmittal. Thank you for your cooperation. >>> >>> > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From yang02.wang at sap.com Wed Dec 14 06:26:16 2011 From: yang02.wang at sap.com (Wang, Yang) Date: Wed, 14 Dec 2011 15:26:16 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: <4EE89835.3070604@oracle.com> References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> <4EE89835.3070604@oracle.com> Message-ID: Hi Bertrand, 1. For the stub concern, it is true that there is an existing stub, but it is only invoked via implicit exception handler(see function continuation_for_implicit_exception). For explicit stack overflow check in "interpreter", the stub is in hotspot not used previously. So the fix is to borrow it. Since the stub is generated after the code-generation for interpreter, the entry address was load indirectly. 2. Going through the stub is like a guard for the VM call, as shown in the picture in webrev: stub frame on top of C frame. When GC fails to handle the OOP in C frame, the stub frame remedies it by containing a copy of the OOP, which is to be handled by GC. 3. For the concern of callee-saved register, I guess you mean Sparc only. You are right that the IN and Local registers are not called "callee-saved" technically(but "never-saved"). However, they are also saved by callee in callee's frame in certain cases(like register window overflow). I hope my understanding here is correct. Thanks and welcome more inputs! Yang -----Original Message----- From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] Sent: Mittwoch, 14. Dezember 2011 13:36 To: Wang, Yang Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net; Coleen Phillimore Subject: Re: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter Sorry, I was notified of the CR and got involved in the bug because we were wondering whether the bug was impacting our embedded ports. I sent my own review in an internal alias but should have let you know. FYI, we were still discussing it because I raised some issues about the proposed fix. First, thanks for spotting the bug! We do agree with the first problem. We should indeed ensure that SP is correct. My concerns were about the second part. First, the change is doing more that just going through the stub. It seems that your are trying to solve a third problem. x86 was already using the throw_StackOverflowError_entry stub. What your proposed change seems to imply is that you encountered a case where the stub had not yet been generated and hence you had to delay the loading of its address. Is that correct ? In addition, the explanations about why we have to go through that stub did not fit my knowledge of HotSpot and I was trying to clarify that internally (thanks Tom for your confirmations). With our Java ABI, none of the registers allocated by the compiler are callee-saved. Hence, at call sites, the GC should not have to update any OOP in callee-saved registers (but might have to update arguments). If fixing SP is not sufficient to solve your test case on SPARC then the problem is not exactly what you describe. Now, that does not mean the fix would not be correct :-) Going through that stub might be safer anyway, particularly since we are doing it on x86. My issues are about the comments themselves (and the third problem mentioned above). Thanks, Bertrand. On 12/13/11 09:19 PM, Christian Thalinger wrote: > > On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: > >> There's now a bug report for this issue: >> >> 7116216: StackOverflow GC crash >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >> >> so could somebody please have a look at the fix proposed by Yang? > > Sorry, I will have a look tomorrow. > > -- Chris > >> >> Regards, >> Volker >> >> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>> Hi folks, >>> >>> We found two problems during throwing an StackOverflow exception from >>> interpreter. >>> >>> 1. Before preparing to throw a StackOverflow exception, the last Java >>> frame is set to the current sp. This is problematic when the StackOverflow >>> is thrown on top of c2i adapter. Solution : the real caller frame(unextended >>> sp) should be set as last Java frame. >>> >>> 2. When Garbage collection happens during throwing StackOverflow >>> exception, and callee-saved register(or "never-saved" register which behaves >>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>> frame(generated by VM calls), and hence fails to process the OOP. Solution : >>> We build a runtime stub frame before doing a VM call, which guarantees the >>> location of Callee-saved registers are always recognizable by GC. >>> >>> Detailed descriptions and tests could be found in webrev >>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>> >>> I don't have a bugID yet. Please kindly open one bug for this issue. >>> >>> >>> >>> Thanks, >>> >>> Yang >>> >>> >>> >>> >>> >>> Yang Wang >>> Software Engineer >>> >>> TIP Core AS&VM Technology (AG) >>> SAP JVM JIT Compiler >>> >>> SAP AG >>> Dietmar-Hopp-Allee 16 >>> 69190 Walldorf, Germany >>> >>> T +49 6227 7-50320 >>> F +49 6227 78-48541 >>> Email : yang02.wang at sap.com >>> www.sap.com >>> >>> >>> Pflichtangaben/Mandatory Disclosure Statements: >>> http://www.sap.com/company/legal/impressum.epx >>> >>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich >>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte >>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >>> Dank. >>> >>> This e-mail may contain trade secrets or privileged, undisclosed, or >>> otherwise confidential information. If you have received this e-mail in >>> error, you are hereby notified that any review, copying, or distribution of >>> it is strictly prohibited. Please inform us immediately and destroy the >>> original transmittal. Thank you for your cooperation. >>> >>> > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From roland.westrelin at oracle.com Wed Dec 14 07:55:05 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 14 Dec 2011 16:55:05 +0100 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Message-ID: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> http://cr.openjdk.java.net/~roland/7121140/webrev.00/ For systems that don't implement total store ordering a store store barrier is required after a newly allocated objects is initialized and before it becomes globally reachable. Roland. From bertrand.delsart at oracle.com Wed Dec 14 08:14:43 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 14 Dec 2011 17:14:43 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> <4EE89835.3070604@oracle.com> Message-ID: <4EE8CB73.7090800@oracle.com> Hi Yang, Answers inlined. On 12/14/11 03:26 PM, Wang, Yang wrote: > 1. For the stub concern, it is true that there is an existing stub, but it is only invoked via implicit exception handler(see function continuation_for_implicit_exception). For explicit stack overflow check in "interpreter", the stub is in hotspot not used previously. So the fix is to borrow it. Since the stub is generated after the code-generation for interpreter, the entry address was load indirectly. The stub was used on x86 in the call you modified :-) In addition, some stubs are generated before the interpreter. That's why I asked whether you had really noticed an issue (e.g. whether the code generated a jump to a NULL address on x86). Anyway, I'll double check when the stub is generated and, if necessary, see whether we can initialize it earlier instead of deferring the load. > 2. Going through the stub is like a guard for the VM call, as shown in the picture in webrev: stub frame on top of C frame. When GC fails to handle the OOP in C frame, the stub frame remedies it by containing a copy of the OOP, which is to be handled by GC. Understood. The problem is not really about whether we need a stub (I'm still reviewing that for sparc). The problem is about the reasons stated. I'm trying to remove the comments that might be confusing. For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" when at a method call site (elsewhere, it can indeed be an oop that needs to be updated). See point 3. From a jited code point of view, there is no callee-saved registers in our compiled Java ABI for x86. I'm currently reviewing the Sparc part because it is indeed a special case... and the one that was unfortunately not using the stub :-( > 3. For the concern of callee-saved register, I guess you mean Sparc only. You are right that the IN and Local registers are not called "callee-saved" technically(but "never-saved"). However, they are also saved by callee in callee's frame in certain cases(like register window overflow). I hope my understanding here is correct. No. That was not sparc only. In fact Sparc might be the exception. If you look for instance at the definition of is_caller_save_register() in c1_FrameMap_x86.hpp, you'll see that HotSpot now assumes that all registers can be scratched by called Java methods. We measured that performance were better when not using callee saved registers (for compiled Java code). Sparc is a special case because the IN and Local registers are automatically protected. This is the only platform which provides callee-saved registers "for free" when building frames (thanks to the register windows). Hence, I thought that our JIT compilers were no longer using callee-saved registers on any of the supported platforms but Sparc might indeed be the exception. > > Thanks and welcome more inputs! > Yang > > > > -----Original Message----- > From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] > Sent: Mittwoch, 14. Dezember 2011 13:36 > To: Wang, Yang > Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net; Coleen Phillimore > Subject: Re: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter > > Sorry, > > I was notified of the CR and got involved in the bug because we were > wondering whether the bug was impacting our embedded ports. I sent my > own review in an internal alias but should have let you know. FYI, we > were still discussing it because I raised some issues about the proposed > fix. > > First, thanks for spotting the bug! We do agree with the first problem. > We should indeed ensure that SP is correct. > > My concerns were about the second part. > > First, the change is doing more that just going through the stub. It > seems that your are trying to solve a third problem. x86 was already > using the throw_StackOverflowError_entry stub. What your proposed change > seems to imply is that you encountered a case where the stub had not yet > been generated and hence you had to delay the loading of its address. Is > that correct ? > > In addition, the explanations about why we have to go through that stub > did not fit my knowledge of HotSpot and I was trying to clarify that > internally (thanks Tom for your confirmations). > > With our Java ABI, none of the registers allocated by the compiler are > callee-saved. Hence, at call sites, the GC should not have to update any > OOP in callee-saved registers (but might have to update arguments). If > fixing SP is not sufficient to solve your test case on SPARC then the > problem is not exactly what you describe. > > Now, that does not mean the fix would not be correct :-) Going through > that stub might be safer anyway, particularly since we are doing it on > x86. My issues are about the comments themselves (and the third problem > mentioned above). > > Thanks, > > Bertrand. > > On 12/13/11 09:19 PM, Christian Thalinger wrote: >> >> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: >> >>> There's now a bug report for this issue: >>> >>> 7116216: StackOverflow GC crash >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >>> >>> so could somebody please have a look at the fix proposed by Yang? >> >> Sorry, I will have a look tomorrow. >> >> -- Chris >> >>> >>> Regards, >>> Volker >>> >>> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>>> Hi folks, >>>> >>>> We found two problems during throwing an StackOverflow exception from >>>> interpreter. >>>> >>>> 1. Before preparing to throw a StackOverflow exception, the last Java >>>> frame is set to the current sp. This is problematic when the StackOverflow >>>> is thrown on top of c2i adapter. Solution : the real caller frame(unextended >>>> sp) should be set as last Java frame. >>>> >>>> 2. When Garbage collection happens during throwing StackOverflow >>>> exception, and callee-saved register(or "never-saved" register which behaves >>>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>>> frame(generated by VM calls), and hence fails to process the OOP. Solution : >>>> We build a runtime stub frame before doing a VM call, which guarantees the >>>> location of Callee-saved registers are always recognizable by GC. >>>> >>>> Detailed descriptions and tests could be found in webrev >>>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>>> >>>> I don't have a bugID yet. Please kindly open one bug for this issue. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Yang >>>> >>>> >>>> >>>> >>>> >>>> Yang Wang >>>> Software Engineer >>>> >>>> TIP Core AS&VM Technology (AG) >>>> SAP JVM JIT Compiler >>>> >>>> SAP AG >>>> Dietmar-Hopp-Allee 16 >>>> 69190 Walldorf, Germany >>>> >>>> T +49 6227 7-50320 >>>> F +49 6227 78-48541 >>>> Email : yang02.wang at sap.com >>>> www.sap.com >>>> >>>> >>>> Pflichtangaben/Mandatory Disclosure Statements: >>>> http://www.sap.com/company/legal/impressum.epx >>>> >>>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich >>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte >>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen >>>> Dank. >>>> >>>> This e-mail may contain trade secrets or privileged, undisclosed, or >>>> otherwise confidential information. If you have received this e-mail in >>>> error, you are hereby notified that any review, copying, or distribution of >>>> it is strictly prohibited. Please inform us immediately and destroy the >>>> original transmittal. Thank you for your cooperation. >>>> >>>> >> > > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From bertrand.delsart at oracle.com Wed Dec 14 08:49:38 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 14 Dec 2011 17:49:38 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: <4EE8CB73.7090800@oracle.com> References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> <4EE89835.3070604@oracle.com> <4EE8CB73.7090800@oracle.com> Message-ID: <4EE8D3A2.6010700@oracle.com> Sorry, I just realized that x86 was not using the same stub. I got caught up in the confusion created by the comments and did not notice the difference between the call to Interpreter::throw_StackOverflowError_entry() and the call to SharedRuntime::throw_StackOverflowError_entry() The real reason for the failure seems to be that x86 was calling something that assumes the active frame is interpreted (see generate_StackOverflowError_handler). If this is called with a compiled frame context (after a c2i), this could indeed lead to issues that I need to investigate further. I know understand better the reasons for your fix and will see whether this is indeed calling the right stub and whether I could generate it earlier to avoid delaying the load. Thanks, Bertrand. On 12/14/11 05:14 PM, Bertrand Delsart wrote: > Hi Yang, > > Answers inlined. > > On 12/14/11 03:26 PM, Wang, Yang wrote: >> 1. For the stub concern, it is true that there is an existing stub, >> but it is only invoked via implicit exception handler(see function >> continuation_for_implicit_exception). For explicit stack overflow >> check in "interpreter", the stub is in hotspot not used previously. So >> the fix is to borrow it. Since the stub is generated after the >> code-generation for interpreter, the entry address was load indirectly. > > The stub was used on x86 in the call you modified :-) In addition, some > stubs are generated before the interpreter. That's why I asked whether > you had really noticed an issue (e.g. whether the code generated a jump > to a NULL address on x86). > > Anyway, I'll double check when the stub is generated and, if necessary, > see whether we can initialize it earlier instead of deferring the load. > >> 2. Going through the stub is like a guard for the VM call, as shown in >> the picture in webrev: stub frame on top of C frame. When GC fails to >> handle the OOP in C frame, the stub frame remedies it by containing a >> copy of the OOP, which is to be handled by GC. > > Understood. The problem is not really about whether we need a stub (I'm > still reviewing that for sparc). The problem is about the reasons > stated. I'm trying to remove the comments that might be confusing. > > For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" > when at a method call site (elsewhere, it can indeed be an oop that > needs to be updated). See point 3. From a jited code point of view, > there is no callee-saved registers in our compiled Java ABI for x86. > > I'm currently reviewing the Sparc part because it is indeed a special > case... and the one that was unfortunately not using the stub :-( > >> 3. For the concern of callee-saved register, I guess you mean Sparc >> only. You are right that the IN and Local registers are not called >> "callee-saved" technically(but "never-saved"). However, they are also >> saved by callee in callee's frame in certain cases(like register >> window overflow). I hope my understanding here is correct. > > No. That was not sparc only. In fact Sparc might be the exception. > > If you look for instance at the definition of is_caller_save_register() > in c1_FrameMap_x86.hpp, you'll see that HotSpot now assumes that all > registers can be scratched by called Java methods. We measured that > performance were better when not using callee saved registers (for > compiled Java code). > > Sparc is a special case because the IN and Local registers are > automatically protected. This is the only platform which provides > callee-saved registers "for free" when building frames (thanks to the > register windows). Hence, I thought that our JIT compilers were no > longer using callee-saved registers on any of the supported platforms > but Sparc might indeed be the exception. > >> >> Thanks and welcome more inputs! >> Yang >> >> >> >> -----Original Message----- >> From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] >> Sent: Mittwoch, 14. Dezember 2011 13:36 >> To: Wang, Yang >> Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net; Coleen >> Phillimore >> Subject: Re: Request for Review(S): JVM crashes when throwing >> StackOverflow exception from interpreter >> >> Sorry, >> >> I was notified of the CR and got involved in the bug because we were >> wondering whether the bug was impacting our embedded ports. I sent my >> own review in an internal alias but should have let you know. FYI, we >> were still discussing it because I raised some issues about the proposed >> fix. >> >> First, thanks for spotting the bug! We do agree with the first problem. >> We should indeed ensure that SP is correct. >> >> My concerns were about the second part. >> >> First, the change is doing more that just going through the stub. It >> seems that your are trying to solve a third problem. x86 was already >> using the throw_StackOverflowError_entry stub. What your proposed change >> seems to imply is that you encountered a case where the stub had not yet >> been generated and hence you had to delay the loading of its address. Is >> that correct ? >> >> In addition, the explanations about why we have to go through that stub >> did not fit my knowledge of HotSpot and I was trying to clarify that >> internally (thanks Tom for your confirmations). >> >> With our Java ABI, none of the registers allocated by the compiler are >> callee-saved. Hence, at call sites, the GC should not have to update any >> OOP in callee-saved registers (but might have to update arguments). If >> fixing SP is not sufficient to solve your test case on SPARC then the >> problem is not exactly what you describe. >> >> Now, that does not mean the fix would not be correct :-) Going through >> that stub might be safer anyway, particularly since we are doing it on >> x86. My issues are about the comments themselves (and the third problem >> mentioned above). >> >> Thanks, >> >> Bertrand. >> >> On 12/13/11 09:19 PM, Christian Thalinger wrote: >>> >>> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: >>> >>>> There's now a bug report for this issue: >>>> >>>> 7116216: StackOverflow GC crash >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >>>> >>>> so could somebody please have a look at the fix proposed by Yang? >>> >>> Sorry, I will have a look tomorrow. >>> >>> -- Chris >>> >>>> >>>> Regards, >>>> Volker >>>> >>>> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>>>> Hi folks, >>>>> >>>>> We found two problems during throwing an StackOverflow exception from >>>>> interpreter. >>>>> >>>>> 1. Before preparing to throw a StackOverflow exception, the last Java >>>>> frame is set to the current sp. This is problematic when the >>>>> StackOverflow >>>>> is thrown on top of c2i adapter. Solution : the real caller >>>>> frame(unextended >>>>> sp) should be set as last Java frame. >>>>> >>>>> 2. When Garbage collection happens during throwing StackOverflow >>>>> exception, and callee-saved register(or "never-saved" register >>>>> which behaves >>>>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>>>> frame(generated by VM calls), and hence fails to process the OOP. >>>>> Solution : >>>>> We build a runtime stub frame before doing a VM call, which >>>>> guarantees the >>>>> location of Callee-saved registers are always recognizable by GC. >>>>> >>>>> Detailed descriptions and tests could be found in webrev >>>>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>>>> >>>>> I don't have a bugID yet. Please kindly open one bug for this issue. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yang >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yang Wang >>>>> Software Engineer >>>>> >>>>> TIP Core AS&VM Technology (AG) >>>>> SAP JVM JIT Compiler >>>>> >>>>> SAP AG >>>>> Dietmar-Hopp-Allee 16 >>>>> 69190 Walldorf, Germany >>>>> >>>>> T +49 6227 7-50320 >>>>> F +49 6227 78-48541 >>>>> Email : yang02.wang at sap.com >>>>> www.sap.com >>>>> >>>>> >>>>> Pflichtangaben/Mandatory Disclosure Statements: >>>>> http://www.sap.com/company/legal/impressum.epx >>>>> >>>>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail >>>>> irrt?mlich >>>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>>>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. >>>>> Bitte >>>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. >>>>> Vielen >>>>> Dank. >>>>> >>>>> This e-mail may contain trade secrets or privileged, undisclosed, or >>>>> otherwise confidential information. If you have received this >>>>> e-mail in >>>>> error, you are hereby notified that any review, copying, or >>>>> distribution of >>>>> it is strictly prohibited. Please inform us immediately and destroy >>>>> the >>>>> original transmittal. Thank you for your cooperation. >>>>> >>>>> >>> >> >> > > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From yang02.wang at sap.com Wed Dec 14 09:55:01 2011 From: yang02.wang at sap.com (Wang, Yang) Date: Wed, 14 Dec 2011 18:55:01 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: <4EE8D3A2.6010700@oracle.com> References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> <4EE89835.3070604@oracle.com> <4EE8CB73.7090800@oracle.com> <4EE8D3A2.6010700@oracle.com> Message-ID: Hello again, Well, I think I am still not clear enough about the term "callee-save". From Java ABI's perspective, there is no callee-saved registers; but from C ABI's perspective, ebp is callee-saved, and it is causing problem : it saves and restores it without interacting with GC. And I don't understand why you say " For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" when at a method call site". Actually I saw "ebp" in OopMap in a call site with "PrintAssembly". Thanks, Yang -----Original Message----- From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] Sent: Mittwoch, 14. Dezember 2011 17:50 To: Wang, Yang Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net Subject: Re: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter Sorry, I just realized that x86 was not using the same stub. I got caught up in the confusion created by the comments and did not notice the difference between the call to Interpreter::throw_StackOverflowError_entry() and the call to SharedRuntime::throw_StackOverflowError_entry() The real reason for the failure seems to be that x86 was calling something that assumes the active frame is interpreted (see generate_StackOverflowError_handler). If this is called with a compiled frame context (after a c2i), this could indeed lead to issues that I need to investigate further. I know understand better the reasons for your fix and will see whether this is indeed calling the right stub and whether I could generate it earlier to avoid delaying the load. Thanks, Bertrand. On 12/14/11 05:14 PM, Bertrand Delsart wrote: > Hi Yang, > > Answers inlined. > > On 12/14/11 03:26 PM, Wang, Yang wrote: >> 1. For the stub concern, it is true that there is an existing stub, >> but it is only invoked via implicit exception handler(see function >> continuation_for_implicit_exception). For explicit stack overflow >> check in "interpreter", the stub is in hotspot not used previously. So >> the fix is to borrow it. Since the stub is generated after the >> code-generation for interpreter, the entry address was load indirectly. > > The stub was used on x86 in the call you modified :-) In addition, some > stubs are generated before the interpreter. That's why I asked whether > you had really noticed an issue (e.g. whether the code generated a jump > to a NULL address on x86). > > Anyway, I'll double check when the stub is generated and, if necessary, > see whether we can initialize it earlier instead of deferring the load. > >> 2. Going through the stub is like a guard for the VM call, as shown in >> the picture in webrev: stub frame on top of C frame. When GC fails to >> handle the OOP in C frame, the stub frame remedies it by containing a >> copy of the OOP, which is to be handled by GC. > > Understood. The problem is not really about whether we need a stub (I'm > still reviewing that for sparc). The problem is about the reasons > stated. I'm trying to remove the comments that might be confusing. > > For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" > when at a method call site (elsewhere, it can indeed be an oop that > needs to be updated). See point 3. From a jited code point of view, > there is no callee-saved registers in our compiled Java ABI for x86. > > I'm currently reviewing the Sparc part because it is indeed a special > case... and the one that was unfortunately not using the stub :-( > >> 3. For the concern of callee-saved register, I guess you mean Sparc >> only. You are right that the IN and Local registers are not called >> "callee-saved" technically(but "never-saved"). However, they are also >> saved by callee in callee's frame in certain cases(like register >> window overflow). I hope my understanding here is correct. > > No. That was not sparc only. In fact Sparc might be the exception. > > If you look for instance at the definition of is_caller_save_register() > in c1_FrameMap_x86.hpp, you'll see that HotSpot now assumes that all > registers can be scratched by called Java methods. We measured that > performance were better when not using callee saved registers (for > compiled Java code). > > Sparc is a special case because the IN and Local registers are > automatically protected. This is the only platform which provides > callee-saved registers "for free" when building frames (thanks to the > register windows). Hence, I thought that our JIT compilers were no > longer using callee-saved registers on any of the supported platforms > but Sparc might indeed be the exception. > >> >> Thanks and welcome more inputs! >> Yang >> >> >> >> -----Original Message----- >> From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] >> Sent: Mittwoch, 14. Dezember 2011 13:36 >> To: Wang, Yang >> Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net; Coleen >> Phillimore >> Subject: Re: Request for Review(S): JVM crashes when throwing >> StackOverflow exception from interpreter >> >> Sorry, >> >> I was notified of the CR and got involved in the bug because we were >> wondering whether the bug was impacting our embedded ports. I sent my >> own review in an internal alias but should have let you know. FYI, we >> were still discussing it because I raised some issues about the proposed >> fix. >> >> First, thanks for spotting the bug! We do agree with the first problem. >> We should indeed ensure that SP is correct. >> >> My concerns were about the second part. >> >> First, the change is doing more that just going through the stub. It >> seems that your are trying to solve a third problem. x86 was already >> using the throw_StackOverflowError_entry stub. What your proposed change >> seems to imply is that you encountered a case where the stub had not yet >> been generated and hence you had to delay the loading of its address. Is >> that correct ? >> >> In addition, the explanations about why we have to go through that stub >> did not fit my knowledge of HotSpot and I was trying to clarify that >> internally (thanks Tom for your confirmations). >> >> With our Java ABI, none of the registers allocated by the compiler are >> callee-saved. Hence, at call sites, the GC should not have to update any >> OOP in callee-saved registers (but might have to update arguments). If >> fixing SP is not sufficient to solve your test case on SPARC then the >> problem is not exactly what you describe. >> >> Now, that does not mean the fix would not be correct :-) Going through >> that stub might be safer anyway, particularly since we are doing it on >> x86. My issues are about the comments themselves (and the third problem >> mentioned above). >> >> Thanks, >> >> Bertrand. >> >> On 12/13/11 09:19 PM, Christian Thalinger wrote: >>> >>> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: >>> >>>> There's now a bug report for this issue: >>>> >>>> 7116216: StackOverflow GC crash >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >>>> >>>> so could somebody please have a look at the fix proposed by Yang? >>> >>> Sorry, I will have a look tomorrow. >>> >>> -- Chris >>> >>>> >>>> Regards, >>>> Volker >>>> >>>> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>>>> Hi folks, >>>>> >>>>> We found two problems during throwing an StackOverflow exception from >>>>> interpreter. >>>>> >>>>> 1. Before preparing to throw a StackOverflow exception, the last Java >>>>> frame is set to the current sp. This is problematic when the >>>>> StackOverflow >>>>> is thrown on top of c2i adapter. Solution : the real caller >>>>> frame(unextended >>>>> sp) should be set as last Java frame. >>>>> >>>>> 2. When Garbage collection happens during throwing StackOverflow >>>>> exception, and callee-saved register(or "never-saved" register >>>>> which behaves >>>>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>>>> frame(generated by VM calls), and hence fails to process the OOP. >>>>> Solution : >>>>> We build a runtime stub frame before doing a VM call, which >>>>> guarantees the >>>>> location of Callee-saved registers are always recognizable by GC. >>>>> >>>>> Detailed descriptions and tests could be found in webrev >>>>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>>>> >>>>> I don't have a bugID yet. Please kindly open one bug for this issue. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yang >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yang Wang >>>>> Software Engineer >>>>> >>>>> TIP Core AS&VM Technology (AG) >>>>> SAP JVM JIT Compiler >>>>> >>>>> SAP AG >>>>> Dietmar-Hopp-Allee 16 >>>>> 69190 Walldorf, Germany >>>>> >>>>> T +49 6227 7-50320 >>>>> F +49 6227 78-48541 >>>>> Email : yang02.wang at sap.com >>>>> www.sap.com >>>>> >>>>> >>>>> Pflichtangaben/Mandatory Disclosure Statements: >>>>> http://www.sap.com/company/legal/impressum.epx >>>>> >>>>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail >>>>> irrt?mlich >>>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>>>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. >>>>> Bitte >>>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. >>>>> Vielen >>>>> Dank. >>>>> >>>>> This e-mail may contain trade secrets or privileged, undisclosed, or >>>>> otherwise confidential information. If you have received this >>>>> e-mail in >>>>> error, you are hereby notified that any review, copying, or >>>>> distribution of >>>>> it is strictly prohibited. Please inform us immediately and destroy >>>>> the >>>>> original transmittal. Thank you for your cooperation. >>>>> >>>>> >>> >> >> > > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Wed Dec 14 10:15:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Dec 2011 10:15:08 -0800 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> Message-ID: <4EE8E7AC.9090208@oracle.com> Looks good. Vladimir Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7121140/webrev.00/ > > For systems that don't implement total store ordering a store store barrier is required after a newly allocated objects is initialized and before it becomes globally reachable. > > Roland. From tom.rodriguez at oracle.com Wed Dec 14 11:22:05 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Dec 2011 11:22:05 -0800 Subject: Request for reviews (XL): 7116452: Add support for AVX instructions In-Reply-To: <4EE14DDE.8020307@oracle.com> References: <4EE14DDE.8020307@oracle.com> Message-ID: Overall it looks good. Are there any hidden uses of rscratch1 that's we've introduced? I was looking at d2l_fixup and the current code always explicitly assumes that double_sign_flip is reachable but the new code uses cmp64 which might use rscratch1. It won't because double_sign_flip is allocated from the CodeCache but it had me worried for a minute. We should have a flag for MacroAssembler that disables the implicit use of rscratch1 so we don't get silently screwed. In assembler_x86.cpp could you put a small comment on simd_pre and simd_opc? Reading through the x86 ad files really put me in the mood to eliminate the spurious formatting and naming differences between them. Large portions of them are (or could be) exactly the same. tom On Dec 8, 2011, at 3:53 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7116452/webrev.01 > > 7116452: Add support for AVX instructions > > Initial changes were submitted by Intel. I refactored it to simplify prefix usage in instructions codding (added simd_prefix methods) and VEX encoding was fixed to generate 2bytes prefix when possible. Changes in .ad files were not complete (especially in 32-bit .ad) and were not aggressive as I want. I changed more mach nodes encoding to use macroassembler instructions. Added missing decoding parts in Assembler::locate_operand() and NativeMovRegMem::instruction_start(). > > Note: no new AVX instructions were added in these changes. And no 3 operands format was added to MacroAssembler. It will be other changes. Destination operand is used as second source in current implementation where applicable. > > Float compare implementation in x86_32.ad was replaced with implementation from x86_64.ad. It uses less branches and does not destroy EAX register. Note: ucomiss instruction produces the same result as comiss since we masking numeric exceptions. Also ucomiss could be a little faster since it does not need to check control word for QNaN values. > > Vector instructions with VEX prefix use unaligned load for memory operands where with old REX prefix it require 16 bytes alignment. Instructions version with memory operand were added for that but they should be used only with VEX prefix, assert was added. ANDPD and XORPD with memory operand were used before with 16 bytes aligned memory (we have special code to do it). I added assert to check address alignment for these instructions. > > As part of these changes REX.W prefix was removed from instructions where it was not needed: MOVDQA, MOVDQU, PCMPESTRI, PSRLQ, PSRLDQ, PTEST. > > > Tested with UseAVX=1|0, UseSSE=4|2|1|0, CTW, VM regression tests, nsk. > > Thanks, > Vladimir From tom.rodriguez at oracle.com Wed Dec 14 11:41:33 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Dec 2011 11:41:33 -0800 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> Message-ID: On Dec 14, 2011, at 7:55 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7121140/webrev.00/ > > For systems that don't implement total store ordering a store store barrier is required after a newly allocated objects is initialized and before it becomes globally reachable. I think the instruct name should be membar_storestoree instead of unnecessary_membar_storestore and remove the "unnecessary so" part of the comment. It's like membar_release where it's necessary but it never emits any assembly. I wouldn't expect this to affect performance since it's not emitting an extra instructions but we are emitting some extra barriers which tangles of the memory graph a bit. Could you do some quick performance to make sure nothing's changed? Otherwise it looks good. tom > > Roland. From roland.westrelin at oracle.com Wed Dec 14 12:35:52 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 14 Dec 2011 21:35:52 +0100 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> Message-ID: <29B39F2D-D3D1-4C37-8EB8-E4B2A6D18569@oracle.com> > I think the instruct name should be membar_storestoree instead of unnecessary_membar_storestore and remove the "unnecessary so" part of the comment. It's like membar_release where it's necessary but it never emits any assembly. Makes sense. I'll change that before I push it. > I wouldn't expect this to affect performance since it's not emitting an extra instructions but we are emitting some extra barriers which tangles of the memory graph a bit. Could you do some quick performance to make sure nothing's changed? Ok. I'll do that. Would specjvm98 + specjbb2005 on x86 be sufficient? > Otherwise it looks good. Thanks for the review. Roland. From vladimir.kozlov at oracle.com Wed Dec 14 12:54:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Dec 2011 12:54:26 -0800 Subject: Request for reviews (XL): 7116452: Add support for AVX instructions In-Reply-To: References: <4EE14DDE.8020307@oracle.com> Message-ID: <4EE90D02.3030107@oracle.com> Tom Rodriguez wrote: > Overall it looks good. > > Are there any hidden uses of rscratch1 that's we've introduced? I was looking at d2l_fixup and the current code always explicitly assumes that double_sign_flip is reachable but the new code uses cmp64 which might use rscratch1. It won't because double_sign_flip is allocated from the CodeCache but it had me worried for a minute. We should have a flag for MacroAssembler that disables the implicit use of rscratch1 so we don't get silently screwed. It is used in all float instructions which have constant operand (so it is reachable). And I can't use cmpq instead of cmp64 there since as_Address() method can be called only from MacroAssembler. But I agree with you that if we use assembler instruction in ad file we should have only reachable addresses. Something like this: void MacroAssembler::addss(XMMRegister dst, AddressLiteral src, bool only_reachable) { if (reachable(src)) { addss(dst, as_Address(src)); } else { assert(!only_reachable, ""); lea(rscratch1, src); addss(dst, Address(rscratch1, 0)); } } > > In assembler_x86.cpp could you put a small comment on simd_pre and simd_opc? Done: + // SSE SIMD prefix byte values corresponding to VexSimdPrefix encoding. static int simd_pre[4] = { 0, 0x66, 0xF3, 0xF2 }; + // SSE opcode second byte values (first is 0x0F) corresponding to VexOpcode encoding. static int simd_opc[4] = { 0, 0, 0x38, 0x3A }; + // Generate SSE legacy REX prefix and SIMD opcode based on VEX encoding. void Assembler::rex_prefix(Address adr, XMMRegister xreg, VexSimdPrefix pre, VexOpcode opc, bool rex_w) { > > Reading through the x86 ad files really put me in the mood to eliminate the spurious formatting and naming differences between them. Large portions of them are (or could be) exactly the same. I have the same feeling. I want to create third x86.ad file which has common instructions definitions. Currently Xmm registers naming is different (regXD vs regD) but we can fix it. Thanks, Vladimir > > tom > > On Dec 8, 2011, at 3:53 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7116452/webrev.01 >> >> 7116452: Add support for AVX instructions >> >> Initial changes were submitted by Intel. I refactored it to simplify prefix usage in instructions codding (added simd_prefix methods) and VEX encoding was fixed to generate 2bytes prefix when possible. Changes in .ad files were not complete (especially in 32-bit .ad) and were not aggressive as I want. I changed more mach nodes encoding to use macroassembler instructions. Added missing decoding parts in Assembler::locate_operand() and NativeMovRegMem::instruction_start(). >> >> Note: no new AVX instructions were added in these changes. And no 3 operands format was added to MacroAssembler. It will be other changes. Destination operand is used as second source in current implementation where applicable. >> >> Float compare implementation in x86_32.ad was replaced with implementation from x86_64.ad. It uses less branches and does not destroy EAX register. Note: ucomiss instruction produces the same result as comiss since we masking numeric exceptions. Also ucomiss could be a little faster since it does not need to check control word for QNaN values. >> >> Vector instructions with VEX prefix use unaligned load for memory operands where with old REX prefix it require 16 bytes alignment. Instructions version with memory operand were added for that but they should be used only with VEX prefix, assert was added. ANDPD and XORPD with memory operand were used before with 16 bytes aligned memory (we have special code to do it). I added assert to check address alignment for these instructions. >> >> As part of these changes REX.W prefix was removed from instructions where it was not needed: MOVDQA, MOVDQU, PCMPESTRI, PSRLQ, PSRLDQ, PTEST. >> >> >> Tested with UseAVX=1|0, UseSSE=4|2|1|0, CTW, VM regression tests, nsk. >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Wed Dec 14 13:01:47 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Dec 2011 13:01:47 -0800 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: <29B39F2D-D3D1-4C37-8EB8-E4B2A6D18569@oracle.com> References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> <29B39F2D-D3D1-4C37-8EB8-E4B2A6D18569@oracle.com> Message-ID: <23EB8DF3-4235-41EE-8577-9CC8CC5EDD40@oracle.com> On Dec 14, 2011, at 12:35 PM, Roland Westrelin wrote: >> I think the instruct name should be membar_storestoree instead of unnecessary_membar_storestore and remove the "unnecessary so" part of the comment. It's like membar_release where it's necessary but it never emits any assembly. > > Makes sense. I'll change that before I push it. > >> I wouldn't expect this to affect performance since it's not emitting an extra instructions but we are emitting some extra barriers which tangles of the memory graph a bit. Could you do some quick performance to make sure nothing's changed? > > Ok. I'll do that. Would specjvm98 + specjbb2005 on x86 be sufficient? > yep. tom >> Otherwise it looks good. > > Thanks for the review. > > Roland. From tom.rodriguez at oracle.com Wed Dec 14 13:08:27 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 14 Dec 2011 13:08:27 -0800 Subject: Request for reviews (XL): 7116452: Add support for AVX instructions In-Reply-To: <4EE90D02.3030107@oracle.com> References: <4EE14DDE.8020307@oracle.com> <4EE90D02.3030107@oracle.com> Message-ID: > >> Reading through the x86 ad files really put me in the mood to eliminate the spurious formatting and naming differences between them. Large portions of them are (or could be) exactly the same. > > I have the same feeling. I want to create third x86.ad file which has common instructions definitions. Currently Xmm registers naming is different (regXD vs regD) but we can fix it. I actually wasted some time yesterday fixing some naming and formatting. There are a lot of spurious renames like RegMem to reg_mem plus all the formatting stuff. Switching to MacroAssembler in more places would remove a lot of differences too. There's also the eReg vs. rReg naming but I think we should just switch to rReg and there's the upper vs. lower case format output and I think we should switch to lower. Plus things like movq vs movl. It's ugly but we should minimize as much as we can. tom > > Thanks, > Vladimir > >> tom >> On Dec 8, 2011, at 3:53 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7116452/webrev.01 >>> >>> 7116452: Add support for AVX instructions >>> >>> Initial changes were submitted by Intel. I refactored it to simplify prefix usage in instructions codding (added simd_prefix methods) and VEX encoding was fixed to generate 2bytes prefix when possible. Changes in .ad files were not complete (especially in 32-bit .ad) and were not aggressive as I want. I changed more mach nodes encoding to use macroassembler instructions. Added missing decoding parts in Assembler::locate_operand() and NativeMovRegMem::instruction_start(). >>> >>> Note: no new AVX instructions were added in these changes. And no 3 operands format was added to MacroAssembler. It will be other changes. Destination operand is used as second source in current implementation where applicable. >>> >>> Float compare implementation in x86_32.ad was replaced with implementation from x86_64.ad. It uses less branches and does not destroy EAX register. Note: ucomiss instruction produces the same result as comiss since we masking numeric exceptions. Also ucomiss could be a little faster since it does not need to check control word for QNaN values. >>> >>> Vector instructions with VEX prefix use unaligned load for memory operands where with old REX prefix it require 16 bytes alignment. Instructions version with memory operand were added for that but they should be used only with VEX prefix, assert was added. ANDPD and XORPD with memory operand were used before with 16 bytes aligned memory (we have special code to do it). I added assert to check address alignment for these instructions. >>> >>> As part of these changes REX.W prefix was removed from instructions where it was not needed: MOVDQA, MOVDQU, PCMPESTRI, PSRLQ, PSRLDQ, PTEST. >>> >>> >>> Tested with UseAVX=1|0, UseSSE=4|2|1|0, CTW, VM regression tests, nsk. >>> >>> Thanks, >>> Vladimir From yang02.wang at sap.com Thu Dec 15 02:46:08 2011 From: yang02.wang at sap.com (Wang, Yang) Date: Thu, 15 Dec 2011 11:46:08 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> <4EE89835.3070604@oracle.com> <4EE8CB73.7090800@oracle.com> <4EE8D3A2.6010700@oracle.com> Message-ID: Hi Bertrand, I don't want to insert comments on the long text, so here are some points I would like to clarify: 1. I understand, hotspot does not use callee-saved register in compiled java code for performance reasons. However, ebp is an exception. It is pushed in the beginning of a function(Prolog), and poped in the end(Epilog). So I don't see any difference to the callee-save concept. If there's any difference(maybe from register allocator's perspective?), could you help clarify? 2. You mentioned "the GC should not have to update any OOP in callee-saved registers except arguments". However, the location of ebp is always updated explicitly in frame traversal for the sake of GC(see function update_map_with_saved_link). 3. As SAP JVM is a server VM, all I mentioned is only about the server edition. I noticed there's difference between C1 and C2 in the context(see function sender_for_interpreter_frame). It may add extra difficulty to your review :( Thanks, Yang -----Original Message----- From: yang02.wang at sap.com Sent: Mittwoch, 14. Dezember 2011 18:55 To: 'Bertrand Delsart' Cc: hotspot-compiler-dev at openjdk.java.net Subject: RE: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter Hello again, Well, I think I am still not clear enough about the term "callee-save". From Java ABI's perspective, there is no callee-saved registers; but from C ABI's perspective, ebp is callee-saved, and it is causing problem : it saves and restores it without interacting with GC. And I don't understand why you say " For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" when at a method call site". Actually I saw "ebp" in OopMap in a call site with "PrintAssembly". Thanks, Yang -----Original Message----- From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] Sent: Mittwoch, 14. Dezember 2011 17:50 To: Wang, Yang Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net Subject: Re: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter Sorry, I just realized that x86 was not using the same stub. I got caught up in the confusion created by the comments and did not notice the difference between the call to Interpreter::throw_StackOverflowError_entry() and the call to SharedRuntime::throw_StackOverflowError_entry() The real reason for the failure seems to be that x86 was calling something that assumes the active frame is interpreted (see generate_StackOverflowError_handler). If this is called with a compiled frame context (after a c2i), this could indeed lead to issues that I need to investigate further. I know understand better the reasons for your fix and will see whether this is indeed calling the right stub and whether I could generate it earlier to avoid delaying the load. Thanks, Bertrand. On 12/14/11 05:14 PM, Bertrand Delsart wrote: > Hi Yang, > > Answers inlined. > > On 12/14/11 03:26 PM, Wang, Yang wrote: >> 1. For the stub concern, it is true that there is an existing stub, >> but it is only invoked via implicit exception handler(see function >> continuation_for_implicit_exception). For explicit stack overflow >> check in "interpreter", the stub is in hotspot not used previously. So >> the fix is to borrow it. Since the stub is generated after the >> code-generation for interpreter, the entry address was load indirectly. > > The stub was used on x86 in the call you modified :-) In addition, some > stubs are generated before the interpreter. That's why I asked whether > you had really noticed an issue (e.g. whether the code generated a jump > to a NULL address on x86). > > Anyway, I'll double check when the stub is generated and, if necessary, > see whether we can initialize it earlier instead of deferring the load. > >> 2. Going through the stub is like a guard for the VM call, as shown in >> the picture in webrev: stub frame on top of C frame. When GC fails to >> handle the OOP in C frame, the stub frame remedies it by containing a >> copy of the OOP, which is to be handled by GC. > > Understood. The problem is not really about whether we need a stub (I'm > still reviewing that for sparc). The problem is about the reasons > stated. I'm trying to remove the comments that might be confusing. > > For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" > when at a method call site (elsewhere, it can indeed be an oop that > needs to be updated). See point 3. From a jited code point of view, > there is no callee-saved registers in our compiled Java ABI for x86. > > I'm currently reviewing the Sparc part because it is indeed a special > case... and the one that was unfortunately not using the stub :-( > >> 3. For the concern of callee-saved register, I guess you mean Sparc >> only. You are right that the IN and Local registers are not called >> "callee-saved" technically(but "never-saved"). However, they are also >> saved by callee in callee's frame in certain cases(like register >> window overflow). I hope my understanding here is correct. > > No. That was not sparc only. In fact Sparc might be the exception. > > If you look for instance at the definition of is_caller_save_register() > in c1_FrameMap_x86.hpp, you'll see that HotSpot now assumes that all > registers can be scratched by called Java methods. We measured that > performance were better when not using callee saved registers (for > compiled Java code). > > Sparc is a special case because the IN and Local registers are > automatically protected. This is the only platform which provides > callee-saved registers "for free" when building frames (thanks to the > register windows). Hence, I thought that our JIT compilers were no > longer using callee-saved registers on any of the supported platforms > but Sparc might indeed be the exception. > >> >> Thanks and welcome more inputs! >> Yang >> >> >> >> -----Original Message----- >> From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] >> Sent: Mittwoch, 14. Dezember 2011 13:36 >> To: Wang, Yang >> Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net; Coleen >> Phillimore >> Subject: Re: Request for Review(S): JVM crashes when throwing >> StackOverflow exception from interpreter >> >> Sorry, >> >> I was notified of the CR and got involved in the bug because we were >> wondering whether the bug was impacting our embedded ports. I sent my >> own review in an internal alias but should have let you know. FYI, we >> were still discussing it because I raised some issues about the proposed >> fix. >> >> First, thanks for spotting the bug! We do agree with the first problem. >> We should indeed ensure that SP is correct. >> >> My concerns were about the second part. >> >> First, the change is doing more that just going through the stub. It >> seems that your are trying to solve a third problem. x86 was already >> using the throw_StackOverflowError_entry stub. What your proposed change >> seems to imply is that you encountered a case where the stub had not yet >> been generated and hence you had to delay the loading of its address. Is >> that correct ? >> >> In addition, the explanations about why we have to go through that stub >> did not fit my knowledge of HotSpot and I was trying to clarify that >> internally (thanks Tom for your confirmations). >> >> With our Java ABI, none of the registers allocated by the compiler are >> callee-saved. Hence, at call sites, the GC should not have to update any >> OOP in callee-saved registers (but might have to update arguments). If >> fixing SP is not sufficient to solve your test case on SPARC then the >> problem is not exactly what you describe. >> >> Now, that does not mean the fix would not be correct :-) Going through >> that stub might be safer anyway, particularly since we are doing it on >> x86. My issues are about the comments themselves (and the third problem >> mentioned above). >> >> Thanks, >> >> Bertrand. >> >> On 12/13/11 09:19 PM, Christian Thalinger wrote: >>> >>> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: >>> >>>> There's now a bug report for this issue: >>>> >>>> 7116216: StackOverflow GC crash >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >>>> >>>> so could somebody please have a look at the fix proposed by Yang? >>> >>> Sorry, I will have a look tomorrow. >>> >>> -- Chris >>> >>>> >>>> Regards, >>>> Volker >>>> >>>> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>>>> Hi folks, >>>>> >>>>> We found two problems during throwing an StackOverflow exception from >>>>> interpreter. >>>>> >>>>> 1. Before preparing to throw a StackOverflow exception, the last Java >>>>> frame is set to the current sp. This is problematic when the >>>>> StackOverflow >>>>> is thrown on top of c2i adapter. Solution : the real caller >>>>> frame(unextended >>>>> sp) should be set as last Java frame. >>>>> >>>>> 2. When Garbage collection happens during throwing StackOverflow >>>>> exception, and callee-saved register(or "never-saved" register >>>>> which behaves >>>>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>>>> frame(generated by VM calls), and hence fails to process the OOP. >>>>> Solution : >>>>> We build a runtime stub frame before doing a VM call, which >>>>> guarantees the >>>>> location of Callee-saved registers are always recognizable by GC. >>>>> >>>>> Detailed descriptions and tests could be found in webrev >>>>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>>>> >>>>> I don't have a bugID yet. Please kindly open one bug for this issue. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yang >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Yang Wang >>>>> Software Engineer >>>>> >>>>> TIP Core AS&VM Technology (AG) >>>>> SAP JVM JIT Compiler >>>>> >>>>> SAP AG >>>>> Dietmar-Hopp-Allee 16 >>>>> 69190 Walldorf, Germany >>>>> >>>>> T +49 6227 7-50320 >>>>> F +49 6227 78-48541 >>>>> Email : yang02.wang at sap.com >>>>> www.sap.com >>>>> >>>>> >>>>> Pflichtangaben/Mandatory Disclosure Statements: >>>>> http://www.sap.com/company/legal/impressum.epx >>>>> >>>>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail >>>>> irrt?mlich >>>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>>>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. >>>>> Bitte >>>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. >>>>> Vielen >>>>> Dank. >>>>> >>>>> This e-mail may contain trade secrets or privileged, undisclosed, or >>>>> otherwise confidential information. If you have received this >>>>> e-mail in >>>>> error, you are hereby notified that any review, copying, or >>>>> distribution of >>>>> it is strictly prohibited. Please inform us immediately and destroy >>>>> the >>>>> original transmittal. Thank you for your cooperation. >>>>> >>>>> >>> >> >> > > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Thu Dec 15 03:19:36 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 15 Dec 2011 11:19:36 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7116452: Add support for AVX instructions Message-ID: <20111215111942.A08A4476D0@hg.openjdk.java.net> Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp From bertrand.delsart at oracle.com Thu Dec 15 05:56:24 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 15 Dec 2011 14:56:24 +0100 Subject: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: References: <573DC172-AD0D-41AD-B7BB-9B57D8823919@oracle.com> <4EE89835.3070604@oracle.com> <4EE8CB73.7090800@oracle.com> <4EE8D3A2.6010700@oracle.com> Message-ID: <4EE9FC88.304@oracle.com> Hi Yang, I'm currently testing a modified version of the fix and I will go through the shared runtime stubs anyway, if not exactly for the reasons that were stated in the comments :-) Hence, these following answers are just for information, to try to clarify any remaining confusion. FYI, your fix was correct from a coding point of view. The only difference in what I'm currently testing is that I'm avoiding the delayed loading by moving the generation of the stub to StubGenerator::generate_initial. I'll generate the updated webrev once my testing is complete. As for the comments, they now seem correct in a C2 context... but got us confused because the problem is more general. It was failing on a platform which did not modify SP and which did not use callee-saved register :-) The problem is indeed that we had not considered that the caller might not be an interpreted frame. The issues with calling the interpreter version of the throw instead of the shared runtime one are more than just a problem of missing stub and callee-saved registers. Note that we were still discussing it internally when we were pinged by Volker and I opened up the discussion. I am indeed more familiar with C1 and I was still trying to get some confirmation for C2 (this is the only only part of the JVM I've not yet been seriously involved with). The status of ebp/rbp was not yet clear in the answers I got. I knew it was saved/restored but, from the answers I got and the fact that it is used in a special way for JSR292, I thought it was no longer really 'trusted' as an allocable callee-saved registers. I was going to double-check the AD file but I'll trust you if you saw EBP in a call site oopmap. Thanks for double-checking. Seems that C1 is not smart enough to trust EBP's restored value but that C2 is much smarter :-) I'll let C2 experts chime in if they think this needs further clarification. Thanks again for spotting the bug, providing a test case and suggesting a solution. In fact, one of our platforms was doing the right thing (including generating the stub in generate_initial) but we had not noticed the discrepancy :-( Bertrand. On 12/15/11 11:46 AM, Wang, Yang wrote: > Hi Bertrand, > I don't want to insert comments on the long text, so here are some points I would like to clarify: > 1. I understand, hotspot does not use callee-saved register in compiled java code for performance reasons. However, ebp is an exception. It is pushed in the beginning of a function(Prolog), and poped in the end(Epilog). So I don't see any difference to the callee-save concept. If there's any difference(maybe from register allocator's perspective?), could you help clarify? > > 2. You mentioned "the GC should not have to update any OOP in callee-saved registers except arguments". However, the location of ebp is always updated explicitly in frame traversal for the sake of GC(see function update_map_with_saved_link). > > 3. As SAP JVM is a server VM, all I mentioned is only about the server edition. I noticed there's difference between C1 and C2 in the context(see function sender_for_interpreter_frame). It may add extra difficulty to your review :( > > Thanks, > Yang > > -----Original Message----- > From: yang02.wang at sap.com > Sent: Mittwoch, 14. Dezember 2011 18:55 > To: 'Bertrand Delsart' > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: RE: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter > > Hello again, > Well, I think I am still not clear enough about the term "callee-save". From Java ABI's perspective, there is no callee-saved registers; but from C ABI's perspective, ebp is callee-saved, and it is causing problem : it saves and restores it without interacting with GC. > > And I don't understand why you say " For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" when at a method call site". Actually I saw "ebp" in OopMap in a call site with "PrintAssembly". > > Thanks, > Yang > -----Original Message----- > From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] > Sent: Mittwoch, 14. Dezember 2011 17:50 > To: Wang, Yang > Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net > Subject: Re: Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter > > Sorry, > > I just realized that x86 was not using the same stub. > > I got caught up in the confusion created by the comments and did not > notice the difference between the call to > Interpreter::throw_StackOverflowError_entry() and the call to > SharedRuntime::throw_StackOverflowError_entry() > > The real reason for the failure seems to be that x86 was calling > something that assumes the active frame is interpreted (see > generate_StackOverflowError_handler). If this is called with a compiled > frame context (after a c2i), this could indeed lead to issues that I > need to investigate further. > > I know understand better the reasons for your fix and will see whether > this is indeed calling the right stub and whether I could generate it > earlier to avoid delaying the load. > > Thanks, > > Bertrand. > > On 12/14/11 05:14 PM, Bertrand Delsart wrote: >> Hi Yang, >> >> Answers inlined. >> >> On 12/14/11 03:26 PM, Wang, Yang wrote: >>> 1. For the stub concern, it is true that there is an existing stub, >>> but it is only invoked via implicit exception handler(see function >>> continuation_for_implicit_exception). For explicit stack overflow >>> check in "interpreter", the stub is in hotspot not used previously. So >>> the fix is to borrow it. Since the stub is generated after the >>> code-generation for interpreter, the entry address was load indirectly. >> >> The stub was used on x86 in the call you modified :-) In addition, some >> stubs are generated before the interpreter. That's why I asked whether >> you had really noticed an issue (e.g. whether the code generated a jump >> to a NULL address on x86). >> >> Anyway, I'll double check when the stub is generated and, if necessary, >> see whether we can initialize it earlier instead of deferring the load. >> >>> 2. Going through the stub is like a guard for the VM call, as shown in >>> the picture in webrev: stub frame on top of C frame. When GC fails to >>> handle the OOP in C frame, the stub frame remedies it by containing a >>> copy of the OOP, which is to be handled by GC. >> >> Understood. The problem is not really about whether we need a stub (I'm >> still reviewing that for sparc). The problem is about the reasons >> stated. I'm trying to remove the comments that might be confusing. >> >> For instance, on x86, "ebp" cannot be an "oop that expects to be GCed" >> when at a method call site (elsewhere, it can indeed be an oop that >> needs to be updated). See point 3. From a jited code point of view, >> there is no callee-saved registers in our compiled Java ABI for x86. >> >> I'm currently reviewing the Sparc part because it is indeed a special >> case... and the one that was unfortunately not using the stub :-( >> >>> 3. For the concern of callee-saved register, I guess you mean Sparc >>> only. You are right that the IN and Local registers are not called >>> "callee-saved" technically(but "never-saved"). However, they are also >>> saved by callee in callee's frame in certain cases(like register >>> window overflow). I hope my understanding here is correct. >> >> No. That was not sparc only. In fact Sparc might be the exception. >> >> If you look for instance at the definition of is_caller_save_register() >> in c1_FrameMap_x86.hpp, you'll see that HotSpot now assumes that all >> registers can be scratched by called Java methods. We measured that >> performance were better when not using callee saved registers (for >> compiled Java code). >> >> Sparc is a special case because the IN and Local registers are >> automatically protected. This is the only platform which provides >> callee-saved registers "for free" when building frames (thanks to the >> register windows). Hence, I thought that our JIT compilers were no >> longer using callee-saved registers on any of the supported platforms >> but Sparc might indeed be the exception. >> >>> >>> Thanks and welcome more inputs! >>> Yang >>> >>> >>> >>> -----Original Message----- >>> From: Bertrand Delsart [mailto:bertrand.delsart at oracle.com] >>> Sent: Mittwoch, 14. Dezember 2011 13:36 >>> To: Wang, Yang >>> Cc: Volker Simonis; hotspot-compiler-dev at openjdk.java.net; Coleen >>> Phillimore >>> Subject: Re: Request for Review(S): JVM crashes when throwing >>> StackOverflow exception from interpreter >>> >>> Sorry, >>> >>> I was notified of the CR and got involved in the bug because we were >>> wondering whether the bug was impacting our embedded ports. I sent my >>> own review in an internal alias but should have let you know. FYI, we >>> were still discussing it because I raised some issues about the proposed >>> fix. >>> >>> First, thanks for spotting the bug! We do agree with the first problem. >>> We should indeed ensure that SP is correct. >>> >>> My concerns were about the second part. >>> >>> First, the change is doing more that just going through the stub. It >>> seems that your are trying to solve a third problem. x86 was already >>> using the throw_StackOverflowError_entry stub. What your proposed change >>> seems to imply is that you encountered a case where the stub had not yet >>> been generated and hence you had to delay the loading of its address. Is >>> that correct ? >>> >>> In addition, the explanations about why we have to go through that stub >>> did not fit my knowledge of HotSpot and I was trying to clarify that >>> internally (thanks Tom for your confirmations). >>> >>> With our Java ABI, none of the registers allocated by the compiler are >>> callee-saved. Hence, at call sites, the GC should not have to update any >>> OOP in callee-saved registers (but might have to update arguments). If >>> fixing SP is not sufficient to solve your test case on SPARC then the >>> problem is not exactly what you describe. >>> >>> Now, that does not mean the fix would not be correct :-) Going through >>> that stub might be safer anyway, particularly since we are doing it on >>> x86. My issues are about the comments themselves (and the third problem >>> mentioned above). >>> >>> Thanks, >>> >>> Bertrand. >>> >>> On 12/13/11 09:19 PM, Christian Thalinger wrote: >>>> >>>> On Dec 7, 2011, at 10:45 AM, Volker Simonis wrote: >>>> >>>>> There's now a bug report for this issue: >>>>> >>>>> 7116216: StackOverflow GC crash >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116216 >>>>> >>>>> so could somebody please have a look at the fix proposed by Yang? >>>> >>>> Sorry, I will have a look tomorrow. >>>> >>>> -- Chris >>>> >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> On Wed, Nov 16, 2011 at 6:04 PM, Wang, Yang wrote: >>>>>> Hi folks, >>>>>> >>>>>> We found two problems during throwing an StackOverflow exception from >>>>>> interpreter. >>>>>> >>>>>> 1. Before preparing to throw a StackOverflow exception, the last Java >>>>>> frame is set to the current sp. This is problematic when the >>>>>> StackOverflow >>>>>> is thrown on top of c2i adapter. Solution : the real caller >>>>>> frame(unextended >>>>>> sp) should be set as last Java frame. >>>>>> >>>>>> 2. When Garbage collection happens during throwing StackOverflow >>>>>> exception, and callee-saved register(or "never-saved" register >>>>>> which behaves >>>>>> alike) happens to be an OOP, GC is unable to locate the OOP in C >>>>>> frame(generated by VM calls), and hence fails to process the OOP. >>>>>> Solution : >>>>>> We build a runtime stub frame before doing a VM call, which >>>>>> guarantees the >>>>>> location of Callee-saved registers are always recognizable by GC. >>>>>> >>>>>> Detailed descriptions and tests could be found in webrev >>>>>> http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ >>>>>> >>>>>> I don't have a bugID yet. Please kindly open one bug for this issue. >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yang >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Yang Wang >>>>>> Software Engineer >>>>>> >>>>>> TIP Core AS&VM Technology (AG) >>>>>> SAP JVM JIT Compiler >>>>>> >>>>>> SAP AG >>>>>> Dietmar-Hopp-Allee 16 >>>>>> 69190 Walldorf, Germany >>>>>> >>>>>> T +49 6227 7-50320 >>>>>> F +49 6227 78-48541 >>>>>> Email : yang02.wang at sap.com >>>>>> www.sap.com >>>>>> >>>>>> >>>>>> Pflichtangaben/Mandatory Disclosure Statements: >>>>>> http://www.sap.com/company/legal/impressum.epx >>>>>> >>>>>> Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige >>>>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail >>>>>> irrt?mlich >>>>>> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine >>>>>> Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. >>>>>> Bitte >>>>>> benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. >>>>>> Vielen >>>>>> Dank. >>>>>> >>>>>> This e-mail may contain trade secrets or privileged, undisclosed, or >>>>>> otherwise confidential information. If you have received this >>>>>> e-mail in >>>>>> error, you are hereby notified that any review, copying, or >>>>>> distribution of >>>>>> it is strictly prohibited. Please inform us immediately and destroy >>>>>> the >>>>>> original transmittal. Thank you for your cooperation. >>>>>> >>>>>> >>>> >>> >>> >> >> > > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From roland.westrelin at oracle.com Thu Dec 15 06:45:44 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 15 Dec 2011 15:45:44 +0100 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> Message-ID: <42EDE902-3FD3-4C90-BBA5-9408451822CD@oracle.com> > I wouldn't expect this to affect performance since it's not emitting an extra instructions but we are emitting some extra barriers which tangles of the memory graph a bit. Could you do some quick performance to make sure nothing's changed? Below are the results. Roland. ============================================================================ tt1 Benchmark Samples Mean Stdev specjbb2005 10 196409.50 0.01 peak 10 219067.61 0.02 peak_warehouse 10 4.00 0.00 last 10 196409.49 0.01 interval_average 10 11553.50 0.01 first 10 35924.81 0.01 overall_average 10 167704.10 0.01 last_warehouse 10 8.00 0.00 ============================================================================ tt2 Benchmark Samples Mean Stdev %Diff P Significant specjbb2005 10 196016.36 0.01 -0.20 0.737 * peak 10 216797.36 0.02 -1.04 0.262 * peak_warehouse 10 4.00 0.00 -0.00 0.000 * last 10 196016.35 0.01 -0.20 0.737 * interval_average 10 11530.40 0.01 -0.20 0.737 * first 10 35558.66 0.00 -1.02 0.000 Yes overall_average 10 167822.07 0.01 0.07 0.852 * last_warehouse 10 8.00 0.00 -0.00 0.000 * ============================================================================ ============================================================================ t1 Benchmark Samples Mean Stdev specjvm98 10 667.76 0.00 javac 10 392.03 0.01 db 10 438.88 0.00 jess 10 700.73 0.00 jack 10 594.09 0.01 compress 10 536.31 0.00 mtrt 10 1808.20 0.02 mpegaudio 10 852.60 0.01 ============================================================================ t2 Benchmark Samples Mean Stdev %Diff P Significant specjvm98 10 666.48 0.00 -0.19 0.183 * javac 10 391.46 0.01 -0.15 0.827 * db 10 439.52 0.00 0.15 0.501 * jess 10 701.00 0.01 0.04 0.870 * jack 10 589.77 0.00 -0.73 0.006 Yes compress 10 537.17 0.01 0.16 0.534 * mtrt 10 1788.32 0.02 -1.10 0.229 * mpegaudio 10 855.14 0.01 0.30 0.468 * ============================================================================ From roland.westrelin at oracle.com Thu Dec 15 06:52:37 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 15 Dec 2011 15:52:37 +0100 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites Message-ID: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> http://cr.openjdk.java.net/~roland/7121756/webrev.00/ Implements profile based inlining in C1. Execution of a method starts interpreted as usual. A method transitions from interpreted to compiled in the usual way as well. When the method is compiled, the compiler identifies a number of call sites that are candidates for profiling and further inlining. At those call sites, the method is compiled so that a per call site counter is incremented and tested for overflow when the call site is used. On first call site resolution, a timestamp is also recorded. The count and timestamp are used to compute a frequency. A frequency higher than a high water mark detects a hot call site. A hot call site triggers a recompilation of the caller method in which the callee is inlined. A frequency higher than a low water mark detects a warm call site. Otherwise the call site is cold. Recompiling with the extra inlining won't bring a performance advantage for a warm or cold call site. But keeping the profiling on at a warm call site is detrimental so it is dropped. At a cold call site profiling can be kept enabled to trigger later recompilation if the call site becomes hot. To perform profiling, the compiler identifies the candidate call sites and generates a stub similar to the static call stub in the nmethod's stub area. The profile call stub performs the following step: 1- load mdo pointer in register 2- increment counter for call site 3- branch to runtime if counter crosses threshold 4- jump to callee On call site resolution, for a call to a compiled method, the jump (4- above) is patched with the resolved call site info (to continue to callee's code or transition stub) then the call site is patched to point to the profile call stub. Profiling can be later fully disabled for the call site (if the call site is polymorphic or if the compilation policy finds it's better to not profile the call site anymore) by reresolving the call. The compiler also uses profile data to inline a frequent virtual method if profile data suggests a single receiver class. State changes of inline caches associated with call sites (performed in the runtime) are used to collect receiver class data. Correctness during execution is enforced with a compiled guard and a deoptimization can be triggered. From rednaxelafx at gmail.com Thu Dec 15 07:28:42 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 15 Dec 2011 23:28:42 +0800 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: Hi Roland, Interesting. Now C1's getting more of the heavier gears :-) A few things I'd like to ask: 1. How does this change interact with tiered mode? I see that in a tiered build, C1ProfileInlining is set to false in arguments.cpp. So this set of changes is only meant for a Client VM, right? 2. Is this change mainly targeted at embedded builds? In a desktop/server scenario, I had a feeling that the Client VM was going away, replaced by a unified tiered VM in the future. Hence the question. 3. Are there any plans to do a late-inlining phase for C1? I tried to make C1 able to inline at more callsites by adding Phi::exact_type(), but failed [1]. The main reason for failing is that before the whole HIR graph is built, the CFG isn't stable yet, and quering Phi::exact_type() during graph building just won't work. But if there's more compilation budget to spend, say we're in a hot method, an optional inlining phase after the HIR graph is built might be profitable. I'd like to see more comments on this point. Regards, Kris Mok [1]: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-August/006049.html On Thu, Dec 15, 2011 at 10:52 PM, Roland Westrelin < roland.westrelin at oracle.com> wrote: > http://cr.openjdk.java.net/~roland/7121756/webrev.00/ > > Implements profile based inlining in C1. > > Execution of a method starts interpreted as usual. A method transitions > from interpreted to compiled in the usual way as well. When the method is > compiled, the compiler identifies a number of call sites that are > candidates for profiling and further inlining. At those call sites, the > method is compiled so that a per call site counter is incremented and > tested for overflow when the call site is used. On first call site > resolution, a timestamp is also recorded. The count and timestamp are used > to compute a frequency. A frequency higher than a high water mark detects a > hot call site. A hot call site triggers a recompilation of the caller > method in which the callee is inlined. A frequency higher than a low water > mark detects a warm call site. Otherwise the call site is cold. Recompiling > with the extra inlining won't bring a performance advantage for a warm or > cold call site. But keeping the profiling on at a warm call site is > detrimental so it is dropped. At a cold call site profiling can be kept > enabled to trigger later recompilation if the call site becomes hot. > > To perform profiling, the compiler identifies the candidate call sites and > generates a stub similar to the static call stub in the nmethod's stub > area. The profile call stub performs the following step: > 1- load mdo pointer in register > 2- increment counter for call site > 3- branch to runtime if counter crosses threshold > 4- jump to callee > > On call site resolution, for a call to a compiled method, the jump (4- > above) is patched with the resolved call site info (to continue to callee's > code or transition stub) then the call site is patched to point to the > profile call stub. Profiling can be later fully disabled for the call site > (if the call site is polymorphic or if the compilation policy finds it's > better to not profile the call site anymore) by reresolving the call. > > The compiler also uses profile data to inline a frequent virtual method if > profile data suggests a single receiver class. State changes of inline > caches associated with call sites (performed in the runtime) are used to > collect receiver class data. Correctness during execution is enforced with > a compiled guard and a deoptimization can be triggered. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111215/65f4a3b8/attachment.html From roland.westrelin at oracle.com Thu Dec 15 07:32:39 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 15 Dec 2011 16:32:39 +0100 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: <015420FB-7B48-4979-93FE-E9F61002AE97@oracle.com> Hi Kris, > 1. How does this change interact with tiered mode? > I see that in a tiered build, C1ProfileInlining is set to false in arguments.cpp. So this set of changes is only meant for a Client VM, right? Yes, it's client only. > 2. Is this change mainly targeted at embedded builds? > In a desktop/server scenario, I had a feeling that the Client VM was going away, replaced by a unified tiered VM in the future. Hence the question. Yes, it's mostly for embedded builds. > 3. Are there any plans to do a late-inlining phase for C1? I don't think there is a plan for anything like that. Roland. From vladimir.kozlov at oracle.com Thu Dec 15 10:36:25 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Dec 2011 10:36:25 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX Message-ID: <4EEA3E29.3000400@oracle.com> http://cr.openjdk.java.net/~kvn/7121648/webrev 7121648: Use 3-operands SIMD instructions on x86 with AVX VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. There is slight improvement in performance on AVX machine (full result in bug report): Benchmark Samples Mean Stdev %Diff P Significant scimark_small 20 1031.87 4.68 2.85 0.000 Yes LU 20 1966.82 21.36 6.18 0.000 Yes FFT 20 658.28 10.33 4.91 0.000 Yes Monte 20 545.31 2.93 -0.37 0.179 * SOR 20 994.96 0.67 -0.00 0.910 * Sparse 20 993.99 1.49 -0.02 0.629 * Thanks, Vladimir From tom.rodriguez at oracle.com Thu Dec 15 11:34:56 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 11:34:56 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX In-Reply-To: <4EEA3E29.3000400@oracle.com> References: <4EEA3E29.3000400@oracle.com> Message-ID: On Dec 15, 2011, at 10:36 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7121648/webrev > > 7121648: Use 3-operands SIMD instructions on x86 with AVX adlc.make: Can you use $(Platform_arch) instead of $(ARCH)? I know it's the same but names are more obviously parallel. > > VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: > > vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] > > I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. Instead of duplicating regX and regXD why not just rename regX and refXD to regF and regD and come up with a new name for the FPU regs. Maybe regFPRF and regFPRD? Also can you correct the formatting in the new file to have the %{ on the same line? And remove the // XXX's after the ins_cost. Otherwise it looks fine. tom > > There is slight improvement in performance on AVX machine (full result in bug report): > > Benchmark Samples Mean Stdev %Diff P Significant > scimark_small 20 1031.87 4.68 2.85 0.000 Yes > LU 20 1966.82 21.36 6.18 0.000 Yes > FFT 20 658.28 10.33 4.91 0.000 Yes > Monte 20 545.31 2.93 -0.37 0.179 * > SOR 20 994.96 0.67 -0.00 0.910 * > Sparse 20 993.99 1.49 -0.02 0.629 * > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Dec 15 11:42:47 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Dec 2011 11:42:47 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX In-Reply-To: References: <4EEA3E29.3000400@oracle.com> Message-ID: <4EEA4DB7.2090502@oracle.com> Thank you, Tom Tom Rodriguez wrote: > On Dec 15, 2011, at 10:36 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7121648/webrev >> >> 7121648: Use 3-operands SIMD instructions on x86 with AVX > > adlc.make: > > Can you use $(Platform_arch) instead of $(ARCH)? I know it's the same but names are more obviously parallel. Done. > >> VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: >> >> vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] >> >> I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. > > Instead of duplicating regX and regXD why not just rename regX and refXD to regF and regD and come up with a new name for the FPU regs. Maybe regFPRF and regFPRD? I am fine with renaming FPU registers to regFPRF and regFPRD but it will be a lot places in x86_32.ad. If you fine with it I will do renaming. > Also can you correct the formatting in the new file to have the %{ on the same line? And remove the // XXX's after the ins_cost. Done. > > Otherwise it looks fine. Thanks, Vladimir > > tom > >> There is slight improvement in performance on AVX machine (full result in bug report): >> >> Benchmark Samples Mean Stdev %Diff P Significant >> scimark_small 20 1031.87 4.68 2.85 0.000 Yes >> LU 20 1966.82 21.36 6.18 0.000 Yes >> FFT 20 658.28 10.33 4.91 0.000 Yes >> Monte 20 545.31 2.93 -0.37 0.179 * >> SOR 20 994.96 0.67 -0.00 0.910 * >> Sparse 20 993.99 1.49 -0.02 0.629 * >> >> Thanks, >> Vladimir > From tom.rodriguez at oracle.com Thu Dec 15 11:54:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 11:54:03 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX In-Reply-To: <4EEA4DB7.2090502@oracle.com> References: <4EEA3E29.3000400@oracle.com> <4EEA4DB7.2090502@oracle.com> Message-ID: <7C709738-806E-40DA-9A5A-F19D6A6D5F6F@oracle.com> On Dec 15, 2011, at 11:42 AM, Vladimir Kozlov wrote: > Thank you, Tom > > Tom Rodriguez wrote: >> On Dec 15, 2011, at 10:36 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7121648/webrev >>> >>> 7121648: Use 3-operands SIMD instructions on x86 with AVX >> adlc.make: >> Can you use $(Platform_arch) instead of $(ARCH)? I know it's the same but names are more obviously parallel. > > Done. > >>> VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: >>> >>> vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] >>> >>> I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. >> Instead of duplicating regX and regXD why not just rename regX and refXD to regF and regD and come up with a new name for the FPU regs. Maybe regFPRF and regFPRD? > > I am fine with renaming FPU registers to regFPRF and regFPRD but it will be a lot places in x86_32.ad. If you fine with it I will do renaming. I just think if we're going to start down this path I want to make it more consistent instead of papering over the difference. So I'm ok with the changes since for the most part it will be pure text replacement. You'll probably need to rename things like immXF and immF to be consistent. tom > >> Also can you correct the formatting in the new file to have the %{ on the same line? And remove the // XXX's after the ins_cost. > > Done. > >> Otherwise it looks fine. > > Thanks, > Vladimir > >> tom >>> There is slight improvement in performance on AVX machine (full result in bug report): >>> >>> Benchmark Samples Mean Stdev %Diff P Significant >>> scimark_small 20 1031.87 4.68 2.85 0.000 Yes >>> LU 20 1966.82 21.36 6.18 0.000 Yes >>> FFT 20 658.28 10.33 4.91 0.000 Yes >>> Monte 20 545.31 2.93 -0.37 0.179 * >>> SOR 20 994.96 0.67 -0.00 0.910 * >>> Sparse 20 993.99 1.49 -0.02 0.629 * >>> >>> Thanks, >>> Vladimir From tom.rodriguez at oracle.com Thu Dec 15 12:04:29 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 12:04:29 -0800 Subject: review for 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Message-ID: http://cr.openjdk.java.net/~never/7121073 7 lines changed: 2 ins; 0 del; 5 mod; 3239 unchg 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: To ensure that memory operations for type checks are properly ordered, several fields are smeared together into the same alias slice. The existing logic is sloppy and includes a slightly larger chunk of memory than intended. Currently this is fine but changes to the shape of Klass can invalidate it. The fix is to properly test the boundaries. Additionally I changed the logic for setting the PTR to use NotNull instead of Constant to be consisten with all the following logic which uses NotNull. Tested with full CTW. From tom.rodriguez at oracle.com Thu Dec 15 12:34:10 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 12:34:10 -0800 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: <42EDE902-3FD3-4C90-BBA5-9408451822CD@oracle.com> References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> <42EDE902-3FD3-4C90-BBA5-9408451822CD@oracle.com> Message-ID: <4FA71ECC-003E-4E5B-92C9-B4767DE24374@oracle.com> On Dec 15, 2011, at 6:45 AM, Roland Westrelin wrote: >> I wouldn't expect this to affect performance since it's not emitting an extra instructions but we are emitting some extra barriers which tangles of the memory graph a bit. Could you do some quick performance to make sure nothing's changed? > > Below are the results. Could you do a longer set of specjvm98 to confirm the jess difference? Looking at the data, I don't really think it's real but another, longer set of runs should tell us that. Try 20. tom > > Roland. > > ============================================================================ > tt1 > Benchmark Samples Mean Stdev > specjbb2005 10 196409.50 0.01 > peak 10 219067.61 0.02 > peak_warehouse 10 4.00 0.00 > last 10 196409.49 0.01 > interval_average 10 11553.50 0.01 > first 10 35924.81 0.01 > overall_average 10 167704.10 0.01 > last_warehouse 10 8.00 0.00 > ============================================================================ > tt2 > Benchmark Samples Mean Stdev %Diff P Significant > specjbb2005 10 196016.36 0.01 -0.20 0.737 * > peak 10 216797.36 0.02 -1.04 0.262 * > peak_warehouse 10 4.00 0.00 -0.00 0.000 * > last 10 196016.35 0.01 -0.20 0.737 * > interval_average 10 11530.40 0.01 -0.20 0.737 * > first 10 35558.66 0.00 -1.02 0.000 Yes > overall_average 10 167822.07 0.01 0.07 0.852 * > last_warehouse 10 8.00 0.00 -0.00 0.000 * > ============================================================================ > > ============================================================================ > t1 > Benchmark Samples Mean Stdev > specjvm98 10 667.76 0.00 > javac 10 392.03 0.01 > db 10 438.88 0.00 > jess 10 700.73 0.00 > jack 10 594.09 0.01 > compress 10 536.31 0.00 > mtrt 10 1808.20 0.02 > mpegaudio 10 852.60 0.01 > ============================================================================ > t2 > Benchmark Samples Mean Stdev %Diff P Significant > specjvm98 10 666.48 0.00 -0.19 0.183 * > javac 10 391.46 0.01 -0.15 0.827 * > db 10 439.52 0.00 0.15 0.501 * > jess 10 701.00 0.01 0.04 0.870 * > jack 10 589.77 0.00 -0.73 0.006 Yes > compress 10 537.17 0.01 0.16 0.534 * > mtrt 10 1788.32 0.02 -1.10 0.229 * > mpegaudio 10 855.14 0.01 0.30 0.468 * > ============================================================================ > From vladimir.kozlov at oracle.com Thu Dec 15 12:44:32 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Dec 2011 12:44:32 -0800 Subject: review for 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type In-Reply-To: References: Message-ID: <4EEA5C30.503@oracle.com> Tom, Can you updated related comments? Otherwise looks good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7121073 > 7 lines changed: 2 ins; 0 del; 5 mod; 3239 unchg > > 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type > Reviewed-by: > > To ensure that memory operations for type checks are properly ordered, > several fields are smeared together into the same alias slice. The > existing logic is sloppy and includes a slightly larger chunk of > memory than intended. Currently this is fine but changes to the shape > of Klass can invalidate it. The fix is to properly test the > boundaries. Additionally I changed the logic for setting the PTR to > use NotNull instead of Constant to be consisten with all the following > logic which uses NotNull. Tested with full CTW. > From tom.rodriguez at oracle.com Thu Dec 15 13:01:14 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 13:01:14 -0800 Subject: review for 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type In-Reply-To: <4EEA5C30.503@oracle.com> References: <4EEA5C30.503@oracle.com> Message-ID: <794DE48E-0323-43A8-91C5-D799E6E51D98@oracle.com> On Dec 15, 2011, at 12:44 PM, Vladimir Kozlov wrote: > Tom, > > Can you updated related comments? Otherwise looks good. How about this: // If we are referencing a field within a Klass, we need // to assume the worst case of an Object. Both exact and // inexact types must flatten to the same alias class so // use NotNull as the PTR. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7121073 >> 7 lines changed: 2 ins; 0 del; 5 mod; 3239 unchg >> 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type >> Reviewed-by: >> To ensure that memory operations for type checks are properly ordered, >> several fields are smeared together into the same alias slice. The >> existing logic is sloppy and includes a slightly larger chunk of >> memory than intended. Currently this is fine but changes to the shape >> of Klass can invalidate it. The fix is to properly test the >> boundaries. Additionally I changed the logic for setting the PTR to >> use NotNull instead of Constant to be consisten with all the following >> logic which uses NotNull. Tested with full CTW. From vladimir.kozlov at oracle.com Thu Dec 15 12:57:10 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Dec 2011 12:57:10 -0800 Subject: review for 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type In-Reply-To: <794DE48E-0323-43A8-91C5-D799E6E51D98@oracle.com> References: <4EEA5C30.503@oracle.com> <794DE48E-0323-43A8-91C5-D799E6E51D98@oracle.com> Message-ID: <4EEA5F26.9010807@oracle.com> Good. Thanks, Vladimir Tom Rodriguez wrote: > On Dec 15, 2011, at 12:44 PM, Vladimir Kozlov wrote: > >> Tom, >> >> Can you updated related comments? Otherwise looks good. > > How about this: > > // If we are referencing a field within a Klass, we need > // to assume the worst case of an Object. Both exact and > // inexact types must flatten to the same alias class so > // use NotNull as the PTR. > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7121073 >>> 7 lines changed: 2 ins; 0 del; 5 mod; 3239 unchg >>> 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type >>> Reviewed-by: >>> To ensure that memory operations for type checks are properly ordered, >>> several fields are smeared together into the same alias slice. The >>> existing logic is sloppy and includes a slightly larger chunk of >>> memory than intended. Currently this is fine but changes to the shape >>> of Klass can invalidate it. The fix is to properly test the >>> boundaries. Additionally I changed the logic for setting the PTR to >>> use NotNull instead of Constant to be consisten with all the following >>> logic which uses NotNull. Tested with full CTW. > From tom.rodriguez at oracle.com Thu Dec 15 13:02:21 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 15 Dec 2011 13:02:21 -0800 Subject: review for 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type In-Reply-To: <4EEA5F26.9010807@oracle.com> References: <4EEA5C30.503@oracle.com> <794DE48E-0323-43A8-91C5-D799E6E51D98@oracle.com> <4EEA5F26.9010807@oracle.com> Message-ID: Thanks Vladimir. tom On Dec 15, 2011, at 12:57 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> On Dec 15, 2011, at 12:44 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> Can you updated related comments? Otherwise looks good. >> How about this: >> // If we are referencing a field within a Klass, we need >> // to assume the worst case of an Object. Both exact and >> // inexact types must flatten to the same alias class so >> // use NotNull as the PTR. >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7121073 >>>> 7 lines changed: 2 ins; 0 del; 5 mod; 3239 unchg >>>> 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type >>>> Reviewed-by: >>>> To ensure that memory operations for type checks are properly ordered, >>>> several fields are smeared together into the same alias slice. The >>>> existing logic is sloppy and includes a slightly larger chunk of >>>> memory than intended. Currently this is fine but changes to the shape >>>> of Klass can invalidate it. The fix is to properly test the >>>> boundaries. Additionally I changed the logic for setting the PTR to >>>> use NotNull instead of Constant to be consisten with all the following >>>> logic which uses NotNull. Tested with full CTW. From vladimir.kozlov at oracle.com Thu Dec 15 17:22:42 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Dec 2011 17:22:42 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX In-Reply-To: <7C709738-806E-40DA-9A5A-F19D6A6D5F6F@oracle.com> References: <4EEA3E29.3000400@oracle.com> <4EEA4DB7.2090502@oracle.com> <7C709738-806E-40DA-9A5A-F19D6A6D5F6F@oracle.com> Message-ID: <4EEA9D62.4070605@oracle.com> I did renaming and updated webrev. http://cr.openjdk.java.net/~kvn/7121648/webrev I also fixed match_into_reg() to fold load into arithmetic instruction in a loop. Load was not folded because its control (NULL check) is usually moved outside the loop and loop's head is Region. So I added check for control of load's memory (memory phi) which stays inside a loop. Before: 090 B11: # B11 B12 <- B10 B11 Loop: B11-B11 inner main of N69 Freq: 999991 090 movsd XMM0, [R8 + #16 + RCX << #3] # double 097 movsd XMM1, [R9 + #16 + RCX << #3] # double 09e vaddsd XMM0, XMM1, XMM0 0a2 movsd [R11 + #16 + RCX << #3], XMM0 # double After: 090 B11: # B11 B12 <- B10 B11 Loop: B11-B11 inner main of N69 Freq: 999991 090 movsd XMM0, [R8 + #16 + RCX << #3] # double 097 vaddsd XMM0, XMM0, [R9 + #16 + RCX << #3] 09e movsd [R11 + #16 + RCX << #3], XMM0 # double Vladimir Tom Rodriguez wrote: > On Dec 15, 2011, at 11:42 AM, Vladimir Kozlov wrote: > >> Thank you, Tom >> >> Tom Rodriguez wrote: >>> On Dec 15, 2011, at 10:36 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7121648/webrev >>>> >>>> 7121648: Use 3-operands SIMD instructions on x86 with AVX >>> adlc.make: >>> Can you use $(Platform_arch) instead of $(ARCH)? I know it's the same but names are more obviously parallel. >> Done. >> >>>> VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: >>>> >>>> vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] >>>> >>>> I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. >>> Instead of duplicating regX and regXD why not just rename regX and refXD to regF and regD and come up with a new name for the FPU regs. Maybe regFPRF and regFPRD? >> I am fine with renaming FPU registers to regFPRF and regFPRD but it will be a lot places in x86_32.ad. If you fine with it I will do renaming. > > I just think if we're going to start down this path I want to make it more consistent instead of papering over the difference. So I'm ok with the changes since for the most part it will be pure text replacement. You'll probably need to rename things like immXF and immF to be consistent. > > tom > >>> Also can you correct the formatting in the new file to have the %{ on the same line? And remove the // XXX's after the ins_cost. >> Done. >> >>> Otherwise it looks fine. >> Thanks, >> Vladimir >> >>> tom >>>> There is slight improvement in performance on AVX machine (full result in bug report): >>>> >>>> Benchmark Samples Mean Stdev %Diff P Significant >>>> scimark_small 20 1031.87 4.68 2.85 0.000 Yes >>>> LU 20 1966.82 21.36 6.18 0.000 Yes >>>> FFT 20 658.28 10.33 4.91 0.000 Yes >>>> Monte 20 545.31 2.93 -0.37 0.179 * >>>> SOR 20 994.96 0.67 -0.00 0.910 * >>>> Sparse 20 993.99 1.49 -0.02 0.629 * >>>> >>>> Thanks, >>>> Vladimir > From john.coomes at oracle.com Thu Dec 15 20:42:06 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:42:06 +0000 Subject: hg: hsx/hotspot-comp: 3 new changesets Message-ID: <20111216044206.422E947700@hg.openjdk.java.net> Changeset: 8606f4ab62dc Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/rev/7010bd24cdd0 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:42:12 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:42:12 +0000 Subject: hg: hsx/hotspot-comp/corba: 3 new changesets Message-ID: <20111216044215.D68B047701@hg.openjdk.java.net> Changeset: 05f47d29b438 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/corba/rev/312cf15d1657 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:42:22 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:42:22 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 5 new changesets Message-ID: <20111216044222.9BF9F47702@hg.openjdk.java.net> Changeset: e32444f13774 Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxp/rev/09eb517404b0 Merge Changeset: db44484a9d6e Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/ebec6a7e8d4e Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:42:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:42:29 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 5 new changesets Message-ID: <20111216044229.8064347703@hg.openjdk.java.net> Changeset: 23c42f40fd3e Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/jaxws/rev/3d45ab79643d Merge Changeset: b38846b9974c Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxws/rev/54928c8850f5 Merge ! .hgtags From john.coomes at oracle.com Thu Dec 15 20:43:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:43:49 +0000 Subject: hg: hsx/hotspot-comp/jdk: 64 new changesets Message-ID: <20111216045832.C1F5D4770D@hg.openjdk.java.net> Changeset: 23acf34c80b0 Author: neugens Date: 2011-12-03 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jdk/rev/4075d524fa46 Merge Changeset: e53a078c2840 Author: anthony Date: 2011-11-09 13:43 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/1df53949945d Merge Changeset: 90d33a64a404 Author: rupashka Date: 2011-11-21 18:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/45eb5a61da07 Merge Changeset: 79b5c5a8c7e9 Author: serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a3edcdff37e1 Merge Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/da28826c5672 Merge Changeset: f352dd3cdff8 Author: dl Date: 2011-12-05 13:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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 roland.westrelin at oracle.com Fri Dec 16 04:12:38 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 16 Dec 2011 13:12:38 +0100 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: <4FA71ECC-003E-4E5B-92C9-B4767DE24374@oracle.com> References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> <42EDE902-3FD3-4C90-BBA5-9408451822CD@oracle.com> <4FA71ECC-003E-4E5B-92C9-B4767DE24374@oracle.com> Message-ID: <1FA9C324-B2DD-4DB3-9A02-18A2889E2074@oracle.com> > Could you do a longer set of specjvm98 to confirm the jess difference? Looking at the data, I don't really think it's real but another, longer set of runs should tell us that. Try 20. See below. Roland. ============================================================================ t1 Benchmark Samples Mean Stdev specjvm98 20 666.33 0.00 javac 20 392.47 0.01 db 20 438.68 0.00 jess 20 699.73 0.01 jack 20 593.50 0.01 compress 20 536.20 0.00 mtrt 20 1786.87 0.02 mpegaudio 20 851.56 0.01 ============================================================================ t2 Benchmark Samples Mean Stdev %Diff P Significant specjvm98 20 666.90 0.00 0.08 0.518 * javac 20 392.72 0.02 0.06 0.895 * db 20 439.33 0.00 0.15 0.342 * jess 20 700.23 0.01 0.07 0.760 * jack 20 590.51 0.01 -0.50 0.047 * compress 20 537.69 0.01 0.28 0.230 * mtrt 20 1794.64 0.01 0.44 0.333 * mpegaudio 20 852.44 0.01 0.10 0.678 * ============================================================================ From bertrand.delsart at oracle.com Fri Dec 16 09:18:36 2011 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Fri, 16 Dec 2011 18:18:36 +0100 Subject: Updated Request for Review(S): JVM crashes when throwing StackOverflow exception from interpreter In-Reply-To: References: Message-ID: <4EEB7D6C.70508@oracle.com> Hi Yang (and reviewers), Here is the updated webrev for approval. http://cr.openjdk.java.net/~bdelsart/7116216/00/ As stated previously, I updated the comments to try to avoid confusion and modified the code so that the stub address is available at code generation time. In addition, I noticed two other minor issues: - removed useless setting of saved_exception_pc (which was necessary only for the old InterpreterRuntime call) on sparc. - fixed the @run class name in StackOverflow.java Code has been tested for C1 and C2, including with WalkStackALot and VerifyStack stress options. Thanks again for your help... and sorry for the confusion around C2 and C1 differences. Bertrand. On 11/16/11 06:04 PM, Wang, Yang wrote: > Hi folks, > > We found two problems during throwing an StackOverflow exception from > interpreter. > > 1.Before preparing to throw a StackOverflow exception, the last Java > frame is set to the current sp. This is problematic when the > StackOverflow is thrown on top of c2i adapter. Solution : the real > caller frame(unextended sp) should be set as last Java frame. > > 2.When Garbage collection happens during throwing StackOverflow > exception, and callee-saved register(or "never-saved" register which > behaves alike) happens to be an OOP, GC is unable to locate the OOP in C > frame(generated by VM calls), and hence fails to process the OOP. > Solution : We build a runtime stub frame before doing a VM call, which > guarantees the location of Callee-saved registers are always > recognizable by GC. > > Detailed descriptions and tests could be found in webrev > http://www.sapjvm.com/yw/webrevs/StackOverflow_GC_Crash/ > > I don?t have a bugID yet. Please kindly open one bug for this issue. > > Thanks, > > Yang > > *Yang Wang > *Software Engineer > > TIP Core AS&VM Technology (AG)* > *SAP JVM JIT Compiler// > > *SAP AG** > *Dietmar-Hopp-Allee 16 > 69190 Walldorf, Germany** > > T +49 6227 7-50320* > *F +49 6227 78-48541* > *Email : yang02.wang at sap.com* > *www.sap.com > > * > *Pflichtangaben/Mandatory Disclosure Statements: > http://www.sap.com/company/legal/impressum.epx* > > *Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese E-Mail > irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, > eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. > Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. > Vielen Dank. * > > *This e-mail may contain trade secrets or privileged, undisclosed, or > otherwise confidential information. If you have received this e-mail in > error, you are hereby notified that any review, copying, or distribution > of it is strictly prohibited. Please inform us immediately and destroy > the original transmittal. Thank you for your cooperation. > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From igor.veresov at oracle.com Fri Dec 16 22:13:42 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 16 Dec 2011 22:13:42 -0800 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: I guess something similar could be achieved by utilizing the regular tiered infrastructure (level 3 and/or interpreter) for profiling and then recompiling with C1 with type checked guarded inline like you did. So, this could've been, say, level 3.5 and tiered would've used it instead of current level 4 as a final compilation state (with perhaps substantially lower compile thresholds in this case). Have you tried doing something like that? igor On Thursday, December 15, 2011 at 6:52 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7121756/webrev.00/ > > Implements profile based inlining in C1. > > Execution of a method starts interpreted as usual. A method transitions from interpreted to compiled in the usual way as well. When the method is compiled, the compiler identifies a number of call sites that are candidates for profiling and further inlining. At those call sites, the method is compiled so that a per call site counter is incremented and tested for overflow when the call site is used. On first call site resolution, a timestamp is also recorded. The count and timestamp are used to compute a frequency. A frequency higher than a high water mark detects a hot call site. A hot call site triggers a recompilation of the caller method in which the callee is inlined. A frequency higher than a low water mark detects a warm call site. Otherwise the call site is cold. Recompiling with the extra inlining won't bring a performance advantage for a warm or cold call site. But keeping the profiling on at a warm call site is detrimental so it is dropped. At a cold call site pr! ofiling c an be kept enabled to trigger later recompilation if the call site becomes hot. > > To perform profiling, the compiler identifies the candidate call sites and generates a stub similar to the static call stub in the nmethod's stub area. The profile call stub performs the following step: > 1- load mdo pointer in register > 2- increment counter for call site > 3- branch to runtime if counter crosses threshold > 4- jump to callee > > On call site resolution, for a call to a compiled method, the jump (4- above) is patched with the resolved call site info (to continue to callee's code or transition stub) then the call site is patched to point to the profile call stub. Profiling can be later fully disabled for the call site (if the call site is polymorphic or if the compilation policy finds it's better to not profile the call site anymore) by reresolving the call. > > The compiler also uses profile data to inline a frequent virtual method if profile data suggests a single receiver class. State changes of inline caches associated with call sites (performed in the runtime) are used to collect receiver class data. Correctness during execution is enforced with a compiled guard and a deoptimization can be triggered. From roland.westrelin at oracle.com Mon Dec 19 07:09:22 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 19 Dec 2011 16:09:22 +0100 Subject: request for review (L): 7121756 Improve C1 inlining policy by using profiling at call sites In-Reply-To: References: <68105D4B-D98D-48F2-A84F-A398D295ABA3@oracle.com> Message-ID: > I guess something similar could be achieved by utilizing the regular tiered infrastructure (level 3 and/or interpreter) for profiling and then recompiling with C1 with type checked guarded inline like you did. So, this could've been, say, level 3.5 and tiered would've used it instead of current level 4 as a final compilation state (with perhaps substantially lower compile thresholds in this case). Have you tried doing something like that? Yes something similar could have been achieved that way and that's actually what I tried first but results were not good. The gain when going from c1 to c1 + extra inlining here is not as big as when going from c1 to c2 in tiered so the risk is that the gain you get from running the improved code once it is recompiled doesn't make up for the slow down due to the profiling code. Profiling here happens out of line. Once a call site is seen a sufficient number of times, profiling is disabled and it causes no extra cost. If a call site is found to be hot and a recompilation is triggered, no more profiling code is run at this call site until the new code is ready. If a call site is found to be warm (the benefit from recompiling is not big enough but the cost of profiling is too high), profiling is fully disabled and there is no need for a new compilation to get code without profiling, so compiler threads are not loaded and new better code for other methods will get ready sooner. To inline a virtual call here, we need to know whether a single receiver exists or not. If there's more than one, knowing what the others are doesn't matter. So profiling data can be collected at inline cache state change which is essentially free. In principle it's similar to tiered but because the gain from c1 to c1+extra inlining, it has its own specialized way of collecting profile data tailored to get only what it needs with the smallest extra cost. Roland. From tom.rodriguez at oracle.com Mon Dec 19 11:10:51 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 19 Dec 2011 11:10:51 -0800 Subject: review request (M): 7121140: Allocation paths require explicit memory synchronization operations for RMO systems In-Reply-To: <1FA9C324-B2DD-4DB3-9A02-18A2889E2074@oracle.com> References: <8946CA8C-2E30-49E1-B53C-7A52FE6E716D@oracle.com> <42EDE902-3FD3-4C90-BBA5-9408451822CD@oracle.com> <4FA71ECC-003E-4E5B-92C9-B4767DE24374@oracle.com> <1FA9C324-B2DD-4DB3-9A02-18A2889E2074@oracle.com> Message-ID: On Dec 16, 2011, at 4:12 AM, Roland Westrelin wrote: >> Could you do a longer set of specjvm98 to confirm the jess difference? Looking at the data, I don't really think it's real but another, longer set of runs should tell us that. Try 20. > > See below. That looks ok. Go ahead and push. tom > > Roland. > > ============================================================================ > t1 > Benchmark Samples Mean Stdev > specjvm98 20 666.33 0.00 > javac 20 392.47 0.01 > db 20 438.68 0.00 > jess 20 699.73 0.01 > jack 20 593.50 0.01 > compress 20 536.20 0.00 > mtrt 20 1786.87 0.02 > mpegaudio 20 851.56 0.01 > ============================================================================ > t2 > Benchmark Samples Mean Stdev %Diff P Significant > specjvm98 20 666.90 0.00 0.08 0.518 * > javac 20 392.72 0.02 0.06 0.895 * > db 20 439.33 0.00 0.15 0.342 * > jess 20 700.23 0.01 0.07 0.760 * > jack 20 590.51 0.01 -0.50 0.047 * > compress 20 537.69 0.01 0.28 0.230 * > mtrt 20 1794.64 0.01 0.44 0.333 * > mpegaudio 20 852.44 0.01 0.10 0.678 * > ============================================================================ > From tom.rodriguez at oracle.com Mon Dec 19 14:02:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 19 Dec 2011 14:02:02 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX In-Reply-To: <4EEA9D62.4070605@oracle.com> References: <4EEA3E29.3000400@oracle.com> <4EEA4DB7.2090502@oracle.com> <7C709738-806E-40DA-9A5A-F19D6A6D5F6F@oracle.com> <4EEA9D62.4070605@oracle.com> Message-ID: <63FA8C65-E72B-450C-B753-883CA3A18522@oracle.com> Looks good to me. tom On Dec 15, 2011, at 5:22 PM, Vladimir Kozlov wrote: > I did renaming and updated webrev. > > http://cr.openjdk.java.net/~kvn/7121648/webrev > > I also fixed match_into_reg() to fold load into arithmetic instruction in a loop. Load was not folded because its control (NULL check) is usually moved outside the loop and loop's head is Region. So I added check for control of load's memory (memory phi) which stays inside a loop. > > Before: > 090 B11: # B11 B12 <- B10 B11 Loop: B11-B11 inner main of N69 Freq: 999991 > 090 movsd XMM0, [R8 + #16 + RCX << #3] # double > 097 movsd XMM1, [R9 + #16 + RCX << #3] # double > 09e vaddsd XMM0, XMM1, XMM0 > 0a2 movsd [R11 + #16 + RCX << #3], XMM0 # double > > After: > 090 B11: # B11 B12 <- B10 B11 Loop: B11-B11 inner main of N69 Freq: 999991 > 090 movsd XMM0, [R8 + #16 + RCX << #3] # double > 097 vaddsd XMM0, XMM0, [R9 + #16 + RCX << #3] > 09e movsd [R11 + #16 + RCX << #3], XMM0 # double > > Vladimir > > Tom Rodriguez wrote: >> On Dec 15, 2011, at 11:42 AM, Vladimir Kozlov wrote: >>> Thank you, Tom >>> >>> Tom Rodriguez wrote: >>>> On Dec 15, 2011, at 10:36 AM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/7121648/webrev >>>>> >>>>> 7121648: Use 3-operands SIMD instructions on x86 with AVX >>>> adlc.make: >>>> Can you use $(Platform_arch) instead of $(ARCH)? I know it's the same but names are more obviously parallel. >>> Done. >>> >>>>> VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: >>>>> >>>>> vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] >>>>> >>>>> I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. >>>> Instead of duplicating regX and regXD why not just rename regX and refXD to regF and regD and come up with a new name for the FPU regs. Maybe regFPRF and regFPRD? >>> I am fine with renaming FPU registers to regFPRF and regFPRD but it will be a lot places in x86_32.ad. If you fine with it I will do renaming. >> I just think if we're going to start down this path I want to make it more consistent instead of papering over the difference. So I'm ok with the changes since for the most part it will be pure text replacement. You'll probably need to rename things like immXF and immF to be consistent. >> tom >>>> Also can you correct the formatting in the new file to have the %{ on the same line? And remove the // XXX's after the ins_cost. >>> Done. >>> >>>> Otherwise it looks fine. >>> Thanks, >>> Vladimir >>> >>>> tom >>>>> There is slight improvement in performance on AVX machine (full result in bug report): >>>>> >>>>> Benchmark Samples Mean Stdev %Diff P Significant >>>>> scimark_small 20 1031.87 4.68 2.85 0.000 Yes >>>>> LU 20 1966.82 21.36 6.18 0.000 Yes >>>>> FFT 20 658.28 10.33 4.91 0.000 Yes >>>>> Monte 20 545.31 2.93 -0.37 0.179 * >>>>> SOR 20 994.96 0.67 -0.00 0.910 * >>>>> Sparse 20 993.99 1.49 -0.02 0.629 * >>>>> >>>>> Thanks, >>>>> Vladimir From vladimir.kozlov at oracle.com Mon Dec 19 14:08:26 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Dec 2011 14:08:26 -0800 Subject: Request for reviews (M): 7121648: Use 3-operands SIMD instructions on x86 with AVX In-Reply-To: <63FA8C65-E72B-450C-B753-883CA3A18522@oracle.com> References: <4EEA3E29.3000400@oracle.com> <4EEA4DB7.2090502@oracle.com> <7C709738-806E-40DA-9A5A-F19D6A6D5F6F@oracle.com> <4EEA9D62.4070605@oracle.com> <63FA8C65-E72B-450C-B753-883CA3A18522@oracle.com> Message-ID: <4EEFB5DA.3070706@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > Looks good to me. > > tom > > On Dec 15, 2011, at 5:22 PM, Vladimir Kozlov wrote: > >> I did renaming and updated webrev. >> >> http://cr.openjdk.java.net/~kvn/7121648/webrev >> >> I also fixed match_into_reg() to fold load into arithmetic instruction in a loop. Load was not folded because its control (NULL check) is usually moved outside the loop and loop's head is Region. So I added check for control of load's memory (memory phi) which stays inside a loop. >> >> Before: >> 090 B11: # B11 B12 <- B10 B11 Loop: B11-B11 inner main of N69 Freq: 999991 >> 090 movsd XMM0, [R8 + #16 + RCX << #3] # double >> 097 movsd XMM1, [R9 + #16 + RCX << #3] # double >> 09e vaddsd XMM0, XMM1, XMM0 >> 0a2 movsd [R11 + #16 + RCX << #3], XMM0 # double >> >> After: >> 090 B11: # B11 B12 <- B10 B11 Loop: B11-B11 inner main of N69 Freq: 999991 >> 090 movsd XMM0, [R8 + #16 + RCX << #3] # double >> 097 vaddsd XMM0, XMM0, [R9 + #16 + RCX << #3] >> 09e movsd [R11 + #16 + RCX << #3], XMM0 # double >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Dec 15, 2011, at 11:42 AM, Vladimir Kozlov wrote: >>>> Thank you, Tom >>>> >>>> Tom Rodriguez wrote: >>>>> On Dec 15, 2011, at 10:36 AM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/7121648/webrev >>>>>> >>>>>> 7121648: Use 3-operands SIMD instructions on x86 with AVX >>>>> adlc.make: >>>>> Can you use $(Platform_arch) instead of $(ARCH)? I know it's the same but names are more obviously parallel. >>>> Done. >>>> >>>>>> VEX prefix converts legacy SSE instructions into 3 operands instructions. Use such instructions in C2 generated code for machines with AVX: >>>>>> >>>>>> vaddsd XMM2, XMM0, [RSI + #8 + RCX << #3] >>>>>> >>>>>> I also did go ahead and created x86.ad file to collect common 32- and 64-bit mach instructions definitions. >>>>> Instead of duplicating regX and regXD why not just rename regX and refXD to regF and regD and come up with a new name for the FPU regs. Maybe regFPRF and regFPRD? >>>> I am fine with renaming FPU registers to regFPRF and regFPRD but it will be a lot places in x86_32.ad. If you fine with it I will do renaming. >>> I just think if we're going to start down this path I want to make it more consistent instead of papering over the difference. So I'm ok with the changes since for the most part it will be pure text replacement. You'll probably need to rename things like immXF and immF to be consistent. >>> tom >>>>> Also can you correct the formatting in the new file to have the %{ on the same line? And remove the // XXX's after the ins_cost. >>>> Done. >>>> >>>>> Otherwise it looks fine. >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>>> There is slight improvement in performance on AVX machine (full result in bug report): >>>>>> >>>>>> Benchmark Samples Mean Stdev %Diff P Significant >>>>>> scimark_small 20 1031.87 4.68 2.85 0.000 Yes >>>>>> LU 20 1966.82 21.36 6.18 0.000 Yes >>>>>> FFT 20 658.28 10.33 4.91 0.000 Yes >>>>>> Monte 20 545.31 2.93 -0.37 0.179 * >>>>>> SOR 20 994.96 0.67 -0.00 0.910 * >>>>>> Sparse 20 993.99 1.49 -0.02 0.629 * >>>>>> >>>>>> Thanks, >>>>>> Vladimir > From tom.rodriguez at oracle.com Tue Dec 20 01:57:09 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 20 Dec 2011 09:57:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Message-ID: <20111220095713.44C7E4776B@hg.openjdk.java.net> Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp From roland.westrelin at oracle.com Tue Dec 20 09:05:29 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 20 Dec 2011 09:05:29 -0800 (PST) Subject: review request (S): 7123108 C1: assert(if_state != NULL) failed: states do not match up Message-ID: http://cr.openjdk.java.net/~roland/7123108/webrev.00/ 7114106 fixed CEE: the state of the if that is used is adjusted so that it is at the same inline level as the common successor state. Similarly, if the inline level of the common successor's state is higher than the one of the if, the state of the common successor that is used must be adjusted so both states are at the same inline level. Roland. From roland.westrelin at oracle.com Tue Dec 20 09:24:45 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 20 Dec 2011 18:24:45 +0100 Subject: review request (S): 7123253: C1: in store check code, usage of registers may be incorrect Message-ID: http://cr.openjdk.java.net/~roland/7123253/webrev.00/ Assembly code in LIR_Assembler::emit_opTypeCheck() for case code == lir_store_check uses value (an input) after k_RInfo (a temp) is written to. If k_RInfo and value are the same, this code breaks. Roland. From tom.rodriguez at oracle.com Tue Dec 20 10:41:42 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Dec 2011 10:41:42 -0800 Subject: review request (S): 7123253: C1: in store check code, usage of registers may be incorrect In-Reply-To: References: Message-ID: Looks good. tom On Dec 20, 2011, at 9:24 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/7123253/webrev.00/ > > Assembly code in LIR_Assembler::emit_opTypeCheck() for case code == lir_store_check uses value (an input) after k_RInfo (a temp) is written to. If k_RInfo and value are the same, this code breaks. > > Roland. From tom.rodriguez at oracle.com Tue Dec 20 10:46:02 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Dec 2011 10:46:02 -0800 (PST) Subject: review request (S): 7123108 C1: assert(if_state != NULL) failed: states do not match up In-Reply-To: References: Message-ID: <5C30AA9A-13A1-4F58-AA48-FC19FE66A44E@oracle.com> Can you derive a regression test from the test in the report? It's a generated test so it's pretty ugly but it should be possible to trim away most of it. Other it looks good. tom On Dec 20, 2011, at 9:05 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/7123108/webrev.00/ > > 7114106 fixed CEE: the state of the if that is used is adjusted so that it is at the same inline level as the common successor state. Similarly, if the inline level of the common successor's state is higher than the one of the if, the state of the common successor that is used must be adjusted so both states are at the same inline level. > > Roland. From vladimir.kozlov at oracle.com Tue Dec 20 11:23:41 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 20 Dec 2011 19:23:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7121648: Use 3-operands SIMD instructions on x86 with AVX Message-ID: <20111220192345.B43C647770@hg.openjdk.java.net> Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp From stefan.karlsson at oracle.com Tue Dec 20 19:08:40 2011 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Wed, 21 Dec 2011 03:08:40 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Message-ID: <20111221030847.9106847775@hg.openjdk.java.net> Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.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 ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp From roland.westrelin at oracle.com Wed Dec 21 03:46:40 2011 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 21 Dec 2011 12:46:40 +0100 Subject: review request (S): 7123108 C1: assert(if_state != NULL) failed: states do not match up In-Reply-To: <5C30AA9A-13A1-4F58-AA48-FC19FE66A44E@oracle.com> References: <5C30AA9A-13A1-4F58-AA48-FC19FE66A44E@oracle.com> Message-ID: <3D991A65-8A99-427B-919E-D344F69C9A9C@oracle.com> > Can you derive a regression test from the test in the report? It's a generated test so it's pretty ugly but it should be possible to trim away most of it. Is this ok? http://cr.openjdk.java.net/~roland/7123108/webrev.01/ Roland. From jon.masamitsu at oracle.com Wed Dec 21 08:15:30 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 21 Dec 2011 08:15:30 -0800 Subject: Modification to the write barrier In-Reply-To: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> References: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> Message-ID: <4EF20622.8060905@oracle.com> Forwarding to hotspot-compiler-dev. On 12/21/2011 1:21 AM, Lokesh Gidra wrote: > Hi, > > I want to make some modifications to the write barrier of the parallel scavenge GC. The changes I made are visible in interpreted mode, but not in JIT compiled code. Can someone please point me to the code location where I can find the code for write barrier for JIT compilation, so that I can run my test without -Xint option as well. > > Thanks in advance. > > Regards, > Lokesh > From tom.rodriguez at oracle.com Wed Dec 21 09:46:07 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Dec 2011 09:46:07 -0800 Subject: Modification to the write barrier In-Reply-To: <4EF20622.8060905@oracle.com> References: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> <4EF20622.8060905@oracle.com> Message-ID: <75922118-EB10-4B97-BED2-AC6700F5EAB6@oracle.com> On Dec 21, 2011, at 8:15 AM, Jon Masamitsu wrote: > Forwarding to hotspot-compiler-dev. > > On 12/21/2011 1:21 AM, Lokesh Gidra wrote: >> Hi, >> >> I want to make some modifications to the write barrier of the parallel scavenge GC. The changes I made are visible in interpreted mode, but not in JIT compiled code. Can someone please point me to the code location where I can find the code for write barrier for JIT compilation, so that I can run my test without -Xint option as well. The C2 barrier code is in src/share/vm/opto/graphKit.cpp and the C1 code is in src/share/vm/c1/c1_LIRGenerator.cpp. tom >> >> Thanks in advance. >> >> Regards, >> Lokesh >> From tom.rodriguez at oracle.com Wed Dec 21 09:55:40 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Dec 2011 09:55:40 -0800 Subject: review request (S): 7123108 C1: assert(if_state != NULL) failed: states do not match up In-Reply-To: <3D991A65-8A99-427B-919E-D344F69C9A9C@oracle.com> References: <5C30AA9A-13A1-4F58-AA48-FC19FE66A44E@oracle.com> <3D991A65-8A99-427B-919E-D344F69C9A9C@oracle.com> Message-ID: On Dec 21, 2011, at 3:46 AM, Roland Westrelin wrote: >> Can you derive a regression test from the test in the report? It's a generated test so it's pretty ugly but it should be possible to trim away most of it. > > Is this ok? Yep. tom > > http://cr.openjdk.java.net/~roland/7123108/webrev.01/ > > Roland. From roland.westrelin at oracle.com Thu Dec 22 01:47:03 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 22 Dec 2011 09:47:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Message-ID: <20111222094709.008A74778E@hg.openjdk.java.net> Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp From roland.westrelin at oracle.com Thu Dec 22 03:33:17 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 22 Dec 2011 11:33:17 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7123108: C1: assert(if_state != NULL) failed: states do not match up Message-ID: <20111222113325.8A95147790@hg.openjdk.java.net> Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java From vladimir.kozlov at oracle.com Thu Dec 22 16:12:48 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Dec 2011 16:12:48 -0800 Subject: Request for reviews (S): 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Message-ID: <4EF3C780.8000003@oracle.com> http://cr.openjdk.java.net/~kvn/7110832/webrev 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Distance is too large for one short branch in string_indexofC8(). Note, it does not fail always because different REX prefixes are generated for different input registers. I added verification code in debug VM by reducing allowed distance (by 32 bytes) for short branches. It can be used in a large hand written assembler code. Tested with full CTW. Thanks, Vladimir From igor.veresov at oracle.com Thu Dec 22 16:38:30 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 22 Dec 2011 16:38:30 -0800 Subject: Request for reviews (S): 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM In-Reply-To: <4EF3C780.8000003@oracle.com> References: <4EF3C780.8000003@oracle.com> Message-ID: Looks good! But I don't think you need this statement: 265 friend class ShortBranchVerifier; igor On Thursday, December 22, 2011 at 4:12 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7110832/webrev > > 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM > > Distance is too large for one short branch in string_indexofC8(). Note, it does > not fail always because different REX prefixes are generated for different input > registers. > > I added verification code in debug VM by reducing allowed distance (by 32 bytes) > for short branches. It can be used in a large hand written assembler code. > > Tested with full CTW. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Dec 22 16:34:46 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Dec 2011 16:34:46 -0800 Subject: Request for reviews (S): 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM In-Reply-To: References: <4EF3C780.8000003@oracle.com> Message-ID: <4EF3CCA6.40206@oracle.com> Thanks Igor Igor Veresov wrote: > Looks good! > > But I don't think you need this statement: > 265 friend class ShortBranchVerifier; > Yes, it works without it. Vladimir > > > igor > > > On Thursday, December 22, 2011 at 4:12 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7110832/webrev >> >> 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM >> >> Distance is too large for one short branch in string_indexofC8(). Note, it does >> not fail always because different REX prefixes are generated for different input >> registers. >> >> I added verification code in debug VM by reducing allowed distance (by 32 bytes) >> for short branches. It can be used in a large hand written assembler code. >> >> Tested with full CTW. >> >> Thanks, >> Vladimir > > > From john.coomes at oracle.com Thu Dec 22 20:51:37 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:51:37 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b18 for changeset 7010bd24cdd0 Message-ID: <20111223045137.2B999477AD@hg.openjdk.java.net> Changeset: e1fc13802e0c Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e1fc13802e0c Added tag jdk8-b18 for changeset 7010bd24cdd0 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:51:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:51:43 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b18 for changeset 312cf15d1657 Message-ID: <20111223045145.D1892477AE@hg.openjdk.java.net> Changeset: 46bd4a46a5a8 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/46bd4a46a5a8 Added tag jdk8-b18 for changeset 312cf15d1657 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:51:52 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:51:52 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b18 for changeset ebec6a7e8d4e Message-ID: <20111223045152.9FF16477AF@hg.openjdk.java.net> Changeset: 5fb25931f1c2 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/5fb25931f1c2 Added tag jdk8-b18 for changeset ebec6a7e8d4e ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:52:01 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:52:01 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b18 for changeset 54928c8850f5 Message-ID: <20111223045201.8FAA7477B0@hg.openjdk.java.net> Changeset: 72d410c3bab1 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/72d410c3bab1 Added tag jdk8-b18 for changeset 54928c8850f5 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:53:00 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:53:00 +0000 Subject: hg: hsx/hotspot-comp/jdk: 6 new changesets Message-ID: <20111223045424.9AB18477B1@hg.openjdk.java.net> Changeset: 134420afe9c2 Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/c6fab5332075 Added tag jdk8-b18 for changeset 334bd51fb3f3 ! .hgtags From john.coomes at oracle.com Thu Dec 22 20:57:24 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 04:57:24 +0000 Subject: hg: hsx/hotspot-comp/langtools: 14 new changesets Message-ID: <20111223045756.F2C48477B2@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/2584f5358cba Merge Changeset: abfa0d8ea803 Author: ksrini Date: 2011-12-07 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/langtools/rev/3c71fcc22b99 Added tag jdk8-b18 for changeset ab1b1cc78577 ! .hgtags From roland.westrelin at oracle.com Fri Dec 23 02:14:54 2011 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Fri, 23 Dec 2011 10:14:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7123253: C1: in store check code, usage of registers may be incorrect Message-ID: <20111223101502.5A121477C5@hg.openjdk.java.net> Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp From vladimir.kozlov at oracle.com Fri Dec 23 19:15:22 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Dec 2011 19:15:22 -0800 Subject: Request for reviews (S): 7123954: Some CTW test crash with SIGSEGV Message-ID: <4EF543CA.8000309@oracle.com> http://cr.openjdk.java.net/~kvn/7123954/webrev 7123954: Some CTW test crash with SIGSEGV Old problem. Incoming I_O projection is dropped on floor (become dead) when allocation replaced only with slow call (big array). Correct the code for such case. Tested with full CTW. Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Dec 23 19:56:04 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 24 Dec 2011 03:56:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Message-ID: <20111224035608.9BE12477D6@hg.openjdk.java.net> Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp From igor.veresov at oracle.com Tue Dec 27 14:56:18 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 27 Dec 2011 14:56:18 -0800 Subject: Request for reviews (S): 7123954: Some CTW test crash with SIGSEGV In-Reply-To: <4EF543CA.8000309@oracle.com> References: <4EF543CA.8000309@oracle.com> Message-ID: <6647BD96DF98480F80B952387C668EE8@oracle.com> Looks good. igor On Friday, December 23, 2011 at 7:15 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7123954/webrev > > 7123954: Some CTW test crash with SIGSEGV > > Old problem. Incoming I_O projection is dropped on floor (become dead) when > allocation replaced only with slow call (big array). Correct the code for such case. > > Tested with full CTW. > > Thanks, > Vladimir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111227/698eec25/attachment.html From vladimir.kozlov at oracle.com Tue Dec 27 15:02:19 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Dec 2011 15:02:19 -0800 Subject: Request for reviews (S): 7123954: Some CTW test crash with SIGSEGV In-Reply-To: <6647BD96DF98480F80B952387C668EE8@oracle.com> References: <4EF543CA.8000309@oracle.com> <6647BD96DF98480F80B952387C668EE8@oracle.com> Message-ID: <4EFA4E7B.60605@oracle.com> Thank you, Igor Vladimir Igor Veresov wrote: > Looks good. > > igor > > On Friday, December 23, 2011 at 7:15 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7123954/webrev >> >> 7123954: Some CTW test crash with SIGSEGV >> >> Old problem. Incoming I_O projection is dropped on floor (become dead) >> when >> allocation replaced only with slow call (big array). Correct the code >> for such case. >> >> Tested with full CTW. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Dec 27 17:57:19 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 28 Dec 2011 01:57:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7123954: Some CTW test crash with SIGSEGV Message-ID: <20111228015727.B62AC477EA@hg.openjdk.java.net> Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp From vladimir.kozlov at oracle.com Thu Dec 29 13:20:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Dec 2011 13:20:09 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks Message-ID: <4EFCD989.502@oracle.com> http://cr.openjdk.java.net/~kvn/7125896/webrev 7125896: Eliminate nested locks Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. New code is under new product flag EliminateNestedLocks. Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. Tested with full CTW, nsk, jtreg tests, refworkload. Thanks, Vladimir From vladimir.kozlov at oracle.com Thu Dec 29 16:19:28 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 30 Dec 2011 00:19:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 33 new changesets Message-ID: <20111230002035.8D7D64782B@hg.openjdk.java.net> Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/31f6f10e4379 Merge Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/hotspot/rev/129cd462ae89 Merge Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/96ce4c27112f 7122939: TraceBytecodes broken with UseCompressedOops Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register Reviewed-by: coleenp, phh Contributed-by: Volker Simonis ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/4502fd5c7698 Merge Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/11c26bfcf8c7 7091417: recvfrom's 6th input should be of type socklen_t Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp. Reviewed-by: coleenp, dholmes Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/d532160c55f7 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Thu Dec 29 18:01:29 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Dec 2011 18:01:29 -0800 Subject: Request for reviews (XS): 7125879: assert(proj != NULL) failed: must be found Message-ID: <4EFD1B79.90701@oracle.com> http://cr.openjdk.java.net/~kvn/7125879/webrev 7125879: assert(proj != NULL) failed: must be found Case of new array with negative size known during compilation. AllocateArrayNode::Ideal() optimization disconnect unreachable following code since call to runtime will throw exception. As result there will be no users of i_o after the call. Leave i_o attached to slow allocation call to avoid problems in preceding graph. Tested with full CTW and failing test. Thanks, Vladimir From john.coomes at oracle.com Thu Dec 29 20:41:45 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:41:45 +0000 Subject: hg: hsx/hotspot-comp: 4 new changesets Message-ID: <20111230044145.41D1A47839@hg.openjdk.java.net> Changeset: 9acd7374ff8a Author: ohair Date: 2011-12-12 08:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/rev/00d13c40d7a7 Merge Changeset: 237bc29afbfc Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/237bc29afbfc Merge Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:41:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:41:53 +0000 Subject: hg: hsx/hotspot-comp/corba: 5 new changesets Message-ID: <20111230044157.9B8794783A@hg.openjdk.java.net> Changeset: 75529c21094f Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/0289a94d653b Merge Changeset: 052dda3b5ce3 Author: dmeetry Date: 2011-12-18 22:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/corba/rev/e1366c5d84ef Merge Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:42:05 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:42:05 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 5 new changesets Message-ID: <20111230044205.9E4914783B@hg.openjdk.java.net> Changeset: a482d45c93e9 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxp/rev/f26e2ab2c2c7 Merge Changeset: dffeb62b1a7f Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/dffeb62b1a7f Merge Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:42:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:42:17 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 5 new changesets Message-ID: <20111230044217.A5C604783C@hg.openjdk.java.net> Changeset: 6d622b1b4db0 Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/jaxws/rev/b2e4ab8b5fa3 Merge Changeset: b73b733214aa Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/b73b733214aa Merge Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags From john.coomes at oracle.com Thu Dec 29 20:43:14 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:43:14 +0000 Subject: hg: hsx/hotspot-comp/jdk: 30 new changesets Message-ID: <20111230044842.C1DAF47842@hg.openjdk.java.net> Changeset: 7dbc53242c2a Author: art Date: 2011-12-07 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/d4f9d7e86a92 Merge Changeset: 9c0a6185188f Author: ohair Date: 2011-12-12 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/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-comp/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags From igor.veresov at oracle.com Thu Dec 29 23:46:26 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 29 Dec 2011 23:46:26 -0800 Subject: Request for reviews (XS): 7125879: assert(proj =?utf-8?Q?=21=3D_?=NULL) failed: must be found In-Reply-To: <4EFD1B79.90701@oracle.com> References: <4EFD1B79.90701@oracle.com> Message-ID: <408EAC7B21424884B105C5F9347D86EE@oracle.com> Seems fine. igor On Thursday, December 29, 2011 at 6:01 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7125879/webrev > > 7125879: assert(proj != NULL) failed: must be found > > Case of new array with negative size known during compilation. > AllocateArrayNode::Ideal() optimization disconnect unreachable following code > since call to runtime will throw exception. As result there will be no users of > i_o after the call. > > Leave i_o attached to slow allocation call to avoid problems in preceding graph. > > Tested with full CTW and failing test. > > Thanks, > Vladimir > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20111229/f168bae0/attachment-0001.html From vladimir.kozlov at oracle.com Thu Dec 29 23:49:08 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Dec 2011 23:49:08 -0800 Subject: Request for reviews (XS): 7125879: assert(proj != NULL) failed: must be found In-Reply-To: <408EAC7B21424884B105C5F9347D86EE@oracle.com> References: <4EFD1B79.90701@oracle.com> <408EAC7B21424884B105C5F9347D86EE@oracle.com> Message-ID: <4EFD6CF4.1060507@oracle.com> Thank you, Igor Vladimir On 12/29/11 11:46 PM, Igor Veresov wrote: > Seems fine. > > igor > > On Thursday, December 29, 2011 at 6:01 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7125879/webrev >> >> 7125879: assert(proj != NULL) failed: must be found >> >> Case of new array with negative size known during compilation. >> AllocateArrayNode::Ideal() optimization disconnect unreachable following code >> since call to runtime will throw exception. As result there will be no users of >> i_o after the call. >> >> Leave i_o attached to slow allocation call to avoid problems in preceding graph. >> >> Tested with full CTW and failing test. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Fri Dec 30 02:37:29 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Dec 2011 11:37:29 +0100 Subject: Request for reviews (XS): 7125879: assert(proj != NULL) failed: must be found In-Reply-To: <4EFD1B79.90701@oracle.com> References: <4EFD1B79.90701@oracle.com> Message-ID: Looks good. -- Chris On Dec 30, 2011, at 3:01 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7125879/webrev > > 7125879: assert(proj != NULL) failed: must be found > > Case of new array with negative size known during compilation. AllocateArrayNode::Ideal() optimization disconnect unreachable following code since call to runtime will throw exception. As result there will be no users of i_o after the call. > > Leave i_o attached to slow allocation call to avoid problems in preceding graph. > > Tested with full CTW and failing test. > > Thanks, > Vladimir From christian.thalinger at oracle.com Fri Dec 30 02:56:08 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Dec 2011 11:56:08 +0100 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: <4EFCD989.502@oracle.com> References: <4EFCD989.502@oracle.com> Message-ID: I think the changes are good. The only thing I don't like is the raw use of _slot: + (BoxLockNode::boxnode(lock->box_node())->_slot == + BoxLockNode::boxnode(unlock->box_node())->_slot)) { -- Chris On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7125896/webrev > > 7125896: Eliminate nested locks > > Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. > > New code is under new product flag EliminateNestedLocks. > > Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. > > Tested with full CTW, nsk, jtreg tests, refworkload. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Dec 30 10:42:35 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Dec 2011 10:42:35 -0800 Subject: Request for reviews (XS): 7125879: assert(proj != NULL) failed: must be found In-Reply-To: References: <4EFD1B79.90701@oracle.com> Message-ID: <4EFE061B.7020105@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On Dec 30, 2011, at 3:01 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7125879/webrev >> >> 7125879: assert(proj != NULL) failed: must be found >> >> Case of new array with negative size known during compilation. AllocateArrayNode::Ideal() optimization disconnect unreachable following code since call to runtime will throw exception. As result there will be no users of i_o after the call. >> >> Leave i_o attached to slow allocation call to avoid problems in preceding graph. >> >> Tested with full CTW and failing test. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Dec 30 11:23:05 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Dec 2011 11:23:05 -0800 Subject: Request for reviews (L): 7125896: Eliminate nested locks In-Reply-To: References: <4EFCD989.502@oracle.com> Message-ID: <4EFE0F99.4050706@oracle.com> Christian Thalinger wrote: > I think the changes are good. The only thing I don't like is the raw use of _slot: > > + (BoxLockNode::boxnode(lock->box_node())->_slot == > + BoxLockNode::boxnode(unlock->box_node())->_slot)) { Agree. I changed _slot (and other BoxLock fields) to private and replaced above code with new BoxLock's method call: BoxLockNode::same_slot(lock->box_node(), unlock->box_node()) I also did some methods renaming and updated webrev. Thanks, Vladimir > > -- Chris > > On Dec 29, 2011, at 10:20 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7125896/webrev >> >> 7125896: Eliminate nested locks >> >> Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Commoning (GVN) of BoxLock nodes is switched off because nested locks elimination requires separate BoxLock node for each locked region to generated correct debug info for deoptimization. As result there could be merges (and Phi nodes) of BoxLock nodes. One such merge generated by ciTypeFlow (cloning loop head) is avoided but there could be other cases so new code is added to handle it. >> >> New code is under new product flag EliminateNestedLocks. >> >> Also added missed KILL effect for box register in fastlock and fastunlock mach nodes definitions. >> >> Tested with full CTW, nsk, jtreg tests, refworkload. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Fri Dec 30 14:41:53 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 30 Dec 2011 22:41:53 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7125879: assert(proj != NULL) failed: must be found Message-ID: <20111230224156.B982A47855@hg.openjdk.java.net> Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java From headius at headius.com Sat Dec 31 12:10:41 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 31 Dec 2011 14:10:41 -0600 Subject: Crash in C2 with 7u2b13 Message-ID: Got this report from a JRuby user, so I figured I'd toss it on this list and see if I should report it (or if one of you want to look into it directly): http://jira.codehaus.org/browse/JRUBY-6297 It's crashing in one of the compiler threads in ciMethod::resolve_invoke, as far as I can tell. I have no simple reproduction at the moment :( - Charlie