From sean.mullan at oracle.com Wed Aug 1 08:27:07 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 01 Aug 2012 15:27:07 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120801152759.4764C472E9@hg.openjdk.java.net> Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh From daniel.daugherty at oracle.com Wed Aug 1 10:22:48 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Aug 2012 11:22:48 -0600 Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) Message-ID: <501965E8.2080209@oracle.com> Greetings, I have a fix for the following Linux specific FDS bug: 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux Here is the URL for the webrev: http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ What the fix does is reorder and slightly tweak the Makefile logic that supports the DEBUG_BINARIES make option: - when 'DEBUG_BINARIES=true' is specified, the '-g' option is added to the CFLAGS make variable and none of the other {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched - this fix prevents doubled '-g' options and combined '-g' and '-gstabs' options - depending on the particular Linux config being built, a compilation will have a single '-g' or a single '-gstabs' or neither of those options The Linux embedded builds doesn't support FDS yet so most of those compiles fall into the "neither" bucket... Thanks, in advance, for any reviews. Dan From mike.duigou at oracle.com Wed Aug 1 11:37:45 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 01 Aug 2012 18:37:45 +0000 Subject: hg: jdk8/tl/jdk: 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Message-ID: <20120801183804.137F7472EF@hg.openjdk.java.net> Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java From ahughes at redhat.com Wed Aug 1 14:13:37 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 01 Aug 2012 21:13:37 +0000 Subject: hg: jdk8/tl/jdk: 6844255: Potential stack corruption in GetJavaProperties Message-ID: <20120801211403.2FF9A472F5@hg.openjdk.java.net> Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c From coleen.phillimore at oracle.com Wed Aug 1 16:12:05 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 01 Aug 2012 23:12:05 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7129723: MAC: Some regression tests need to recognize Mac OS X platform Message-ID: <20120801231210.7A43D472FF@hg.openjdk.java.net> Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh From zhengyu.gu at oracle.com Wed Aug 1 17:54:28 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 02 Aug 2012 00:54:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20120802005434.AF72447301@hg.openjdk.java.net> Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8e69438de9c6 Merge From sean.mullan at oracle.com Thu Aug 2 07:43:22 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 02 Aug 2012 14:43:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120802144350.F260647318@hg.openjdk.java.net> Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e8bafdcefda Merge From daniel.daugherty at oracle.com Thu Aug 2 08:20:49 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 02 Aug 2012 09:20:49 -0600 Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) In-Reply-To: <501A9615.1070808@oracle.com> References: <501965E8.2080209@oracle.com> <501A9615.1070808@oracle.com> Message-ID: <501A9AD1.307@oracle.com> Thanks Fred! Dan On 8/2/12 9:00 AM, Frederic Parain wrote: > Looks good. > > Fred > > On 8/1/2012 19:22, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a fix for the following Linux specific FDS bug: >> >> 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ >> >> What the fix does is reorder and slightly tweak the Makefile logic >> that supports the DEBUG_BINARIES make option: >> >> - when 'DEBUG_BINARIES=true' is specified, the '-g' option is >> added to the CFLAGS make variable and none of the other >> {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched >> - this fix prevents doubled '-g' options and combined '-g' and >> '-gstabs' options >> - depending on the particular Linux config being built, a >> compilation will have a single '-g' or a single '-gstabs' or >> neither of those options >> >> The Linux embedded builds doesn't support FDS yet so most of >> those compiles fall into the "neither" bucket... >> >> Thanks, in advance, for any reviews. >> >> Dan >> > From ahughes at redhat.com Thu Aug 2 08:53:18 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 11:53:18 -0400 (EDT) Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) In-Reply-To: <501965E8.2080209@oracle.com> Message-ID: <604202083.7749717.1343922798542.JavaMail.root@redhat.com> ----- Original Message ----- > Greetings, > > I have a fix for the following Linux specific FDS bug: > > 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux > > Here is the URL for the webrev: > > http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ > > What the fix does is reorder and slightly tweak the Makefile logic > that supports the DEBUG_BINARIES make option: > > - when 'DEBUG_BINARIES=true' is specified, the '-g' option is > added to the CFLAGS make variable and none of the other > {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched > - this fix prevents doubled '-g' options and combined '-g' and > '-gstabs' options > - depending on the particular Linux config being built, a > compilation will have a single '-g' or a single '-gstabs' or > neither of those options > > The Linux embedded builds doesn't support FDS yet so most of > those compiles fall into the "neither" bucket... > > Thanks, in advance, for any reviews. > > Dan > > Looks good to me. Makes it much clearer than the early version that DEBUG_BINARIES effectively overrides everything else. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From daniel.daugherty at oracle.com Thu Aug 2 09:02:21 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 02 Aug 2012 10:02:21 -0600 Subject: Code review request for Linux DEBUG_BINARIES/FDS fix (7188168) In-Reply-To: <604202083.7749717.1343922798542.JavaMail.root@redhat.com> References: <604202083.7749717.1343922798542.JavaMail.root@redhat.com> Message-ID: <501AA48D.4060207@oracle.com> Thanks Andrew! Dan On 8/2/12 9:53 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> Greetings, >> >> I have a fix for the following Linux specific FDS bug: >> >> 7188168 4/4 7071904 broke the DEBUG_BINARIES option on Linux >> >> Here is the URL for the webrev: >> >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7188168-webrev/0/ >> >> What the fix does is reorder and slightly tweak the Makefile logic >> that supports the DEBUG_BINARIES make option: >> >> - when 'DEBUG_BINARIES=true' is specified, the '-g' option is >> added to the CFLAGS make variable and none of the other >> {DEBUG,FASTDEBUG,OPT}_CFLAGS variables are touched >> - this fix prevents doubled '-g' options and combined '-g' and >> '-gstabs' options >> - depending on the particular Linux config being built, a >> compilation will have a single '-g' or a single '-gstabs' or >> neither of those options >> >> The Linux embedded builds doesn't support FDS yet so most of >> those compiles fall into the "neither" bucket... >> >> Thanks, in advance, for any reviews. >> >> Dan >> >> > Looks good to me. Makes it much clearer than the early version that > DEBUG_BINARIES effectively overrides everything else. From daniel.daugherty at oracle.com Thu Aug 2 16:51:33 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 02 Aug 2012 23:51:33 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Message-ID: <20120802235137.63CAA47329@hg.openjdk.java.net> Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make From stuart.marks at oracle.com Thu Aug 2 18:10:45 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 03 Aug 2012 01:10:45 +0000 Subject: hg: jdk8/tl/jdk: 7187876: ClassCastException in TCPTransport.executeAcceptLoop Message-ID: <20120803011056.B618C47338@hg.openjdk.java.net> Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java From john.coomes at oracle.com Thu Aug 2 20:56:59 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:56:59 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120803035659.B4D6E47356@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:57:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:57:06 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120803035709.1D33347357@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:57:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:57:16 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120803035724.CA2F047358@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:57:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:57:34 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120803035738.D5C0447359@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From john.coomes at oracle.com Thu Aug 2 20:57:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 03:57:49 +0000 Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b50 for changeset e4bae5c53fca Message-ID: <20120803035841.1CD604735A@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags From john.coomes at oracle.com Thu Aug 2 21:00:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Aug 2012 04:00:28 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b50 for changeset b2d8a270f5f2 Message-ID: <20120803040037.A05BB4735B@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags From maurizio.cimadamore at oracle.com Fri Aug 3 02:15:32 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 03 Aug 2012 09:15:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120803091601.8756947361@hg.openjdk.java.net> Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! 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/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/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! 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/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java From xueming.shen at oracle.com Fri Aug 3 13:36:11 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 03 Aug 2012 20:36:11 +0000 Subject: hg: jdk8/tl/jdk: 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Message-ID: <20120803203637.C9C044736B@hg.openjdk.java.net> Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java From daniel.daugherty at oracle.com Fri Aug 3 20:31:57 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 04 Aug 2012 03:31:57 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7181175: Enable builds on Windows with MinGW/MSYS Message-ID: <20120804033202.4E2C747378@hg.openjdk.java.net> Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make From kumar.x.srinivasan at oracle.com Sat Aug 4 16:36:02 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 04 Aug 2012 23:36:02 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120804233656.5075B47389@hg.openjdk.java.net> Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java From daniel.daugherty at oracle.com Mon Aug 6 11:44:56 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 06 Aug 2012 18:44:56 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 13 new changesets Message-ID: <20120806184525.96A48473BD@hg.openjdk.java.net> Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! 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/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ff58dfd5b977 Merge Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e37a5219e297 Merge Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c3c2141203e7 Merge From yumin.qi at oracle.com Mon Aug 6 14:40:14 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Mon, 06 Aug 2012 14:40:14 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging Message-ID: <502039BE.6090108@oracle.com> Hi, Please give your comments of the changes about 6830717: replay of compilations would help with debugging. http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. contributed by Tom R (never). webrev: http://cr.openjdk.java.net/~minqi/6830717/ Thanks Yumin From keith.mcguigan at oracle.com Mon Aug 6 22:06:53 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 07 Aug 2012 05:06:53 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7116786: RFE: Detailed information on VerifyErrors Message-ID: <20120807050655.DA2E8473CD@hg.openjdk.java.net> Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar From alan.bateman at oracle.com Tue Aug 7 04:48:43 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Aug 2012 11:48:43 +0000 Subject: hg: jdk8/tl/jdk: 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Message-ID: <20120807114853.E377C473D2@hg.openjdk.java.net> Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh From lana.steuck at oracle.com Tue Aug 7 23:06:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:06:54 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120808060654.ECD174740F@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:06:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:06:54 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120808060658.0931F47410@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:03 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120808060714.543A047411@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:05 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120808060714.A9C1447412@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:10 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120808060731.B65B047413@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cfa70d7ac944 Merge From lana.steuck at oracle.com Tue Aug 7 23:07:26 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:26 +0000 Subject: hg: jdk8/tl/hotspot: 37 new changesets Message-ID: <20120808060917.2339E47414@hg.openjdk.java.net> Changeset: 54e66510c9cd Author: amurillo Date: 2012-07-13 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54e66510c9cd 7184050: new hotspot build - hs24-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8150fa46d2ed Author: jiangli Date: 2012-06-26 19:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8150fa46d2ed 7178145: Change constMethodOop::_exception_table to optionally inlined u2 table. Summary: Change constMethodOop::_exception_table to optionally inlined u2 table. Reviewed-by: bdelsart, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java + agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f0b82641fb7e Author: bdelsart Date: 2012-07-02 04:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0b82641fb7e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d68b1274b9ba Author: jiangli Date: 2012-07-05 18:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d68b1274b9ba 7180914: Compilation warning after: 7172967: Eliminate the constMethod's _method backpointer to the methodOop. Summary: Use read_pointer(J...) to access from 'constMethod' base in name_for_methodOop(), libjvm_db.c. Reviewed-by: kvn, coleenp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 161ae369407d Author: jiangli Date: 2012-07-05 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/161ae369407d 7181632: nsk classLoad001_14 failure and CompileTheWorld crash after 7178145. Summary: Need to copy the inlined exception table to the new constMethodOop during method rewriting. Reviewed-by: coleenp, dholmes ! src/share/vm/oops/methodOop.cpp Changeset: e74da3c2b827 Author: jiangli Date: 2012-07-13 20:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e74da3c2b827 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0bca41b2fa63 Author: jiangli Date: 2012-07-17 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bca41b2fa63 Merge Changeset: 922993931b3d Author: brutisso Date: 2012-07-11 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/922993931b3d 7178361: G1: Make sure that PrintGC and PrintGCDetails use the same timing for the GC pause Summary: Also reviewed by: vitalyd at gmail.com. Move the timing out of G1CollectorPolicy into the G1GCPhaseTimes class Reviewed-by: johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! 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/g1GCPhaseTimes.cpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 3a431b605145 Author: jmasa Date: 2012-07-16 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a431b605145 Merge ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 7553d441b878 Author: jmasa Date: 2012-07-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7553d441b878 Merge Changeset: 6d8f36bcef55 Author: jrose Date: 2012-07-12 00:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d8f36bcef55 6711908: JVM needs direct access to some annotations Summary: Add annotation extraction code to class file parser. Reviewed-by: twisti, jrose, kvn Contributed-by: michael.haupt at oracle.com ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.hpp Changeset: ed21db7b3fda Author: kvn Date: 2012-07-13 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed21db7b3fda 7123926: Some CTW test crash: !_control.contains(ctrl) Summary: Don't eliminate Integer::toString() call node during String concatenation optimization if it has several uses. Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: 56c4f88474b3 Author: twisti Date: 2012-07-16 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56c4f88474b3 7087357: JSR 292: remove obsolete code after 7085860 Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2c368ea3e844 Author: kvn Date: 2012-07-16 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c368ea3e844 7181494: cleanup avx and vectors code Summary: renamed mach nodes which use scalar AVX instructions, added integer vectors shuffling instructions Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/code/vmreg.hpp Changeset: 9c9fb30d2b3b Author: kvn Date: 2012-07-16 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c9fb30d2b3b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/unsafe.cpp Changeset: dd785aabe02b Author: kvn Date: 2012-07-17 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd785aabe02b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp Changeset: bc3e01899804 Author: kvn Date: 2012-07-19 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc3e01899804 Merge Changeset: d900d95bfdb0 Author: fparain Date: 2012-07-16 04:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d900d95bfdb0 7183754: Test runtime/6294277/Test6294277.sh runs wrong JVM Reviewed-by: kamg, coleenp, ctornqvi ! test/runtime/6294277/SourceDebugExtension.java - test/runtime/6294277/Test6294277.sh Changeset: 149c36689fcb Author: asaha Date: 2012-07-17 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/149c36689fcb 7053586: TEST: runtime/7020373/Test7020373.sh fails on 64-bit platforms Reviewed-by: kamg ! test/runtime/7020373/Test7020373.sh Changeset: 7e5976e66c62 Author: zgu Date: 2012-07-19 09:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e5976e66c62 7182543: NMT ON: Aggregate a few NMT related bugs Summary: 1) Fixed MemTrackWorker::generations_in_used() calculation 2) Ensured NMT not to leak memory recorders after shutdown 3) Used ThreadCritical to block safepoint safe threads Reviewed-by: acorn, coleenp, dholmes, kvn ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f1f45dddb0bd Author: zgu Date: 2012-07-16 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1f45dddb0bd 7181986: NMT ON: Assertion failure when running jdi ExpiredRequestDeletionTest Summary: Changed _query_lock to heap object from static object. Also fixed _query_lock and snapshot lock ranks, so they can participate deadlock detection. Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: d5bc62fcfac7 Author: zgu Date: 2012-07-19 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5bc62fcfac7 Merge ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 04a9b3789683 Author: zgu Date: 2012-07-16 14:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04a9b3789683 7181989: NMT ON: Assertion failure when NMT checks thread's native stack base address Summary: Assertion on stack base is not necessary Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memTracker.cpp Changeset: 58a04a45a549 Author: zgu Date: 2012-07-19 09:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58a04a45a549 Merge ! src/share/vm/services/memTracker.cpp Changeset: 950ed41429e5 Author: zgu Date: 2012-07-19 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/950ed41429e5 Merge Changeset: 12fc2571a6e2 Author: coleenp Date: 2012-07-20 12:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12fc2571a6e2 Merge - test/runtime/6294277/Test6294277.sh Changeset: bd54fe36b5e5 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd54fe36b5e5 Merge - test/runtime/6294277/Test6294277.sh Changeset: 15eb2b903b04 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15eb2b903b04 Added tag hs24-b17 for changeset bd54fe36b5e5 ! .hgtags Changeset: aba91a731143 Author: amurillo Date: 2012-07-23 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aba91a731143 7185775: new hotspot build - hs24-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fe94b4e7212b Author: asaha Date: 2012-07-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe94b4e7212b 7185550: TEST: runtime/7020373/Test7020373.sh fails because there is no test/runtime/7020373/testcase.jar Reviewed-by: coleenp ! test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: 43541217e9f7 Author: jiangli Date: 2012-07-26 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43541217e9f7 7187046: Crash in ClassFileParser on solaris-ia32 during RetransformClasses. Summary: Lower compiler optimization level when compiling jvmtiClassFileReconstituter.cpp as a workaround for the solaris x86 5.10 cc bug. Reviewed-by: kvn, coleenp ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make Changeset: 611e8a669a2c Author: dlong Date: 2012-07-16 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/611e8a669a2c 7147464: Java crashed while executing method with over 8k of dneg operations Summary: replace recursive method with iterative Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: a93a6d2c9e6c Author: jiangli Date: 2012-07-24 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a93a6d2c9e6c Merge Changeset: bcd1b9d98558 Author: jiangli Date: 2012-07-26 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcd1b9d98558 Merge Changeset: 72e0362c3f0c Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72e0362c3f0c Merge ! .hgtags - test/runtime/6294277/Test6294277.sh Changeset: 58f237a9e83a Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58f237a9e83a Added tag hs24-b18 for changeset 72e0362c3f0c ! .hgtags Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags From lana.steuck at oracle.com Tue Aug 7 23:07:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:56 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20120808061039.F37A747415@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c From ahughes at redhat.com Wed Aug 8 04:38:12 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 08 Aug 2012 11:38:12 +0000 Subject: hg: jdk8/tl/jdk: 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Message-ID: <20120808113853.0E03047419@hg.openjdk.java.net> Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c From alan.bateman at oracle.com Wed Aug 8 07:32:54 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 Aug 2012 14:32:54 +0000 Subject: hg: jdk8/tl/jdk: 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Message-ID: <20120808143325.73F714741B@hg.openjdk.java.net> Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java From kumar.x.srinivasan at oracle.com Wed Aug 8 09:33:24 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 08 Aug 2012 16:33:24 +0000 Subject: hg: jdk8/tl/jdk: 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Message-ID: <20120808163344.942374741F@hg.openjdk.java.net> Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java From sundararajan.athijegannathan at oracle.com Wed Aug 8 09:45:37 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 08 Aug 2012 16:45:37 +0000 Subject: hg: jdk8/tl/langtools: 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Message-ID: <20120808164541.2905947420@hg.openjdk.java.net> Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java From vladimir.kozlov at oracle.com Wed Aug 8 10:11:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Aug 2012 10:11:31 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <502039BE.6090108@oracle.com> References: <502039BE.6090108@oracle.com> Message-ID: <50229DC3.5080004@oracle.com> This looks good. Small note: I don't see skip_Replay variable usage in other places. Yumin, could you add replay to C1 compilations as next step? Thanks, Vladimir yumin.qi at oracle.com wrote: > Hi, > > Please give your comments of the changes about > 6830717: replay of compilations would help with debugging. > http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 > > Sometime jvm crashes in the process of compilation or in compiled > method. To reproduce the compilation process in debug JVM is helpful for > quickly identifying root cause. > To do recompilation, we collect data by using of SA (Serviceability > Agent) to extract application and system class data from core file. > Those information includes nmethod, methodOop, methodDataOop, > instanceKlass and corresponding ci counterparts. > With reconfiguring similar (not exactly same) compiling environment as > in the core file, try to compile again the failed java methods. > > contributed by Tom R (never). webrev: > > http://cr.openjdk.java.net/~minqi/6830717/ > > > Thanks > Yumin From roland.westrelin at oracle.com Wed Aug 8 10:29:29 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 08 Aug 2012 10:29:29 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <502039BE.6090108@oracle.com> References: <502039BE.6090108@oracle.com> Message-ID: <87lihpb8cm.fsf@oracle.com> > Please give your comments of the changes about > 6830717: replay of compilations would help with debugging. > http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 It looks good to me. Roland. From yumin.qi at oracle.com Wed Aug 8 10:30:27 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 08 Aug 2012 10:30:27 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <50229DC3.5080004@oracle.com> References: <502039BE.6090108@oracle.com> <50229DC3.5080004@oracle.com> Message-ID: <5022A233.4030308@oracle.com> Thanks. On 8/8/2012 10:11 AM, Vladimir Kozlov wrote: > This looks good. Small note: I don't see skip_Replay variable usage in > other places. > > Yumin, could you add replay to C1 compilations as next step? > I could do, file a bug and assign it to serviceability team --- if it assigned to me. It will be a low priority as I can see. If you want to assign this to your new hire, it is OK to me too. --Yumin From dmitry.samersoff at oracle.com Thu Aug 9 03:53:29 2012 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 09 Aug 2012 10:53:29 +0000 Subject: hg: jdk8/tl/jdk: 7183753: [TEST] Some colon in the diff for this test Message-ID: <20120809105414.95DC44744A@hg.openjdk.java.net> Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out From xueming.shen at oracle.com Thu Aug 9 10:15:49 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 09 Aug 2012 17:15:49 +0000 Subject: hg: jdk8/tl/jdk: 7189363: Regex Pattern compilation buggy for special sequences Message-ID: <20120809171612.1831D4744F@hg.openjdk.java.net> Changeset: 717ed00b7787 Author: sherman Date: 2012-08-09 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/717ed00b7787 7189363: Regex Pattern compilation buggy for special sequences Summary: fixed the incorrect implementation in expr(...) Reviewed-by: psandoz, alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From john.coomes at oracle.com Fri Aug 10 02:28:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 09:28:17 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120810092818.9643F4747D@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From john.coomes at oracle.com Fri Aug 10 02:28:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 09:28:28 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120810092839.4D93D4747E@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From john.coomes at oracle.com Fri Aug 10 02:28:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 09:28:49 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120810092919.63E214747F@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From john.coomes at oracle.com Fri Aug 10 02:29:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 09:29:27 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120810092946.71DA347480@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From john.coomes at oracle.com Fri Aug 10 02:30:48 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 09:30:48 +0000 Subject: hg: hsx/hotspot-rt/jdk: 30 new changesets Message-ID: <20120810093819.B8AFC47481@hg.openjdk.java.net> Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: 773474da570b Author: khazra Date: 2012-07-18 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/773474da570b 7185051: Remove TestProviderLeak.java from the ProblemList Summary: Remove TestProviderLeak.java from jdk test problem list. Reviewed-by: khazra Contributed-by: dan.xu at oracle.com ! test/ProblemList.txt Changeset: 2c2e4ecc8f7e Author: chegar Date: 2012-07-19 18:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c2e4ecc8f7e 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Reviewed-by: chegar Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/net/DatagramPacket/ReuseBuf.java Changeset: 84cd98a5641c Author: sherman Date: 2012-07-19 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/84cd98a5641c 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Summary: to support Unicode nfd/nfc file path on Macos Reviewed-by: alanb ! make/java/nio/Makefile ! src/share/native/java/io/io_util.h ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h + src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c + test/java/io/File/MacPathTest.java + test/java/io/File/MacPathTest.sh + test/java/nio/file/Path/MacPathTest.java + test/java/nio/file/Path/MacPathTest.sh Changeset: 5dc3f32c0d26 Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5dc3f32c0d26 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7e49c6f7507e Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7e49c6f7507e 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java Changeset: 11d5ddc6a6d4 Author: alanb Date: 2012-07-22 20:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11d5ddc6a6d4 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Reviewed-by: chegar ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java Changeset: f7731fc8c98a Author: weijun Date: 2012-07-24 09:20 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f7731fc8c98a 7179796: GSSExceptionImpl outputs duplicate mech oid Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java Changeset: e0e7cc711bda Author: xuelei Date: 2012-07-24 03:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e0e7cc711bda 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Reviewed-by: vinnie ! test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: a18f2806bef2 Author: sherman Date: 2012-07-24 12:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a18f2806bef2 6653797: Reimplement JDK charset repository charsets.jar Summary: Migrated all jis based charsets to new implementation Reviewed-by: okutsu ! make/java/nio/FILES_java.gmk ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/DoubleByte-X.java.template + make/tools/CharsetMapping/JIS_X_0201.c2b ! make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/JIS_X_0208.map + make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b + make/tools/CharsetMapping/JIS_X_0208_MS5022X.map + make/tools/CharsetMapping/JIS_X_0208_MS932.map + make/tools/CharsetMapping/JIS_X_0208_MS932.nr + make/tools/CharsetMapping/JIS_X_0208_Solaris.map + make/tools/CharsetMapping/JIS_X_0208_Solaris.nr + make/tools/CharsetMapping/JIS_X_0212.map + make/tools/CharsetMapping/JIS_X_0212_MS5022X.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.nr + make/tools/CharsetMapping/PCK.c2b + make/tools/CharsetMapping/PCK.map + make/tools/CharsetMapping/PCK.nr + make/tools/CharsetMapping/SJIS.c2b + make/tools/CharsetMapping/SJIS.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java + test/sun/nio/cs/OLD/EUC_JP_OLD.java + test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java + test/sun/nio/cs/OLD/JIS_X_0201_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0208_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_OLD.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/PCK_OLD.java + test/sun/nio/cs/OLD/SJIS_OLD.java + test/sun/nio/cs/OLD/SingleByteDecoder.java + test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestX11JIS0201.java Changeset: 74ceda3a98a0 Author: khazra Date: 2012-07-24 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/74ceda3a98a0 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Summary: Change implementation to enable user without administrative privileges to call flush Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! test/ProblemList.txt Changeset: 42eac77355d2 Author: sherman Date: 2012-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/42eac77355d2 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Summary: fixed the test case Reviewed-by: alanb ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java Changeset: f267302093d4 Author: weijun Date: 2012-07-26 20:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f267302093d4 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh Changeset: 35fec642fd32 Author: coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 018e555a7a07 Author: dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy Changeset: a093f6247b52 Author: lana Date: 2012-07-27 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a093f6247b52 Merge Changeset: 78644d4a9a32 Author: dxu Date: 2012-07-30 04:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/78644d4a9a32 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java Changeset: 38263aa28324 Author: michaelm Date: 2012-07-30 22:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/38263aa28324 7120665: Change Java SE spec so that external networking not required Reviewed-by: alanb ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/package.html Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags From john.coomes at oracle.com Fri Aug 10 02:40:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Aug 2012 09:40:56 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b51 for changeset c4cd4cab2220 Message-ID: <20120810094109.89CDA47482@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags From sean.mullan at oracle.com Fri Aug 10 06:19:51 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 10 Aug 2012 13:19:51 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120810132030.15BD147483@hg.openjdk.java.net> Changeset: 57b5025548d6 Author: mullan Date: 2012-08-10 09:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57b5025548d6 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null Reviewed-by: valeriep ! src/share/classes/sun/security/provider/certpath/BasicChecker.java Changeset: 629f357fc17b Author: mullan Date: 2012-08-10 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/629f357fc17b Merge From valerie.peng at oracle.com Fri Aug 10 13:11:14 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 10 Aug 2012 20:11:14 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120810201145.E123447493@hg.openjdk.java.net> Changeset: 114fbbeb8f75 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/114fbbeb8f75 7107613: scalability bloker in javax.crypto.CryptoPermissions Summary: Changed the type of field "perms" from Hashtable to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/CryptoPermissions.java Changeset: 175036ada2e3 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/175036ada2e3 7107616: scalability bloker in javax.crypto.JceSecurityManager Summary: Changed the type of field "exemptCache" from HashMap to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/JceSecurityManager.java Changeset: 9e97dacbfd35 Author: valeriep Date: 2012-08-10 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e97dacbfd35 7185471: Avoid key expansion when AES cipher is re-init w/ the same key Summary: Saved the last cipher key value and skip key expansion if key value is the same. Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/crypto/provider/AESCrypt.java From lana.steuck at oracle.com Fri Aug 10 14:01:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:07 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120810210107.E226347494@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:07 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120810210111.8CE8547495@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:09 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120810210118.0A27C47496@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:14 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:14 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120810210121.DBA8347497@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1d2db0e5eabc Merge From lana.steuck at oracle.com Fri Aug 10 14:01:21 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:21 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120810210129.0D22B47498@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:12 +0000 Subject: hg: jdk8/tl/hotspot: 15 new changesets Message-ID: <20120810210149.78C0C47499@hg.openjdk.java.net> Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! 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/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 14:01:25 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:25 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20120810210210.96A404749A@hg.openjdk.java.net> Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8649489aff Merge Changeset: 449c17c7a63a Author: lana Date: 2012-08-10 12:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/449c17c7a63a Merge Changeset: e8b14276d434 Author: lana Date: 2012-08-10 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8b14276d434 Merge From daniel.daugherty at oracle.com Sat Aug 11 10:18:11 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 11 Aug 2012 17:18:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Message-ID: <20120811171821.36A8B474B8@hg.openjdk.java.net> Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile From chris.hegarty at oracle.com Sun Aug 12 14:57:58 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 12 Aug 2012 21:57:58 +0000 Subject: hg: jdk8/tl/jdk: 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Message-ID: <20120812215828.DDB64474C8@hg.openjdk.java.net> Changeset: e7d125f2575b Author: chegar Date: 2012-08-12 22:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Reviewed-by: chegar Contributed-by: Christian Schulte ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/ProxySelector/MultiThreadedSystemProxies.java From luchsh at linux.vnet.ibm.com Mon Aug 13 04:52:47 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Mon, 13 Aug 2012 11:52:47 +0000 Subject: hg: jdk8/tl/jdk: 7190219: (bf) CharBuffer.put(String, int, int) modifies position even if BufferOverflowException thrown Message-ID: <20120813115315.AA9ED474D7@hg.openjdk.java.net> Changeset: bf0c6f91bc22 Author: luchsh Date: 2012-08-13 19:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf0c6f91bc22 7190219: (bf) CharBuffer.put(String,int,int) modifies position even if BufferOverflowException thrown Reviewed-by: alanb ! src/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java From chris.hegarty at oracle.com Mon Aug 13 05:42:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 13 Aug 2012 12:42:04 +0000 Subject: hg: jdk8/tl/jdk: 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Message-ID: <20120813124227.27CDB474DB@hg.openjdk.java.net> Changeset: 399c2adf3ad6 Author: chegar Date: 2012-08-13 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/399c2adf3ad6 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Reviewed-by: chegar Contributed-by: Shirish Kuncolienkar ! src/solaris/native/java/net/NetworkInterface.c From vincent.x.ryan at oracle.com Mon Aug 13 06:13:18 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 13 Aug 2012 13:13:18 +0000 Subject: hg: jdk8/tl/jdk: 7190945: pkcs11 problem loading NSS libs on Ubuntu Message-ID: <20120813131337.54712474DD@hg.openjdk.java.net> Changeset: 5e5bdfd18325 Author: vinnie Date: 2012-08-13 14:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e5bdfd18325 7190945: pkcs11 problem loading NSS libs on Ubuntu Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/pkcs11/Secmod.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/keystore.jks From jonathan.gibbons at oracle.com Mon Aug 13 12:16:08 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 Aug 2012 19:16:08 +0000 Subject: hg: jdk8/tl/jdk: 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Message-ID: <20120813191618.C7FEE474E6@hg.openjdk.java.net> Changeset: f0bf7358ba23 Author: jfranck Date: 2012-08-09 17:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0bf7358ba23 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerAnnotation.java From christian.thalinger at oracle.com Mon Aug 13 17:02:36 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Aug 2012 17:02:36 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <502039BE.6090108@oracle.com> References: <502039BE.6090108@oracle.com> Message-ID: <73AAAA90-0AFC-4F91-9BBF-A71BC3924735@oracle.com> On Aug 6, 2012, at 2:40 PM, yumin.qi at oracle.com wrote: > Hi, > > Please give your comments of the changes about > 6830717: replay of compilations would help with debugging. > http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 > > Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. > To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. > With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. > > contributed by Tom R (never). webrev: > > http://cr.openjdk.java.net/~minqi/6830717/ src/share/vm/ci/ciReplay.cpp: 603 if (strcmp(field_signature, "[B") == 0) { 604 oop value = oopFactory::new_byteArray(length, CHECK); 605 java_mirror->obj_field_put(fd.offset(), value); 606 } else if (strcmp(field_signature, "[Z") == 0) { 607 oop value = oopFactory::new_boolArray(length, CHECK); 608 java_mirror->obj_field_put(fd.offset(), value); 609 } else if (strcmp(field_signature, "[C") == 0) { 610 oop value = oopFactory::new_charArray(length, CHECK); 611 java_mirror->obj_field_put(fd.offset(), value); 612 } else if (strcmp(field_signature, "[S") == 0) { 613 oop value = oopFactory::new_shortArray(length, CHECK); 614 java_mirror->obj_field_put(fd.offset(), value); 615 } else if (strcmp(field_signature, "[F") == 0) { 616 oop value = oopFactory::new_singleArray(length, CHECK); 617 java_mirror->obj_field_put(fd.offset(), value); 618 } else if (strcmp(field_signature, "[D") == 0) { 619 oop value = oopFactory::new_doubleArray(length, CHECK); 620 java_mirror->obj_field_put(fd.offset(), value); 621 } else if (strcmp(field_signature, "[I") == 0) { 622 oop value = oopFactory::new_intArray(length, CHECK); 623 java_mirror->obj_field_put(fd.offset(), value); 624 } else if (strcmp(field_signature, "[J") == 0) { 625 oop value = oopFactory::new_longArray(length, CHECK); 626 java_mirror->obj_field_put(fd.offset(), value); 627 } else if (field_signature[0] == '[' && field_signature[1] == 'L') { Can't we switch on the second character? And move this call: 630 java_mirror->obj_field_put(fd.offset(), value); out of the switch? 637 if (strcmp(field_signature, "I") == 0) { 638 int value = atoi(string_value); 639 java_mirror->int_field_put(fd.offset(), value); 640 } else if (strcmp(field_signature, "B") == 0) { 641 int value = atoi(string_value); 642 java_mirror->byte_field_put(fd.offset(), value); 643 } else if (strcmp(field_signature, "C") == 0) { 644 int value = atoi(string_value); 645 java_mirror->char_field_put(fd.offset(), value); 646 } else if (strcmp(field_signature, "S") == 0) { 647 int value = atoi(string_value); 648 java_mirror->short_field_put(fd.offset(), value); 649 } else if (strcmp(field_signature, "Z") == 0) { 650 int value = atol(string_value); 651 java_mirror->bool_field_put(fd.offset(), value); 652 } else if (strcmp(field_signature, "J") == 0) { 653 jlong value; 654 if (sscanf(string_value, INT64_FORMAT, &value) != 1) { 655 fprintf(stderr, "Error parsing long: %s\n", string_value); 656 return; 657 } 658 java_mirror->long_field_put(fd.offset(), value); 659 } else if (strcmp(field_signature, "F") == 0) { 660 float value = atof(string_value); 661 java_mirror->float_field_put(fd.offset(), value); 662 } else if (strcmp(field_signature, "D") == 0) { 663 double value = atof(string_value); 664 java_mirror->double_field_put(fd.offset(), value); 665 } else if (strcmp(field_signature, "Ljava/lang/String;") == 0) { 666 Handle value = java_lang_String::create_from_str(string_value, CHECK); 667 java_mirror->obj_field_put(fd.offset(), value()); 668 } else if (field_signature[0] == 'L') { Same here (not the put though)? Otherwise it looks good. -- Chris > > Thanks > Yumin From staffan.larsen at oracle.com Tue Aug 14 00:50:03 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 14 Aug 2012 09:50:03 +0200 Subject: 7090324: gclog rotation via external tool In-Reply-To: <5017B761.5070203@lab.ntt.co.jp> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> Message-ID: <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> Hi Yasumasa, This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. [1] http://openjdk.java.net/jeps/158 /Staffan On 31 jul 2012, at 12:45, Yasumasa Suenaga wrote: > Hi, > > I've posted a patch for gc log rotation via jinfo tool last year. > Then I received an email that essence of my patch will be implemented as > "subcommands" of jcmd. > > Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to > implement function of gclog rotation. > > Will this RFE be implemented? > > I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. > So, if this RFE is not implemented for a while, I would like to contribute > patch for jcmd. > > > Regards, > > Yasumasa > > > On 2011/09/29 21:15, James Melvin wrote: >> Hi Yasumasa, >> >> Thanks very much for your OpenJDK contribution! As part of the effort to >> port JRockit features to HotSpot, we plan to introduce a consolidated >> commandline serviceability tool (jcmd) to potentially replace many of >> the existing tools in the bin directory, such as jmap, jstack, jinfo and >> others. Over the next few update releases, we plan to add several jcmd >> *subcommands* instead to accomplish specific tasks or affect the running >> JVM instance. We'd like to use the essence of your contribution in one >> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >> begin rotating GC logs. We hope you find this attractive and hope you >> will help review and perfect the change. >> >> Thanks, >> >> Jim Melvin >> Sr. Engineering Manager >> Oracle >> >> >> >> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>> (I've changed subject of this email to new RFE.) >>> >>> This RFE is enhancement of current gclog implementation. >>> So, I'd like to discuss about rotating gclog. >>> >>> My customers need gclog rotation which is invoked by external trigger. >>> So I've requested this RFE and made a patch. >>> >>> >>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>> The aim of this RFE is to synchronize gclog and the other logs. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> (2011/09/22 20:55), Rainer Jung wrote: >>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>> >>>>> Yasumasa, >>>>> >>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>> solution. >>>>>> However, Windows usually doesn't have syslog. >>>>>> >>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>> independent in realtime. >>>>> >>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>> as well as numerous syslog implementations. >>>>> >>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>> server and now it allows for developers to send a structured events from >>>>> theirs application. >>>> >>>> AFAIK log rotation for loggc is already implemented though not >>>> necessarily yet released. The change discussed here is about supporting >>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>> only rotating by size or time via a startup parameter. >>>> >>>> If you want support for syslog or Windows APIs included, it would be >>>> best to start a new discussion. >>>> >>>> A GC log for an application under load might easily produce a block of >>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>> for log file rotation can be argued away by referring to syslog or >>>> Windows log API as the correct solution. >>>> >>>> The messages are not really line formatted, the format can vary a lot >>>> (depending on the excat XX switches), the traffic can be quite high and >>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>> risk in writing it out with very little latency. In addition, for >>>> analysis, you wouldn't want to look at each event individually, but >>>> instead process the whole file through a script or tool, which should >>>> not depend on the output specifics of a platform specific log apparatus. >>>> >>>> Regards, >>>> >>>> Rainer >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120814/29f831f1/attachment.html From suenaga.yasumasa at lab.ntt.co.jp Tue Aug 14 02:20:19 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Tue, 14 Aug 2012 18:20:19 +0900 Subject: 7090324: gclog rotation via external tool In-Reply-To: <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> Message-ID: <502A1853.70508@lab.ntt.co.jp> Hi Staffan, May I ask you 2 questions about this JEP? 1. One of goals of this JEP is defined as following: "File rotation of log files by size (similar to what is available for GC logs today)" My patch realizes log rotation by external trigger. 7090324 is included in this JEP? (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html Could you include this RFE in this JEP? If we use log rotation, I think that name of logs is very important for log management. Thanks, Yasumasa On 2012/08/14 16:50, Staffan Larsen wrote: > Hi Yasumasa, > > This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. > > [1] http://openjdk.java.net/jeps/158 > > /Staffan > > On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: > >> Hi, >> >> I've posted a patch for gc log rotation via jinfo tool last year. >> Then I received an email that essence of my patch will be implemented as >> "subcommands" of jcmd. >> >> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >> implement function of gclog rotation. >> >> Will this RFE be implemented? >> >> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >> So, if this RFE is not implemented for a while, I would like to contribute >> patch for jcmd. >> >> >> Regards, >> >> Yasumasa >> >> >> On 2011/09/29 21:15, James Melvin wrote: >>> Hi Yasumasa, >>> >>> Thanks very much for your OpenJDK contribution! As part of the effort to >>> port JRockit features to HotSpot, we plan to introduce a consolidated >>> commandline serviceability tool (jcmd) to potentially replace many of >>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>> others. Over the next few update releases, we plan to add several jcmd >>> *subcommands* instead to accomplish specific tasks or affect the running >>> JVM instance. We'd like to use the essence of your contribution in one >>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>> begin rotating GC logs. We hope you find this attractive and hope you >>> will help review and perfect the change. >>> >>> Thanks, >>> >>> Jim Melvin >>> Sr. Engineering Manager >>> Oracle >>> >>> >>> >>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>> (I've changed subject of this email to new RFE.) >>>> >>>> This RFE is enhancement of current gclog implementation. >>>> So, I'd like to discuss about rotating gclog. >>>> >>>> My customers need gclog rotation which is invoked by external trigger. >>>> So I've requested this RFE and made a patch. >>>> >>>> >>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>> The aim of this RFE is to synchronize gclog and the other logs. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>> >>>>>> Yasumasa, >>>>>> >>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>> solution. >>>>>>> However, Windows usually doesn't have syslog. >>>>>>> >>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>> independent in realtime. >>>>>> >>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>> as well as numerous syslog implementations. >>>>>> >>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>> server and now it allows for developers to send a structured events from >>>>>> theirs application. >>>>> >>>>> AFAIK log rotation for loggc is already implemented though not >>>>> necessarily yet released. The change discussed here is about supporting >>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>> only rotating by size or time via a startup parameter. >>>>> >>>>> If you want support for syslog or Windows APIs included, it would be >>>>> best to start a new discussion. >>>>> >>>>> A GC log for an application under load might easily produce a block of >>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>> for log file rotation can be argued away by referring to syslog or >>>>> Windows log API as the correct solution. >>>>> >>>>> The messages are not really line formatted, the format can vary a lot >>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>> risk in writing it out with very little latency. In addition, for >>>>> analysis, you wouldn't want to look at each event individually, but >>>>> instead process the whole file through a script or tool, which should >>>>> not depend on the output specifics of a platform specific log apparatus. >>>>> >>>>> Regards, >>>>> >>>>> Rainer >>>>> >>>> >> > From kirk at kodewerk.com Tue Aug 14 02:26:53 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 14 Aug 2012 11:26:53 +0200 Subject: 7090324: gclog rotation via external tool In-Reply-To: <502A1853.70508@lab.ntt.co.jp> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> Message-ID: Hi Yasumasa, I'm not sure that log file rotation is a part of this JEP. However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. Regards, Kirk On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: > Hi Staffan, > > May I ask you 2 questions about this JEP? > > 1. One of goals of this JEP is defined as following: > "File rotation of log files by size (similar to what is available for GC logs today)" > My patch realizes log rotation by external trigger. > 7090324 is included in this JEP? > (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) > > 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html > Could you include this RFE in this JEP? > If we use log rotation, I think that name of logs is very important for log management. > > > Thanks, > > Yasumasa > > > On 2012/08/14 16:50, Staffan Larsen wrote: >> Hi Yasumasa, >> >> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >> >> [1] http://openjdk.java.net/jeps/158 >> >> /Staffan >> >> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >> >>> Hi, >>> >>> I've posted a patch for gc log rotation via jinfo tool last year. >>> Then I received an email that essence of my patch will be implemented as >>> "subcommands" of jcmd. >>> >>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>> implement function of gclog rotation. >>> >>> Will this RFE be implemented? >>> >>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>> So, if this RFE is not implemented for a while, I would like to contribute >>> patch for jcmd. >>> >>> >>> Regards, >>> >>> Yasumasa >>> >>> >>> On 2011/09/29 21:15, James Melvin wrote: >>>> Hi Yasumasa, >>>> >>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>> commandline serviceability tool (jcmd) to potentially replace many of >>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>> others. Over the next few update releases, we plan to add several jcmd >>>> *subcommands* instead to accomplish specific tasks or affect the running >>>> JVM instance. We'd like to use the essence of your contribution in one >>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>> begin rotating GC logs. We hope you find this attractive and hope you >>>> will help review and perfect the change. >>>> >>>> Thanks, >>>> >>>> Jim Melvin >>>> Sr. Engineering Manager >>>> Oracle >>>> >>>> >>>> >>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>> (I've changed subject of this email to new RFE.) >>>>> >>>>> This RFE is enhancement of current gclog implementation. >>>>> So, I'd like to discuss about rotating gclog. >>>>> >>>>> My customers need gclog rotation which is invoked by external trigger. >>>>> So I've requested this RFE and made a patch. >>>>> >>>>> >>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>> >>>>>>> Yasumasa, >>>>>>> >>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>> solution. >>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>> >>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>> independent in realtime. >>>>>>> >>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>> as well as numerous syslog implementations. >>>>>>> >>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>> server and now it allows for developers to send a structured events from >>>>>>> theirs application. >>>>>> >>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>> necessarily yet released. The change discussed here is about supporting >>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>> only rotating by size or time via a startup parameter. >>>>>> >>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>> best to start a new discussion. >>>>>> >>>>>> A GC log for an application under load might easily produce a block of >>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>> for log file rotation can be argued away by referring to syslog or >>>>>> Windows log API as the correct solution. >>>>>> >>>>>> The messages are not really line formatted, the format can vary a lot >>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>> risk in writing it out with very little latency. In addition, for >>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>> instead process the whole file through a script or tool, which should >>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rainer >>>>>> >>>>> >>> >> > From Dmitry.Samersoff at oracle.com Tue Aug 14 03:17:20 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 14 Aug 2012 14:17:20 +0400 Subject: JEP 158: Unified JVM logging In-Reply-To: References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> Message-ID: <502A25B0.20004@oracle.com> Kirk, > However I do have very serious concerns about this JEP in that it > doesn't fix the problems that exist in current logging frameworks, > it only mimics them. > http://openjdk.java.net/jeps/158 Any comments is much appreciated. Personally, I think that log rotation is out of scope and responsibility of JVM. -Dmitry On 2012-08-14 13:26, Kirk Pepperdine wrote: > Hi Yasumasa, > > I'm not sure that log file rotation is a part of this JEP. > However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. > > Regards, > Kirk > > On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: > >> Hi Staffan, >> >> May I ask you 2 questions about this JEP? >> >> 1. One of goals of this JEP is defined as following: >> "File rotation of log files by size (similar to what is available for GC logs today)" >> My patch realizes log rotation by external trigger. >> 7090324 is included in this JEP? >> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >> >> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >> Could you include this RFE in this JEP? >> If we use log rotation, I think that name of logs is very important for log management. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2012/08/14 16:50, Staffan Larsen wrote: >>> Hi Yasumasa, >>> >>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>> >>> [1] http://openjdk.java.net/jeps/158 >>> >>> /Staffan >>> >>> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >>> >>>> Hi, >>>> >>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>> Then I received an email that essence of my patch will be implemented as >>>> "subcommands" of jcmd. >>>> >>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>> implement function of gclog rotation. >>>> >>>> Will this RFE be implemented? >>>> >>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>> So, if this RFE is not implemented for a while, I would like to contribute >>>> patch for jcmd. >>>> >>>> >>>> Regards, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2011/09/29 21:15, James Melvin wrote: >>>>> Hi Yasumasa, >>>>> >>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>> others. Over the next few update releases, we plan to add several jcmd >>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>> will help review and perfect the change. >>>>> >>>>> Thanks, >>>>> >>>>> Jim Melvin >>>>> Sr. Engineering Manager >>>>> Oracle >>>>> >>>>> >>>>> >>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>> (I've changed subject of this email to new RFE.) >>>>>> >>>>>> This RFE is enhancement of current gclog implementation. >>>>>> So, I'd like to discuss about rotating gclog. >>>>>> >>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>> So I've requested this RFE and made a patch. >>>>>> >>>>>> >>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>> >>>>>>>> Yasumasa, >>>>>>>> >>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>> solution. >>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>> >>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>> independent in realtime. >>>>>>>> >>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>> as well as numerous syslog implementations. >>>>>>>> >>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>> theirs application. >>>>>>> >>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>> only rotating by size or time via a startup parameter. >>>>>>> >>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>> best to start a new discussion. >>>>>>> >>>>>>> A GC log for an application under load might easily produce a block of >>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>> Windows log API as the correct solution. >>>>>>> >>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>> instead process the whole file through a script or tool, which should >>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Rainer >>>>>>> >>>>>> >>>> >>> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From suenaga.yasumasa at lab.ntt.co.jp Tue Aug 14 03:56:37 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Tue, 14 Aug 2012 19:56:37 +0900 Subject: JEP 158: Unified JVM logging In-Reply-To: <502A25B0.20004@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: <502A2EE5.4050705@lab.ntt.co.jp> Hi, Other softwares (e.g. syslog, apache) are implemented log rotation support. When these software receives SIGHUP, they close current log and reopen it. I think that JVM should be supported same level of log management at least. Current implementation, JVM open logs at start, and never close it. So we can't have timing of moving and archiving logs. JVM have to run on Windows. However, Windows is not implemented signal trigger. (BREAK is reserved for Thread-Dump) Thus I think that JVM should have function of log rotation in multi-platform. Thanks, Yasumasa On 2012/08/14 19:17, Dmitry Samersoff wrote: > Kirk, > >> However I do have very serious concerns about this JEP in that it >> doesn't fix the problems that exist in current logging frameworks, >> it only mimics them. > >> http://openjdk.java.net/jeps/158 > > Any comments is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: >> Hi Yasumasa, >> >> I'm not sure that log file rotation is a part of this JEP. >> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. >> >> Regards, >> Kirk >> >> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: >> >>> Hi Staffan, >>> >>> May I ask you 2 questions about this JEP? >>> >>> 1. One of goals of this JEP is defined as following: >>> "File rotation of log files by size (similar to what is available for GC logs today)" >>> My patch realizes log rotation by external trigger. >>> 7090324 is included in this JEP? >>> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >>> >>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>> Could you include this RFE in this JEP? >>> If we use log rotation, I think that name of logs is very important for log management. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>> Hi Yasumasa, >>>> >>>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>>> >>>> [1] http://openjdk.java.net/jeps/158 >>>> >>>> /Staffan >>>> >>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga> wrote: >>>> >>>>> Hi, >>>>> >>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>> Then I received an email that essence of my patch will be implemented as >>>>> "subcommands" of jcmd. >>>>> >>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>>> implement function of gclog rotation. >>>>> >>>>> Will this RFE be implemented? >>>>> >>>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>>> So, if this RFE is not implemented for a while, I would like to contribute >>>>> patch for jcmd. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>>> others. Over the next few update releases, we plan to add several jcmd >>>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>> will help review and perfect the change. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim Melvin >>>>>> Sr. Engineering Manager >>>>>> Oracle >>>>>> >>>>>> >>>>>> >>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>> (I've changed subject of this email to new RFE.) >>>>>>> >>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>> >>>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>>> So I've requested this RFE and made a patch. >>>>>>> >>>>>>> >>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>> >>>>>>>>> Yasumasa, >>>>>>>>> >>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>> solution. >>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>> >>>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>>> independent in realtime. >>>>>>>>> >>>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>>> as well as numerous syslog implementations. >>>>>>>>> >>>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>>> theirs application. >>>>>>>> >>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>> >>>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>>> best to start a new discussion. >>>>>>>> >>>>>>>> A GC log for an application under load might easily produce a block of >>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>> Windows log API as the correct solution. >>>>>>>> >>>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>> instead process the whole file through a script or tool, which should >>>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Rainer >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > > From zhengyu.gu at oracle.com Tue Aug 14 13:00:31 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 14 Aug 2012 20:00:31 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Message-ID: <20120814200037.ED1E14751A@hg.openjdk.java.net> Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp From kirk at kodewerk.com Wed Aug 15 01:44:15 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 15 Aug 2012 10:44:15 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <502A25B0.20004@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: Hi Dmitry, Lets start with this. Common logging command-line options for all components Logging is performed at different levels: error, warning, info, debug, trace Logging messages are in human-readable plain text IMHO, these current set of goals are based on the assumptions that all component is hierarchical in nature and that they will log the same way without the possibility of binary dumps. I would argue these assumptions over-reach and preclude certain types of logging that take place in the JVM today. The current system of command-line (experimental) options follow a format that is quite consistent. The options provide semantic meaning as to what will be logged. This semantic meaning is lost when we reduce everything to the level of error, warning, info, debug and trace. It's sets up arbitrary categories in which developers will be left to decide what level a particular activity should be logged at. To make this real I'll use the -XX:+PrintTenuringDistribution flag as an example. When I set that flag it's very clear what's to be logged. My question is, should this be logged at the info level? How about debug? Maybe trace? And if I set those levels, what else comes along for the ride? IOWs, if I attempt to keep the same model of GC logging, we'd need different levels. If we need different levels then we're about to violate the first goal. What this example suggests is that gc logging would be better served by using categories (or subjects if we can take something from the pub/sub metaphor) or tags or labels or what ever you want to call them. Using tags, I can create a system of levels using error, warning, info, debug, and trace if that fits how I'm setting up logging. But from levels it's difficult to implement things using categories. This is a case where the one of the non-goals should be, we shouldn't prevent people from structuring their logs as they see best fits the component they are instrumenting. The non-goals that should be reconsidered is to force human-readability. I would argue that this is again over-reaching in that properly structured log files should almost *never* be read by a human. In the cases why force an unnecessary requirement. I say this because I've run into a number of applications where logging was the primary bottleneck. In those cases there were two primary problems, one was bulk and the other was threading (lock contention which I shan't address here). Now while trying to solve the problem of bulkiness and lock contention might be considered a premature optimization at this stage and I certainty wouldn't disagree, I would not like to see designs or specifications that would naturally preclude some very obvious solutions. One of the solutions to bulk is to use a more compact format be some form of binary. That option has been taken away for what I would call an ideological requirement. There is no technical reason why I shouldn't be able to log in binary other than connivence. In addition, you don't know what else is happening on the system (disk??) you're logging to so it behoves you to be as light as possible. I'll leave it at this for now. -- Kirk On 2012-08-14, at 12:17 PM, Dmitry Samersoff wrote: > Kirk, > >> However I do have very serious concerns about this JEP in that it >> doesn't fix the problems that exist in current logging frameworks, >> it only mimics them. > >> http://openjdk.java.net/jeps/158 > > Any comments is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: >> Hi Yasumasa, >> >> I'm not sure that log file rotation is a part of this JEP. >> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. >> >> Regards, >> Kirk >> >> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: >> >>> Hi Staffan, >>> >>> May I ask you 2 questions about this JEP? >>> >>> 1. One of goals of this JEP is defined as following: >>> "File rotation of log files by size (similar to what is available for GC logs today)" >>> My patch realizes log rotation by external trigger. >>> 7090324 is included in this JEP? >>> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >>> >>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>> Could you include this RFE in this JEP? >>> If we use log rotation, I think that name of logs is very important for log management. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>> Hi Yasumasa, >>>> >>>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>>> >>>> [1] http://openjdk.java.net/jeps/158 >>>> >>>> /Staffan >>>> >>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >>>> >>>>> Hi, >>>>> >>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>> Then I received an email that essence of my patch will be implemented as >>>>> "subcommands" of jcmd. >>>>> >>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>>> implement function of gclog rotation. >>>>> >>>>> Will this RFE be implemented? >>>>> >>>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>>> So, if this RFE is not implemented for a while, I would like to contribute >>>>> patch for jcmd. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>>> others. Over the next few update releases, we plan to add several jcmd >>>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>> will help review and perfect the change. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim Melvin >>>>>> Sr. Engineering Manager >>>>>> Oracle >>>>>> >>>>>> >>>>>> >>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>> (I've changed subject of this email to new RFE.) >>>>>>> >>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>> >>>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>>> So I've requested this RFE and made a patch. >>>>>>> >>>>>>> >>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>> >>>>>>>>> Yasumasa, >>>>>>>>> >>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>> solution. >>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>> >>>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>>> independent in realtime. >>>>>>>>> >>>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>>> as well as numerous syslog implementations. >>>>>>>>> >>>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>>> theirs application. >>>>>>>> >>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>> >>>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>>> best to start a new discussion. >>>>>>>> >>>>>>>> A GC log for an application under load might easily produce a block of >>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>> Windows log API as the correct solution. >>>>>>>> >>>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>> instead process the whole file through a script or tool, which should >>>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Rainer >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120815/4f47d2a1/attachment.html From kirk at kodewerk.com Wed Aug 15 01:56:07 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 15 Aug 2012 10:56:07 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <502A25B0.20004@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: <6976D1D8-DD7B-43D8-B03D-E0D3E05BD771@kodewerk.com> Hi Dmitry, I should have added that Neal Ford has an excellent talk on taxonomy systems and tags vs. hierarchies. It includes a bit on the 5 kingdoms that all organisms are split into. Yet many organisms show characteristics from more than one kingdom while some others show characteristics of none. Problem is, the current hierarchical system forces categorization in a way that doesn't work where as a tag system would easily be able to cope. I'm trying to find a link to the talk. Regards, Kirk On 2012-08-14, at 12:17 PM, Dmitry Samersoff wrote: > Kirk, > >> However I do have very serious concerns about this JEP in that it >> doesn't fix the problems that exist in current logging frameworks, >> it only mimics them. > >> http://openjdk.java.net/jeps/158 > > Any comments is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: >> Hi Yasumasa, >> >> I'm not sure that log file rotation is a part of this JEP. >> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. >> >> Regards, >> Kirk >> >> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: >> >>> Hi Staffan, >>> >>> May I ask you 2 questions about this JEP? >>> >>> 1. One of goals of this JEP is defined as following: >>> "File rotation of log files by size (similar to what is available for GC logs today)" >>> My patch realizes log rotation by external trigger. >>> 7090324 is included in this JEP? >>> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >>> >>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>> Could you include this RFE in this JEP? >>> If we use log rotation, I think that name of logs is very important for log management. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>> Hi Yasumasa, >>>> >>>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>>> >>>> [1] http://openjdk.java.net/jeps/158 >>>> >>>> /Staffan >>>> >>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >>>> >>>>> Hi, >>>>> >>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>> Then I received an email that essence of my patch will be implemented as >>>>> "subcommands" of jcmd. >>>>> >>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>>> implement function of gclog rotation. >>>>> >>>>> Will this RFE be implemented? >>>>> >>>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>>> So, if this RFE is not implemented for a while, I would like to contribute >>>>> patch for jcmd. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>>> others. Over the next few update releases, we plan to add several jcmd >>>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>> will help review and perfect the change. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim Melvin >>>>>> Sr. Engineering Manager >>>>>> Oracle >>>>>> >>>>>> >>>>>> >>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>> (I've changed subject of this email to new RFE.) >>>>>>> >>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>> >>>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>>> So I've requested this RFE and made a patch. >>>>>>> >>>>>>> >>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>> >>>>>>>>> Yasumasa, >>>>>>>>> >>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>> solution. >>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>> >>>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>>> independent in realtime. >>>>>>>>> >>>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>>> as well as numerous syslog implementations. >>>>>>>>> >>>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>>> theirs application. >>>>>>>> >>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>> >>>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>>> best to start a new discussion. >>>>>>>> >>>>>>>> A GC log for an application under load might easily produce a block of >>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>> Windows log API as the correct solution. >>>>>>>> >>>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>> instead process the whole file through a script or tool, which should >>>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Rainer >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > From kirk at kodewerk.com Wed Aug 15 02:25:22 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 15 Aug 2012 11:25:22 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <502A25B0.20004@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: <883AE36C-A267-43EE-956F-DC8B7C52EBA3@kodewerk.com> Hi Dmitry, Neal Ford talk is call "Abstraction Distraction".. it's downloadable and you can see it here. http://vimeo.com/44235657 -- Kirk On 2012-08-14, at 12:17 PM, Dmitry Samersoff wrote: > Kirk, > >> However I do have very serious concerns about this JEP in that it >> doesn't fix the problems that exist in current logging frameworks, >> it only mimics them. > >> http://openjdk.java.net/jeps/158 > > Any comments is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: >> Hi Yasumasa, >> >> I'm not sure that log file rotation is a part of this JEP. >> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. >> >> Regards, >> Kirk >> >> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: >> >>> Hi Staffan, >>> >>> May I ask you 2 questions about this JEP? >>> >>> 1. One of goals of this JEP is defined as following: >>> "File rotation of log files by size (similar to what is available for GC logs today)" >>> My patch realizes log rotation by external trigger. >>> 7090324 is included in this JEP? >>> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >>> >>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>> Could you include this RFE in this JEP? >>> If we use log rotation, I think that name of logs is very important for log management. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>> Hi Yasumasa, >>>> >>>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>>> >>>> [1] http://openjdk.java.net/jeps/158 >>>> >>>> /Staffan >>>> >>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >>>> >>>>> Hi, >>>>> >>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>> Then I received an email that essence of my patch will be implemented as >>>>> "subcommands" of jcmd. >>>>> >>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>>> implement function of gclog rotation. >>>>> >>>>> Will this RFE be implemented? >>>>> >>>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>>> So, if this RFE is not implemented for a while, I would like to contribute >>>>> patch for jcmd. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>>> others. Over the next few update releases, we plan to add several jcmd >>>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>> will help review and perfect the change. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jim Melvin >>>>>> Sr. Engineering Manager >>>>>> Oracle >>>>>> >>>>>> >>>>>> >>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>> (I've changed subject of this email to new RFE.) >>>>>>> >>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>> >>>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>>> So I've requested this RFE and made a patch. >>>>>>> >>>>>>> >>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>> >>>>>>>>> Yasumasa, >>>>>>>>> >>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>> solution. >>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>> >>>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>>> independent in realtime. >>>>>>>>> >>>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>>> as well as numerous syslog implementations. >>>>>>>>> >>>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>>> theirs application. >>>>>>>> >>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>> >>>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>>> best to start a new discussion. >>>>>>>> >>>>>>>> A GC log for an application under load might easily produce a block of >>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>> Windows log API as the correct solution. >>>>>>>> >>>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>> instead process the whole file through a script or tool, which should >>>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Rainer >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120815/bd40674c/attachment.html From Dmitry.Samersoff at oracle.com Wed Aug 15 02:29:49 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Aug 2012 13:29:49 +0400 Subject: JEP 158: Unified JVM logging In-Reply-To: <883AE36C-A267-43EE-956F-DC8B7C52EBA3@kodewerk.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <883AE36C-A267-43EE-956F-DC8B7C52EBA3@kodewerk.com> Message-ID: <502B6C0D.3040802@oracle.com> Kirk, Thank you. I'm downloading it. PS: Tags vs hierarchy discussion is as old as taxonomy it self. -Dmitry On 2012-08-15 13:25, Kirk Pepperdine wrote: > Hi Dmitry, > > Neal Ford talk is call "Abstraction Distraction".. it's downloadable and > you can see it here. http://vimeo.com/44235657 > > -- Kirk > > On 2012-08-14, at 12:17 PM, Dmitry Samersoff > > wrote: > >> Kirk, >> >>> However I do have very serious concerns about this JEP in that it >>> doesn't fix the problems that exist in current logging frameworks, >>> it only mimics them. >> >>> http://openjdk.java.net/jeps/158 >> >> Any comments is much appreciated. >> >> Personally, I think that log rotation is out of scope and responsibility >> of JVM. >> >> -Dmitry >> >> >> On 2012-08-14 13:26, Kirk Pepperdine wrote: >>> Hi Yasumasa, >>> >>> I'm not sure that log file rotation is a part of this JEP. >>> However I do have very serious concerns about this JEP in that it >>> doesn't fix the problems that exist in current logging frameworks, it >>> only mimics them. >>> >>> Regards, >>> Kirk >>> >>> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga >>> >> > wrote: >>> >>>> Hi Staffan, >>>> >>>> May I ask you 2 questions about this JEP? >>>> >>>> 1. One of goals of this JEP is defined as following: >>>> "File rotation of log files by size (similar to what is >>>> available for GC logs today)" >>>> My patch realizes log rotation by external trigger. >>>> 7090324 is included in this JEP? >>>> (Is 7090324 included in "Logging can be configured dynamically at >>>> runtime via jcmd or MBeans" ? ) >>>> >>>> 2. I've posted a patch for "6950794: Make the GC log file name >>>> parameterized" . >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>>> Could you include this RFE in this JEP? >>>> If we use log rotation, I think that name of logs is very >>>> important for log management. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>>> Hi Yasumasa, >>>>> >>>>> This work should be done in the context of the Unified Logging JEP >>>>> [1]. Unfortunately, that work has not yet started due to resource >>>>> constraints. Comments on the proposal are welcome. >>>>> >>>>> [1] http://openjdk.java.net/jeps/158 >>>>> >>>>> /Staffan >>>>> >>>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga >>>>> >>>> >>>>> > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>>> Then I received an email that essence of my patch will be >>>>>> implemented as >>>>>> "subcommands" of jcmd. >>>>>> >>>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not >>>>>> seem to >>>>>> implement function of gclog rotation. >>>>>> >>>>>> Will this RFE be implemented? >>>>>> >>>>>> I need to rotate gclog which is synchronized with signal, cron, >>>>>> etc... on Linux. >>>>>> So, if this RFE is not implemented for a while, I would like to >>>>>> contribute >>>>>> patch for jcmd. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Thanks very much for your OpenJDK contribution! As part of the >>>>>>> effort to >>>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>>> the existing tools in the bin directory, such as jmap, jstack, >>>>>>> jinfo and >>>>>>> others. Over the next few update releases, we plan to add several >>>>>>> jcmd >>>>>>> *subcommands* instead to accomplish specific tasks or affect the >>>>>>> running >>>>>>> JVM instance. We'd like to use the essence of your contribution >>>>>>> in one >>>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the >>>>>>> JVM to >>>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>>> will help review and perfect the change. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jim Melvin >>>>>>> Sr. Engineering Manager >>>>>>> Oracle >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>>> (I've changed subject of this email to new RFE.) >>>>>>>> >>>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>>> >>>>>>>> My customers need gclog rotation which is invoked by external >>>>>>>> trigger. >>>>>>>> So I've requested this RFE and made a patch. >>>>>>>> >>>>>>>> >>>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>>> >>>>>>>>>> Yasumasa, >>>>>>>>>> >>>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>>> solution. >>>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>>> >>>>>>>>>>> So, I think that gclog is needed for logging GC stats with >>>>>>>>>>> platform >>>>>>>>>>> independent in realtime. >>>>>>>>>> >>>>>>>>>> Windows has it's own logging API as reach as syslog is or ever >>>>>>>>>> better >>>>>>>>>> as well as numerous syslog implementations. >>>>>>>>>> >>>>>>>>>> Native windows logging API was completely redesigned for >>>>>>>>>> Windows 2008 >>>>>>>>>> server and now it allows for developers to send a structured >>>>>>>>>> events from >>>>>>>>>> theirs application. >>>>>>>>> >>>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>>> necessarily yet released. The change discussed here is about >>>>>>>>> supporting >>>>>>>>> an externally generated rotation trigger, e.g. via a signal, >>>>>>>>> instead of >>>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>>> >>>>>>>>> If you want support for syslog or Windows APIs included, it >>>>>>>>> would be >>>>>>>>> best to start a new discussion. >>>>>>>>> >>>>>>>>> A GC log for an application under load might easily produce a >>>>>>>>> block of >>>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that >>>>>>>>> the need >>>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>>> Windows log API as the correct solution. >>>>>>>>> >>>>>>>>> The messages are not really line formatted, the format can vary >>>>>>>>> a lot >>>>>>>>> (depending on the excat XX switches), the traffic can be quite >>>>>>>>> high and >>>>>>>>> AFAIK the JVM writes it synchronously, so there must be >>>>>>>>> absolutely no >>>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>>> instead process the whole file through a script or tool, which >>>>>>>>> should >>>>>>>>> not depend on the output specifics of a platform specific log >>>>>>>>> apparatus. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Rainer >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kirk at kodewerk.com Wed Aug 15 03:09:28 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 15 Aug 2012 12:09:28 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <502B6C0D.3040802@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <883AE36C-A267-43EE-956F-DC8B7C52EBA3@kodewerk.com> <502B6C0D.3040802@oracle.com> Message-ID: <27886498-DC82-4022-8AA8-88D57E60366A@kodewerk.com> On 2012-08-15, at 11:29 AM, Dmitry Samersoff wrote: > Kirk, > > Thank you. I'm downloading it. > > PS: > Tags vs hierarchy discussion is as old as taxonomy it self. which is why I'm surprised we're here ;-) Kirk From Dmitry.Samersoff at oracle.com Wed Aug 15 06:28:01 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Aug 2012 17:28:01 +0400 Subject: JEP 158: Unified JVM logging In-Reply-To: <6976D1D8-DD7B-43D8-B03D-E0D3E05BD771@kodewerk.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <6976D1D8-DD7B-43D8-B03D-E0D3E05BD771@kodewerk.com> Message-ID: <502BA3E1.5000702@oracle.com> Kirk, On 2012-08-15 12:56, Kirk Pepperdine wrote: > I should have added that Neal Ford has an excellent talk on taxonomy systems and tags vs. hierarchies. > It includes a bit on the 5 kingdoms that all organisms are split into. Yet many organisms show characteristics > from more than one kingdom while some others show characteristics of none. Problem is, > the current hierarchical system forces categorization in a way that doesn't work where > as a tag system would easily be able to cope. I'm trying to find a link to the talk. Really good talk. Stepping aside from logging problem - hierarchy require additional efforts from a people who builds hierarchy, but tags put the same efforts to people who uses it. If I'm constructing new butterfly and check description of Insecta, Lepidoptera I should get a list of the most important characteristics of all butterflies. It's responsibility of persons building hierarchy to create this list. I trust them and believe that if I give all these characteristics to my being it become a butterfly. But with tags I should build the list of characteristics by my self, e.g. start from insects with tags "four wings", and then refine the mix of Lepidoptera and Hymenoptera using other tags to distinguish between butterfly and bees. So tags give you more power but require much more efforts in regular case. -Dmitry > > Regards, > Kirk > > On 2012-08-14, at 12:17 PM, Dmitry Samersoff wrote: > >> Kirk, >> >>> However I do have very serious concerns about this JEP in that it >>> doesn't fix the problems that exist in current logging frameworks, >>> it only mimics them. >> >>> http://openjdk.java.net/jeps/158 >> >> Any comments is much appreciated. >> >> Personally, I think that log rotation is out of scope and responsibility >> of JVM. >> >> -Dmitry >> >> >> On 2012-08-14 13:26, Kirk Pepperdine wrote: >>> Hi Yasumasa, >>> >>> I'm not sure that log file rotation is a part of this JEP. >>> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. >>> >>> Regards, >>> Kirk >>> >>> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: >>> >>>> Hi Staffan, >>>> >>>> May I ask you 2 questions about this JEP? >>>> >>>> 1. One of goals of this JEP is defined as following: >>>> "File rotation of log files by size (similar to what is available for GC logs today)" >>>> My patch realizes log rotation by external trigger. >>>> 7090324 is included in this JEP? >>>> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >>>> >>>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>>> Could you include this RFE in this JEP? >>>> If we use log rotation, I think that name of logs is very important for log management. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>>> Hi Yasumasa, >>>>> >>>>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>>>> >>>>> [1] http://openjdk.java.net/jeps/158 >>>>> >>>>> /Staffan >>>>> >>>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>>> Then I received an email that essence of my patch will be implemented as >>>>>> "subcommands" of jcmd. >>>>>> >>>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>>>> implement function of gclog rotation. >>>>>> >>>>>> Will this RFE be implemented? >>>>>> >>>>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>>>> So, if this RFE is not implemented for a while, I would like to contribute >>>>>> patch for jcmd. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>>>> others. Over the next few update releases, we plan to add several jcmd >>>>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>>> will help review and perfect the change. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jim Melvin >>>>>>> Sr. Engineering Manager >>>>>>> Oracle >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>>> (I've changed subject of this email to new RFE.) >>>>>>>> >>>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>>> >>>>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>>>> So I've requested this RFE and made a patch. >>>>>>>> >>>>>>>> >>>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>>> >>>>>>>>>> Yasumasa, >>>>>>>>>> >>>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>>> solution. >>>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>>> >>>>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>>>> independent in realtime. >>>>>>>>>> >>>>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>>>> as well as numerous syslog implementations. >>>>>>>>>> >>>>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>>>> theirs application. >>>>>>>>> >>>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>>> >>>>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>>>> best to start a new discussion. >>>>>>>>> >>>>>>>>> A GC log for an application under load might easily produce a block of >>>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>>> Windows log API as the correct solution. >>>>>>>>> >>>>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>>> instead process the whole file through a script or tool, which should >>>>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Rainer >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From ahughes at redhat.com Wed Aug 15 06:36:16 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 15 Aug 2012 13:36:16 +0000 Subject: hg: jdk8/tl/jdk: 7110151: Use underlying platform's zlib library for Java zlib support Message-ID: <20120815133648.516A647534@hg.openjdk.java.net> Changeset: 35e024c6a62c Author: andrew Date: 2012-08-15 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35e024c6a62c 7110151: Use underlying platform's zlib library for Java zlib support Summary: Make SYSTEM_ZLIB more flexible by using ZLIB_{CFLAGS,LIBS} and building on more than just MACOSX. Reviewed-by: sherman, alanb ! make/com/sun/java/pack/Makefile ! make/common/Program.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/java/jli/Makefile ! make/java/zip/Makefile ! make/jdk_generic_profile.sh ! make/sun/splashscreen/Makefile ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zip_util.c From kirk at kodewerk.com Wed Aug 15 06:49:13 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 15 Aug 2012 15:49:13 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <502BA3E1.5000702@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <6976D1D8-DD7B-43D8-B03D-E0D3E05BD771@kodewerk.com> <502BA3E1.5000702@oracle.com> Message-ID: <2896294D-7C54-4CDC-A7C8-46E3B000F206@kodewerk.com> On 2012-08-15, at 3:28 PM, Dmitry Samersoff wrote: > Kirk, > > On 2012-08-15 12:56, Kirk Pepperdine wrote: >> I should have added that Neal Ford has an excellent talk on taxonomy systems and tags vs. hierarchies. >> It includes a bit on the 5 kingdoms that all organisms are split into. Yet many organisms show characteristics >> from more than one kingdom while some others show characteristics of none. Problem is, >> the current hierarchical system forces categorization in a way that doesn't work where >> as a tag system would easily be able to cope. I'm trying to find a link to the talk. > > Really good talk. > > Stepping aside from logging problem - > > hierarchy require additional efforts from a people who builds hierarchy, > but tags put the same efforts to people who uses it. > > If I'm constructing new butterfly and check description of Insecta, > Lepidoptera I should get a list of the most important characteristics of > all butterflies. It's responsibility of persons building hierarchy to > create this list. I trust them and believe that if I give all these > characteristics to my being it become a butterfly. I think the point of Neal's talk is this type of taxonomy is better suited to tags. As you mentioned, a butterfly has wings.. but so do bees.. and birds.. and bats. So maybe not such a good idea to use wings a differentiator in a hierarchy. But as a tag it works out very well. A taxonomy for butterflies would simply include all the relevant tags. > > But with tags I should build the list of characteristics by my self, > e.g. start from insects with tags "four wings", and then refine the mix > of Lepidoptera and Hymenoptera using other tags to distinguish between > butterfly and bees. > > So tags give you more power but require much more efforts in regular case. I guess what I've also implicitly said is that the current GC logging system is essentially tag based. My feeling is that tags could be cleaned up which means I could probably get everything that I might want in about a dozen flags or less. I don't really want to get into an implementation discussion so lets just call the following a bad implementation and go from there. java -log:gc,pauseTime,tenuring,stoppedTime,occupancyConfiguredSize,tag5,tag6 my.main This seems about the same amount of effort as it to log today which isn't insignificant but it's also not a big burden that it's worth the loss of flexibility that is currently enjoyed. And again, tags don't preclude someone defining hierarchies of tags if that makes sense to they way their component works. -- Kirk From Dmitry.Samersoff at oracle.com Wed Aug 15 07:19:47 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Aug 2012 18:19:47 +0400 Subject: JEP 158: Unified JVM logging In-Reply-To: References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: <502BB003.8020701@oracle.com> Kirk, Please see below. ** Staffan, please correct me if I misunderstood something. On 2012-08-15 12:44, Kirk Pepperdine wrote: > Hi Dmitry, > > Lets start with this. > > * Common logging command-line options for all components > * Logging is performed at different levels: error, warning, info, > debug, trace > * Logging messages are in human-readable plain text > > > IMHO, these current set of goals are based on the assumptions that all > component is hierarchical in nature and that they will log the same way > without the possibility of binary dumps. I would argue these assumptions > over-reach and preclude certain types of logging that take place in the > JVM today. Components should be independent. With plain tag systems we for sure end up with the same tags in different areas and messed log in result. Treat categories as namespaces rather than true hierarchy. > The current system of command-line (experimental) options follow a > format that is quite consistent. The options provide semantic meaning as > to what will be logged. This semantic meaning is lost when we reduce > everything to the level of error, warning, info, debug and trace. I guess Levels are independent to categories. i.e. I think Log:info,gc,younggen should be possible. Levels - warning, info etc primary intended to indicate production system impact caused by logging. debug should never used in production. info is ok for production but has some performance impact warning has no performance impact etc. > It's > sets up arbitrary categories in which developers will be left to decide > what level a particular activity should be logged at. To make this real > I'll use the -XX:+PrintTenuringDistribution flag as an example. When I > set that flag it's very clear what's to be logged. My question is, > should this be logged at the info level? How about debug? Maybe trace? > And if I set those levels, what else comes along for the ride? IOWs, if > I attempt to keep the same model of GC logging, we'd need different > levels. If we need different levels then we're about to violate the > first goal. > > What this example suggests is that gc logging would be better served by > using categories (or subjects if we can take something from the pub/sub > metaphor) or tags or labels or what ever you want to call them. Using > tags, I can create a system of levels using error, warning, info, debug, > and trace if that fits how I'm setting up logging. But from levels it's > difficult to implement things using categories. This is a case where the > one of the non-goals should be, we shouldn't prevent people from > structuring their logs as they see best fits the component they are > instrumenting. > > The non-goals that should be reconsidered is to force human-readability. > I would argue that this is again over-reaching in that properly > structured log files should almost *never* be read by a human. Human readable means that human can use grep to check for (e.g) error presence. It doesn't mean that people would load logs to theirs iPADs and read with family at the evening. Lots of big customers uses dedicated log servers and often this log servers don't have java. (e.g. in the past I used to use OpenBSD or FreeBSD for all infrastructure tasks). We shouldn't require all admins have special decoding tool installed on all machines they works with. > In thee > cases why force an unnecessary requirement. I say this because I've run > into a number of applications where logging was the primary bottleneck. > In those cases there were two primary problems, one was bulk and the > other was threading (lock contention which I shan't address here). I'm no ready to talk about treading. But IMHO, bulk should be beaten on other levels: From separate log servers to good piece of software to analyze raw logs and store important counters only. Also we should reduce *needs* of logging. > Now > while trying to solve the problem of bulkiness and lock contention might > be considered a premature optimization at this stage and I certainty > wouldn't disagree, I would not like to see designs or specifications > that would naturally preclude some very obvious solutions. One of the > solutions to bulk is to use a more compact format be some form of > binary. That option has been taken away for what I would call an > ideological requirement. There is no technical reason why I shouldn't be > able to log in binary other than connivence. In addition, you don't know > what else is happening on the system (disk??) you're logging to so it > behoves you to be as light as possible. -Dmitry > > I'll leave it at this for now. > > -- Kirk > > On 2012-08-14, at 12:17 PM, Dmitry Samersoff > > wrote: > >> Kirk, >> >>> However I do have very serious concerns about this JEP in that it >>> doesn't fix the problems that exist in current logging frameworks, >>> it only mimics them. >> >>> http://openjdk.java.net/jeps/158 >> >> Any comments is much appreciated. >> >> Personally, I think that log rotation is out of scope and responsibility >> of JVM. >> >> -Dmitry >> >> >> On 2012-08-14 13:26, Kirk Pepperdine wrote: >>> Hi Yasumasa, >>> >>> I'm not sure that log file rotation is a part of this JEP. >>> However I do have very serious concerns about this JEP in that it >>> doesn't fix the problems that exist in current logging frameworks, it >>> only mimics them. >>> >>> Regards, >>> Kirk >>> >>> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga >>> >> > wrote: >>> >>>> Hi Staffan, >>>> >>>> May I ask you 2 questions about this JEP? >>>> >>>> 1. One of goals of this JEP is defined as following: >>>> "File rotation of log files by size (similar to what is >>>> available for GC logs today)" >>>> My patch realizes log rotation by external trigger. >>>> 7090324 is included in this JEP? >>>> (Is 7090324 included in "Logging can be configured dynamically at >>>> runtime via jcmd or MBeans" ? ) >>>> >>>> 2. I've posted a patch for "6950794: Make the GC log file name >>>> parameterized" . >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>>> Could you include this RFE in this JEP? >>>> If we use log rotation, I think that name of logs is very >>>> important for log management. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>>> Hi Yasumasa, >>>>> >>>>> This work should be done in the context of the Unified Logging JEP >>>>> [1]. Unfortunately, that work has not yet started due to resource >>>>> constraints. Comments on the proposal are welcome. >>>>> >>>>> [1] http://openjdk.java.net/jeps/158 >>>>> >>>>> /Staffan >>>>> >>>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga >>>>> >>>> >>>>> > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>>> Then I received an email that essence of my patch will be >>>>>> implemented as >>>>>> "subcommands" of jcmd. >>>>>> >>>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not >>>>>> seem to >>>>>> implement function of gclog rotation. >>>>>> >>>>>> Will this RFE be implemented? >>>>>> >>>>>> I need to rotate gclog which is synchronized with signal, cron, >>>>>> etc... on Linux. >>>>>> So, if this RFE is not implemented for a while, I would like to >>>>>> contribute >>>>>> patch for jcmd. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Thanks very much for your OpenJDK contribution! As part of the >>>>>>> effort to >>>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>>> the existing tools in the bin directory, such as jmap, jstack, >>>>>>> jinfo and >>>>>>> others. Over the next few update releases, we plan to add several >>>>>>> jcmd >>>>>>> *subcommands* instead to accomplish specific tasks or affect the >>>>>>> running >>>>>>> JVM instance. We'd like to use the essence of your contribution >>>>>>> in one >>>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the >>>>>>> JVM to >>>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>>> will help review and perfect the change. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jim Melvin >>>>>>> Sr. Engineering Manager >>>>>>> Oracle >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>>> (I've changed subject of this email to new RFE.) >>>>>>>> >>>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>>> >>>>>>>> My customers need gclog rotation which is invoked by external >>>>>>>> trigger. >>>>>>>> So I've requested this RFE and made a patch. >>>>>>>> >>>>>>>> >>>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>>> >>>>>>>>>> Yasumasa, >>>>>>>>>> >>>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>>> solution. >>>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>>> >>>>>>>>>>> So, I think that gclog is needed for logging GC stats with >>>>>>>>>>> platform >>>>>>>>>>> independent in realtime. >>>>>>>>>> >>>>>>>>>> Windows has it's own logging API as reach as syslog is or ever >>>>>>>>>> better >>>>>>>>>> as well as numerous syslog implementations. >>>>>>>>>> >>>>>>>>>> Native windows logging API was completely redesigned for >>>>>>>>>> Windows 2008 >>>>>>>>>> server and now it allows for developers to send a structured >>>>>>>>>> events from >>>>>>>>>> theirs application. >>>>>>>>> >>>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>>> necessarily yet released. The change discussed here is about >>>>>>>>> supporting >>>>>>>>> an externally generated rotation trigger, e.g. via a signal, >>>>>>>>> instead of >>>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>>> >>>>>>>>> If you want support for syslog or Windows APIs included, it >>>>>>>>> would be >>>>>>>>> best to start a new discussion. >>>>>>>>> >>>>>>>>> A GC log for an application under load might easily produce a >>>>>>>>> block of >>>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that >>>>>>>>> the need >>>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>>> Windows log API as the correct solution. >>>>>>>>> >>>>>>>>> The messages are not really line formatted, the format can vary >>>>>>>>> a lot >>>>>>>>> (depending on the excat XX switches), the traffic can be quite >>>>>>>>> high and >>>>>>>>> AFAIK the JVM writes it synchronously, so there must be >>>>>>>>> absolutely no >>>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>>> instead process the whole file through a script or tool, which >>>>>>>>> should >>>>>>>>> not depend on the output specifics of a platform specific log >>>>>>>>> apparatus. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Rainer >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Wed Aug 15 09:58:13 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Aug 2012 10:58:13 -0600 Subject: code review for JLI/JPLIS test (7191322) Message-ID: <502BD525.4040309@oracle.com> Greetings, I wrote a test for the following bug: 7064927 4/4 retransformClasses() does not pass in LocalVariableTable of a method a long time ago. 7064927 was fixed in the hotspot repo back in HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed to the JDK repo. The java.lang.instrument (JLI) tests live in the JDK repo. I'm using the following bug: 7191322 4/4 add test for 7064927 to java.lang.instrument to get the test into the JDK8 T&L repo. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ Thanks, in advance, for any comments. Dan P.S. The new test has been executed and passes on all platforms supported by JPRT except for MacOS X. There is a temporary build issue on MacOS X at the moment. From Dmitry.Samersoff at oracle.com Wed Aug 15 10:39:49 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 15 Aug 2012 21:39:49 +0400 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502BD525.4040309@oracle.com> References: <502BD525.4040309@oracle.com> Message-ID: <502BDEE5.7010602@oracle.com> Dan, VerifyLocalVariableTableOnRetransformTest.sh 1. if [ "${TESTJAVA}" = "" ] Some shells doesn't handle it correctly. It's more safe to do if [ "x${TESTJAVA}" = "x" ] (the same is for other conditions below) 2. ll. 69 it's better to add quotes around 0 or use -eq instead of = besides that looks good for me. -Dmitry On 2012-08-15 20:58, Daniel D. Daugherty wrote: > Greetings, > > I wrote a test for the following bug: > > 7064927 4/4 retransformClasses() does not pass in > LocalVariableTable of a method > > a long time ago. 7064927 was fixed in the hotspot repo back in > HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed > to the JDK repo. The java.lang.instrument (JLI) tests live in the > JDK repo. > > I'm using the following bug: > > 7191322 4/4 add test for 7064927 to java.lang.instrument > > to get the test into the JDK8 T&L repo. Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ > > Thanks, in advance, for any comments. > > Dan > > P.S. > The new test has been executed and passes on all platforms > supported by JPRT except for MacOS X. There is a temporary > build issue on MacOS X at the moment. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Wed Aug 15 12:16:29 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Aug 2012 12:16:29 -0700 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502BD525.4040309@oracle.com> References: <502BD525.4040309@oracle.com> Message-ID: <502BF58D.6090202@oracle.com> Dan, Thank you for doing this! Does the fix for 7064927 passes in LVTT tables as well? If so, then LVTT need to be tested too (is it right that just LVT is tested?). If not, then do we have a corresponding CR filed? The test looks good in general. Just one minor question: Q1: The line VerifyLocalVariableTableOnRetransformTest.java: 103 contains a long web link referencing the jvaweb.sfbay but the link is not resolved in the browser. Do we have to correct the link or, maybe, get rid of it? Thanks, Serguei On 8/15/12 9:58 AM, Daniel D. Daugherty wrote: > Greetings, > > I wrote a test for the following bug: > > 7064927 4/4 retransformClasses() does not pass in > LocalVariableTable of a method > > a long time ago. 7064927 was fixed in the hotspot repo back in > HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed > to the JDK repo. The java.lang.instrument (JLI) tests live in the > JDK repo. > > I'm using the following bug: > > 7191322 4/4 add test for 7064927 to java.lang.instrument > > to get the test into the JDK8 T&L repo. Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ > > Thanks, in advance, for any comments. > > Dan > > P.S. > The new test has been executed and passes on all platforms > supported by JPRT except for MacOS X. There is a temporary > build issue on MacOS X at the moment. From daniel.daugherty at oracle.com Wed Aug 15 13:38:46 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Aug 2012 14:38:46 -0600 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502BDEE5.7010602@oracle.com> References: <502BD525.4040309@oracle.com> <502BDEE5.7010602@oracle.com> Message-ID: <502C08D6.3010705@oracle.com> Dmitry, Thanks for the quick review! Replies embedded below. On 8/15/12 11:39 AM, Dmitry Samersoff wrote: > Dan, > > VerifyLocalVariableTableOnRetransformTest.sh Just FYI that VerifyLocalVariableTableOnRetransformTest.sh is a copy of one of the existing JLI .sh files with minor tweaking specific for this test. All of the comments below are on the "boiler plate" stuff that I copied. > 1. > > if [ "${TESTJAVA}" = "" ] > > Some shells doesn't handle it correctly. > It's more safe to do > if [ "x${TESTJAVA}" = "x" ] > > (the same is for other conditions below) I've never heard of a shell not handling the above correctly when double quotes are used. This is an idiom that is in all of the JLI .sh tests and probably in all the JDI .sh tests. I have seen the following: if [ x${TESTJAVA} = x ] in some other scripts and that drives me bonkers. I'm planning to keep this one as is, if that's OK with you. > 2. > > ll. 69 > > it's better to add quotes around 0 or > use -eq instead of = > > > besides that looks good for me. This is also a pretty common idiom: if [ "$result" = 0 ]; then and I find a bunch of uses of it in existing JLI tests. I can't find any use of '-eq' at all in the JLI tests. In the JDI tests, I find both '-eq' and the above both with and without quotes, but mostly the later. I'm planning to keep this one as is, if that's OK with you. Again, thanks for the quick review! Please let me know if you are OK with the above resolutions. Dan > -Dmitry > > > On 2012-08-15 20:58, Daniel D. Daugherty wrote: >> Greetings, >> >> I wrote a test for the following bug: >> >> 7064927 4/4 retransformClasses() does not pass in >> LocalVariableTable of a method >> >> a long time ago. 7064927 was fixed in the hotspot repo back in >> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >> to the JDK repo. The java.lang.instrument (JLI) tests live in the >> JDK repo. >> >> I'm using the following bug: >> >> 7191322 4/4 add test for 7064927 to java.lang.instrument >> >> to get the test into the JDK8 T&L repo. Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >> >> Thanks, in advance, for any comments. >> >> Dan >> >> P.S. >> The new test has been executed and passes on all platforms >> supported by JPRT except for MacOS X. There is a temporary >> build issue on MacOS X at the moment. > From daniel.daugherty at oracle.com Wed Aug 15 13:47:53 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Aug 2012 14:47:53 -0600 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502BF58D.6090202@oracle.com> References: <502BD525.4040309@oracle.com> <502BF58D.6090202@oracle.com> Message-ID: <502C0AF9.4020907@oracle.com> Serguei, Thanks for the quick review! Replies embedded below. On 8/15/12 1:16 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > Thank you for doing this! > > Does the fix for 7064927 passes in LVTT tables as well? I don't think so, but that would be a question for Thomas and/or Coleen. > If so, then LVTT need to be tested too (is it right that just LVT is > tested?). Yes, my test only verifies LVT and does not verify LVTT. > If not, then do we have a corresponding CR filed? I'm not aware of an open bug for LVTT, but I haven't looked for one. I'm just closing out old, dangling threads from my Serviceability days... > The test looks good in general. Thanks! > Just one minor question: > > Q1: The line VerifyLocalVariableTableOnRetransformTest.java: 103 > contains a long > web link referencing the jvaweb.sfbay but the link is not resolved > in the browser. > Do we have to correct the link or, maybe, get rid of it? Bad Dan! The correct URL should be: http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#retransformClasses%28java.lang.Class...%29 I will fix that. Again, thanks for the quick review! Dan > > > Thanks, > Serguei > > > On 8/15/12 9:58 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I wrote a test for the following bug: >> >> 7064927 4/4 retransformClasses() does not pass in >> LocalVariableTable of a method >> >> a long time ago. 7064927 was fixed in the hotspot repo back in >> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >> to the JDK repo. The java.lang.instrument (JLI) tests live in the >> JDK repo. >> >> I'm using the following bug: >> >> 7191322 4/4 add test for 7064927 to java.lang.instrument >> >> to get the test into the JDK8 T&L repo. Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >> >> Thanks, in advance, for any comments. >> >> Dan >> >> P.S. >> The new test has been executed and passes on all platforms >> supported by JPRT except for MacOS X. There is a temporary >> build issue on MacOS X at the moment. > > From james.holmlund at oracle.com Wed Aug 15 13:49:54 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Wed, 15 Aug 2012 20:49:54 +0000 Subject: hg: jdk8/tl/langtools: 7191449: update copyright year to match last edit in jdk8 langtools repository Message-ID: <20120815204957.4373F4753D@hg.openjdk.java.net> Changeset: 9d47f4850714 Author: jjh Date: 2012-08-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 7191449: update copyright year to match last edit in jdk8 langtools repository Reviewed-by: jjh Contributed-by: steve.sides at oracle.com ! make/jprt.properties ! make/tools/anttasks/CompilePropertiesTask.java ! make/tools/anttasks/GenStubsTask.java ! make/tools/anttasks/SelectToolTask.java ! make/tools/compileproperties/CompileProperties.java ! make/tools/genstubs/GenStubs.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/api/7086261/T7086261.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/IllegalDot.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/typevars/T7148242.java ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/parser/T4881269.java ! test/tools/javac/processing/TestWarnErrorCount.java From serguei.spitsyn at oracle.com Wed Aug 15 14:44:44 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Aug 2012 14:44:44 -0700 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502C0AF9.4020907@oracle.com> References: <502BD525.4040309@oracle.com> <502BF58D.6090202@oracle.com> <502C0AF9.4020907@oracle.com> Message-ID: <502C184C.1040906@oracle.com> Dan, I'll file a new CR to cover the LVTT issue. As I remember correctly, the LVTT issue was out of the 7064927 scope. Thanks, Serguei On 8/15/12 1:47 PM, Daniel D. Daugherty wrote: > Serguei, > > Thanks for the quick review! > > Replies embedded below. > > > On 8/15/12 1:16 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Thank you for doing this! >> >> Does the fix for 7064927 passes in LVTT tables as well? > > I don't think so, but that would be a question for Thomas > and/or Coleen. > > >> If so, then LVTT need to be tested too (is it right that just LVT is >> tested?). > > Yes, my test only verifies LVT and does not verify LVTT. > > >> If not, then do we have a corresponding CR filed? > > I'm not aware of an open bug for LVTT, but I haven't looked for one. > I'm just closing out old, dangling threads from my Serviceability > days... > > >> The test looks good in general. > > Thanks! > > >> Just one minor question: >> >> Q1: The line VerifyLocalVariableTableOnRetransformTest.java: 103 >> contains a long >> web link referencing the jvaweb.sfbay but the link is not resolved >> in the browser. >> Do we have to correct the link or, maybe, get rid of it? > > Bad Dan! The correct URL should be: > > http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#retransformClasses%28java.lang.Class...%29 > > > I will fix that. > > Again, thanks for the quick review! > > Dan > > > >> >> >> Thanks, >> Serguei >> >> >> On 8/15/12 9:58 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I wrote a test for the following bug: >>> >>> 7064927 4/4 retransformClasses() does not pass in >>> LocalVariableTable of a method >>> >>> a long time ago. 7064927 was fixed in the hotspot repo back in >>> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >>> to the JDK repo. The java.lang.instrument (JLI) tests live in the >>> JDK repo. >>> >>> I'm using the following bug: >>> >>> 7191322 4/4 add test for 7064927 to java.lang.instrument >>> >>> to get the test into the JDK8 T&L repo. Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >>> >>> Thanks, in advance, for any comments. >>> >>> Dan >>> >>> P.S. >>> The new test has been executed and passes on all platforms >>> supported by JPRT except for MacOS X. There is a temporary >>> build issue on MacOS X at the moment. >> >> From rob.mckenna at oracle.com Wed Aug 15 14:45:47 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 15 Aug 2012 21:45:47 +0000 Subject: hg: jdk8/tl/jdk: 6931128: (spec) File attribute tests fail when run as root. Message-ID: <20120815214616.DAD5F4753E@hg.openjdk.java.net> Changeset: da14e2c90bcb Author: robm Date: 2012-08-15 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb 6931128: (spec) File attribute tests fail when run as root. Reviewed-by: alanb ! src/share/classes/java/io/File.java ! test/java/io/File/Basic.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java ! test/java/io/File/SymLinks.java + test/java/io/File/Util.java From serguei.spitsyn at oracle.com Wed Aug 15 15:07:01 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Aug 2012 15:07:01 -0700 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502C184C.1040906@oracle.com> References: <502BD525.4040309@oracle.com> <502BF58D.6090202@oracle.com> <502C0AF9.4020907@oracle.com> <502C184C.1040906@oracle.com> Message-ID: <502C1D85.2010704@oracle.com> New CR is: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method Thanks, Serguei On 8/15/12 2:44 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > I'll file a new CR to cover the LVTT issue. > As I remember correctly, the LVTT issue was out of the 7064927 scope. > > Thanks, > Serguei > > > On 8/15/12 1:47 PM, Daniel D. Daugherty wrote: >> Serguei, >> >> Thanks for the quick review! >> >> Replies embedded below. >> >> >> On 8/15/12 1:16 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> Thank you for doing this! >>> >>> Does the fix for 7064927 passes in LVTT tables as well? >> >> I don't think so, but that would be a question for Thomas >> and/or Coleen. >> >> >>> If so, then LVTT need to be tested too (is it right that just LVT is >>> tested?). >> >> Yes, my test only verifies LVT and does not verify LVTT. >> >> >>> If not, then do we have a corresponding CR filed? >> >> I'm not aware of an open bug for LVTT, but I haven't looked for one. >> I'm just closing out old, dangling threads from my Serviceability >> days... >> >> >>> The test looks good in general. >> >> Thanks! >> >> >>> Just one minor question: >>> >>> Q1: The line VerifyLocalVariableTableOnRetransformTest.java: 103 >>> contains a long >>> web link referencing the jvaweb.sfbay but the link is not >>> resolved in the browser. >>> Do we have to correct the link or, maybe, get rid of it? >> >> Bad Dan! The correct URL should be: >> >> http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/Instrumentation.html#retransformClasses%28java.lang.Class...%29 >> >> >> I will fix that. >> >> Again, thanks for the quick review! >> >> Dan >> >> >> >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 8/15/12 9:58 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I wrote a test for the following bug: >>>> >>>> 7064927 4/4 retransformClasses() does not pass in >>>> LocalVariableTable of a method >>>> >>>> a long time ago. 7064927 was fixed in the hotspot repo back in >>>> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >>>> to the JDK repo. The java.lang.instrument (JLI) tests live in the >>>> JDK repo. >>>> >>>> I'm using the following bug: >>>> >>>> 7191322 4/4 add test for 7064927 to java.lang.instrument >>>> >>>> to get the test into the JDK8 T&L repo. Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >>>> >>>> Thanks, in advance, for any comments. >>>> >>>> Dan >>>> >>>> P.S. >>>> The new test has been executed and passes on all platforms >>>> supported by JPRT except for MacOS X. There is a temporary >>>> build issue on MacOS X at the moment. >>> >>> > > From Dmitry.Samersoff at oracle.com Wed Aug 15 15:27:18 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 16 Aug 2012 02:27:18 +0400 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502C08D6.3010705@oracle.com> References: <502BD525.4040309@oracle.com> <502BDEE5.7010602@oracle.com> <502C08D6.3010705@oracle.com> Message-ID: <502C2246.5020904@oracle.com> Dan, I'm OK with leaving everything as is - >> if [ "${TESTJAVA}" = "" ] I did a quick check and construction above works on linux, cygwin, Sol10, Sol8 - so I was paranoid here. -Dmitry On 2012-08-16 00:38, Daniel D. Daugherty wrote: > Dmitry, > > Thanks for the quick review! > > Replies embedded below. > > > On 8/15/12 11:39 AM, Dmitry Samersoff wrote: >> Dan, >> >> VerifyLocalVariableTableOnRetransformTest.sh > > Just FYI that VerifyLocalVariableTableOnRetransformTest.sh > is a copy of one of the existing JLI .sh files with minor > tweaking specific for this test. All of the comments below > are on the "boiler plate" stuff that I copied. > > >> 1. >> >> if [ "${TESTJAVA}" = "" ] >> >> Some shells doesn't handle it correctly. >> It's more safe to do >> if [ "x${TESTJAVA}" = "x" ] >> >> (the same is for other conditions below) > > I've never heard of a shell not handling the above > correctly when double quotes are used. This is an > idiom that is in all of the JLI .sh tests and probably > in all the JDI .sh tests. I have seen the following: > > if [ x${TESTJAVA} = x ] > > in some other scripts and that drives me bonkers. > > I'm planning to keep this one as is, if that's OK > with you. > > >> 2. >> >> ll. 69 >> >> it's better to add quotes around 0 or >> use -eq instead of = >> >> >> besides that looks good for me. > > This is also a pretty common idiom: > > if [ "$result" = 0 ]; then > > and I find a bunch of uses of it in existing JLI tests. > I can't find any use of '-eq' at all in the JLI tests. > In the JDI tests, I find both '-eq' and the above both > with and without quotes, but mostly the later. > > I'm planning to keep this one as is, if that's OK > with you. > > > Again, thanks for the quick review! Please let me know > if you are OK with the above resolutions. > > Dan > > >> -Dmitry >> >> >> On 2012-08-15 20:58, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I wrote a test for the following bug: >>> >>> 7064927 4/4 retransformClasses() does not pass in >>> LocalVariableTable of a method >>> >>> a long time ago. 7064927 was fixed in the hotspot repo back in >>> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >>> to the JDK repo. The java.lang.instrument (JLI) tests live in the >>> JDK repo. >>> >>> I'm using the following bug: >>> >>> 7191322 4/4 add test for 7064927 to java.lang.instrument >>> >>> to get the test into the JDK8 T&L repo. Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >>> >>> Thanks, in advance, for any comments. >>> >>> Dan >>> >>> P.S. >>> The new test has been executed and passes on all platforms >>> supported by JPRT except for MacOS X. There is a temporary >>> build issue on MacOS X at the moment. >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From kelly.ohair at oracle.com Wed Aug 15 22:28:21 2012 From: kelly.ohair at oracle.com (Kelly Ohair) Date: Thu, 16 Aug 2012 07:28:21 +0200 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502BDEE5.7010602@oracle.com> References: <502BD525.4040309@oracle.com> <502BDEE5.7010602@oracle.com> Message-ID: <2015FF14-55E5-4906-8A00-C7CCC5841A35@oracle.com> Sent from my iPhone On Aug 15, 2012, at 19:39, Dmitry Samersoff wrote: > Dan, > > VerifyLocalVariableTableOnRetransformTest.sh > > 1. > > if [ "${TESTJAVA}" = "" ] > > Some shells doesn't handle it correctly. > It's more safe to do > > if [ "x${TESTJAVA}" = "x" ] > > (the same is for other conditions below) > i myself find the x trick ugly i have not had a need to do the x trick for 10 years what sh or bash shell that we use has this problem still?????? > 2. > > ll. 69 > > it's better to add quotes around 0 or > use -eq instead of = yup i agree there > > besides that looks good for me. > > -Dmitry > > > On 2012-08-15 20:58, Daniel D. Daugherty wrote: >> Greetings, >> >> I wrote a test for the following bug: >> >> 7064927 4/4 retransformClasses() does not pass in >> LocalVariableTable of a method >> >> a long time ago. 7064927 was fixed in the hotspot repo back in >> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >> to the JDK repo. The java.lang.instrument (JLI) tests live in the >> JDK repo. >> >> I'm using the following bug: >> >> 7191322 4/4 add test for 7064927 to java.lang.instrument >> >> to get the test into the JDK8 T&L repo. Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >> >> Thanks, in advance, for any comments. >> >> Dan >> >> P.S. >> The new test has been executed and passes on all platforms >> supported by JPRT except for MacOS X. There is a temporary >> build issue on MacOS X at the moment. > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > From Dmitry.Samersoff at oracle.com Thu Aug 16 00:07:33 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 16 Aug 2012 11:07:33 +0400 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <2015FF14-55E5-4906-8A00-C7CCC5841A35@oracle.com> References: <502BD525.4040309@oracle.com> <502BDEE5.7010602@oracle.com> <2015FF14-55E5-4906-8A00-C7CCC5841A35@oracle.com> Message-ID: <502C9C35.4050307@oracle.com> Kelly, > i myself find the x trick ugly > i have not had a need to do the x trick for 10 years > what sh or bash shell that we use has this problem still?????? I checked for supported platforms (Linux, Solaris 10,8 Cygwin) - all shells work fine. So probably all modern shells handle [ "$NONEXISTING_VAR" = "" ] correctly. The x trick originated to /usr/bin/[ that processed command line arguments one by one, end up to just = and report a syntax error. Hmm - at least my linux's /usr/bin/test handles it correctly as well. May be it's a time to become less paranoid and stop adding x ;)) -Dmitry On 2012-08-16 09:28, Kelly Ohair wrote: > > > Sent from my iPhone > > On Aug 15, 2012, at 19:39, Dmitry Samersoff wrote: > >> Dan, >> >> VerifyLocalVariableTableOnRetransformTest.sh >> >> 1. >> >> if [ "${TESTJAVA}" = "" ] >> >> Some shells doesn't handle it correctly. >> It's more safe to do >> >> if [ "x${TESTJAVA}" = "x" ] >> >> (the same is for other conditions below) >> > > i myself find the x trick ugly > > i have not had a need to do the x trick for 10 years > > what sh or bash shell that we use has this problem still?????? > >> 2. >> >> ll. 69 >> >> it's better to add quotes around 0 or >> use -eq instead of = > > yup i agree there > >> >> besides that looks good for me. >> >> -Dmitry >> >> >> On 2012-08-15 20:58, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I wrote a test for the following bug: >>> >>> 7064927 4/4 retransformClasses() does not pass in >>> LocalVariableTable of a method >>> >>> a long time ago. 7064927 was fixed in the hotspot repo back in >>> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >>> to the JDK repo. The java.lang.instrument (JLI) tests live in the >>> JDK repo. >>> >>> I'm using the following bug: >>> >>> 7191322 4/4 add test for 7064927 to java.lang.instrument >>> >>> to get the test into the JDK8 T&L repo. Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >>> >>> Thanks, in advance, for any comments. >>> >>> Dan >>> >>> P.S. >>> The new test has been executed and passes on all platforms >>> supported by JPRT except for MacOS X. There is a temporary >>> build issue on MacOS X at the moment. >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From sean.coffey at oracle.com Thu Aug 16 02:32:58 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:32:58 +0000 Subject: hg: jdk8/tl/jdk: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <20120816093349.7EF9C47550@hg.openjdk.java.net> Changeset: 39b01268b845 Author: coffeys Date: 2012-08-16 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b01268b845 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! test/Makefile + test/com/sun/corba/cachedSocket/7056731.sh + test/com/sun/corba/cachedSocket/Hello.idl + test/com/sun/corba/cachedSocket/HelloClient.java + test/com/sun/corba/cachedSocket/HelloServer.java From sean.coffey at oracle.com Thu Aug 16 02:34:28 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:34:28 +0000 Subject: hg: jdk8/tl/corba: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <20120816093431.6142B47551@hg.openjdk.java.net> Changeset: 18a02ad8dc73 Author: coffeys Date: 2012-08-16 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18a02ad8dc73 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! src/share/classes/com/sun/corba/se/impl/transport/CorbaResponseWaitingRoomImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java From sean.coffey at oracle.com Thu Aug 16 02:46:06 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:46:06 +0000 Subject: hg: jdk8/tl/jdk: 7185965: Build error in javadoc make stage for bundles not containing crypto package Message-ID: <20120816094633.1DA8047552@hg.openjdk.java.net> Changeset: 56d8756749bd Author: coffeys Date: 2012-08-16 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d8756749bd 7185965: Build error in javadoc make stage for bundles not containing crypto package Reviewed-by: chegar ! make/common/shared/Defs-java.gmk From alan.bateman at oracle.com Thu Aug 16 03:19:54 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 10:19:54 +0000 Subject: hg: jdk8/tl/jdk: 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Message-ID: <20120816102027.68A4047555@hg.openjdk.java.net> Changeset: e48a9a1c14e3 Author: alanb Date: 2012-08-16 11:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e48a9a1c14e3 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Reviewed-by: andrew ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From alan.bateman at oracle.com Thu Aug 16 03:42:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 10:42:55 +0000 Subject: hg: jdk8/tl/jdk: 7191892: ProblemList.txt updates (8/2012) Message-ID: <20120816104317.4D07A47556@hg.openjdk.java.net> Changeset: 4fb8792725d5 Author: alanb Date: 2012-08-16 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fb8792725d5 7191892: ProblemList.txt updates (8/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From daniel.daugherty at oracle.com Thu Aug 16 06:13:03 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Aug 2012 07:13:03 -0600 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <2015FF14-55E5-4906-8A00-C7CCC5841A35@oracle.com> References: <502BD525.4040309@oracle.com> <502BDEE5.7010602@oracle.com> <2015FF14-55E5-4906-8A00-C7CCC5841A35@oracle.com> Message-ID: <502CF1DF.6010007@oracle.com> Kelly, Thanks for the review. Replies embedded below. On 8/15/12 11:28 PM, Kelly Ohair wrote: > > Sent from my iPhone > > On Aug 15, 2012, at 19:39, Dmitry Samersoff wrote: > >> Dan, >> >> VerifyLocalVariableTableOnRetransformTest.sh >> >> 1. >> >> if [ "${TESTJAVA}" = "" ] >> >> Some shells doesn't handle it correctly. >> It's more safe to do >> >> if [ "x${TESTJAVA}" = "x" ] >> >> (the same is for other conditions below) >> > i myself find the x trick ugly > > i have not had a need to do the x trick for 10 years > > what sh or bash shell that we use has this problem still?????? Dmitry and I hashed this one out. He is OK with what I have. >> 2. >> >> ll. 69 >> >> it's better to add quotes around 0 or >> use -eq instead of = > yup i agree there This is what I wrote to Dmitry: > This is also a pretty common idiom: > > if [ "$result" = 0 ]; then > > and I find a bunch of uses of it in existing JLI tests. > I can't find any use of '-eq' at all in the JLI tests. > In the JDI tests, I find both '-eq' and the above both > with and without quotes, but mostly the later. > > I'm planning to keep this one as is, if that's OK > with you. He is OK with what I have. Again, thanks for the review! Please let me know if you are OK with the above resolutions. Dan >> besides that looks good for me. >> >> -Dmitry >> >> >> On 2012-08-15 20:58, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I wrote a test for the following bug: >>> >>> 7064927 4/4 retransformClasses() does not pass in >>> LocalVariableTable of a method >>> >>> a long time ago. 7064927 was fixed in the hotspot repo back in >>> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >>> to the JDK repo. The java.lang.instrument (JLI) tests live in the >>> JDK repo. >>> >>> I'm using the following bug: >>> >>> 7191322 4/4 add test for 7064927 to java.lang.instrument >>> >>> to get the test into the JDK8 T&L repo. Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >>> >>> Thanks, in advance, for any comments. >>> >>> Dan >>> >>> P.S. >>> The new test has been executed and passes on all platforms >>> supported by JPRT except for MacOS X. There is a temporary >>> build issue on MacOS X at the moment. >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> From alan.bateman at oracle.com Thu Aug 16 06:35:49 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 13:35:49 +0000 Subject: hg: jdk8/tl/jdk: 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Message-ID: <20120816133612.A8DEF4755A@hg.openjdk.java.net> Changeset: e50a39d011b5 Author: alanb Date: 2012-08-16 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e50a39d011b5 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/registry/readTest/readTest.sh From kelly.ohair at oracle.com Thu Aug 16 11:43:52 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 16 Aug 2012 20:43:52 +0200 Subject: code review for JLI/JPLIS test (7191322) In-Reply-To: <502CF1DF.6010007@oracle.com> References: <502BD525.4040309@oracle.com> <502BDEE5.7010602@oracle.com> <2015FF14-55E5-4906-8A00-C7CCC5841A35@oracle.com> <502CF1DF.6010007@oracle.com> Message-ID: i m fine wit it -kto On Aug 16, 2012, at 3:13 PM, Daniel D. Daugherty wrote: > Kelly, > > Thanks for the review. Replies embedded below. > > > On 8/15/12 11:28 PM, Kelly Ohair wrote: >> >> Sent from my iPhone >> >> On Aug 15, 2012, at 19:39, Dmitry Samersoff wrote: >> >>> Dan, >>> >>> VerifyLocalVariableTableOnRetransformTest.sh >>> >>> 1. >>> >>> if [ "${TESTJAVA}" = "" ] >>> >>> Some shells doesn't handle it correctly. >>> It's more safe to do >>> >>> if [ "x${TESTJAVA}" = "x" ] >>> >>> (the same is for other conditions below) >>> >> i myself find the x trick ugly >> >> i have not had a need to do the x trick for 10 years >> >> what sh or bash shell that we use has this problem still?????? > > Dmitry and I hashed this one out. He is OK with what I have. > > >>> 2. >>> >>> ll. 69 >>> >>> it's better to add quotes around 0 or >>> use -eq instead of = >> yup i agree there > > This is what I wrote to Dmitry: > >> This is also a pretty common idiom: >> >> if [ "$result" = 0 ]; then >> >> and I find a bunch of uses of it in existing JLI tests. >> I can't find any use of '-eq' at all in the JLI tests. >> In the JDI tests, I find both '-eq' and the above both >> with and without quotes, but mostly the later. >> >> I'm planning to keep this one as is, if that's OK >> with you. > > > He is OK with what I have. > > Again, thanks for the review! Please let me know > if you are OK with the above resolutions. > > Dan > > >>> besides that looks good for me. >>> >>> -Dmitry >>> >>> >>> On 2012-08-15 20:58, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I wrote a test for the following bug: >>>> >>>> 7064927 4/4 retransformClasses() does not pass in >>>> LocalVariableTable of a method >>>> >>>> a long time ago. 7064927 was fixed in the hotspot repo back in >>>> HSX-23-B09 by Thomas W. and Coleen, but the test was never pushed >>>> to the JDK repo. The java.lang.instrument (JLI) tests live in the >>>> JDK repo. >>>> >>>> I'm using the following bug: >>>> >>>> 7191322 4/4 add test for 7064927 to java.lang.instrument >>>> >>>> to get the test into the JDK8 T&L repo. Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/7191322-webrev/0/ >>>> >>>> Thanks, in advance, for any comments. >>>> >>>> Dan >>>> >>>> P.S. >>>> The new test has been executed and passes on all platforms >>>> supported by JPRT except for MacOS X. There is a temporary >>>> build issue on MacOS X at the moment. >>> >>> -- >>> Dmitry Samersoff >>> Java Hotspot development team, SPB04 >>> * There will come soft rains ... >>> >>> From john.coomes at oracle.com Thu Aug 16 21:17:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 04:17:37 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b52 for changeset 8d24def5ceb3 Message-ID: <20120817041737.7D36C47593@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags From john.coomes at oracle.com Thu Aug 16 21:17:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 04:17:43 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b52 for changeset 80689ff9cb49 Message-ID: <20120817041746.D234947594@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags From john.coomes at oracle.com Thu Aug 16 21:17:51 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 04:17:51 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b52 for changeset bd3c00d57614 Message-ID: <20120817041801.6449D47595@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags From john.coomes at oracle.com Thu Aug 16 21:18:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 04:18:07 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b52 for changeset f62bc618122e Message-ID: <20120817041811.BCADA47596@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags From john.coomes at oracle.com Thu Aug 16 21:19:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 04:19:15 +0000 Subject: hg: hsx/hotspot-rt/jdk: 29 new changesets Message-ID: <20120817042501.8370B47597@hg.openjdk.java.net> Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4e8bafdcefda Merge Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/da8649489aff Merge Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.java + src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java + src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags From john.coomes at oracle.com Thu Aug 16 21:26:45 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Aug 2012 04:26:45 +0000 Subject: hg: hsx/hotspot-rt/langtools: 7 new changesets Message-ID: <20120817042704.A0F7347598@hg.openjdk.java.net> Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! 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/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/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! 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/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cfa70d7ac944 Merge Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1d2db0e5eabc Merge Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags From staffan.larsen at oracle.com Fri Aug 17 00:59:52 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Aug 2012 09:59:52 +0200 Subject: -Xdebug a no-op? Message-ID: <20832C43-585D-4FF8-85F1-21997F556E6A@oracle.com> Can someone confirm that -Xdebug is mostly a no-op flag right now? I assume it is still there for backwards compatibility, but it does not seem to have any impact. Thanks, /Staffan From luchsh at linux.vnet.ibm.com Fri Aug 17 02:15:38 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 17 Aug 2012 09:15:38 +0000 Subject: hg: jdk8/tl/jdk: 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Message-ID: <20120817091746.C6ED04759F@hg.openjdk.java.net> Changeset: 4993f8aa7f2e Author: dingxmin Date: 2012-08-17 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4993f8aa7f2e 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c From serguei.spitsyn at oracle.com Fri Aug 17 02:52:54 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 Aug 2012 02:52:54 -0700 Subject: -Xdebug a no-op? In-Reply-To: <20832C43-585D-4FF8-85F1-21997F556E6A@oracle.com> References: <20832C43-585D-4FF8-85F1-21997F556E6A@oracle.com> Message-ID: <502E1476.5050303@oracle.com> Staffan, If I remember correctly, the -Xdebug options was to enable JVMDI which was deprecated in JDK 5.0. Please, refer to this page: http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html The JVMDI was still available in 5.0 but was implemented as wrapper api of the JVMTI. I've included Jim Holmlund, the former JPDA spec lead, to keep me honest. This is the only code in VM that still depends on the -Xdebug flag value but not sure it is still valid: src/share/vm/runtime/arguments.cpp: 2852 jint Arguments::finalize_vm_init_args(SysClassPath* scp_p, bool scp_assembly_required) { 2853 // This must be done after all -D arguments have been processed. 2854 scp_p->expand_endorsed(); 2855 2856 if (scp_assembly_required || scp_p->get_endorsed() != NULL) { 2857 // Assemble the bootclasspath elements into the final path. 2858 Arguments::set_sysclasspath(scp_p->combined_path()); 2859 } 2860 2861 // This must be done after all arguments have been processed. 2862 // java_compiler() true means set to "NONE" or empty. 2863 if (java_compiler() && !xdebug_mode()) { 2864 // For backwards compatibility, we switch to interpreted mode if 2865 // -Djava.compiler="NONE" or "" is specified AND "-Xdebug" was 2866 // not specified. 2867 set_mode_flags(_int); 2868 } Thanks, Serguei On 8/17/12 12:59 AM, Staffan Larsen wrote: > Can someone confirm that -Xdebug is mostly a no-op flag right now? I assume it is still there for backwards compatibility, but it does not seem to have any impact. > > Thanks, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120817/c26ed83d/attachment.html From huizhe.wang at oracle.com Fri Aug 17 09:47:27 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 17 Aug 2012 16:47:27 +0000 Subject: hg: jdk8/tl/jaxp: 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Message-ID: <20120817164731.96CBA475B1@hg.openjdk.java.net> Changeset: 2946807a6d7f Author: joehw Date: 2012-08-17 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2946807a6d7f 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Summary: similar to the patch for 6756677 for XMLInputFactory and XMLOutputFactory, this patch fixes an error in XMLEventFactory where factoryId was taken as factory class. Reviewed-by: lancea ! src/javax/xml/stream/XMLEventFactory.java From sean.mullan at oracle.com Fri Aug 17 11:36:09 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 17 Aug 2012 18:36:09 +0000 Subject: hg: jdk8/tl/jdk: 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Message-ID: <20120817183630.404F8475B3@hg.openjdk.java.net> Changeset: 6b2ebf3c4964 Author: mullan Date: 2012-08-17 14:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b2ebf3c4964 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/x509/URIName.java + test/sun/security/x509/URIName/Parse.java From staffan.larsen at oracle.com Fri Aug 17 12:44:26 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Aug 2012 21:44:26 +0200 Subject: JEP 158 In-Reply-To: <40E80414-7CC9-40B1-B801-59AC33C821D2@kodewerk.com> References: <20120618213859.738A913EE@eggemoggin.niobe.net> <25BA359D-58E7-48F3-9575-E555A31FE3C2@kodewerk.com> <4FE10530.5030901@oracle.com> <1BC2C076-7066-406A-87B2-A6F4618B7ECC@kodewerk.com> <4FE17C77.2050800@oracle.com> <40E80414-7CC9-40B1-B801-59AC33C821D2@kodewerk.com> Message-ID: <77BD6C9D-9939-4F76-9C1B-8A731DD92FCB@oracle.com> I don't think the JEP has been updated, only published. I have not had time to do any changes to it. /Staffan On 10 jul 2012, at 17:16, Kirk Pepperdine wrote: > Hi Staffan, > > I've noticed that the specification has been updated but still contains the hierarchical level system. Is it your intention to maintain level in the specification? > > Regards, > Kirk > > On 2012-06-20, at 12:50 PM, Staffan Larsen wrote: > >> Hi, >> >> Thanks for the feedback! >> >> It is going to be hard to find the right balance between a system that provides great power and one that is simple to use and to implement. In general, I will lean more towards making it simple, but I want to make sure we cover the major use cases as well. >> >> It looks like there are three possible ways to select log messages being discussed here. I'd like to discuss how to solve your problem for each one. >> >> 1) Selection based on component/level. (This is what is described in the JEP.) >> In this case we can have any number of components. So we can have gc and tenuring as different component. They will each have a level associated with them. However there is no relationship between the gc and the tenuring component, so to enable both you need to say -Xverbose:gc,tenuring. To only enable tenuring you can say -Xverbose:tenuring. To enable all gc messages, except tenuring you say -Xverbose:gc. >> >> 2) Selection based on component/level where the component is a hierarchy. >> In this case the different steps in the hierarchy can have different levels associated with them, but if there is no explicit level associated, the parent level will be used. So to enable both tenuring and gc you would say -Xverbose:gc. To enable only gc you would say -Xverbose:gc,gc.tenuring=none (I made up the 'none' level). To enable only tenuring you would say -Xverbose:gc.tenuring. >> >> 3) Selection based on tags. >> In this case log messages are associated with a set of tags instead of a component/level tuple. You select messages by specifying tags you want to see. I imagine that in this case the tenuring messages would be tagged with both the gc and the tenuring tags, but that there would be other messages tagged with gc only. To enable gc and tenuring you would say -Xverbose:gc,tenuring. To enable all gc messages you say -Xverbose:gc. There is no way to see only gc messages without seeing the tenuring messages. >> >> Is this a fair description of the different ways? I'm especially interested in the last one - I'm not sure I captured your idea correctly there. >> >> Thanks, >> /Staffan >> >> >> On 20 jun 2012, at 09:32, Jesper Wilhelmsson wrote: >> >>> Hi Kirk, >>> >>> I'm CC'ing serviceability on this since this is really their JEP and discussions around it should go on the serviceability list, even though it seems you are mainly interested in GC logging at this point. >>> >>> I understand what you want and I see that the logging level won't help us get there. I don't agree that the logging we have today can't fit nicely into a hierarchical scheme though, it just needs to be more fine grained to achieve what you want. >>> >>> We can be pretty generous with modules and in principal have one module for each verbose flag that exists today. Personally I don't think that is a good idea, but it certainly is possible. I would rather like to propose a different solution. >>> >>> How about we have a gc module that can be filtered based on different sub modules. The sub modules could be fairly close to the existing verbose flags that exists today if that turns out to be a good way to divide information. It could look like this >>> >>> -Xverbose:gc=info,gc.tenuring=debug >>> >>> to set regular gc verbose to info level (I would say that is close to PrintGC) and turn on more detailed logging for tenuring. Or >>> >>> -Xverbose:gc.tenuring >>> >>> that could be equal to what that flag prints today. Let's see what the serviceability team thinks since they are the ones who will actually implement this in the end. >>> >>> Another solution that I don't really like but guess is easier to implement is to add the current verbose flag to the actual message so that the logs can be filtered based on that. But this will clutter the messages and we would still have the problem to decide on which level things should get logged. >>> /Jesper >>> >>> >>> On 2012-06-20 07:28, Kirk Pepperdine wrote: >>>> >>>> Hi Jesper, >>>> >>>> I did read the spec and I do like the ability to specify the "component" that you'd like to log information from. So I feel that is a great improvement over the (broken) pattern established in every major logging Java framework. I'm going to stick to GC logging just because I've spent so much time puzzling over them and adjusting my parser to deal with all the changes that have continuously crept into them. While 'm certainly not going to argue for keeping the current GC logging framework what I will say is that it's not all bad in that the flags that have been provided to me are almost always semantically meaningful in that they tell me what I'm going to see. In this spirit I'd like to see a category like TenuringDetails for example. Is this information INFO, DEBUG, or TRACE? hard to say but it's clearly TenuringDetails and so this is a subcategory that I'd like to define and it's clearly not a subcategory that you'd want to define a generalize logging framework. And it is here that this specification over-reaches. It tries to define logging categories that are not only are devoid of meaning, they assume a hierarchical structure to them. Going back to GC logging I would argue that while there is some hierarchy in there, most of the messages don't nicely fit into this imposed hierarchical developer centric list of categories. >>>> >>>> I think we could easily both agree that it would be ridiculous for me to ask that you add PrintTunuring to the list of levels yet that is exactly what I want. So I guess what I'm asking is, what would the spec look like if you removed the log levels from it and allowed me to define my own or to not even use levels at all. >>>> >>>> Regards, >>>> Kirk >>>> >>>> On 2012-06-20, at 1:03 AM, Jesper Wilhelmsson wrote: >>>> >>>>> Hi Kirk, >>>>> >>>>> To select what should be logged there should be logging modules. A module could be for example class loading, gc, jit compiler etc. The logging level is just a way to control how much logging you want. Setting gc=info would give you some basic gc logging while gc=debug would give you more detailed info. >>>>> >>>>> A typical command line could look like >>>>> >>>>> -Xverbose:gc=debug,finalizer=info,compiler,alloc,cookies=trace >>>>> /Jesper >>>>> >>>>> >>>>> On 2012-06-19 23:44, Kirk Pepperdine wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I see the logging framework JEP finally was published. This is great news. >>>>>> >>>>>> I'd like to comment on this quality >>>>>> >>>>>> "Logging is performed at different levels: error, warning, info, debug, trace" >>>>>> >>>>>> If we accept the problems associated with level based logging, these name work for generic frameworks such as Log4J and JDK logging. However, the names are meaningless in that they carry no semantic context with what would be logged. The nice thing about the current set of flags is they convey the information that will be printed. >>>>>> >>>>>> On the question of log levels. I was hoping that we would have learned from the follies of using level based logging instead of a digital or tag based system. IOWs a on or off different aspects without having to eat the whole elephant of records that some developer arbitrarily decided should be dumped at a particular log level. One can level tags.. but you can't get tags or digital behaviour from levels. >>>>>> >>>>>> Kind regards, >>>>>> Kirk Pepperdine >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120817/bc46e4b2/attachment.html From daniel.daugherty at oracle.com Fri Aug 17 12:53:33 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 17 Aug 2012 19:53:33 +0000 Subject: hg: jdk8/tl/jdk: 7191322: add test for 7064927 to java.lang.instrument Message-ID: <20120817195352.E35B9475B6@hg.openjdk.java.net> Changeset: 509421263cdd Author: dcubed Date: 2012-08-17 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/509421263cdd 7191322: add test for 7064927 to java.lang.instrument Summary: Add support for canRetransform attribute to the test manager. Add test for 7064927. Reviewed-by: dsamersoff, sspitsyn, ohair ! test/java/lang/instrument/ATransformerManagementTestCase.java + test/java/lang/instrument/DummyClassWithLVT.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh + test/java/lang/instrument/retransformAgent.mf From staffan.larsen at oracle.com Fri Aug 17 13:08:32 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Aug 2012 22:08:32 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: Hi, I would agree that there are great merits to tag-based systems instead of hierarchical systems. However, the JEP does not have a hierarchical system in mind. Components, as the JEP refers to them, are not hierarchical, but they are disjunct. Disjunct in the sense that a particular log output in the source code can only belong to one component - this would be a difference from a purely tag based system. For each component in the proposal, there is the possibility of logging messages of different severities; these are the 'levels' (maybe a bad and confusing terminology?). I think I do understand your use-case and I would be happy if we could find a workable system that solves this use-case. I gave it a shot in [1] - my suggestion #3. This suggested implementation had some serious problems in the way you could select log messages. I would love to see a better proposal for how this could be implemented. Logging information in binary certainly reduces bulk and can also make it much easier to parse and visualize the data. The JRockit Flight Recorder technology has a binary format for storing information (it is also a self-describing format which includes meta-data to facilitate parsing) which is optimized for storage speed and size. As you probably know, we are working on a port of JFR to HotSpot. Thanks, /Staffan [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-June/006369.html On 15 aug 2012, at 10:44, Kirk Pepperdine wrote: > Hi Dmitry, > > Lets start with this. > > Common logging command-line options for all components > Logging is performed at different levels: error, warning, info, debug, trace > Logging messages are in human-readable plain text > > IMHO, these current set of goals are based on the assumptions that all component is hierarchical in nature and that they will log the same way without the possibility of binary dumps. I would argue these assumptions over-reach and preclude certain types of logging that take place in the JVM today. > > The current system of command-line (experimental) options follow a format that is quite consistent. The options provide semantic meaning as to what will be logged. This semantic meaning is lost when we reduce everything to the level of error, warning, info, debug and trace. It's sets up arbitrary categories in which developers will be left to decide what level a particular activity should be logged at. To make this real I'll use the -XX:+PrintTenuringDistribution flag as an example. When I set that flag it's very clear what's to be logged. My question is, should this be logged at the info level? How about debug? Maybe trace? And if I set those levels, what else comes along for the ride? IOWs, if I attempt to keep the same model of GC logging, we'd need different levels. If we need different levels then we're about to violate the first goal. > > What this example suggests is that gc logging would be better served by using categories (or subjects if we can take something from the pub/sub metaphor) or tags or labels or what ever you want to call them. Using tags, I can create a system of levels using error, warning, info, debug, and trace if that fits how I'm setting up logging. But from levels it's difficult to implement things using categories. This is a case where the one of the non-goals should be, we shouldn't prevent people from structuring their logs as they see best fits the component they are instrumenting. > > The non-goals that should be reconsidered is to force human-readability. I would argue that this is again over-reaching in that properly structured log files should almost *never* be read by a human. In the cases why force an unnecessary requirement. I say this because I've run into a number of applications where logging was the primary bottleneck. In those cases there were two primary problems, one was bulk and the other was threading (lock contention which I shan't address here). Now while trying to solve the problem of bulkiness and lock contention might be considered a premature optimization at this stage and I certainty wouldn't disagree, I would not like to see designs or specifications that would naturally preclude some very obvious solutions. One of the solutions to bulk is to use a more compact format be some form of binary. That option has been taken away for what I would call an ideological requirement. There is no technical reason why I shouldn't be able to log in binary other than connivence. In addition, you don't know what else is happening on the system (disk??) you're logging to so it behoves you to be as light as possible. > > I'll leave it at this for now. > > -- Kirk > > On 2012-08-14, at 12:17 PM, Dmitry Samersoff wrote: > >> Kirk, >> >>> However I do have very serious concerns about this JEP in that it >>> doesn't fix the problems that exist in current logging frameworks, >>> it only mimics them. >> >>> http://openjdk.java.net/jeps/158 >> >> Any comments is much appreciated. >> >> Personally, I think that log rotation is out of scope and responsibility >> of JVM. >> >> -Dmitry >> >> >> On 2012-08-14 13:26, Kirk Pepperdine wrote: >>> Hi Yasumasa, >>> >>> I'm not sure that log file rotation is a part of this JEP. >>> However I do have very serious concerns about this JEP in that it doesn't fix the problems that exist in current logging frameworks, it only mimics them. >>> >>> Regards, >>> Kirk >>> >>> On 2012-08-14, at 11:20 AM, Yasumasa Suenaga wrote: >>> >>>> Hi Staffan, >>>> >>>> May I ask you 2 questions about this JEP? >>>> >>>> 1. One of goals of this JEP is defined as following: >>>> "File rotation of log files by size (similar to what is available for GC logs today)" >>>> My patch realizes log rotation by external trigger. >>>> 7090324 is included in this JEP? >>>> (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) >>>> >>>> 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html >>>> Could you include this RFE in this JEP? >>>> If we use log rotation, I think that name of logs is very important for log management. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2012/08/14 16:50, Staffan Larsen wrote: >>>>> Hi Yasumasa, >>>>> >>>>> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >>>>> >>>>> [1] http://openjdk.java.net/jeps/158 >>>>> >>>>> /Staffan >>>>> >>>>> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I've posted a patch for gc log rotation via jinfo tool last year. >>>>>> Then I received an email that essence of my patch will be implemented as >>>>>> "subcommands" of jcmd. >>>>>> >>>>>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>>>>> implement function of gclog rotation. >>>>>> >>>>>> Will this RFE be implemented? >>>>>> >>>>>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>>>>> So, if this RFE is not implemented for a while, I would like to contribute >>>>>> patch for jcmd. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2011/09/29 21:15, James Melvin wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>>>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>>>>> commandline serviceability tool (jcmd) to potentially replace many of >>>>>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>>>>> others. Over the next few update releases, we plan to add several jcmd >>>>>>> *subcommands* instead to accomplish specific tasks or affect the running >>>>>>> JVM instance. We'd like to use the essence of your contribution in one >>>>>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>>>>> begin rotating GC logs. We hope you find this attractive and hope you >>>>>>> will help review and perfect the change. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jim Melvin >>>>>>> Sr. Engineering Manager >>>>>>> Oracle >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>>>>> (I've changed subject of this email to new RFE.) >>>>>>>> >>>>>>>> This RFE is enhancement of current gclog implementation. >>>>>>>> So, I'd like to discuss about rotating gclog. >>>>>>>> >>>>>>>> My customers need gclog rotation which is invoked by external trigger. >>>>>>>> So I've requested this RFE and made a patch. >>>>>>>> >>>>>>>> >>>>>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>>>>> >>>>>>>>>> Yasumasa, >>>>>>>>>> >>>>>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>>>>> solution. >>>>>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>>>>> >>>>>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>>>>> independent in realtime. >>>>>>>>>> >>>>>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>>>>> as well as numerous syslog implementations. >>>>>>>>>> >>>>>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>>>>> server and now it allows for developers to send a structured events from >>>>>>>>>> theirs application. >>>>>>>>> >>>>>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>>>>> necessarily yet released. The change discussed here is about supporting >>>>>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>>>>> only rotating by size or time via a startup parameter. >>>>>>>>> >>>>>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>>>>> best to start a new discussion. >>>>>>>>> >>>>>>>>> A GC log for an application under load might easily produce a block of >>>>>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>>>>> for log file rotation can be argued away by referring to syslog or >>>>>>>>> Windows log API as the correct solution. >>>>>>>>> >>>>>>>>> The messages are not really line formatted, the format can vary a lot >>>>>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>>>>> risk in writing it out with very little latency. In addition, for >>>>>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>>>>> instead process the whole file through a script or tool, which should >>>>>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Rainer >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Java Hotspot development team, SPB04 >> * There will come soft rains ... >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120817/f0f7ac07/attachment-0001.html From staffan.larsen at oracle.com Fri Aug 17 13:12:38 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Aug 2012 22:12:38 +0200 Subject: 7090324: gclog rotation via external tool In-Reply-To: <502A1853.70508@lab.ntt.co.jp> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> Message-ID: <7C2E0A4F-79DF-4D75-808B-A08619B8B303@oracle.com> Hi Yasumasa, As the JEP stands today, neither of these features are a part of the JEP, but they could be (the JEP is only a proposal). What I would like to see, though is that log rotation and log file naming works the same across all of the JVM. I don't want to have one implementation for the GC and one for the compilers, for example. This 'unification' is partly what the JEP is about. So for this reason, implementing these features should be done in the context of the JEP. Thanks, /Staffan On 14 aug 2012, at 11:20, Yasumasa Suenaga wrote: > Hi Staffan, > > May I ask you 2 questions about this JEP? > > 1. One of goals of this JEP is defined as following: > "File rotation of log files by size (similar to what is available for GC logs today)" > My patch realizes log rotation by external trigger. > 7090324 is included in this JEP? > (Is 7090324 included in "Logging can be configured dynamically at runtime via jcmd or MBeans" ? ) > > 2. I've posted a patch for "6950794: Make the GC log file name parameterized" . > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html > Could you include this RFE in this JEP? > If we use log rotation, I think that name of logs is very important for log management. > > > Thanks, > > Yasumasa > > > On 2012/08/14 16:50, Staffan Larsen wrote: >> Hi Yasumasa, >> >> This work should be done in the context of the Unified Logging JEP [1]. Unfortunately, that work has not yet started due to resource constraints. Comments on the proposal are welcome. >> >> [1] http://openjdk.java.net/jeps/158 >> >> /Staffan >> >> On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: >> >>> Hi, >>> >>> I've posted a patch for gc log rotation via jinfo tool last year. >>> Then I received an email that essence of my patch will be implemented as >>> "subcommands" of jcmd. >>> >>> Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to >>> implement function of gclog rotation. >>> >>> Will this RFE be implemented? >>> >>> I need to rotate gclog which is synchronized with signal, cron, etc... on Linux. >>> So, if this RFE is not implemented for a while, I would like to contribute >>> patch for jcmd. >>> >>> >>> Regards, >>> >>> Yasumasa >>> >>> >>> On 2011/09/29 21:15, James Melvin wrote: >>>> Hi Yasumasa, >>>> >>>> Thanks very much for your OpenJDK contribution! As part of the effort to >>>> port JRockit features to HotSpot, we plan to introduce a consolidated >>>> commandline serviceability tool (jcmd) to potentially replace many of >>>> the existing tools in the bin directory, such as jmap, jstack, jinfo and >>>> others. Over the next few update releases, we plan to add several jcmd >>>> *subcommands* instead to accomplish specific tasks or affect the running >>>> JVM instance. We'd like to use the essence of your contribution in one >>>> of the jcmd subcommands (instead of extending jinfo) to ask the JVM to >>>> begin rotating GC logs. We hope you find this attractive and hope you >>>> will help review and perfect the change. >>>> >>>> Thanks, >>>> >>>> Jim Melvin >>>> Sr. Engineering Manager >>>> Oracle >>>> >>>> >>>> >>>> On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: >>>>> (I've changed subject of this email to new RFE.) >>>>> >>>>> This RFE is enhancement of current gclog implementation. >>>>> So, I'd like to discuss about rotating gclog. >>>>> >>>>> My customers need gclog rotation which is invoked by external trigger. >>>>> So I've requested this RFE and made a patch. >>>>> >>>>> >>>>> In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . >>>>> The aim of this RFE is to synchronize gclog and the other logs. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> (2011/09/22 20:55), Rainer Jung wrote: >>>>>> On 22.09.2011 13:20, Dmitry Samersoff wrote: >>>>>>> >>>>>>> Yasumasa, >>>>>>> >>>>>>> On 2011-09-22 04:47, Yasumasa Suenaga wrote: >>>>>>>> If we can think Java on Linux and Solaris only, syslog is best >>>>>>>> solution. >>>>>>>> However, Windows usually doesn't have syslog. >>>>>>>> >>>>>>>> So, I think that gclog is needed for logging GC stats with platform >>>>>>>> independent in realtime. >>>>>>> >>>>>>> Windows has it's own logging API as reach as syslog is or ever better >>>>>>> as well as numerous syslog implementations. >>>>>>> >>>>>>> Native windows logging API was completely redesigned for Windows 2008 >>>>>>> server and now it allows for developers to send a structured events from >>>>>>> theirs application. >>>>>> >>>>>> AFAIK log rotation for loggc is already implemented though not >>>>>> necessarily yet released. The change discussed here is about supporting >>>>>> an externally generated rotation trigger, e.g. via a signal, instead of >>>>>> only rotating by size or time via a startup parameter. >>>>>> >>>>>> If you want support for syslog or Windows APIs included, it would be >>>>>> best to start a new discussion. >>>>>> >>>>>> A GC log for an application under load might easily produce a block of >>>>>> about 1.5 KB size every few seconds. I seriously doubt, that the need >>>>>> for log file rotation can be argued away by referring to syslog or >>>>>> Windows log API as the correct solution. >>>>>> >>>>>> The messages are not really line formatted, the format can vary a lot >>>>>> (depending on the excat XX switches), the traffic can be quite high and >>>>>> AFAIK the JVM writes it synchronously, so there must be absolutely no >>>>>> risk in writing it out with very little latency. In addition, for >>>>>> analysis, you wouldn't want to look at each event individually, but >>>>>> instead process the whole file through a script or tool, which should >>>>>> not depend on the output specifics of a platform specific log apparatus. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rainer >>>>>> >>>>> >>> >> > From staffan.larsen at oracle.com Fri Aug 17 13:20:00 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 17 Aug 2012 22:20:00 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <502BB003.8020701@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <502BB003.8020701@oracle.com> Message-ID: <2FF50E25-8A2C-4837-8C46-44E8C5CD6180@oracle.com> On 15 aug 2012, at 16:19, Dmitry Samersoff wrote: > On 2012-08-15 12:44, Kirk Pepperdine wrote: > >> The current system of command-line (experimental) options follow a >> format that is quite consistent. The options provide semantic meaning as >> to what will be logged. This semantic meaning is lost when we reduce >> everything to the level of error, warning, info, debug and trace. > > I guess Levels are independent to categories. i.e. I think > > Log:info,gc,younggen should be possible The suggestion in the JEP is that each category/component has several levels, so in that sense they are not independent. To enable logging you would specify a list of {component, level} tuples, like: gc:info, younggen:trace But to make it easier to type in the most common case the 'info' level is considered 'default' if nothing else is specified. So the above would be equivalent to saying just gc, younggen:trace Thanks, /Staffan From kirk at kodewerk.com Fri Aug 17 13:32:45 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 17 Aug 2012 22:32:45 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <2FF50E25-8A2C-4837-8C46-44E8C5CD6180@oracle.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <502BB003.8020701@oracle.com> <2FF50E25-8A2C-4837-8C46-44E8C5CD6180@oracle.com> Message-ID: <325CA5D7-13B4-4A72-ADA2-C7BFAA9F1353@kodewerk.com> Hi Staffan, Thanks for the response. You call it levels, I call is at hierarchy. I'm happy to change to the work levels. On 2012-08-17, at 10:20 PM, Staffan Larsen wrote: > > On 15 aug 2012, at 16:19, Dmitry Samersoff wrote: > >> On 2012-08-15 12:44, Kirk Pepperdine wrote: >> >>> The current system of command-line (experimental) options follow a >>> format that is quite consistent. The options provide semantic meaning as >>> to what will be logged. This semantic meaning is lost when we reduce >>> everything to the level of error, warning, info, debug and trace. >> >> I guess Levels are independent to categories. i.e. I think >> >> Log:info,gc,younggen should be possible > > The suggestion in the JEP is that each category/component has several levels, so in that sense they are not independent. To enable logging you would specify a list of {component, level} tuples, like: > > gc:info, younggen:trace > > But to make it easier to type in the most common case the 'info' level is considered 'default' if nothing else is specified. So the above would be equivalent to saying just > > gc, younggen:trace Right, and this is at the heart of one of my objections is that the predefined levels used by everyone lack semantic meaning where as being able to define tags or groups of tags would allow one to define levels but not force one to use levels. There certainly is a case for levels and I would not want them precluded but I do not believe it is desirable for all components to hierarchically reduce log messages. If I had a better idea of the schedule for the JEP I'd have a better understanding of when I might be able to pitch in rather then just play seagull. Regards, Kirk From jonathan.gibbons at oracle.com Fri Aug 17 17:30:26 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 18 Aug 2012 00:30:26 +0000 Subject: hg: jdk8/tl/langtools: 7192449: fix up tests to accommodate jtreg spec change Message-ID: <20120818003031.31DB1475B9@hg.openjdk.java.net> Changeset: 5ac2e9ee969e Author: jjg Date: 2012-08-17 17:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5ac2e9ee969e 7192449: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java From daniel.daugherty at oracle.com Fri Aug 17 19:11:41 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 18 Aug 2012 02:11:41 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 13 new changesets Message-ID: <20120818021212.B1C09475BE@hg.openjdk.java.net> Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_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/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.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_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp From Alan.Bateman at oracle.com Sat Aug 18 03:35:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 18 Aug 2012 11:35:38 +0100 Subject: 7192275: Minimize LogManager dependencies on java.beans Message-ID: <502F6FFA.1050202@oracle.com> I need a reviewer for a small change to the LogManager implementation that reduces its dependency on the beans classes. As background, the LogManager addPropertyChangeListener and removePropertyChangeListener result in a toxic dependency on classes in the beans package. With modularity coming then I think we will eventually get to the point where we need to consider removing these methods, that's a discussion for another day. In the mean-time we need to minimize the dependency to only the PropertyChangeListener and PropertyChangeEvent classes. The webrev with the change is here: http://cr.openjdk.java.net/~alanb/7192275/webrev/ The changes are very simple and just replace the code that was using PropertyChangeSupport (a supporting class) with a Map that is used to keep track of the registered listeners. One thing I found is that the tests in the jdk repository don't provide any coverage for these methods so I've used the opportunity to add a simple test to exercise this code. Thanks, Alan. From kumar.x.srinivasan at oracle.com Sat Aug 18 05:17:11 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 18 Aug 2012 12:17:11 +0000 Subject: hg: jdk8/tl/jdk: 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Message-ID: <20120818121739.E1A6F475C3@hg.openjdk.java.net> Changeset: 16f2865aac24 Author: ksrini Date: 2012-08-17 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16f2865aac24 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java From Dmitry.Samersoff at oracle.com Sat Aug 18 05:56:27 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 18 Aug 2012 16:56:27 +0400 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <502F6FFA.1050202@oracle.com> References: <502F6FFA.1050202@oracle.com> Message-ID: <502F90FB.8070202@oracle.com> Alan, 1. 315 - IMHO, it's better to call checkAccess() before null pointer check. This problem exists in original code as well. 2. This place is not clean for me - env is constant under loop. is it intentional? 975 for (int i = 0; i < count; i++) { 976 listener.propertyChange(ev); 977 } Besides that looks good for me. -Dmitry On 2012-08-18 14:35, Alan Bateman wrote: > > I need a reviewer for a small change to the LogManager implementation > that reduces its dependency on the beans classes. > > As background, the LogManager addPropertyChangeListener and > removePropertyChangeListener result in a toxic dependency on classes in > the beans package. With modularity coming then I think we will > eventually get to the point where we need to consider removing these > methods, that's a discussion for another day. In the mean-time we need > to minimize the dependency to only the PropertyChangeListener and > PropertyChangeEvent classes. > > The webrev with the change is here: > http://cr.openjdk.java.net/~alanb/7192275/webrev/ > > The changes are very simple and just replace the code that was using > PropertyChangeSupport (a supporting class) with a Map that is used to > keep track of the registered listeners. One thing I found is that the > tests in the jdk repository don't provide any coverage for these methods > so I've used the opportunity to add a simple test to exercise this code. > > Thanks, > Alan. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From mandy.chung at oracle.com Sat Aug 18 11:09:43 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 18 Aug 2012 11:09:43 -0700 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <502F6FFA.1050202@oracle.com> References: <502F6FFA.1050202@oracle.com> Message-ID: <502FDA67.1030706@oracle.com> Alan, Looks good to me. It's good to add a test to cover these methods (thanks). You might want to add the case when SecurityManager is enabled. Your change doesn't affect the permission check and I'm fine with what you have. Mandy On 8/18/2012 3:35 AM, Alan Bateman wrote: > > I need a reviewer for a small change to the LogManager implementation > that reduces its dependency on the beans classes. > > As background, the LogManager addPropertyChangeListener and > removePropertyChangeListener result in a toxic dependency on classes > in the beans package. With modularity coming then I think we will > eventually get to the point where we need to consider removing these > methods, that's a discussion for another day. In the mean-time we need > to minimize the dependency to only the PropertyChangeListener and > PropertyChangeEvent classes. > > The webrev with the change is here: > http://cr.openjdk.java.net/~alanb/7192275/webrev/ > > The changes are very simple and just replace the code that was using > PropertyChangeSupport (a supporting class) with a Map that is used to > keep track of the registered listeners. One thing I found is that the > tests in the jdk repository don't provide any coverage for these > methods so I've used the opportunity to add a simple test to exercise > this code. > > Thanks, > Alan. From Alan.Bateman at oracle.com Sat Aug 18 12:37:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 18 Aug 2012 20:37:20 +0100 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <502F90FB.8070202@oracle.com> References: <502F6FFA.1050202@oracle.com> <502F90FB.8070202@oracle.com> Message-ID: <502FEEF0.1060101@oracle.com> Thanks for reviewing this, replies inline. On 18/08/2012 13:56, Dmitry Samersoff wrote: > Alan, > > 1. 315 - IMHO, it's better to call checkAccess() before null pointer > check. This problem exists in original code as well. If there are two or more exceptions that are appropriate for a particular case then developers have to prepared for either. In the case if someone invokes the addPropertyChangeListener with null and at the same time would fail the permission check then either exception is valid; you can't assume one or the other. There can of course be cases where you have to be careful to do a permission check before other checks because failing some other check might reveal something to an adversary. This isn't the case here and in addition I don't think we should change existing behavior without good reason. > > 2. This place is not clean for me - env is constant under loop. > is it intentional? > > 975 for (int i = 0; i< count; i++) { > 976 listener.propertyChange(ev); > 977 } > It is intentional as the spec requires that a listener be invoked for as many times as it is registered. I could of course have used a while loop instead, maybe "while (count-- > 0)" but I think the above is clear. -Alan From Alan.Bateman at oracle.com Sat Aug 18 13:05:18 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 18 Aug 2012 21:05:18 +0100 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <502FDA67.1030706@oracle.com> References: <502F6FFA.1050202@oracle.com> <502FDA67.1030706@oracle.com> Message-ID: <502FF57E.5010102@oracle.com> On 18/08/2012 19:09, Mandy Chung wrote: > Alan, > > Looks good to me. It's good to add a test to cover these methods > (thanks). You might want to add the case when SecurityManager is > enabled. Your change doesn't affect the permission check and I'm fine > with what you have. > > Mandy Thanks for looking at this. Tests using a security manager would require a bit more work and slightly beyond the scope of the changes but let me see if I find time before pushing this change. -Alan. From Alan.Bateman at oracle.com Sat Aug 18 14:14:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 18 Aug 2012 22:14:34 +0100 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <502FF57E.5010102@oracle.com> References: <502F6FFA.1050202@oracle.com> <502FDA67.1030706@oracle.com> <502FF57E.5010102@oracle.com> Message-ID: <503005BA.50101@oracle.com> On 18/08/2012 21:05, Alan Bateman wrote: > Thanks for looking at this. Tests using a security manager would > require a bit more work and slightly beyond the scope of the changes > but let me see if I find time before pushing this change. I've updated the webrev with an addition test that exercise these methods with a security manager set. The test runs twice, once with a policy file that grants LoggingPermission("control"), the second time with the default policy. I think this should be good enough for now. http://cr.openjdk.java.net/~alanb/7192275/webrev/ -Alan. From mandy.chung at oracle.com Sat Aug 18 17:15:39 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 18 Aug 2012 17:15:39 -0700 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <503005BA.50101@oracle.com> References: <502F6FFA.1050202@oracle.com> <502FDA67.1030706@oracle.com> <502FF57E.5010102@oracle.com> <503005BA.50101@oracle.com> Message-ID: <5030302B.9030101@oracle.com> On 8/18/2012 2:14 PM, Alan Bateman wrote: > On 18/08/2012 21:05, Alan Bateman wrote: >> Thanks for looking at this. Tests using a security manager would >> require a bit more work and slightly beyond the scope of the changes >> but let me see if I find time before pushing this change. > I've updated the webrev with an addition test that exercise these > methods with a security manager set. The test runs twice, once with a > policy file that grants LoggingPermission("control"), the second time > with the default policy. I think this should be good enough for now. > > http://cr.openjdk.java.net/~alanb/7192275/webrev/ Looks good. Thanks Mandy From Dmitry.Samersoff at oracle.com Sun Aug 19 00:50:02 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 19 Aug 2012 11:50:02 +0400 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <502FEEF0.1060101@oracle.com> References: <502F6FFA.1050202@oracle.com> <502F90FB.8070202@oracle.com> <502FEEF0.1060101@oracle.com> Message-ID: <50309AAA.1060000@oracle.com> Alan, On 2012-08-18 23:37, Alan Bateman wrote: > Thanks for reviewing this, replies inline. > > On 18/08/2012 13:56, Dmitry Samersoff wrote: >> Alan, >> >> 1. 315 - IMHO, it's better to call checkAccess() before null pointer >> check. This problem exists in original code as well. > If there are two or more exceptions that are appropriate for a > particular case then developers have to prepared for either. I'm not sure it's correct in generic case - exception it self could be untrusted code so on my opinion security check have to be done first, before everything else. But I'm ok to leave everything as is in this case because it doesn't make things worth. Value of security check in non-final method is doubtful anyway. >> 2. This place is not clean for me - env is constant under loop. >> is it intentional? >> >> 975 for (int i = 0; i< count; i++) { >> 976 listener.propertyChange(ev); >> 977 } >> > It is intentional as the spec requires that a listener be invoked for as > many times as it is registered. I could of course have used a while loop > instead, maybe "while (count-- > 0)" but I think the above is clear. Thank you for clarification. I'm OK with for loop, but extra comments there wold be helpful. -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From alan.bateman at oracle.com Sun Aug 19 05:06:11 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Aug 2012 12:06:11 +0000 Subject: hg: jdk8/tl/jdk: 7192275: Minimize LogManager dependencies on java.beans Message-ID: <20120819120704.462214762F@hg.openjdk.java.net> Changeset: a2359f0f9533 Author: alanb Date: 2012-08-19 13:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2359f0f9533 7192275: Minimize LogManager dependencies on java.beans Summary: Reduce dependency to PropertyChangeListener and PropertyChangeEvent. Also add basic test coverage. Reviewed-by: dcubed, dsamersoff, mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Listeners.java + test/java/util/logging/ListenersWithSM.java + test/java/util/logging/java.policy From alan.bateman at oracle.com Sun Aug 19 05:30:25 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Aug 2012 12:30:25 +0000 Subject: hg: jdk8/tl/jdk: 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Message-ID: <20120819123045.5436247630@hg.openjdk.java.net> Changeset: 5e7cfe034df4 Author: alanb Date: 2012-08-19 13:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7cfe034df4 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! test/java/nio/file/WatchService/MayFlies.java From Alan.Bateman at oracle.com Sun Aug 19 05:56:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Aug 2012 13:56:12 +0100 Subject: 7192275: Minimize LogManager dependencies on java.beans In-Reply-To: <50309AAA.1060000@oracle.com> References: <502F6FFA.1050202@oracle.com> <502F90FB.8070202@oracle.com> <502FEEF0.1060101@oracle.com> <50309AAA.1060000@oracle.com> Message-ID: <5030E26C.4070604@oracle.com> On 19/08/2012 08:50, Dmitry Samersoff wrote: > : > I'm not sure it's correct in generic case - exception it self could be > untrusted code so on my opinion security check have to be done first, > before everything else. If there are cases where an exception might reveal something to an adversary then it would be appropriate to do the permission check and throw the SecurityException before other checks that might yield an exception. It is of course a non-issue with the code that we are looking at here as it's just an NPE. However in the general case then someone, say writing a conformance test, then they cannot assume the exception for cases where the more than one exception is possible. > > But I'm ok to leave everything as is in this case because it doesn't > make things worth. Value of security check in non-final method is > doubtful anyway. Yes, let's leave this one for now as it's not an issue and I don't want to be changing longstanding behavior with this change. As regards overriding the methods then they can certainly be done in a custom LogManager but such as custom LogManager would not be returned by LogManager.getLogManager (unless configured via the java.util.logging.manager property of course). So thanks for the review, the changes are in jdk8/tl/jdk now. -Alan. From staffan.larsen at oracle.com Sun Aug 19 12:52:52 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 19 Aug 2012 21:52:52 +0200 Subject: JEP 158: Unified JVM logging In-Reply-To: <325CA5D7-13B4-4A72-ADA2-C7BFAA9F1353@kodewerk.com> References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com><3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com><4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> <502BB003.8020701@oracle.com> <2FF50E25-8A2C-4837-8C46-44E8C5CD6180@oracle.com> <325CA5D7-13B4-4A72-ADA2-C7BFAA9F1353@kodewerk.com> Message-ID: <026A78FD-9F3C-4332-8621-24BFF012B065@oracle.com> On 17 aug 2012, at 22:32, Kirk Pepperdine wrote: >> >> The suggestion in the JEP is that each category/component has several levels, so in that sense they are not independent. To enable logging you would specify a list of {component, level} tuples, like: >> >> gc:info, younggen:trace >> >> But to make it easier to type in the most common case the 'info' level is considered 'default' if nothing else is specified. So the above would be equivalent to saying just >> >> gc, younggen:trace > > Right, and this is at the heart of one of my objections is that the predefined levels used by everyone lack semantic meaning where as being able to define tags or groups of tags would allow one to define levels but not force one to use levels. There certainly is a case for levels and I would not want them precluded but I do not believe it is desirable for all components to hierarchically reduce log messages. > > If I had a better idea of the schedule for the JEP I'd have a better understanding of when I might be able to pitch in rather then just play seagull. The schedule is vague at the best. Originally we thought we could do this for jdk 8, but there aren't resources enough to do that. I'm still hoping for jdk 9, but the infrastructure needs to be done early in the jdk 9 schedule to give all groups time to adapt their logging. No resources (within Oracle) has yet been committed to the project. /Staffan From weijun.wang at oracle.com Sun Aug 19 17:00:18 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 20 Aug 2012 00:00:18 +0000 Subject: hg: jdk8/tl/jdk: 7192202: Make sure keytool prints both unknown and unparseable extensions Message-ID: <20120820000050.9204147635@hg.openjdk.java.net> Changeset: 86c963b1dbf8 Author: weijun Date: 2012-08-20 07:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c963b1dbf8 7192202: Make sure keytool prints both unknown and unparseable extensions Reviewed-by: mullan + test/sun/security/tools/keytool/UnknownAndUnparseable.java From rob.mckenna at oracle.com Mon Aug 20 06:50:34 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 20 Aug 2012 13:50:34 +0000 Subject: hg: jdk8/tl/jdk: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Message-ID: <20120820135100.E98944763F@hg.openjdk.java.net> Changeset: 59aa7660ade4 Author: robm Date: 2012-08-20 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59aa7660ade4 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Reviewed-by: dholmes, alanb ! test/java/lang/ProcessBuilder/Basic.java From sundararajan.athijegannathan at oracle.com Mon Aug 20 08:52:11 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 20 Aug 2012 15:52:11 +0000 Subject: hg: jdk8/tl/langtools: 7181320: javac NullPointerException for switch labels with cast to String expressions Message-ID: <20120820155215.0C83D47641@hg.openjdk.java.net> Changeset: 464f52f59f7d Author: sundar Date: 2012-08-20 21:24 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/464f52f59f7d 7181320: javac NullPointerException for switch labels with cast to String expressions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/StringsInSwitch/7181320/BinOpInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CastInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel1.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel2.java From jonathan.gibbons at oracle.com Mon Aug 20 13:50:39 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 20 Aug 2012 20:50:39 +0000 Subject: hg: jdk8/tl/langtools: 7192744: fix up tests to accommodate jtreg spec change Message-ID: <20120820205043.5BB7B4764C@hg.openjdk.java.net> Changeset: 37008b4cd97a Author: jjg Date: 2012-08-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37008b4cd97a 7192744: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/T6920317.java From james.holmlund at oracle.com Mon Aug 20 13:51:30 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Mon, 20 Aug 2012 13:51:30 -0700 Subject: -Xdebug a no-op? In-Reply-To: <502E1476.5050303@oracle.com> References: <20832C43-585D-4FF8-85F1-21997F556E6A@oracle.com> <502E1476.5050303@oracle.com> Message-ID: <5032A352.7060803@oracle.com> On 8/17/2012 2:52 AM, serguei.spitsyn at oracle.com wrote: > Staffan, > > If I remember correctly, the -Xdebug options was to enable JVMDI which was deprecated in JDK 5.0. > Please, refer to this page: > http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html > > The JVMDI was still available in 5.0 but was implemented as wrapper api of the JVMTI. > I've included Jim Holmlund, the former JPDA spec lead, to keep me honest. > You are an honest man! - jjh > This is the only code in VM that still depends on the -Xdebug flag value but not sure it is still > valid: > > src/share/vm/runtime/arguments.cpp: > 2852 jint Arguments::finalize_vm_init_args(SysClassPath* scp_p, bool scp_assembly_required) { > 2853 // This must be done after all -D arguments have been processed. > 2854 scp_p->expand_endorsed(); > 2855 > 2856 if (scp_assembly_required || scp_p->get_endorsed() != NULL) { > 2857 // Assemble the bootclasspath elements into the final path. > 2858 Arguments::set_sysclasspath(scp_p->combined_path()); > 2859 } > 2860 > 2861 // This must be done after all arguments have been processed. > 2862 // java_compiler() true means set to "NONE" or empty. > 2863 if (java_compiler()&& !xdebug_mode()) { > 2864 // For backwards compatibility, we switch to interpreted mode if > 2865 // -Djava.compiler="NONE" or "" is specified AND "-Xdebug" was > 2866 // not specified. > 2867 set_mode_flags(_int); > 2868 } > > > Thanks, > Serguei > > On 8/17/12 12:59 AM, Staffan Larsen wrote: >> Can someone confirm that -Xdebug is mostly a no-op flag right now? I assume it is still there for backwards compatibility, but it does not seem to have any impact. >> >> Thanks, >> /Staffan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120820/2f3146c0/attachment.html From serguei.spitsyn at oracle.com Mon Aug 20 14:48:08 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Aug 2012 14:48:08 -0700 Subject: -Xdebug a no-op? In-Reply-To: <5032A352.7060803@oracle.com> References: <20832C43-585D-4FF8-85F1-21997F556E6A@oracle.com> <502E1476.5050303@oracle.com> <5032A352.7060803@oracle.com> Message-ID: <5032B098.6050305@oracle.com> Thanks! Serguei On 8/20/12 1:51 PM, Jim Holmlund wrote: > > > On 8/17/2012 2:52 AM, serguei.spitsyn at oracle.com wrote: >> Staffan, >> >> If I remember correctly, the -Xdebug options was to enable JVMDI >> which was deprecated in JDK 5.0. >> Please, refer to this page: >> http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html >> >> The JVMDI was still available in 5.0 but was implemented as wrapper >> api of the JVMTI. >> I've included Jim Holmlund, the former JPDA spec lead, to keep me honest. >> > You are an honest man! > - jjh > >> This is the only code in VM that still depends on the -Xdebug flag >> value but not sure it is still valid: >> >> src/share/vm/runtime/arguments.cpp: >> 2852 jint Arguments::finalize_vm_init_args(SysClassPath* scp_p, bool scp_assembly_required) { >> 2853 // This must be done after all -D arguments have been processed. >> 2854 scp_p->expand_endorsed(); >> 2855 >> 2856 if (scp_assembly_required || scp_p->get_endorsed() != NULL) { >> 2857 // Assemble the bootclasspath elements into the final path. >> 2858 Arguments::set_sysclasspath(scp_p->combined_path()); >> 2859 } >> 2860 >> 2861 // This must be done after all arguments have been processed. >> 2862 // java_compiler() true means set to "NONE" or empty. >> 2863 if (java_compiler() && !xdebug_mode()) { >> 2864 // For backwards compatibility, we switch to interpreted mode if >> 2865 // -Djava.compiler="NONE" or "" is specified AND "-Xdebug" was >> 2866 // not specified. >> 2867 set_mode_flags(_int); >> 2868 } >> >> >> Thanks, >> Serguei >> >> On 8/17/12 12:59 AM, Staffan Larsen wrote: >>> Can someone confirm that -Xdebug is mostly a no-op flag right now? I assume it is still there for backwards compatibility, but it does not seem to have any impact. >>> >>> Thanks, >>> /Staffan >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120820/21a9baeb/attachment.html From alan.bateman at oracle.com Tue Aug 21 05:45:35 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 Aug 2012 12:45:35 +0000 Subject: hg: jdk8/tl/jdk: 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Message-ID: <20120821124603.52E8E4765B@hg.openjdk.java.net> Changeset: 6d29c2af040f Author: alanb Date: 2012-08-21 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d29c2af040f 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Reviewed-by: alanb Contributed-by: Shirish Kuncolienkar ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java + test/java/nio/channels/SelectionKey/RacyRegister.java From naoto.sato at oracle.com Tue Aug 21 11:03:47 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 21 Aug 2012 18:03:47 +0000 Subject: hg: jdk8/tl/jdk: 6336885: RFE: Locale Data Deployment Enhancements; ... Message-ID: <20120821180407.CD1CF4766A@hg.openjdk.java.net> Changeset: 131a683a2ce0 Author: naoto Date: 2012-08-21 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/131a683a2ce0 6336885: RFE: Locale Data Deployment Enhancements 4609153: Provide locale data for Indic locales 5104387: Support for gl_ES locale (galician language) 6337471: desktop/system locale preferences support 7056139: (cal) SPI support for locale-dependent Calendar parameters 7058206: Provide CalendarData SPI for week params and display field value names 7073852: Support multiple scripts for digits and decimal symbols per locale 7079560: [Fmt-Da] Context dependent month names support in SimpleDateFormat 7171324: getAvailableLocales() of locale sensitive services should return the actual availability of locales 7151414: (cal) Support calendar type identification 7168528: LocaleServiceProvider needs to be aware of Locale extensions 7171372: (cal) locale's default Calendar should be created if unknown calendar is specified Summary: JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (part 1 w/o packaging changes. by Naoto Sato and Masayoshi Okutsu) Reviewed-by: erikj, sherman, peytoia ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/java/mapfile-vers ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/java/util/Makefile ! make/sun/Makefile + make/sun/cldr/Makefile ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! make/sun/text/Makefile ! make/tools/Makefile + make/tools/cldrconverter/Makefile + make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java + make/tools/src/build/tools/cldrconverter/Bundle.java + make/tools/src/build/tools/cldrconverter/BundleGenerator.java + make/tools/src/build/tools/cldrconverter/CLDRConverter.java + make/tools/src/build/tools/cldrconverter/CalendarType.java + make/tools/src/build/tools/cldrconverter/Container.java + make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java + make/tools/src/build/tools/cldrconverter/Entry.java + make/tools/src/build/tools/cldrconverter/IgnoredContainer.java + make/tools/src/build/tools/cldrconverter/KeyContainer.java + make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java + make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java + make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java + make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java + make/tools/src/build/tools/cldrconverter/StringArrayElement.java + make/tools/src/build/tools/cldrconverter/StringArrayEntry.java + make/tools/src/build/tools/cldrconverter/StringEntry.java + make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java + make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateJavaSources.gmk + makefiles/GensrcCLDR.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcProperties.gmk ! makefiles/Tools.gmk + src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c - src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java - src/share/classes/java/text/CollationRules.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/NumberFormat.java - src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java + src/share/classes/java/util/spi/CalendarDataProvider.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/javax/swing/JSpinner.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java ! src/share/classes/sun/text/resources/FormatData.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java + src/share/classes/sun/text/resources/ar/CollationData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java + src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java + src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java + src/share/classes/sun/text/resources/be/CollationData_be.java + src/share/classes/sun/text/resources/be/FormatData_be.java + src/share/classes/sun/text/resources/be/FormatData_be_BY.java + src/share/classes/sun/text/resources/bg/CollationData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java + src/share/classes/sun/text/resources/ca/CollationData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java + src/share/classes/sun/text/resources/cs/CollationData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java + src/share/classes/sun/text/resources/da/CollationData_da.java + src/share/classes/sun/text/resources/da/FormatData_da.java + src/share/classes/sun/text/resources/da/FormatData_da_DK.java + src/share/classes/sun/text/resources/de/FormatData_de.java + src/share/classes/sun/text/resources/de/FormatData_de_AT.java + src/share/classes/sun/text/resources/de/FormatData_de_CH.java + src/share/classes/sun/text/resources/de/FormatData_de_DE.java + src/share/classes/sun/text/resources/de/FormatData_de_LU.java + src/share/classes/sun/text/resources/el/CollationData_el.java + src/share/classes/sun/text/resources/el/FormatData_el.java + src/share/classes/sun/text/resources/el/FormatData_el_CY.java + src/share/classes/sun/text/resources/el/FormatData_el_GR.java + src/share/classes/sun/text/resources/en/FormatData_en.java + src/share/classes/sun/text/resources/en/FormatData_en_AU.java + src/share/classes/sun/text/resources/en/FormatData_en_CA.java + src/share/classes/sun/text/resources/en/FormatData_en_GB.java + src/share/classes/sun/text/resources/en/FormatData_en_IE.java + src/share/classes/sun/text/resources/en/FormatData_en_IN.java + src/share/classes/sun/text/resources/en/FormatData_en_MT.java + src/share/classes/sun/text/resources/en/FormatData_en_NZ.java + src/share/classes/sun/text/resources/en/FormatData_en_PH.java + src/share/classes/sun/text/resources/en/FormatData_en_SG.java + src/share/classes/sun/text/resources/en/FormatData_en_US.java + src/share/classes/sun/text/resources/en/FormatData_en_ZA.java + src/share/classes/sun/text/resources/es/CollationData_es.java + src/share/classes/sun/text/resources/es/FormatData_es.java + src/share/classes/sun/text/resources/es/FormatData_es_AR.java + src/share/classes/sun/text/resources/es/FormatData_es_BO.java + src/share/classes/sun/text/resources/es/FormatData_es_CL.java + src/share/classes/sun/text/resources/es/FormatData_es_CO.java + src/share/classes/sun/text/resources/es/FormatData_es_CR.java + src/share/classes/sun/text/resources/es/FormatData_es_DO.java + src/share/classes/sun/text/resources/es/FormatData_es_EC.java + src/share/classes/sun/text/resources/es/FormatData_es_ES.java + src/share/classes/sun/text/resources/es/FormatData_es_GT.java + src/share/classes/sun/text/resources/es/FormatData_es_HN.java + src/share/classes/sun/text/resources/es/FormatData_es_MX.java + src/share/classes/sun/text/resources/es/FormatData_es_NI.java + src/share/classes/sun/text/resources/es/FormatData_es_PA.java + src/share/classes/sun/text/resources/es/FormatData_es_PE.java + src/share/classes/sun/text/resources/es/FormatData_es_PR.java + src/share/classes/sun/text/resources/es/FormatData_es_PY.java + src/share/classes/sun/text/resources/es/FormatData_es_SV.java + src/share/classes/sun/text/resources/es/FormatData_es_US.java + src/share/classes/sun/text/resources/es/FormatData_es_UY.java + src/share/classes/sun/text/resources/es/FormatData_es_VE.java + src/share/classes/sun/text/resources/et/CollationData_et.java + src/share/classes/sun/text/resources/et/FormatData_et.java + src/share/classes/sun/text/resources/et/FormatData_et_EE.java + src/share/classes/sun/text/resources/fi/CollationData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java + src/share/classes/sun/text/resources/fr/CollationData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java + src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java + src/share/classes/sun/text/resources/ga/FormatData_ga.java + src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java + src/share/classes/sun/text/resources/hi/CollationData_hi.java + src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java + src/share/classes/sun/text/resources/hr/CollationData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java + src/share/classes/sun/text/resources/hu/CollationData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java + src/share/classes/sun/text/resources/in/FormatData_in.java + src/share/classes/sun/text/resources/in/FormatData_in_ID.java + src/share/classes/sun/text/resources/is/CollationData_is.java + src/share/classes/sun/text/resources/is/FormatData_is.java + src/share/classes/sun/text/resources/is/FormatData_is_IS.java + src/share/classes/sun/text/resources/it/FormatData_it.java + src/share/classes/sun/text/resources/it/FormatData_it_CH.java + src/share/classes/sun/text/resources/it/FormatData_it_IT.java + src/share/classes/sun/text/resources/iw/CollationData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java + src/share/classes/sun/text/resources/ja/CollationData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java + src/share/classes/sun/text/resources/ko/CollationData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java + src/share/classes/sun/text/resources/lt/CollationData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java + src/share/classes/sun/text/resources/lv/CollationData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java + src/share/classes/sun/text/resources/mk/CollationData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java + src/share/classes/sun/text/resources/ms/FormatData_ms.java + src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java + src/share/classes/sun/text/resources/mt/FormatData_mt.java + src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java + src/share/classes/sun/text/resources/nl/FormatData_nl.java + src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java + src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java + src/share/classes/sun/text/resources/no/CollationData_no.java + src/share/classes/sun/text/resources/no/FormatData_no.java + src/share/classes/sun/text/resources/no/FormatData_no_NO.java + src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java + src/share/classes/sun/text/resources/pl/CollationData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java + src/share/classes/sun/text/resources/pt/FormatData_pt.java + src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java + src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java + src/share/classes/sun/text/resources/ro/CollationData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java + src/share/classes/sun/text/resources/ru/CollationData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java + src/share/classes/sun/text/resources/sk/CollationData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java + src/share/classes/sun/text/resources/sl/CollationData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java + src/share/classes/sun/text/resources/sq/CollationData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java + src/share/classes/sun/text/resources/sr/CollationData_sr.java + src/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr.java + src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java + src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java + src/share/classes/sun/text/resources/sv/CollationData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java + src/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java + src/share/classes/sun/text/resources/th/BreakIteratorRules_th.java + src/share/classes/sun/text/resources/th/CollationData_th.java + src/share/classes/sun/text/resources/th/FormatData_th.java + src/share/classes/sun/text/resources/th/FormatData_th_TH.java + src/share/classes/sun/text/resources/th/thai_dict - src/share/classes/sun/text/resources/thai_dict + src/share/classes/sun/text/resources/tr/CollationData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java + src/share/classes/sun/text/resources/uk/CollationData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java + src/share/classes/sun/text/resources/vi/CollationData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java + src/share/classes/sun/text/resources/zh/CollationData_zh.java + src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java + src/share/classes/sun/text/resources/zh/CollationData_zh_TW.java + src/share/classes/sun/text/resources/zh/FormatData_zh.java + src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java + src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java + src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java + src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/BuddhistCalendar.java - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java + src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java + src/share/classes/sun/util/cldr/resources/21_0_1/LICENSE + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldml.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldmlSupplemental.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_001.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_AE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_BH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_EG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_IQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_JO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_KW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_OM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_QA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_TN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_YE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be_BY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem_ZM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg_BG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_BD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs_CZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da_DK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_AT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz_BT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_CY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_GR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_JM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_TT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_UM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US_POSIX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_VI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_419.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_AR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_BO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_DO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_EC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_HN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_MX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_NI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_SV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_UY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_VE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et_EE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_IR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo_FO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_KM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_YT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he_IL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr_HR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu_HU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy_AM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ia.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id_ID.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is_IS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja_JP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka_GE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea_CV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl_KZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl_GL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km_KH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko_KR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo_LA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt_LT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv_LV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk_MK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_BN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_MY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my_MM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_NP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_AW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_CW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_NL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_SX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl_PL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_AO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_BR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_GW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_PT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_ST.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_RO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk_SK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl_SI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_SO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq_AL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_SZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_LS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_SE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl_TJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th_TH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to_TO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr_TR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi_VN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_TW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/metaZones.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/numberingSystems.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/supplementalData.xml ! src/share/classes/sun/util/locale/LocaleUtils.java + src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/AvailableLanguageTags.java + src/share/classes/sun/util/locale/provider/BreakDictionary.java + src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CollationRules.java + src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java + src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DecimalFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/HostLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/JRELocaleConstants.java + src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template + src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java + src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + src/share/classes/sun/util/locale/provider/NumberFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java + src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleData.java - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/resources/OpenListResourceBundle.java - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java + src/share/classes/sun/util/resources/ar/CalendarData_ar.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties + src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties + src/share/classes/sun/util/resources/be/CalendarData_be.properties + src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties + src/share/classes/sun/util/resources/be/LocaleNames_be.properties + src/share/classes/sun/util/resources/bg/CalendarData_bg.properties + src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties + src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties + src/share/classes/sun/util/resources/ca/CalendarData_ca.properties + src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties + src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties + src/share/classes/sun/util/resources/cs/CalendarData_cs.properties + src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties + src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties + src/share/classes/sun/util/resources/da/CalendarData_da.properties + src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties + src/share/classes/sun/util/resources/da/LocaleNames_da.properties + src/share/classes/sun/util/resources/de/CalendarData_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties + src/share/classes/sun/util/resources/de/LocaleNames_de.properties + src/share/classes/sun/util/resources/de/TimeZoneNames_de.java + src/share/classes/sun/util/resources/el/CalendarData_el.properties + src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties + src/share/classes/sun/util/resources/el/LocaleNames_el.properties + src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties + src/share/classes/sun/util/resources/en/CalendarData_en.properties + src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties + src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties + src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties + src/share/classes/sun/util/resources/en/LocaleNames_en.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties + src/share/classes/sun/util/resources/en/TimeZoneNames_en.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_CA.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_GB.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_IE.java + src/share/classes/sun/util/resources/es/CalendarData_es.properties + src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties + src/share/classes/sun/util/resources/es/CalendarData_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PE.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties + src/share/classes/sun/util/resources/es/LocaleNames_es.properties + src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties + src/share/classes/sun/util/resources/es/TimeZoneNames_es.java + src/share/classes/sun/util/resources/et/CalendarData_et.properties + src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties + src/share/classes/sun/util/resources/et/LocaleNames_et.properties + src/share/classes/sun/util/resources/fi/CalendarData_fi.properties + src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties + src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties + src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties + src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java + src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties + src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties + src/share/classes/sun/util/resources/hi/CalendarData_hi.properties + src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties + src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties + src/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java + src/share/classes/sun/util/resources/hr/CalendarData_hr.properties + src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties + src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties + src/share/classes/sun/util/resources/hu/CalendarData_hu.properties + src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties + src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties + src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties + src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties + src/share/classes/sun/util/resources/in/LocaleNames_in.properties + src/share/classes/sun/util/resources/is/CalendarData_is.properties + src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties + src/share/classes/sun/util/resources/is/LocaleNames_is.properties + src/share/classes/sun/util/resources/it/CalendarData_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties + src/share/classes/sun/util/resources/it/LocaleNames_it.properties + src/share/classes/sun/util/resources/it/TimeZoneNames_it.java + src/share/classes/sun/util/resources/iw/CalendarData_iw.properties + src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties + src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties + src/share/classes/sun/util/resources/ja/CalendarData_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties + src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties + src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java + src/share/classes/sun/util/resources/ko/CalendarData_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties + src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties + src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java + src/share/classes/sun/util/resources/lt/CalendarData_lt.properties + src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties + src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties + src/share/classes/sun/util/resources/lv/CalendarData_lv.properties + src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties + src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties + src/share/classes/sun/util/resources/mk/CalendarData_mk.properties + src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties + src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties + src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties + src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties + src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties + src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties + src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties + src/share/classes/sun/util/resources/nl/CalendarData_nl.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties + src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties + src/share/classes/sun/util/resources/no/CalendarData_no.properties + src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties + src/share/classes/sun/util/resources/no/LocaleNames_no.properties + src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties + src/share/classes/sun/util/resources/pl/CalendarData_pl.properties + src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties + src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java + src/share/classes/sun/util/resources/ro/CalendarData_ro.properties + src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties + src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties + src/share/classes/sun/util/resources/ru/CalendarData_ru.properties + src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties + src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties + src/share/classes/sun/util/resources/sk/CalendarData_sk.properties + src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties + src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties + src/share/classes/sun/util/resources/sl/CalendarData_sl.properties + src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties + src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties + src/share/classes/sun/util/resources/sq/CalendarData_sq.properties + src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties + src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties + src/share/classes/sun/util/resources/sv/CalendarData_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties + src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties + src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java + src/share/classes/sun/util/resources/th/CalendarData_th.properties + src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties + src/share/classes/sun/util/resources/th/LocaleNames_th.properties + src/share/classes/sun/util/resources/tr/CalendarData_tr.properties + src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties + src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties + src/share/classes/sun/util/resources/uk/CalendarData_uk.properties + src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties + src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties + src/share/classes/sun/util/resources/vi/CalendarData_vi.properties + src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties + src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties + src/share/classes/sun/util/resources/zh/CalendarData_zh.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java + src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java + src/solaris/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/solaris/native/java/lang/java_props_macosx.c + src/solaris/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + test/java/text/Format/DateFormat/ContextMonthNamesTest.java + test/java/text/Format/NumberFormat/MultipleNumberScriptTest.java + test/java/util/Calendar/CalendarTypeTest.java ! test/java/util/Locale/Bug6989440.java + test/java/util/Locale/ExtensionsTest.java ! test/java/util/Locale/LocaleCategory.sh + test/java/util/Locale/LocaleProviders.java + test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/ProviderTest.java + test/java/util/PluggableLocale/SupportedLocalesTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From serguei.spitsyn at oracle.com Tue Aug 21 11:13:07 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Aug 2012 11:13:07 -0700 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method Message-ID: <5033CFB3.4010305@oracle.com> Hello, Please, review the fix for: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ Summary: The following CR was recently fixed: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 But the same issue exists for the LocalVariableTypeTable attribute. The fix was tested with the modified test: test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh The modification is that a local variable with generic signature is added to the class DummyClassWithLVT.java: http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ The test patch will be integrated into the jdk8/tl after the HotSpot fix is promoted. Thanks, Serguei From Dmitry.Samersoff at oracle.com Tue Aug 21 11:47:05 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 22:47:05 +0400 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5033CFB3.4010305@oracle.com> References: <5033CFB3.4010305@oracle.com> Message-ID: <5033D7A9.7050108@oracle.com> Serguei, jvmtiClassFileReconstituter.cpp: 178: attr_count was 1 but become 0 for the case has_localvariable_table() == true && local_variable_table_length == 0 is it intentional? 202: local_variable_type_table_length is always 0 if local_variable_table_length == 0 so I think if should be nested. 216: It might be better to place both attr_size changes together. i.e. if (local_variable_table_length != 0) { ++attr_count; LocalVariableTableElement *elem = method->localvariable_table_start(); for (int idx = 0; idx < local_variable_table_length; idx++) { ... } // Big comment block attr_size += 2 + 4 + 2 + local_variable_table_length ... if (local_variable_type_table_length != 0) { ++attr_count; attr_size += 2 + 4 + 2 + local_variable_type_table_length ... } } -Dmitry On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: > Hello, > > > Please, review the fix for: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ > > > Summary: > > The following CR was recently fixed: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 > > But the same issue exists for the LocalVariableTypeTable attribute. > > The fix was tested with the modified test: > test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh > > The modification is that a local variable with generic signature is added > to the class DummyClassWithLVT.java: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ > > > The test patch will be integrated into the jdk8/tl after the HotSpot fix > is promoted. > > > Thanks, > Serguei -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Tue Aug 21 12:05:38 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Aug 2012 12:05:38 -0700 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5033D7A9.7050108@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> Message-ID: <5033DC02.3050102@oracle.com> Dmitry, Please, see inlined. On 8/21/12 11:47 AM, Dmitry Samersoff wrote: > Serguei, > > jvmtiClassFileReconstituter.cpp: > > 178: attr_count was 1 but become 0 for the case > > has_localvariable_table() == true && local_variable_table_length == 0 > > is it intentional? Yes. You can see the same pattern for all attributes (for instance, has_stackmap_table - L160). > > > 202: local_variable_type_table_length > is always 0 if local_variable_table_length == 0 > > so I think if should be nested. It does not matter. > > 216: It might be better to place both attr_size changes together. > > i.e. > > if (local_variable_table_length != 0) { > ++attr_count; > LocalVariableTableElement *elem = method->localvariable_table_start(); > for (int idx = 0; idx < local_variable_table_length; idx++) { > ... > } > > // Big comment block > > attr_size += 2 + 4 + 2 + local_variable_table_length ... > if (local_variable_type_table_length != 0) { > ++attr_count; > attr_size += 2 + 4 + 2 + local_variable_type_table_length ... > } > > } I'm trying to follow the existing style. But thank you for sharing your thoughts on this! Thanks, Serguei > > -Dmitry > > > On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >> Hello, >> >> >> Please, review the fix for: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >> >> >> Summary: >> >> The following CR was recently fixed: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >> >> But the same issue exists for the LocalVariableTypeTable attribute. >> >> The fix was tested with the modified test: >> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >> >> The modification is that a local variable with generic signature is added >> to the class DummyClassWithLVT.java: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >> >> >> The test patch will be integrated into the jdk8/tl after the HotSpot fix >> is promoted. >> >> >> Thanks, >> Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120821/d9addf34/attachment.html From Dmitry.Samersoff at oracle.com Tue Aug 21 12:05:57 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 23:05:57 +0400 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Message-ID: <5033DC15.4070108@oracle.com> Hi Everybody, Please review small fix. http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Aug 21 12:11:17 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 23:11:17 +0400 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5033DC02.3050102@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> Message-ID: <5033DD55.1010902@oracle.com> Serguei, On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: > You can see the same pattern for all attributes (for instance, > has_stackmap_table - L160). OK. >> 202: local_variable_type_table_length >> is always 0 if local_variable_table_length == 0 >> >> so I think if should be nested. > It does not matter. It saves one if in some cases and makes logic better readable, so I would like to have it changed. Sorry! >> 216: It might be better to place both attr_size changes together. > I'm trying to follow the existing style. OK -Dmitry > > > Thanks, > Serguei >> >> -Dmitry >> >> >> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>> Hello, >>> >>> >>> Please, review the fix for: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>> >>> >>> Summary: >>> >>> The following CR was recently fixed: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>> >>> But the same issue exists for the LocalVariableTypeTable attribute. >>> >>> The fix was tested with the modified test: >>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>> >>> The modification is that a local variable with generic signature is added >>> to the class DummyClassWithLVT.java: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>> >>> >>> The test patch will be integrated into the jdk8/tl after the HotSpot fix >>> is promoted. >>> >>> >>> Thanks, >>> Serguei >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Tue Aug 21 12:23:50 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Aug 2012 20:23:50 +0100 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033DC15.4070108@oracle.com> References: <5033DC15.4070108@oracle.com> Message-ID: <5033E046.1040104@oracle.com> On 21/08/2012 20:05, Dmitry Samersoff wrote: > Hi Everybody, > > Please review small fix. > > http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ > > -Dmitry > Can you explain the issue a bit further? Looking at the code I can see there may be an issue with asynchronous detach (my default, I didn't get that right in the original implementation) but I can't tell if this is what you are trying to address now. -Alan From serguei.spitsyn at oracle.com Tue Aug 21 12:45:36 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Aug 2012 12:45:36 -0700 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5033DD55.1010902@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> Message-ID: <5033E560.7000304@oracle.com> On 8/21/12 12:11 PM, Dmitry Samersoff wrote: > Serguei, > > On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >> You can see the same pattern for all attributes (for instance, >> has_stackmap_table - L160). > OK. > >>> 202: local_variable_type_table_length >>> is always 0 if local_variable_table_length == 0 >>> >>> so I think if should be nested. >> It does not matter. > It saves one if in some cases and makes logic better readable, > so I would like to have it changed. > > Sorry! In fact, I initially considered this option and can change it as you prefer. But let's wait for other reviewers input. Thanks, Serguei > >>> 216: It might be better to place both attr_size changes together. >> I'm trying to follow the existing style. > OK > > -Dmitry > > >> >> Thanks, >> Serguei >>> -Dmitry >>> >>> >>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>> Hello, >>>> >>>> >>>> Please, review the fix for: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>> >>>> >>>> Summary: >>>> >>>> The following CR was recently fixed: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>> >>>> But the same issue exists for the LocalVariableTypeTable attribute. >>>> >>>> The fix was tested with the modified test: >>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>> >>>> The modification is that a local variable with generic signature is added >>>> to the class DummyClassWithLVT.java: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>> >>>> >>>> The test patch will be integrated into the jdk8/tl after the HotSpot fix >>>> is promoted. >>>> >>>> >>>> Thanks, >>>> Serguei > From Dmitry.Samersoff at oracle.com Tue Aug 21 12:57:53 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 21 Aug 2012 23:57:53 +0400 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5033E560.7000304@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> Message-ID: <5033E841.5070600@oracle.com> Serguei, On 2012-08-21 23:45, serguei.spitsyn at oracle.com wrote: > In fact, I initially considered this option and can change it as you > prefer. > But let's wait for other reviewers input. Sure! Thank you! -Dmitry > > Thanks, > Serguei > >> >>>> 216: It might be better to place both attr_size changes together. >>> I'm trying to follow the existing style. >> OK >> >> -Dmitry >> >> >>> >>> Thanks, >>> Serguei >>>> -Dmitry >>>> >>>> >>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>> Hello, >>>>> >>>>> >>>>> Please, review the fix for: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The following CR was recently fixed: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>> >>>>> But the same issue exists for the LocalVariableTypeTable attribute. >>>>> >>>>> The fix was tested with the modified test: >>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>> >>>>> The modification is that a local variable with generic signature is >>>>> added >>>>> to the class DummyClassWithLVT.java: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>> >>>>> >>>>> >>>>> The test patch will be integrated into the jdk8/tl after the >>>>> HotSpot fix >>>>> is promoted. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Tue Aug 21 13:11:45 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Aug 2012 00:11:45 +0400 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033E046.1040104@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> Message-ID: <5033EB81.7020308@oracle.com> Alan, Client detaches from target VM for some reason, so we get EBADF from native layer. It happens rare - once for 1000 iterations or so, depends to hardware, so I'm not sure we should fix it. Serializing enqueue() call we reduce probability of it ever more. -Dmitry On 2012-08-21 23:23, Alan Bateman wrote: > On 21/08/2012 20:05, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >> >> -Dmitry >> > Can you explain the issue a bit further? Looking at the code I can see > there may be an issue with asynchronous detach (my default, I didn't get > that right in the original implementation) but I can't tell if this is > what you are trying to address now. > > -Alan -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Tue Aug 21 13:15:12 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Aug 2012 13:15:12 -0700 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033E046.1040104@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> Message-ID: <5033EC50.30206@oracle.com> Dmitry, It is not clear how would moving the enqueue() call into the synchronized statement solve the asynchronous detach issue. Will this issue come back in some other form? The test is still going to fail intermittently, right? What is reason of the the asynchronous detach? Thanks, Serguei On 8/21/12 12:23 PM, Alan Bateman wrote: > On 21/08/2012 20:05, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >> >> -Dmitry >> > Can you explain the issue a bit further? Looking at the code I can see > there may be an issue with asynchronous detach (my default, I didn't > get that right in the original implementation) but I can't tell if > this is what you are trying to address now. > > -Alan From Dmitry.Samersoff at oracle.com Tue Aug 21 13:24:56 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Aug 2012 00:24:56 +0400 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033EC50.30206@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> <5033EC50.30206@oracle.com> Message-ID: <5033EE98.2080605@oracle.com> Serguei, The test stop falling, this is the reason I send the webrev, but test never fail constantly so I couldn't be sure I fix the problem. -Dmitry On 2012-08-22 00:15, serguei.spitsyn at oracle.com wrote: > Dmitry, > > It is not clear how would moving the enqueue() call into the > synchronized statement solve the asynchronous detach issue. > Will this issue come back in some other form? > The test is still going to fail intermittently, right? > What is reason of the the asynchronous detach? > > Thanks, > Serguei > > > On 8/21/12 12:23 PM, Alan Bateman wrote: >> On 21/08/2012 20:05, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >>> >>> -Dmitry >>> >> Can you explain the issue a bit further? Looking at the code I can see >> there may be an issue with asynchronous detach (my default, I didn't >> get that right in the original implementation) but I can't tell if >> this is what you are trying to address now. >> >> -Alan > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Tue Aug 21 14:05:39 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Aug 2012 14:05:39 -0700 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033EE98.2080605@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> <5033EC50.30206@oracle.com> <5033EE98.2080605@oracle.com> Message-ID: <5033F823.5020105@oracle.com> Dmitry, I see your point. It is still interesting what is the cause of the asynchronous detach as it might bite us again. Thanks, Serguei On 8/21/12 1:24 PM, Dmitry Samersoff wrote: > Serguei, > > The test stop falling, this is the reason I send the webrev, > but test never fail constantly so I couldn't be sure > I fix the problem. > > -Dmitry > > On 2012-08-22 00:15, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> It is not clear how would moving the enqueue() call into the >> synchronized statement solve the asynchronous detach issue. >> Will this issue come back in some other form? >> The test is still going to fail intermittently, right? >> What is reason of the the asynchronous detach? >> >> Thanks, >> Serguei >> >> >> On 8/21/12 12:23 PM, Alan Bateman wrote: >>> On 21/08/2012 20:05, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review small fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >>>> >>>> -Dmitry >>>> >>> Can you explain the issue a bit further? Looking at the code I can see >>> there may be an issue with asynchronous detach (my default, I didn't >>> get that right in the original implementation) but I can't tell if >>> this is what you are trying to address now. >>> >>> -Alan > From Dmitry.Samersoff at oracle.com Tue Aug 21 14:07:33 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Aug 2012 01:07:33 +0400 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033F823.5020105@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> <5033EC50.30206@oracle.com> <5033EE98.2080605@oracle.com> <5033F823.5020105@oracle.com> Message-ID: <5033F895.2030203@oracle.com> Serguei, I continue with this issue, but because of intermittent nature of the failure it takes a time. -Dmitry On 2012-08-22 01:05, serguei.spitsyn at oracle.com wrote: > Dmitry, > > I see your point. > It is still interesting what is the cause of the asynchronous detach as > it might bite us again. > > Thanks, > Serguei > > > On 8/21/12 1:24 PM, Dmitry Samersoff wrote: >> Serguei, >> >> The test stop falling, this is the reason I send the webrev, >> but test never fail constantly so I couldn't be sure >> I fix the problem. >> >> -Dmitry >> >> On 2012-08-22 00:15, serguei.spitsyn at oracle.com wrote: >>> Dmitry, >>> >>> It is not clear how would moving the enqueue() call into the >>> synchronized statement solve the asynchronous detach issue. >>> Will this issue come back in some other form? >>> The test is still going to fail intermittently, right? >>> What is reason of the the asynchronous detach? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 8/21/12 12:23 PM, Alan Bateman wrote: >>>> On 21/08/2012 20:05, Dmitry Samersoff wrote: >>>>> Hi Everybody, >>>>> >>>>> Please review small fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >>>>> >>>>> -Dmitry >>>>> >>>> Can you explain the issue a bit further? Looking at the code I can see >>>> there may be an issue with asynchronous detach (my default, I didn't >>>> get that right in the original implementation) but I can't tell if >>>> this is what you are trying to address now. >>>> >>>> -Alan >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From bill.pittore at oracle.com Tue Aug 21 14:47:16 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Tue, 21 Aug 2012 17:47:16 -0400 Subject: Code review for SA changes to allow for new processor architectures (7154641) Message-ID: <503401E4.7060801@oracle.com> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ thanks, bill From christian.thalinger at oracle.com Tue Aug 21 15:06:01 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 21 Aug 2012 15:06:01 -0700 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <503401E4.7060801@oracle.com> References: <503401E4.7060801@oracle.com> Message-ID: On Aug 21, 2012, at 2:47 PM, BILL PITTORE wrote: > These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. And why is that? -- Chris > > http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ > > thanks, > bill > From david.holmes at oracle.com Tue Aug 21 18:26:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 11:26:29 +1000 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5033E046.1040104@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> Message-ID: <50343545.1020600@oracle.com> On 22/08/2012 5:23 AM, Alan Bateman wrote: > On 21/08/2012 20:05, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >> >> -Dmitry >> > Can you explain the issue a bit further? Looking at the code I can see > there may be an issue with asynchronous detach (my default, I didn't get > that right in the original implementation) but I can't tell if this is > what you are trying to address now. I was going to make a similar request. Some context for the problem and solution makes reviewing a lot easier. In this case as I understand it between checking the fd for the door call and making the door call, someone can call detach, and so we get EBADF. The detach is synchronized on this, so the fix moves the enqueue inside the sync block so that it has to complete before anyone can call detach. David ----- From Dmitry.Samersoff at oracle.com Wed Aug 22 00:03:03 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 22 Aug 2012 11:03:03 +0400 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <50343545.1020600@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> <50343545.1020600@oracle.com> Message-ID: <50348427.7070104@oracle.com> David, > In this case as I understand it between checking the fd for the door > call and making the door call, someone can call detach, and so we get > EBADF. The detach is synchronized on this, so the fix moves the > enqueue inside the sync block so that it has to complete before > anyone can call detach. Exactly! Thank you very much. -Dmitry On 2012-08-22 05:26, David Holmes wrote: > On 22/08/2012 5:23 AM, Alan Bateman wrote: >> On 21/08/2012 20:05, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/7162400/webrev.02/ >>> >>> -Dmitry >>> >> Can you explain the issue a bit further? Looking at the code I can see >> there may be an issue with asynchronous detach (my default, I didn't get >> that right in the original implementation) but I can't tell if this is >> what you are trying to address now. > > I was going to make a similar request. Some context for the problem and > solution makes reviewing a lot easier. > > In this case as I understand it between checking the fd for the door > call and making the door call, someone can call detach, and so we get > EBADF. The detach is synchronized on this, so the fix moves the enqueue > inside the sync block so that it has to complete before anyone can call > detach. > > David > ----- -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From staffan.larsen at oracle.com Wed Aug 22 01:20:12 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Aug 2012 10:20:12 +0200 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <503401E4.7060801@oracle.com> References: <503401E4.7060801@oracle.com> Message-ID: <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux. Some other comments: LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly. LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change? LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message VM.java and vmStructs.cpp - Looks like an unrelated change. saproc.make:94 - weird indentation Thanks, /Staffan On 21 aug 2012, at 23:47, BILL PITTORE wrote: > These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. > > http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ > > thanks, > bill > From staffan.larsen at oracle.com Wed Aug 22 03:26:40 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 22 Aug 2012 10:26:40 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Message-ID: <20120822102648.B304847682@hg.openjdk.java.net> Changeset: be82ef218872 Author: sla Date: 2012-08-22 10:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/be82ef218872 7192916: Hotspot development launcher should use DYLD_LIBRARY_PATH on OS X Reviewed-by: dholmes, dsamersoff, nloodin ! src/os/posix/launcher/launcher.script From Alan.Bateman at oracle.com Wed Aug 22 04:52:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Aug 2012 12:52:57 +0100 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <50343545.1020600@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> <50343545.1020600@oracle.com> Message-ID: <5034C819.8090906@oracle.com> On 22/08/2012 02:26, David Holmes wrote: > > I was going to make a similar request. Some context for the problem > and solution makes reviewing a lot easier. > > In this case as I understand it between checking the fd for the door > call and making the door call, someone can call detach, and so we get > EBADF. The detach is synchronized on this, so the fix moves the > enqueue inside the sync block so that it has to complete before anyone > can call detach. The detach method is specified so that the behavior for this case is implementation-specific so Dmitriy's change is okay, it's just that I assume the detach will block indefinitely in the event that the target VM does not respond to a command. With a bit of work then I think we can change this code to support asynchronous detach, probably using the usual dup2 trick that we do elsewhere in the libraries. The question is whether it's worth doing as the scenario is only likely to arise with tests, not the simple command-line tools. So I think the proposed change is okay for now, we should just make sure to submit an RFE to remember to re-visit this again in the future. -Alan From bill.pittore at oracle.com Wed Aug 22 09:13:11 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 22 Aug 2012 12:13:11 -0400 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> References: <503401E4.7060801@oracle.com> <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> Message-ID: <50350517.3070307@oracle.com> Updated the webrev at http://cr.openjdk.java.net/~bpittore/7154641/webrev.01/ On 8/22/2012 4:20 AM, Staffan Larsen wrote: > I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux. We only made changes to get some embedded platforms supported. Right now that's only Linux. Someone else asked a similar question about the code paths. We (embedded) didn't want to make too many changes to already running/working code for x86, amd64 and sparc on Linux, BSD, Windows, and solaris. It was also our understanding that your team is in the process of evaluating where to go with SA so it seemed best to just make the minimal changes. If using reflection works into your plans going forward someone (your team?) could implement it for all os/cpu combos. > Some other comments: > > LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly. I added a comment here. The exception for unknown cpu would be thrown by LinuxThreadContextFactory.java. I changed the message in that file as per below. > > LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change? In the case of a new cpu, there would be a platform specific version of Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_getThreadIntegerRegisterSet0 that would be called by the Java code to get the processor registers. Likewise, the functions throw_new_debugger_exception() and get_proc_handle() are exported to the platform specific code. > > LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message Fixed. > > VM.java and vmStructs.cpp - Looks like an unrelated change. Actually needed for stack walking on PPC. > saproc.make:94 - weird indentation Fixed. bill > > Thanks, > /Staffan > > > On 21 aug 2012, at 23:47, BILL PITTORE wrote: > >> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. >> >> http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ >> >> thanks, >> bill >> From staffan.larsen at oracle.com Wed Aug 22 11:12:26 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Aug 2012 20:12:26 +0200 Subject: Code review for SA changes to allow for new processor architectures (7154641) In-Reply-To: <50350517.3070307@oracle.com> References: <503401E4.7060801@oracle.com> <113377F5-53D2-44DB-99C2-590E0888772F@oracle.com> <50350517.3070307@oracle.com> Message-ID: <8F20424D-9CEC-47C8-B5B4-C1CA81546825@oracle.com> Thanks for fixing my comments and providing good reasons for your design. I'm ok with these changes now. What the future of SA is remains to be seen, but it's not going to be replaced very soon. Thanks, /Staffan On 22 aug 2012, at 18:13, BILL PITTORE wrote: > Updated the webrev at http://cr.openjdk.java.net/~bpittore/7154641/webrev.01/ > > On 8/22/2012 4:20 AM, Staffan Larsen wrote: >> I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux. > We only made changes to get some embedded platforms supported. Right now that's only Linux. Someone else asked a similar question about the code paths. We (embedded) didn't want to make too many changes to already running/working code for x86, amd64 and sparc on Linux, BSD, Windows, and solaris. It was also our understanding that your team is in the process of evaluating where to go with SA so it seemed best to just make the minimal changes. If using reflection works into your plans going forward someone (your team?) could implement it for all os/cpu combos. >> Some other comments: >> >> LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly. > I added a comment here. The exception for unknown cpu would be thrown by LinuxThreadContextFactory.java. I changed the message in that file as per below. >> >> LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change? > In the case of a new cpu, there would be a platform specific version of > > Java_sun_jvm_hotspot_debugger_linux_LinuxDebuggerLocal_getThreadIntegerRegisterSet0 > > that would be called by the Java code to get the processor registers. Likewise, the functions throw_new_debugger_exception() and get_proc_handle() are exported to the platform specific code. >> >> LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message > Fixed. >> >> VM.java and vmStructs.cpp - Looks like an unrelated change. > Actually needed for stack walking on PPC. >> saproc.make:94 - weird indentation > Fixed. > > bill >> >> Thanks, >> /Staffan >> >> >> On 21 aug 2012, at 23:47, BILL PITTORE wrote: >> >>> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path. >>> >>> http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/ >>> >>> thanks, >>> bill >>> > From serguei.spitsyn at oracle.com Wed Aug 22 11:34:55 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Aug 2012 11:34:55 -0700 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5033E560.7000304@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> Message-ID: <5035264F.2020909@oracle.com> Dmitry, Thank you for the review! Please, find new webrev version here: http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/ I also changed the line: 196 if (elem[idx].signature_cp_index > 0) { to this: 196 if (elem[idx].signature_cp_index != 0) { Both are correct as the signature_cp_index is u2. But "signature_cp_index != 0" is more clear. Thanks, Serguei On 8/21/12 12:45 PM, serguei.spitsyn at oracle.com wrote: > On 8/21/12 12:11 PM, Dmitry Samersoff wrote: >> Serguei, >> >> On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >>> You can see the same pattern for all attributes (for instance, >>> has_stackmap_table - L160). >> OK. >> >>>> 202: local_variable_type_table_length >>>> is always 0 if local_variable_table_length == 0 >>>> >>>> so I think if should be nested. >>> It does not matter. >> It saves one if in some cases and makes logic better readable, >> so I would like to have it changed. >> >> Sorry! > > In fact, I initially considered this option and can change it as you > prefer. > But let's wait for other reviewers input. > > Thanks, > Serguei > >> >>>> 216: It might be better to place both attr_size changes together. >>> I'm trying to follow the existing style. >> OK >> >> -Dmitry >> >> >>> >>> Thanks, >>> Serguei >>>> -Dmitry >>>> >>>> >>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>> Hello, >>>>> >>>>> >>>>> Please, review the fix for: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The following CR was recently fixed: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>> >>>>> But the same issue exists for the LocalVariableTypeTable attribute. >>>>> >>>>> The fix was tested with the modified test: >>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>> >>>>> >>>>> The modification is that a local variable with generic signature >>>>> is added >>>>> to the class DummyClassWithLVT.java: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>> >>>>> >>>>> >>>>> The test patch will be integrated into the jdk8/tl after the >>>>> HotSpot fix >>>>> is promoted. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >> > From Dmitry.Samersoff at oracle.com Wed Aug 22 13:33:54 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 23 Aug 2012 00:33:54 +0400 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5035264F.2020909@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> <5035264F.2020909@oracle.com> Message-ID: <50354232.6080508@oracle.com> Serguei, Thank you for making changes. Looks good for me! -Dmitry On 2012-08-22 22:34, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for the review! > > Please, find new webrev version here: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/ > > I also changed the line: > 196 if (elem[idx].signature_cp_index > 0) { > to this: > 196 if (elem[idx].signature_cp_index != 0) { > > Both are correct as the signature_cp_index is u2. > But "signature_cp_index != 0" is more clear. > > > Thanks, > Serguei > > > On 8/21/12 12:45 PM, serguei.spitsyn at oracle.com wrote: >> On 8/21/12 12:11 PM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >>>> You can see the same pattern for all attributes (for instance, >>>> has_stackmap_table - L160). >>> OK. >>> >>>>> 202: local_variable_type_table_length >>>>> is always 0 if local_variable_table_length == 0 >>>>> >>>>> so I think if should be nested. >>>> It does not matter. >>> It saves one if in some cases and makes logic better readable, >>> so I would like to have it changed. >>> >>> Sorry! >> >> In fact, I initially considered this option and can change it as you >> prefer. >> But let's wait for other reviewers input. >> >> Thanks, >> Serguei >> >>> >>>>> 216: It might be better to place both attr_size changes together. >>>> I'm trying to follow the existing style. >>> OK >>> >>> -Dmitry >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>>> Hello, >>>>>> >>>>>> >>>>>> Please, review the fix for: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The following CR was recently fixed: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>>> >>>>>> But the same issue exists for the LocalVariableTypeTable attribute. >>>>>> >>>>>> The fix was tested with the modified test: >>>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>>> >>>>>> >>>>>> The modification is that a local variable with generic signature >>>>>> is added >>>>>> to the class DummyClassWithLVT.java: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>>> >>>>>> >>>>>> >>>>>> The test patch will be integrated into the jdk8/tl after the >>>>>> HotSpot fix >>>>>> is promoted. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From david.holmes at oracle.com Wed Aug 22 17:28:50 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Aug 2012 10:28:50 +1000 Subject: RR, S: 7162400 Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand In-Reply-To: <5034C819.8090906@oracle.com> References: <5033DC15.4070108@oracle.com> <5033E046.1040104@oracle.com> <50343545.1020600@oracle.com> <5034C819.8090906@oracle.com> Message-ID: <50357942.3010809@oracle.com> On 22/08/2012 9:52 PM, Alan Bateman wrote: > On 22/08/2012 02:26, David Holmes wrote: >> >> I was going to make a similar request. Some context for the problem >> and solution makes reviewing a lot easier. >> >> In this case as I understand it between checking the fd for the door >> call and making the door call, someone can call detach, and so we get >> EBADF. The detach is synchronized on this, so the fix moves the >> enqueue inside the sync block so that it has to complete before anyone >> can call detach. > The detach method is specified so that the behavior for this case is > implementation-specific so Dmitriy's change is okay, it's just that I > assume the detach will block indefinitely in the event that the target > VM does not respond to a command. With a bit of work then I think we can > change this code to support asynchronous detach, probably using the > usual dup2 trick that we do elsewhere in the libraries. The question is > whether it's worth doing as the scenario is only likely to arise with > tests, not the simple command-line tools. So I think the proposed change > is okay for now, we should just make sure to submit an RFE to remember > to re-visit this again in the future. Ah I see. I'm not familiar with the details of the underlying communication protocol. If the enqueue can indeed block indefinitely then moving it inside the sync block prevents the detach indefinitely. In which case the enqueue needs to remain an "open call" but the native method needs to be robust in the face of EBADF and/or the calling code needs to handle that possibility when there is a race with the detach. David ----- > -Alan From luchsh at linux.vnet.ibm.com Thu Aug 23 01:30:01 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Thu, 23 Aug 2012 08:30:01 +0000 Subject: hg: jdk8/tl/jdk: 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Message-ID: <20120823083029.3251A476A8@hg.openjdk.java.net> Changeset: e7b53fe85540 Author: dingxmin Date: 2012-08-23 16:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7b53fe85540 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Reviewed-by: dholmes, alanb ! src/solaris/classes/java/lang/Terminator.java ! src/windows/classes/java/lang/Terminator.java From alan.bateman at oracle.com Thu Aug 23 05:08:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 23 Aug 2012 12:08:02 +0000 Subject: hg: jdk8/tl/jdk: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Message-ID: <20120823120831.28817476AC@hg.openjdk.java.net> Changeset: de5a85353f4d Author: alanb Date: 2012-08-23 13:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de5a85353f4d 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Reviewed-by: alanb Contributed-by: Jason T Greene ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java From mandy.chung at oracle.com Thu Aug 23 10:43:23 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 10:43:23 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader Message-ID: <50366BBB.2060406@oracle.com> This change is to bring the jdk modularization changes from jigsaw repo [1] to jdk8. This allows the jdk modularization changes to be exposed for testing as early as possible and minimize the amount of changes carried in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ Summary: The VM bootstrap class loader (null) has been the defining class loader for all system classes (i.e. rt.jar and any classes on the bootclasspath). In modular world, the system classes are going to be modularized into multiple modulesand and many of which will be loaded by its own (non-null) module loader. The JDK implementation has the assumption that the defining class loader of system classes is null and it'll no longer be true when running as modules. Typical patterns in the JDK code include: Class.forName(classname, false, null) should be changed to: Class.forName(classname, false,) if (loader == null) condition check should be modified to check if the loader is responsible for loading system classes. This is the first set of change for this problem we identified. Similar change in other components will be made in the future. Testing: run all jdk core test targets on all platforms. Thanks Mandy P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in the java.lang.management. From Alan.Bateman at oracle.com Thu Aug 23 11:58:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Aug 2012 19:58:25 +0100 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50366BBB.2060406@oracle.com> References: <50366BBB.2060406@oracle.com> Message-ID: <50367D51.90506@oracle.com> On 23/08/2012 18:43, Mandy Chung wrote: > This change is to bring the jdk modularization changes from jigsaw > repo [1] > to jdk8. This allows the jdk modularization changes to be exposed for > testing as early as possible and minimize the amount of changes carried > in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ > This looks good to me and it's good to have these changes in jdk8. One suggestion for ReflectUtil is to add a private static boolean isAncestor method as I think that would make the checks in needsPackageAccessCheck easier to read. Also in ClassLoader you could use just use needsClassLoaderPermissionCheck(from,to). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120823/00d98d8e/attachment.html From mandy.chung at oracle.com Thu Aug 23 12:33:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 12:33:48 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50367D51.90506@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> Message-ID: <5036859C.3020801@oracle.com> On 8/23/2012 11:58 AM, Alan Bateman wrote: > On 23/08/2012 18:43, Mandy Chung wrote: >> This change is to bring the jdk modularization changes from jigsaw >> repo [1] >> to jdk8. This allows the jdk modularization changes to be exposed for >> testing as early as possible and minimize the amount of changes carried >> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >> > This looks good to me and it's good to have these changes in jdk8. > > One suggestion for ReflectUtil is to add a private static boolean > isAncestor method as I think that would make the checks in > needsPackageAccessCheck easier to read. Also in ClassLoader you could > use just use needsClassLoaderPermissionCheck(from,to). > Done. This is a good cleanup I considered to do too but missed in the previous webrev. http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ Thanks for the review. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120823/1dc6bd47/attachment.html From serguei.spitsyn at oracle.com Thu Aug 23 12:48:11 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Aug 2012 12:48:11 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50366BBB.2060406@oracle.com> References: <50366BBB.2060406@oracle.com> Message-ID: <503688FB.4050205@oracle.com> Mandy, It looks good. Just a question below. || *src/share/classes/java/lang/management/ManagementFactory.java* 596 String intfName = mxbeanInterface.getName(); 599 " is not an instance of " + mxbeanInterface); Did you want this?: 596 String intfName = cls.getName(); 599 " is not an instance of " + cls); Thanks, Serguei On 8/23/12 10:43 AM, Mandy Chung wrote: > This change is to bring the jdk modularization changes from jigsaw > repo [1] > to jdk8. This allows the jdk modularization changes to be exposed for > testing as early as possible and minimize the amount of changes carried > in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ > > Summary: > The VM bootstrap class loader (null) has been the defining class loader > for all system classes (i.e. rt.jar and any classes on the > bootclasspath). > > In modular world, the system classes are going to be modularized into > multiple modulesand and many of which will be loaded by its own > (non-null) module loader. > > The JDK implementation has the assumption that the defining class loader > of system classes is null and it'll no longer be true when running as > modules. Typical patterns in the JDK code include: > > Class.forName(classname, false, null) should be changed to: > Class.forName(classname, false,) > > if (loader == null) condition check should be modified to check if the > loader > is responsible for loading system classes. > > This is the first set of change for this problem we identified. Similar > change in other components will be made in the future. > > Testing: run all jdk core test targets on all platforms. > > Thanks > Mandy > P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in > the java.lang.management. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120823/79840c85/attachment.html From mandy.chung at oracle.com Thu Aug 23 12:51:08 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 12:51:08 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503688FB.4050205@oracle.com> References: <50366BBB.2060406@oracle.com> <503688FB.4050205@oracle.com> Message-ID: <503689AC.20301@oracle.com> On 8/23/2012 12:48 PM, serguei.spitsyn at oracle.com wrote: > Mandy, > > It looks good. Thanks. > Just a question below. > > || *src/share/classes/java/lang/management/ManagementFactory.java* > 596 String intfName = mxbeanInterface.getName(); > 599 " is not an instance of " + mxbeanInterface); > > Did you want this?: > 596 String intfName = cls.getName(); > 599 " is not an instance of " + cls); It doesn't make any difference and so leave it as it is will be fine. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120823/12c4a669/attachment.html From Alan.Bateman at oracle.com Thu Aug 23 13:49:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Aug 2012 21:49:59 +0100 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <50369777.5080205@oracle.com> On 23/08/2012 20:33, Mandy Chung wrote: > : > > Done. This is a good cleanup I considered to do too but missed in the > previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy That looks much better, so looks good to me. -Alan From Dmitry.Samersoff at oracle.com Thu Aug 23 14:26:36 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 24 Aug 2012 01:26:36 +0400 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <5036A00C.10000@oracle.com> Mandy, 1. You replace null with getClassLoader() calls in couple of places. getClassLoader requires special permissions - RuntimePermission("getClassLoader") so probably you need to use doPrivileget() there. Did you test your changes with SecurityManager/No permissions for the test ? 2. Did you consider moving sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); inside ClassLoader.needsClassLoaderPermissionCheck(ccl, cl); ? 3. ManagementFactory.java Could you explain the reason of changes (except 588) ? -Dmitry On 2012-08-23 23:33, Mandy Chung wrote: > On 8/23/2012 11:58 AM, Alan Bateman wrote: >> On 23/08/2012 18:43, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw >>> repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >> This looks good to me and it's good to have these changes in jdk8. >> >> One suggestion for ReflectUtil is to add a private static boolean >> isAncestor method as I think that would make the checks in >> needsPackageAccessCheck easier to read. Also in ClassLoader you could >> use just use needsClassLoaderPermissionCheck(from,to). >> > > Done. This is a good cleanup I considered to do too but missed in the > previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From serguei.spitsyn at oracle.com Thu Aug 23 14:54:43 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Aug 2012 14:54:43 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <5036A6A3.60401@oracle.com> Looks good. Thanks, Serguei On 8/23/12 12:33 PM, Mandy Chung wrote: > On 8/23/2012 11:58 AM, Alan Bateman wrote: >> On 23/08/2012 18:43, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw >>> repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >> This looks good to me and it's good to have these changes in jdk8. >> >> One suggestion for ReflectUtil is to add a private static boolean >> isAncestor method as I think that would make the checks in >> needsPackageAccessCheck easier to read. Also in ClassLoader you could >> use just use needsClassLoaderPermissionCheck(from,to). >> > > Done. This is a good cleanup I considered to do too but missed in the > previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120823/1e10efae/attachment-0001.html From mandy.chung at oracle.com Thu Aug 23 16:22:56 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 16:22:56 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036A00C.10000@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> <5036A00C.10000@oracle.com> Message-ID: <5036BB50.7010906@oracle.com> On 8/23/2012 2:26 PM, Dmitry Samersoff wrote: > Mandy, > > 1. You replace null with getClassLoader() calls in couple of places. > getClassLoader requires special permissions - > RuntimePermission("getClassLoader") > > so probably you need to use doPrivileget() there. No, the caller's class loader (all are system classes) is null and so no permission check is required [1]. > Did you test your changes with SecurityManager/No permissions > for the test ? I ran the jck tests that cover this permission check. The jck tests uncovered these classes to be fixed during jigsaw development. > > 2. Did you consider moving > > sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); > > inside ClassLoader.needsClassLoaderPermissionCheck(ccl, cl); ? Yes I did and I decide to leave this sm.checkPermission call in the method body as it's closer to the spec and more readable. > > 3. ManagementFactory.java > > Could you explain the reason of changes (except 588) ? The platform MXBeans (java.lang.management) are currently on the bootclasspath loaded by the null loader. In the modular world, j.l.m. will possibly be put in the "management" module along with JMX so that an application only requires the management module to be present when it uses JMX and platform MXBean. In that case, the management module will be loaded by a non-null module loader. This check (loader != null) would fail in the modular world even loading platform MXBeans. We changed this check and other places in the JDK to call VM.isSystemDomainLoader method and the real check for modules can be made in this single convenient method in the jigsaw repo. > -Dmitry Thanks Mandy [1] http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getClassLoader() > > On 2012-08-23 23:33, Mandy Chung wrote: >> On 8/23/2012 11:58 AM, Alan Bateman wrote: >>> On 23/08/2012 18:43, Mandy Chung wrote: >>>> This change is to bring the jdk modularization changes from jigsaw >>>> repo [1] >>>> to jdk8. This allows the jdk modularization changes to be exposed for >>>> testing as early as possible and minimize the amount of changes carried >>>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>>> >>> This looks good to me and it's good to have these changes in jdk8. >>> >>> One suggestion for ReflectUtil is to add a private static boolean >>> isAncestor method as I think that would make the checks in >>> needsPackageAccessCheck easier to read. Also in ClassLoader you could >>> use just use needsClassLoaderPermissionCheck(from,to). >>> >> Done. This is a good cleanup I considered to do too but missed in the >> previous webrev. >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ >> >> Thanks for the review. >> Mandy > From david.holmes at oracle.com Thu Aug 23 18:27:01 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 11:27:01 +1000 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50366BBB.2060406@oracle.com> References: <50366BBB.2060406@oracle.com> Message-ID: <5036D865.5020704@oracle.com> Hi Mandy, While I understand what you are doing and that it "works" it is far from obvious upon code inspection that where you replace null with Foo.class.getClassLoader(), that the result would always be null. Another way to simplify this would be to add a new overload of Class.forName(): public static Class forName(String name, boolean initialize) That way the loader argument could be dropped completely from a number of the use-cases. David On 24/08/2012 3:43 AM, Mandy Chung wrote: > This change is to bring the jdk modularization changes from jigsaw repo [1] > to jdk8. This allows the jdk modularization changes to be exposed for > testing as early as possible and minimize the amount of changes carried > in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ > > Summary: > The VM bootstrap class loader (null) has been the defining class loader > for all system classes (i.e. rt.jar and any classes on the bootclasspath). > > In modular world, the system classes are going to be modularized into > multiple modulesand and many of which will be loaded by its own > (non-null) module loader. > > The JDK implementation has the assumption that the defining class loader > of system classes is null and it'll no longer be true when running as > modules. Typical patterns in the JDK code include: > > Class.forName(classname, false, null) should be changed to: > Class.forName(classname, false,) > > if (loader == null) condition check should be modified to check if the > loader > is responsible for loading system classes. > > This is the first set of change for this problem we identified. Similar > change in other components will be made in the future. > > Testing: run all jdk core test targets on all platforms. > > Thanks > Mandy > P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in > the java.lang.management. > From john.coomes at oracle.com Thu Aug 23 20:54:18 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:54:18 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b53 for changeset febd7ff52800 Message-ID: <20120824035418.B36C3476D2@hg.openjdk.java.net> Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:54:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:54:23 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b53 for changeset 63aeb7a2472f Message-ID: <20120824035426.7BFF8476D3@hg.openjdk.java.net> Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:54:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:54:32 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b53 for changeset 2c566f25c39f Message-ID: <20120824035442.395FD476D4@hg.openjdk.java.net> Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:54:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:54:49 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b53 for changeset 8a35fd644d3c Message-ID: <20120824035454.C4E09476D5@hg.openjdk.java.net> Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:55:03 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:55:03 +0000 Subject: hg: hsx/hotspot-rt/jdk: Added tag jdk8-b53 for changeset 2c6933c5106b Message-ID: <20120824035558.34AE6476D6@hg.openjdk.java.net> Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags From john.coomes at oracle.com Thu Aug 23 20:57:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Aug 2012 03:57:11 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b53 for changeset d3d0b9cd76e0 Message-ID: <20120824035719.2A5C2476D7@hg.openjdk.java.net> Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags From serguei.spitsyn at oracle.com Thu Aug 23 22:21:45 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Aug 2012 22:21:45 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036D865.5020704@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> Message-ID: <50370F69.8030703@oracle.com> I was thinking about the same. But a CCC request is needed for such a change in public API. It can be done separately if any other API changes are necessary. Thanks, Serguei On 8/23/12 6:27 PM, David Holmes wrote: > Hi Mandy, > > While I understand what you are doing and that it "works" it is far > from obvious upon code inspection that where you replace null with > Foo.class.getClassLoader(), that the result would always be null. > > Another way to simplify this would be to add a new overload of > Class.forName(): > > public static Class forName(String name, boolean initialize) > > That way the loader argument could be dropped completely from a number > of the use-cases. > > David > > On 24/08/2012 3:43 AM, Mandy Chung wrote: >> This change is to bring the jdk modularization changes from jigsaw >> repo [1] >> to jdk8. This allows the jdk modularization changes to be exposed for >> testing as early as possible and minimize the amount of changes carried >> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >> >> Summary: >> The VM bootstrap class loader (null) has been the defining class loader >> for all system classes (i.e. rt.jar and any classes on the >> bootclasspath). >> >> In modular world, the system classes are going to be modularized into >> multiple modulesand and many of which will be loaded by its own >> (non-null) module loader. >> >> The JDK implementation has the assumption that the defining class loader >> of system classes is null and it'll no longer be true when running as >> modules. Typical patterns in the JDK code include: >> >> Class.forName(classname, false, null) should be changed to: >> Class.forName(classname, false,) >> >> if (loader == null) condition check should be modified to check if the >> loader >> is responsible for loading system classes. >> >> This is the first set of change for this problem we identified. Similar >> change in other components will be made in the future. >> >> Testing: run all jdk core test targets on all platforms. >> >> Thanks >> Mandy >> P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in >> the java.lang.management. >> From rickard.backman at oracle.com Fri Aug 24 04:22:38 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 24 Aug 2012 13:22:38 +0200 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5035264F.2020909@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> <5035264F.2020909@oracle.com> Message-ID: Serguei, looks good! /R On Aug 22, 2012, at 8:34 PM, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for the review! > > Please, find new webrev version here: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/ > > I also changed the line: > 196 if (elem[idx].signature_cp_index > 0) { > to this: > 196 if (elem[idx].signature_cp_index != 0) { > > Both are correct as the signature_cp_index is u2. > But "signature_cp_index != 0" is more clear. > > > Thanks, > Serguei > > > On 8/21/12 12:45 PM, serguei.spitsyn at oracle.com wrote: >> On 8/21/12 12:11 PM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >>>> You can see the same pattern for all attributes (for instance, >>>> has_stackmap_table - L160). >>> OK. >>> >>>>> 202: local_variable_type_table_length >>>>> is always 0 if local_variable_table_length == 0 >>>>> >>>>> so I think if should be nested. >>>> It does not matter. >>> It saves one if in some cases and makes logic better readable, >>> so I would like to have it changed. >>> >>> Sorry! >> >> In fact, I initially considered this option and can change it as you prefer. >> But let's wait for other reviewers input. >> >> Thanks, >> Serguei >> >>> >>>>> 216: It might be better to place both attr_size changes together. >>>> I'm trying to follow the existing style. >>> OK >>> >>> -Dmitry >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>>> Hello, >>>>>> >>>>>> >>>>>> Please, review the fix for: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The following CR was recently fixed: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>>> >>>>>> But the same issue exists for the LocalVariableTypeTable attribute. >>>>>> >>>>>> The fix was tested with the modified test: >>>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>>> >>>>>> The modification is that a local variable with generic signature is added >>>>>> to the class DummyClassWithLVT.java: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>>> >>>>>> >>>>>> The test patch will be integrated into the jdk8/tl after the HotSpot fix >>>>>> is promoted. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>> >> > From mandy.chung at oracle.com Fri Aug 24 08:53:09 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 24 Aug 2012 08:53:09 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036D865.5020704@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> Message-ID: <5037A365.6040708@oracle.com> On 8/23/2012 6:27 PM, David Holmes wrote: > > Another way to simplify this would be to add a new overload of > Class.forName(): > > public static Class forName(String name, boolean initialize) > > That way the loader argument could be dropped completely from a number > of the use-cases. Paul and Remi also suggest that during the jigsaw code review on the jigsaw-dev mailing list. It's worth considering. I plan to look at the usage of Class.forName in the JDK and add this new overload of Class.forName method if there are many use of it but I haven't got to it yet. I prefer to push this changeset as it and file a new CR and target it for JDK 8. Mandy From serguei.spitsyn at oracle.com Fri Aug 24 09:39:45 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 Aug 2012 09:39:45 -0700 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> <5035264F.2020909@oracle.com> Message-ID: <5037AE51.7000902@oracle.com> Thanks, Rickard! Serguei On 8/24/12 4:22 AM, Rickard B?ckman wrote: > Serguei, > > looks good! > > /R > > On Aug 22, 2012, at 8:34 PM, serguei.spitsyn at oracle.com wrote: > >> Dmitry, >> >> Thank you for the review! >> >> Please, find new webrev version here: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/ >> >> I also changed the line: >> 196 if (elem[idx].signature_cp_index > 0) { >> to this: >> 196 if (elem[idx].signature_cp_index != 0) { >> >> Both are correct as the signature_cp_index is u2. >> But "signature_cp_index != 0" is more clear. >> >> >> Thanks, >> Serguei >> >> >> On 8/21/12 12:45 PM, serguei.spitsyn at oracle.com wrote: >>> On 8/21/12 12:11 PM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >>>>> You can see the same pattern for all attributes (for instance, >>>>> has_stackmap_table - L160). >>>> OK. >>>> >>>>>> 202: local_variable_type_table_length >>>>>> is always 0 if local_variable_table_length == 0 >>>>>> >>>>>> so I think if should be nested. >>>>> It does not matter. >>>> It saves one if in some cases and makes logic better readable, >>>> so I would like to have it changed. >>>> >>>> Sorry! >>> In fact, I initially considered this option and can change it as you prefer. >>> But let's wait for other reviewers input. >>> >>> Thanks, >>> Serguei >>> >>>>>> 216: It might be better to place both attr_size changes together. >>>>> I'm trying to follow the existing style. >>>> OK >>>> >>>> -Dmitry >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> Please, review the fix for: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> The following CR was recently fixed: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>>>> >>>>>>> But the same issue exists for the LocalVariableTypeTable attribute. >>>>>>> >>>>>>> The fix was tested with the modified test: >>>>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>>>> >>>>>>> The modification is that a local variable with generic signature is added >>>>>>> to the class DummyClassWithLVT.java: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>>>> >>>>>>> >>>>>>> The test patch will be integrated into the jdk8/tl after the HotSpot fix >>>>>>> is promoted. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei From naoto.sato at oracle.com Fri Aug 24 10:15:54 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 24 Aug 2012 17:15:54 +0000 Subject: hg: jdk8/tl/jdk: 7193601: Build breakage with the fix to 6336885 (build-infra build) Message-ID: <20120824171623.E1F28476EB@hg.openjdk.java.net> Changeset: faf4528aea4e Author: naoto Date: 2012-08-24 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/faf4528aea4e 7193601: Build breakage with the fix to 6336885 (build-infra build) Reviewed-by: mduigou ! makefiles/CompileJavaClasses.gmk From alan.bateman at oracle.com Fri Aug 24 11:39:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Aug 2012 18:39:02 +0000 Subject: hg: jdk8/tl/jdk: 7193933: More ProblemList.txt updates (8/2012) Message-ID: <20120824183925.8B920476EC@hg.openjdk.java.net> Changeset: a7cdfd16e36e Author: alanb Date: 2012-08-24 19:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7cdfd16e36e 7193933: More ProblemList.txt updates (8/2012) Reviewed-by: darcy, chegar ! test/ProblemList.txt From kurchi.subhra.hazra at oracle.com Fri Aug 24 11:49:30 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 24 Aug 2012 18:49:30 +0000 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows Message-ID: <20120824184950.4B799476ED@hg.openjdk.java.net> Changeset: bd91a601265c Author: khazra Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c 7168172: (fs) Files.isReadable slow on Windows Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java From david.holmes at oracle.com Fri Aug 24 15:44:36 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Aug 2012 08:44:36 +1000 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5037A365.6040708@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <5037A365.6040708@oracle.com> Message-ID: <503803D4.10604@oracle.com> On 25/08/2012 1:53 AM, Mandy Chung wrote: > On 8/23/2012 6:27 PM, David Holmes wrote: >> >> Another way to simplify this would be to add a new overload of >> Class.forName(): >> >> public static Class forName(String name, boolean initialize) >> >> That way the loader argument could be dropped completely from a number >> of the use-cases. > > Paul and Remi also suggest that during the jigsaw code review on the > jigsaw-dev mailing list. It's worth considering. I plan to look at the > usage of Class.forName in the JDK and add this new overload of > Class.forName method if there are many use of it but I haven't got to it > yet. I prefer to push this changeset as it and file a new CR and target > it for JDK 8. My other query with these changes is whether we are certain that using the specified loader rather than the boot loader will always be correct. David > Mandy From mandy.chung at oracle.com Fri Aug 24 15:57:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 24 Aug 2012 15:57:48 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503803D4.10604@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <5037A365.6040708@oracle.com> <503803D4.10604@oracle.com> Message-ID: <503806EC.8070207@oracle.com> On 8/24/2012 3:44 PM, David Holmes wrote: > My other query with these changes is whether we are certain that using > the specified loader rather than the boot loader will always be correct. Yes I'm to my best knowledge but I'm looking to the reviewers to tell me otherwise :) The class being loaded is either part of the same module or expressed in its module dependency. I ran the JCK tests in module mode with the jigsaw modular JDK that uncovered these files to be changed. There are other places in the JDK that I didn't touch since they were not found by my testing. BTW, I have created a new CR: 7194006: A new Class.forName(String cn, boolean initialize) method http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.02/ This include Paul's suggestion and slightly improved the javadoc for Class.forName you suggested [1]: - * @param initialize whether the class must be initialized + * @param initialize if {@code true} the class will be initialized. + * See Section 12 of The Java Language Specification. Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002534.html From jonathan.gibbons at oracle.com Fri Aug 24 16:51:02 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Aug 2012 16:51:02 -0700 Subject: [PATCH FOR REVIEW] 7194035: update tests for upcoming changes for jtreg Message-ID: <50381366.7080406@oracle.com> Currently, jtreg incorrectly confuses the concept of the /directory/ in which the test's class will be written with the /classpath/ used to locate all of the test's classes, including any library classes. It provides env variable TESTCLASSES and system property test.classes, and tests use these to mean both a directory and a classpath. jtreg will be fixed to separate the two concepts, such that TESTCLASSES/test.classes will continue to mean the /directory/ in which the test's class will the written, and will introduce TESTCLASSPATH/test.class.path for the classpath used to locate all the test's classes. This change only affects a small number of tests, which use both @library and TESTCLASSES. A number of serviceability tests are affected, FAILED: sun/tools/jcmd/jcmd-big-script.sh FAILED: sun/tools/jcmd/jcmd-f.sh FAILED: sun/tools/jcmd/jcmd-help-help.sh FAILED: sun/tools/jcmd/jcmd-pid.sh FAILED: sun/tools/jinfo/Basic.sh FAILED: sun/tools/jmap/Basic.sh FAILED: sun/tools/jps/jps-m_2.sh FAILED: sun/tools/jps/jps-Vvml_2.sh FAILED: sun/tools/jstack/Basic.sh However, all the failures are caused by issues in shared library code, meaning that only that code needs to be updated. The fix is to update the tests where they are using TESTCLASSES/test.classes as a classpath. To ease migration onto the new jtreg, it is suggested that the tests check to see if the new variables are defined (i.e. new jtreg) and to fall back on the old variables if they are not defined (i.e. old jtreg). In shell terms, this can be written ${TESTCLASSPATH:-${TESTCLASSES}} The patch can be seen here: http://cr.openjdk.java.net/~jjg/7194035/webrev.00/ See also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194035 -- Jon From mandy.chung at oracle.com Fri Aug 24 22:56:21 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 25 Aug 2012 05:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7193339: Prepare system classes be defined by a non-null module loader Message-ID: <20120825055642.94E6447702@hg.openjdk.java.net> Changeset: d52081a08d11 Author: mchung Date: 2012-08-24 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d52081a08d11 7193339: Prepare system classes be defined by a non-null module loader Reviewed-by: alanb, dholmes, dsamersoff, sspitsyn, psandoz ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java From Alan.Bateman at oracle.com Sat Aug 25 04:38:53 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Aug 2012 12:38:53 +0100 Subject: [PATCH FOR REVIEW] 7194035: update tests for upcoming changes for jtreg In-Reply-To: <50381366.7080406@oracle.com> References: <50381366.7080406@oracle.com> Message-ID: <5038B94D.90000@oracle.com> On 25/08/2012 00:51, Jonathan Gibbons wrote: > Currently, jtreg incorrectly confuses the concept of the /directory/ > in which the test's class will be written with the /classpath/ used to > locate all of the test's classes, including any library classes. It > provides env variable TESTCLASSES and system property test.classes, > and tests use these to mean both a directory and a classpath. > > jtreg will be fixed to separate the two concepts, such that > TESTCLASSES/test.classes will continue to mean the /directory/ in > which the test's class will the written, and will introduce > TESTCLASSPATH/test.class.path for the classpath used to locate all the > test's classes. > > This change only affects a small number of tests, which use both > @library and TESTCLASSES. A number of serviceability tests are affected, > FAILED: sun/tools/jcmd/jcmd-big-script.sh > FAILED: sun/tools/jcmd/jcmd-f.sh > FAILED: sun/tools/jcmd/jcmd-help-help.sh > FAILED: sun/tools/jcmd/jcmd-pid.sh > FAILED: sun/tools/jinfo/Basic.sh > FAILED: sun/tools/jmap/Basic.sh > FAILED: sun/tools/jps/jps-m_2.sh > FAILED: sun/tools/jps/jps-Vvml_2.sh > FAILED: sun/tools/jstack/Basic.sh > However, all the failures are caused by issues in shared library code, > meaning that only that code needs to be updated. > > The fix is to update the tests where they are using > TESTCLASSES/test.classes as a classpath. > > To ease migration onto the new jtreg, it is suggested that the tests > check to see if the new variables are defined (i.e. new jtreg) and to > fall back on the old variables if they are not defined (i.e. old > jtreg). In shell terms, this can be written > ${TESTCLASSPATH:-${TESTCLASSES}} > > The patch can be seen here: > http://cr.openjdk.java.net/~jjg/7194035/webrev.00/ Jon - does ${TESTCLASSPATH:-${TESTCLASSES}} need to use $PS so that the path separate is correct on Windows? -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120825/dc9c29c0/attachment.html From martijnverburg at gmail.com Wed Aug 15 01:51:59 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 15 Aug 2012 09:51:59 +0100 Subject: JEP 158: Unified JVM logging In-Reply-To: References: <4E6D5DEC.8090109@oss.ntt.co.jp> <4E6DDB8F.4020301@oracle.com> <3568943A-E6A4-4287-8319-8B0993F070F9@oracle.com> <4E7A85AE.10507@oss.ntt.co.jp> <4E7B19EC.5070700@oracle.com> <4E7B2227.9070406@kippdata.de> <4E805629.7030703@oss.ntt.co.jp> <4E846158.3020606@oracle.com> <5017B761.5070203@lab.ntt.co.jp> <5F87EF2F-6D5D-41E3-A778-8692BA2B838A@oracle.com> <502A1853.70508@lab.ntt.co.jp> <502A25B0.20004@oracle.com> Message-ID: I'll only add to this that an option to provide a Human Readable format out of the box would be desirable, but not as a default. On 15 August 2012 09:44, Kirk Pepperdine wrote: > Hi Dmitry, > > Lets start with this. > > Common logging command-line options for all components > Logging is performed at different levels: error, warning, info, debug, trace > Logging messages are in human-readable plain text > > > IMHO, these current set of goals are based on the assumptions that all > component is hierarchical in nature and that they will log the same way > without the possibility of binary dumps. I would argue these assumptions > over-reach and preclude certain types of logging that take place in the JVM > today. > > The current system of command-line (experimental) options follow a format > that is quite consistent. The options provide semantic meaning as to what > will be logged. This semantic meaning is lost when we reduce everything to > the level of error, warning, info, debug and trace. It's sets up arbitrary > categories in which developers will be left to decide what level a > particular activity should be logged at. To make this real I'll use the > -XX:+PrintTenuringDistribution flag as an example. When I set that flag it's > very clear what's to be logged. My question is, should this be logged at the > info level? How about debug? Maybe trace? And if I set those levels, what > else comes along for the ride? IOWs, if I attempt to keep the same model of > GC logging, we'd need different levels. If we need different levels then > we're about to violate the first goal. > > What this example suggests is that gc logging would be better served by > using categories (or subjects if we can take something from the pub/sub > metaphor) or tags or labels or what ever you want to call them. Using tags, > I can create a system of levels using error, warning, info, debug, and trace > if that fits how I'm setting up logging. But from levels it's difficult to > implement things using categories. This is a case where the one of the > non-goals should be, we shouldn't prevent people from structuring their logs > as they see best fits the component they are instrumenting. > > The non-goals that should be reconsidered is to force human-readability. I > would argue that this is again over-reaching in that properly structured log > files should almost *never* be read by a human. In the cases why force an > unnecessary requirement. I say this because I've run into a number of > applications where logging was the primary bottleneck. In those cases there > were two primary problems, one was bulk and the other was threading (lock > contention which I shan't address here). Now while trying to solve the > problem of bulkiness and lock contention might be considered a premature > optimization at this stage and I certainty wouldn't disagree, I would not > like to see designs or specifications that would naturally preclude some > very obvious solutions. One of the solutions to bulk is to use a more > compact format be some form of binary. That option has been taken away for > what I would call an ideological requirement. There is no technical reason > why I shouldn't be able to log in binary other than connivence. In addition, > you don't know what else is happening on the system (disk??) you're logging > to so it behoves you to be as light as possible. > > I'll leave it at this for now. > > -- Kirk > > On 2012-08-14, at 12:17 PM, Dmitry Samersoff > wrote: > > Kirk, > > However I do have very serious concerns about this JEP in that it > doesn't fix the problems that exist in current logging frameworks, > it only mimics them. > > > http://openjdk.java.net/jeps/158 > > > Any comments is much appreciated. > > Personally, I think that log rotation is out of scope and responsibility > of JVM. > > -Dmitry > > > On 2012-08-14 13:26, Kirk Pepperdine wrote: > > Hi Yasumasa, > > I'm not sure that log file rotation is a part of this JEP. > However I do have very serious concerns about this JEP in that it doesn't > fix the problems that exist in current logging frameworks, it only mimics > them. > > Regards, > Kirk > > On 2012-08-14, at 11:20 AM, Yasumasa Suenaga > wrote: > > Hi Staffan, > > May I ask you 2 questions about this JEP? > > 1. One of goals of this JEP is defined as following: > "File rotation of log files by size (similar to what is available for GC > logs today)" > My patch realizes log rotation by external trigger. > 7090324 is included in this JEP? > (Is 7090324 included in "Logging can be configured dynamically at runtime > via jcmd or MBeans" ? ) > > 2. I've posted a patch for "6950794: Make the GC log file name > parameterized" . > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004758.html > Could you include this RFE in this JEP? > If we use log rotation, I think that name of logs is very important for > log management. > > > Thanks, > > Yasumasa > > > On 2012/08/14 16:50, Staffan Larsen wrote: > > Hi Yasumasa, > > This work should be done in the context of the Unified Logging JEP [1]. > Unfortunately, that work has not yet started due to resource constraints. > Comments on the proposal are welcome. > > [1] http://openjdk.java.net/jeps/158 > > /Staffan > > On 31 jul 2012, at 12:45, Yasumasa Suenaga > wrote: > > Hi, > > I've posted a patch for gc log rotation via jinfo tool last year. > Then I received an email that essence of my patch will be implemented as > "subcommands" of jcmd. > > Now, jcmd is provided by OpenJDK. However, current jcmd does not seem to > implement function of gclog rotation. > > Will this RFE be implemented? > > I need to rotate gclog which is synchronized with signal, cron, etc... on > Linux. > So, if this RFE is not implemented for a while, I would like to contribute > patch for jcmd. > > > Regards, > > Yasumasa > > > On 2011/09/29 21:15, James Melvin wrote: > > Hi Yasumasa, > > Thanks very much for your OpenJDK contribution! As part of the effort to > port JRockit features to HotSpot, we plan to introduce a consolidated > commandline serviceability tool (jcmd) to potentially replace many of > the existing tools in the bin directory, such as jmap, jstack, jinfo and > others. Over the next few update releases, we plan to add several jcmd > *subcommands* instead to accomplish specific tasks or affect the running > JVM instance. We'd like to use the essence of your contribution in one > of the jcmd subcommands (instead of extending jinfo) to ask the JVM to > begin rotating GC logs. We hope you find this attractive and hope you > will help review and perfect the change. > > Thanks, > > Jim Melvin > Sr. Engineering Manager > Oracle > > > > On 9/26/11 6:38 AM, Yasumasa Suenaga wrote: > > (I've changed subject of this email to new RFE.) > > This RFE is enhancement of current gclog implementation. > So, I'd like to discuss about rotating gclog. > > My customers need gclog rotation which is invoked by external trigger. > So I've requested this RFE and made a patch. > > > In many case on Linux, logfile is rotated by signal (e.g. SIGHUP) . > The aim of this RFE is to synchronize gclog and the other logs. > > > Thanks, > > Yasumasa > > (2011/09/22 20:55), Rainer Jung wrote: > > On 22.09.2011 13:20, Dmitry Samersoff wrote: > > > Yasumasa, > > On 2011-09-22 04:47, Yasumasa Suenaga wrote: > > If we can think Java on Linux and Solaris only, syslog is best > solution. > However, Windows usually doesn't have syslog. > > So, I think that gclog is needed for logging GC stats with platform > independent in realtime. > > > Windows has it's own logging API as reach as syslog is or ever better > as well as numerous syslog implementations. > > Native windows logging API was completely redesigned for Windows 2008 > server and now it allows for developers to send a structured events from > theirs application. > > > AFAIK log rotation for loggc is already implemented though not > necessarily yet released. The change discussed here is about supporting > an externally generated rotation trigger, e.g. via a signal, instead of > only rotating by size or time via a startup parameter. > > If you want support for syslog or Windows APIs included, it would be > best to start a new discussion. > > A GC log for an application under load might easily produce a block of > about 1.5 KB size every few seconds. I seriously doubt, that the need > for log file rotation can be argued away by referring to syslog or > Windows log API as the correct solution. > > The messages are not really line formatted, the format can vary a lot > (depending on the excat XX switches), the traffic can be quite high and > AFAIK the JVM writes it synchronously, so there must be absolutely no > risk in writing it out with very little latency. In addition, for > analysis, you wouldn't want to look at each event individually, but > instead process the whole file through a script or tool, which should > not depend on the output specifics of a platform specific log apparatus. > > Regards, > > Rainer > > > > > > > > > -- > Dmitry Samersoff > Java Hotspot development team, SPB04 > * There will come soft rains ... > > > From paul.sandoz at oracle.com Fri Aug 24 02:57:26 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Aug 2012 11:57:26 +0200 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <6C0C79F8-7344-4730-92FF-8051291B2793@oracle.com> Hi Mandy, --- old/src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java Thu Aug 23 12:29:01 2012 +++ new/src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java Thu Aug 23 12:29:00 2012 @@ -52,7 +52,7 @@ AccessController.doPrivileged(new PrivilegedAction() { public IIOPProxy run() { try { - Class c = Class.forName(IMPL_CLASS, true, null); + Class c = Class.forName(IMPL_CLASS); Why not: Class c = Class.forName(IMPL_CLASS, true, IIOPHelper.class.getClassLoader()); to avoid traversing up the call stack to obtain the calling class. Paul. On Aug 23, 2012, at 9:33 PM, Mandy Chung wrote: > On 8/23/2012 11:58 AM, Alan Bateman wrote: >> On 23/08/2012 18:43, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >> This looks good to me and it's good to have these changes in jdk8. >> >> One suggestion for ReflectUtil is to add a private static boolean isAncestor method as I think that would make the checks in needsPackageAccessCheck easier to read. Also in ClassLoader you could use just use needsClassLoaderPermissionCheck(from,to). >> > > Done. This is a good cleanup I considered to do too but missed in the previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy From Dmitry.Samersoff at oracle.com Sat Aug 25 08:18:15 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 25 Aug 2012 19:18:15 +0400 Subject: RR, M 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh Message-ID: <5038ECB7.3080609@oracle.com> Hi Everybody, Test was changed to better support windows. http://cr.openjdk.java.net/~dsamersoff/7186723/webrev.01/ -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Sat Aug 25 13:00:46 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Aug 2012 21:00:46 +0100 Subject: RR, M 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <5038ECB7.3080609@oracle.com> References: <5038ECB7.3080609@oracle.com> Message-ID: <50392EEE.1040809@oracle.com> On 25/08/2012 16:18, Dmitry Samersoff wrote: > Hi Everybody, > > Test was changed to better support windows. > > http://cr.openjdk.java.net/~dsamersoff/7186723/webrev.01/ > > -Dmitry > You will also need to remove the test from the exclude (jdk/test/ProblemList.txt), we had to add it because it was causing the jdk_management target to hang Windows systems. I haven't reviewed the changes proposed here but I did skim JMXStartStopDoSomething and just wonder if the busy code is necessary. I would have thought that such a test could control a slave process via a socket connection or other means. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120825/ba8cc489/attachment.html From Dmitry.Samersoff at oracle.com Sat Aug 25 13:16:19 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 26 Aug 2012 00:16:19 +0400 Subject: RR, M 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <50392EEE.1040809@oracle.com> References: <5038ECB7.3080609@oracle.com> <50392EEE.1040809@oracle.com> Message-ID: <50393293.9050608@oracle.com> Alan, On 2012-08-26 00:00, Alan Bateman wrote: > On 25/08/2012 16:18, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Test was changed to better support windows. >> >> http://cr.openjdk.java.net/~dsamersoff/7186723/webrev.01/ >> >> -Dmitry >> > You will also need to remove the test from the exclude > (jdk/test/ProblemList.txt), we had to add it because it was causing the > jdk_management target to hang Windows systems. Thank you! I'll change it. > I haven't reviewed the changes proposed here but I did skim > JMXStartStopDoSomething and just wonder if the busy code is necessary. I > would have thought that such a test could control a slave process via a > socket connection or other means. The test sends couple of jcmd commands to the single server process. jcmd do attach, call, detach for each command. So I have to keep server running for some time. Server process with just while(true) sleep(1); would run forever if test doesn't kill it for some reason - it's why I use busy code. So I'm open for any advice here. -Dmitry -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Sat Aug 25 23:27:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Aug 2012 07:27:39 +0100 Subject: RR, M 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <50393293.9050608@oracle.com> References: <5038ECB7.3080609@oracle.com> <50392EEE.1040809@oracle.com> <50393293.9050608@oracle.com> Message-ID: <5039C1DB.2010504@oracle.com> On 25/08/2012 21:16, Dmitry Samersoff wrote: > : > The test sends couple of jcmd commands to the single server process. > jcmd do attach, call, detach for each command. So I have to keep server > running for some time. > > Server process with just while(true) sleep(1); would run forever if > test doesn't kill it for some reason - it's why I use busy code. > > So I'm open for any advice here. > > -Dmitry > Our tests need to be very reliable and fast to be useful. With this one then I'm concerned that this busy code is going to hog a core on busy machines and just run too quickly on fast machines (although looking at the code I assume Quicksort(data,1000,0); will cause it to immediately barf so I don't think it actual runs). If I were writing this test then I would control the target process via a socket connection. That way you can instruct it to shutdown when required. You'll see an example in java/nio/channels/AsynchronousFileChannel/Lock.java. Closer to your home then com/sun/tools/attach/BasicTests.sh also uses the socket connection to shutdown the "application". The other thing I would do is re-write as much as the test in java as possible, just to keep it portable and easier to maintain. I realize there is a slight complication here in that you need the pid but otherwise I don't see any reason to use a shell test. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120826/eb6e9cc9/attachment.html From weijun.wang at oracle.com Sun Aug 26 19:24:34 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 27 Aug 2012 02:24:34 +0000 Subject: hg: jdk8/tl/jdk: 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Message-ID: <20120827022448.510724772B@hg.openjdk.java.net> Changeset: 61ddc8ce7f3b Author: weijun Date: 2012-08-27 10:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddc8ce7f3b 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/auto/FileKeyTab.java From paul.sandoz at oracle.com Mon Aug 27 01:40:52 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Aug 2012 10:40:52 +0200 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503806EC.8070207@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <5037A365.6040708@oracle.com> <503803D4.10604@oracle.com> <503806EC.8070207@oracle.com> Message-ID: On Aug 25, 2012, at 12:57 AM, Mandy Chung wrote: > On 8/24/2012 3:44 PM, David Holmes wrote: >> My other query with these changes is whether we are certain that using the specified loader rather than the boot loader will always be correct. > > Yes I'm to my best knowledge but I'm looking to the reviewers to tell me otherwise :) > To the best of my knowledge too. > The class being loaded is either part of the same module or expressed in its module dependency. And for that reason it may be best to use the three arg method call [*] as much as possible for code in the JDK code base. If code is shuffled around it then becomes clearer if the constraint, "either part of the same module or expressed in its module dependency", breaks. Paul. [*] That is not a negative on the stuff below. > I ran the JCK tests in module mode with the jigsaw modular JDK that uncovered these files to be changed. There are other places in the JDK that I didn't touch since they were not found by my testing. > > BTW, I have created a new CR: > 7194006: A new Class.forName(String cn, boolean initialize) method > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.02/ > > This include Paul's suggestion and slightly improved the javadoc > for Class.forName you suggested [1]: > > - * @param initialize whether the class must be initialized > + * @param initialize if {@code true} the class will be initialized. > + * See Section 12 of The Java Language Specification. > > Thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002534.html From jonathan.gibbons at oracle.com Mon Aug 27 06:33:31 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 27 Aug 2012 14:33:31 +0100 Subject: [PATCH FOR REVIEW] 7194035: update tests for upcoming changes for jtreg In-Reply-To: <50381366.7080406@oracle.com> References: <50381366.7080406@oracle.com> Message-ID: <503B772B.2030405@oracle.com> > Jon - does ${TESTCLASSPATH:-${TESTCLASSES}} need to use $PS so that the > path separate is correct on Windows? > > -Alan. Alan, The expression as written does not need $PS because the syntax being used is ${A:-${B}} where the :- is shell syntax for providing a default if not set. If I had suggested ${A}:${B} then $PS would be more appropriate. -- Jon From Alan.Bateman at oracle.com Mon Aug 27 07:17:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Aug 2012 15:17:39 +0100 Subject: [PATCH FOR REVIEW] 7194035: update tests for upcoming changes for jtreg In-Reply-To: <503B772B.2030405@oracle.com> References: <50381366.7080406@oracle.com> <503B772B.2030405@oracle.com> Message-ID: <503B8183.9070906@oracle.com> On 27/08/2012 14:33, Jonathan Gibbons wrote: > > Alan, > > The expression as written does not need $PS because the syntax > being used is ${A:-${B}} where the :- is shell syntax for providing > a default if not set. If I had suggested ${A}:${B} then $PS would > be more appropriate. Okay, I was mis-reading it, in which case what you have looks fine. -Alan From kumar.x.srinivasan at oracle.com Mon Aug 27 07:26:54 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 27 Aug 2012 14:26:54 +0000 Subject: hg: jdk8/tl/langtools: 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Message-ID: <20120827142658.856FA47737@hg.openjdk.java.net> Changeset: c9749226cdde Author: ksrini Date: 2012-08-27 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c9749226cdde 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java From dmytro_sheyko at hotmail.com Mon Aug 27 08:59:13 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Mon, 27 Aug 2012 18:59:13 +0300 Subject: com.sun.management.VMOption.toString() Message-ID: Hi, Just found little misprint in com.sun.management.VMOption.toString() It returns "...(read-only)" if writable is true and "...(read-write)" otherwise. Here is a patch: diff -r 156ab3c38556 src/share/classes/com/sun/management/VMOption.java --- a/src/share/classes/com/sun/management/VMOption.java Thu Aug 23 12:27:49 2012 -0700 +++ b/src/share/classes/com/sun/management/VMOption.java Mon Aug 27 18:52:10 2012 +0300 @@ -178,7 +178,7 @@ return "VM option: " + getName() + " value: " + value + " " + " origin: " + origin + " " + - (writeable ? "(read-only)" : "(read-write)"); + (writeable ? "(read-write)" : "(read-only)"); } /** Do we need formal bug report to fix this? Regards, Dmytro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120827/c631beb8/attachment.html From Dmitry.Samersoff at oracle.com Mon Aug 27 09:11:12 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 27 Aug 2012 20:11:12 +0400 Subject: com.sun.management.VMOption.toString() In-Reply-To: References: Message-ID: <503B9C20.8040204@oracle.com> Dmytro, Thank you fro catching it. Yes, we need a CR. I'll file it tomorrow and sponsor the commit. -Dmitry On 2012-08-27 19:59, Dmytro Sheyko wrote: > Hi, > > Just found little misprint in com.sun.management.VMOption.toString() > It returns "...(read-only)" if writable is true and "...(read-write)" > otherwise. > Here is a patch: > > diff -r 156ab3c38556 src/share/classes/com/sun/management/VMOption.java > --- a/src/share/classes/com/sun/management/VMOption.java Thu Aug 23 > 12:27:49 2012 -0700 > +++ b/src/share/classes/com/sun/management/VMOption.java Mon Aug 27 > 18:52:10 2012 +0300 > @@ -178,7 +178,7 @@ > return "VM option: " + getName() + > " value: " + value + " " + > " origin: " + origin + " " + > - (writeable ? "(read-only)" : "(read-write)"); > + (writeable ? "(read-write)" : "(read-only)"); > } > > /** > > Do we need formal bug report to fix this? > > Regards, > Dmytro -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Mon Aug 27 09:32:01 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 27 Aug 2012 16:32:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 22 new changesets Message-ID: <20120827163248.A8F684773C@hg.openjdk.java.net> Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, 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/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ce0254b13eb8 Merge Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! 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/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c32dee9b8023 Merge Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags Changeset: 153776c4cb6f Author: amurillo Date: 2012-08-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/153776c4cb6f 7194004: new hotspot build - hs24-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b3602ff9c1b8 Author: dcubed Date: 2012-08-24 19:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b3602ff9c1b8 Merge From serguei.spitsyn at oracle.com Mon Aug 27 10:09:27 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Aug 2012 10:09:27 -0700 Subject: [PATCH FOR REVIEW] 7194035: update tests for upcoming changes for jtreg In-Reply-To: <50381366.7080406@oracle.com> References: <50381366.7080406@oracle.com> Message-ID: <503BA9C7.70504@oracle.com> Jon, The fix looks fine. Thanks, Serguei On 8/24/12 4:51 PM, Jonathan Gibbons wrote: > Currently, jtreg incorrectly confuses the concept of the /directory/ > in which the test's class will be written with the /classpath/ used to > locate all of the test's classes, including any library classes. It > provides env variable TESTCLASSES and system property test.classes, > and tests use these to mean both a directory and a classpath. > > jtreg will be fixed to separate the two concepts, such that > TESTCLASSES/test.classes will continue to mean the /directory/ in > which the test's class will the written, and will introduce > TESTCLASSPATH/test.class.path for the classpath used to locate all the > test's classes. > > This change only affects a small number of tests, which use both > @library and TESTCLASSES. A number of serviceability tests are affected, > FAILED: sun/tools/jcmd/jcmd-big-script.sh > FAILED: sun/tools/jcmd/jcmd-f.sh > FAILED: sun/tools/jcmd/jcmd-help-help.sh > FAILED: sun/tools/jcmd/jcmd-pid.sh > FAILED: sun/tools/jinfo/Basic.sh > FAILED: sun/tools/jmap/Basic.sh > FAILED: sun/tools/jps/jps-m_2.sh > FAILED: sun/tools/jps/jps-Vvml_2.sh > FAILED: sun/tools/jstack/Basic.sh > However, all the failures are caused by issues in shared library code, > meaning that only that code needs to be updated. > > The fix is to update the tests where they are using > TESTCLASSES/test.classes as a classpath. > > To ease migration onto the new jtreg, it is suggested that the tests > check to see if the new variables are defined (i.e. new jtreg) and to > fall back on the old variables if they are not defined (i.e. old > jtreg). In shell terms, this can be written > ${TESTCLASSPATH:-${TESTCLASSES}} > > The patch can be seen here: > http://cr.openjdk.java.net/~jjg/7194035/webrev.00/ > > See also > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194035 > > -- Jon From lana.steuck at oracle.com Mon Aug 27 11:04:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:48 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20120827180448.5EB9A47744@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 11:04:47 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:47 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120827180452.3413047745@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags Changeset: d086e67eb9dd Author: lana Date: 2012-08-27 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d086e67eb9dd Merge From lana.steuck at oracle.com Mon Aug 27 11:04:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:51 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120827180459.F101D47746@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From lana.steuck at oracle.com Mon Aug 27 11:04:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:51 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120827180500.E86BE47747@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags Changeset: 542c87b8ce7f Author: lana Date: 2012-08-27 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/542c87b8ce7f Merge From lana.steuck at oracle.com Mon Aug 27 11:04:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:54 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20120827180504.56D6B47748@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags Changeset: 933d0234670f Author: lana Date: 2012-08-27 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/933d0234670f Merge From lana.steuck at oracle.com Mon Aug 27 11:05:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:05:02 +0000 Subject: hg: jdk8/tl/hotspot: 12 new changesets Message-ID: <20120827180527.BE26B47749@hg.openjdk.java.net> Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_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/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.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_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 11:05:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:05:06 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20120827180731.A21BC4774A@hg.openjdk.java.net> Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.java + src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java + src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags Changeset: 96990c9da294 Author: lana Date: 2012-08-27 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96990c9da294 Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From yumin.qi at oracle.com Mon Aug 27 14:07:31 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 27 Aug 2012 14:07:31 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly Message-ID: <503BE193.6090807@oracle.com> Hi, all Can I have you code review of 6879063: SA should use hsdis for disassembly http://cr.openjdk.java.net/~minqi/6879063 The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. Tested by dumping full assembly from core files. Reviewed-by: Contributed-by: Tom R (never) Thanks Yumin Qi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120827/28fbbcd2/attachment.html From christian.thalinger at oracle.com Mon Aug 27 14:43:58 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Aug 2012 14:43:58 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <96CEE190-ECC8-40DF-A811-2CA07DDCA1D2@oracle.com> On Aug 27, 2012, at 2:07 PM, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) src/share/tools/hsdis/hsdis.c: Maybe decode_instructions should call decode_instructions_virtual. agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java: + String cpu = VM.getVM().getCPU(); + if (cpu.equals("sparc")) { + if (VM.getVM().isLP64()) { + libname = "hsdis-sparcv9"; + options = "v9only"; + } else { + libname = "hsdis-sparc"; + } + } else if (cpu.equals("x86")) { + libname = "hsdis-i386"; + } else if (cpu.equals("amd64")) { + libname = "hsdis-amd64"; + } else if (cpu.equals("ia64")) { + libname = "hsdis-ia64"; + } Should we use some default libname here like: libname = "hsdis-" + cpu; so we cover other architectures too (and only special-case sparc, x86, ...)? Otherwise it looks good. -- Chris > > Thanks > Yumin Qi > From yumin.qi at oracle.com Mon Aug 27 17:22:18 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 27 Aug 2012 17:22:18 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <96CEE190-ECC8-40DF-A811-2CA07DDCA1D2@oracle.com> References: <503BE193.6090807@oracle.com> <96CEE190-ECC8-40DF-A811-2CA07DDCA1D2@oracle.com> Message-ID: <503C0F3A.2000506@oracle.com> Thanks. I will modify like that. By the way, missed one file, will add and resend out the modified version. make/solaris/makefiles/sa.make Thanks Yumin On 2012/8/27 14:43, Christian Thalinger wrote: > On Aug 27, 2012, at 2:07 PM, Yumin Qi wrote: > >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) > src/share/tools/hsdis/hsdis.c: > > Maybe decode_instructions should call decode_instructions_virtual. > > agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java: > > + String cpu = VM.getVM().getCPU(); > + if (cpu.equals("sparc")) { > + if (VM.getVM().isLP64()) { > + libname = "hsdis-sparcv9"; > + options = "v9only"; > + } else { > + libname = "hsdis-sparc"; > + } > + } else if (cpu.equals("x86")) { > + libname = "hsdis-i386"; > + } else if (cpu.equals("amd64")) { > + libname = "hsdis-amd64"; > + } else if (cpu.equals("ia64")) { > + libname = "hsdis-ia64"; > + } > > Should we use some default libname here like: > > libname = "hsdis-" + cpu; > > so we cover other architectures too (and only special-case sparc, x86, ...)? > > Otherwise it looks good. > > -- Chris > >> Thanks >> Yumin Qi >> From staffan.larsen at oracle.com Tue Aug 28 02:12:32 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 28 Aug 2012 11:12:32 +0200 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> Thanks for picking up Tom's work and completing it. Anything that removes 20k lines of code must be good :-) Is there a way we can write a jtreg test for this? Either by debugging a live JVM or a core file? Having a test would be very helpful, although it may be impossible because of the requirement to download and build binutils. Any other way we can add automatic testing for this? What platforms have you done manual testing on? I noticed that the makefile changes are missing from the bsd makefiles. Unrelated comment: we should remove the ia64 code from SA... Thanks, /Staffan On 27 aug 2012, at 23:07, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) > > Thanks > Yumin Qi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120828/7827b405/attachment.html From weijun.wang at oracle.com Tue Aug 28 02:26:49 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 28 Aug 2012 09:26:49 +0000 Subject: hg: jdk8/tl/jdk: 7194472: FileKeyTab.java test fails on Windows Message-ID: <20120828092759.8619747768@hg.openjdk.java.net> Changeset: fe496675b5e7 Author: weijun Date: 2012-08-28 17:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe496675b5e7 7194472: FileKeyTab.java test fails on Windows Reviewed-by: alanb ! test/sun/security/krb5/auto/FileKeyTab.java From jonathan.gibbons at oracle.com Tue Aug 28 02:29:52 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Aug 2012 09:29:52 +0000 Subject: hg: jdk8/tl/jdk: 7194032: update tests for upcoming changes for jtreg Message-ID: <20120828093013.189D447769@hg.openjdk.java.net> Changeset: 06d0478023ca Author: jjg Date: 2012-08-28 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06d0478023ca 7194032: update tests for upcoming changes for jtreg Reviewed-by: alanb, iris ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh From jonathan.gibbons at oracle.com Tue Aug 28 02:31:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Aug 2012 09:31:48 +0000 Subject: hg: jdk8/tl/jdk: 7194035: update tests for upcoming changes for jtreg Message-ID: <20120828093215.DD29B4776A@hg.openjdk.java.net> Changeset: 997e0d6238b7 Author: jjg Date: 2012-08-28 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/997e0d6238b7 7194035: update tests for upcoming changes for jtreg Reviewed-by: alanb, sspitsyn ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-m_2.sh From alan.bateman at oracle.com Tue Aug 28 03:13:46 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 28 Aug 2012 10:13:46 +0000 Subject: hg: jdk8/tl/jdk: 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Message-ID: <20120828101423.1DAD94776E@hg.openjdk.java.net> Changeset: c5099c988cce Author: alanb Date: 2012-08-28 11:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5099c988cce 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Reviewed-by: dholmes, alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java From vladimir.x.ivanov at oracle.com Tue Aug 28 03:19:27 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Aug 2012 14:19:27 +0400 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <503C9B2F.8000402@oracle.com> Yumin, Nice work! Since you touch src/share/tools/hsdis/Makefile, can you fix the following typo as well? --- a/src/share/tools/hsdis/Makefile Fri Aug 24 16:23:59 2012 -0700 +++ b/src/share/tools/hsdis/Makefile Tue Aug 28 14:16:07 2012 +0400 @@ -118,7 +118,7 @@ BINUTILSDIR = $(shell cd $(BINUTILS);pwd) endif -CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd -I$(TARGET_DIR)/bfd +CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd -I$(TARGET_DIR)/bfd CPPFLAGS += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\" -DLIB_EXT=\"$(LIB_EXT)\" TARGET_DIR = build/$(OS)-$(JDKARCH) Best regards, Vladimir Ivanov On 08/28/12 01:07, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > > The SA has Java based disassemblers for x86 and sparc but amd64. > Instead of porting to amd64 we should switch over to using hsdis for it > like the JVM does. This requires a new entry point into hsdis, > decode_instructions_virtual, which separates the address of the code > being disassembled from the buffer containing the code. The existing > uses of decode_instructions have been updated to use the new interface > and SA Disassembler has Java native methods that call into hsdis and > call back up to Java to perform the disassembly. Also changed makefile > for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible > with the new disassembly interface. Also deleted are dbx based SA > interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) > > Thanks > Yumin Qi > From sean.mullan at oracle.com Tue Aug 28 05:59:24 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 28 Aug 2012 12:59:24 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120828130004.157DF47772@hg.openjdk.java.net> Changeset: 8b90182f2b33 Author: mullan Date: 2012-08-28 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b90182f2b33 7192896: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: ca7f914b5fea Author: mullan Date: 2012-08-28 08:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca7f914b5fea Merge From yumin.qi at oracle.com Tue Aug 28 08:47:57 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 28 Aug 2012 08:47:57 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503C9B2F.8000402@oracle.com> References: <503BE193.6090807@oracle.com> <503C9B2F.8000402@oracle.com> Message-ID: <503CE82D.4090601@oracle.com> Thanks. Will do. Yumin On 8/28/2012 3:19 AM, Vladimir Ivanov wrote: > Yumin, > > Nice work! > > Since you touch src/share/tools/hsdis/Makefile, can you fix the > following typo as well? > > --- a/src/share/tools/hsdis/Makefile Fri Aug 24 16:23:59 2012 -0700 > +++ b/src/share/tools/hsdis/Makefile Tue Aug 28 14:16:07 2012 +0400 > @@ -118,7 +118,7 @@ > BINUTILSDIR = $(shell cd $(BINUTILS);pwd) > endif > > -CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd > -I$(TARGET_DIR)/bfd > +CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd > -I$(TARGET_DIR)/bfd > CPPFLAGS += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\" > -DLIB_EXT=\"$(LIB_EXT)\" > > TARGET_DIR = build/$(OS)-$(JDKARCH) > > Best regards, > Vladimir Ivanov > > On 08/28/12 01:07, Yumin Qi wrote: >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> >> The SA has Java based disassemblers for x86 and sparc but amd64. >> Instead of porting to amd64 we should switch over to using hsdis for it >> like the JVM does. This requires a new entry point into hsdis, >> decode_instructions_virtual, which separates the address of the code >> being disassembled from the buffer containing the code. The existing >> uses of decode_instructions have been updated to use the new interface >> and SA Disassembler has Java native methods that call into hsdis and >> call back up to Java to perform the disassembly. Also changed makefile >> for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible >> with the new disassembly interface. Also deleted are dbx based SA >> interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> From Dmitry.Samersoff at oracle.com Tue Aug 28 08:49:56 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Aug 2012 19:49:56 +0400 Subject: com.sun.management.VMOption.toString() In-Reply-To: References: Message-ID: <503CE8A4.8000803@oracle.com> Dmytro. CR Number 7194597 -Dmitry On 2012-08-27 19:59, Dmytro Sheyko wrote: > Hi, > > Just found little misprint in com.sun.management.VMOption.toString() > It returns "...(read-only)" if writable is true and "...(read-write)" > otherwise. > Here is a patch: > > diff -r 156ab3c38556 src/share/classes/com/sun/management/VMOption.java > --- a/src/share/classes/com/sun/management/VMOption.java Thu Aug 23 > 12:27:49 2012 -0700 > +++ b/src/share/classes/com/sun/management/VMOption.java Mon Aug 27 > 18:52:10 2012 +0300 > @@ -178,7 +178,7 @@ > return "VM option: " + getName() + > " value: " + value + " " + > " origin: " + origin + " " + > - (writeable ? "(read-only)" : "(read-write)"); > + (writeable ? "(read-write)" : "(read-only)"); > } > > /** > > Do we need formal bug report to fix this? > > Regards, > Dmytro -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From daniel.daugherty at oracle.com Tue Aug 28 08:54:27 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Aug 2012 09:54:27 -0600 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <5035264F.2020909@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> <5035264F.2020909@oracle.com> Message-ID: <503CE9B3.5090107@oracle.com> On 8/22/12 12:34 PM, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for the review! > > Please, find new webrev version here: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/ Thumbs up. No content comments. src/share/vm/prims/jvmtiClassFileReconstituter.hpp No comments. src/share/vm/prims/jvmtiClassFileReconstituter.cpp line 178: ++attr_count; line 421: // Write LocalVariableTable attribute Bug fixes for the previous LVT fix? Just making sure. line 456: // JVMSpec| { u2 start_pc; Breaking this line into the following would be more readable: 456 // JVMSpec| { 457 u2 start_pc; Dan > > I also changed the line: > 196 if (elem[idx].signature_cp_index > 0) { > to this: > 196 if (elem[idx].signature_cp_index != 0) { > > Both are correct as the signature_cp_index is u2. > But "signature_cp_index != 0" is more clear. > > > Thanks, > Serguei > > > On 8/21/12 12:45 PM, serguei.spitsyn at oracle.com wrote: >> On 8/21/12 12:11 PM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >>>> You can see the same pattern for all attributes (for instance, >>>> has_stackmap_table - L160). >>> OK. >>> >>>>> 202: local_variable_type_table_length >>>>> is always 0 if local_variable_table_length == 0 >>>>> >>>>> so I think if should be nested. >>>> It does not matter. >>> It saves one if in some cases and makes logic better readable, >>> so I would like to have it changed. >>> >>> Sorry! >> >> In fact, I initially considered this option and can change it as you >> prefer. >> But let's wait for other reviewers input. >> >> Thanks, >> Serguei >> >>> >>>>> 216: It might be better to place both attr_size changes together. >>>> I'm trying to follow the existing style. >>> OK >>> >>> -Dmitry >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>>> Hello, >>>>>> >>>>>> >>>>>> Please, review the fix for: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The following CR was recently fixed: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>>> >>>>>> But the same issue exists for the LocalVariableTypeTable >>>>>> attribute. >>>>>> >>>>>> The fix was tested with the modified test: >>>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>>> >>>>>> >>>>>> The modification is that a local variable with generic signature >>>>>> is added >>>>>> to the class DummyClassWithLVT.java: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>>> >>>>>> >>>>>> >>>>>> The test patch will be integrated into the jdk8/tl after the >>>>>> HotSpot fix >>>>>> is promoted. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>> >> > From yumin.qi at oracle.com Tue Aug 28 08:56:12 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 28 Aug 2012 08:56:12 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> Message-ID: <503CEA1C.6030004@oracle.com> Thanks. On 8/28/2012 2:12 AM, Staffan Larsen wrote: > Thanks for picking up Tom's work and completing it. Anything that > removes 20k lines of code must be good :-) > > Is there a way we can write a jtreg test for this? Either by debugging > a live JVM or a core file? Having a test would be very helpful, > although it may be impossible because of the requirement to download > and build binutils. Any other way we can add automatic testing for this? > If it is possible, will be under anther id --- that is no less work for live process and core file stuff. I will investigate that possibility. > What platforms have you done manual testing on? > Solaris and Linux > I noticed that the makefile changes are missing from the bsd makefiles. > Yes. > Unrelated comment: we should remove the ia64 code from SA... > This should be removed since we no longer support ia64 and the also the code is dead too. --Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120828/9ddad9aa/attachment.html From daniel.daugherty at oracle.com Tue Aug 28 09:58:36 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 28 Aug 2012 16:58:36 +0000 Subject: hg: jdk8/tl/jdk: 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Message-ID: <20120828165911.2FECC4777D@hg.openjdk.java.net> Changeset: bfd5ecb1b4aa Author: dcubed Date: 2012-08-28 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd5ecb1b4aa 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Reviewed-by: alanb ! test/ProblemList.txt From serguei.spitsyn at oracle.com Tue Aug 28 10:01:33 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 Aug 2012 10:01:33 -0700 Subject: Review request for: 7191786 retransformClasses() does not pass in LocalVariableTypeTable of a method In-Reply-To: <503CE9B3.5090107@oracle.com> References: <5033CFB3.4010305@oracle.com> <5033D7A9.7050108@oracle.com> <5033DC02.3050102@oracle.com> <5033DD55.1010902@oracle.com> <5033E560.7000304@oracle.com> <5035264F.2020909@oracle.com> <503CE9B3.5090107@oracle.com> Message-ID: <503CF96D.2070606@oracle.com> On 8/28/12 8:54 AM, Daniel D. Daugherty wrote: > On 8/22/12 12:34 PM, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thank you for the review! >> >> Please, find new webrev version here: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/ > > Thumbs up. No content comments. Ok, thanks! > > src/share/vm/prims/jvmtiClassFileReconstituter.hpp > No comments. > > src/share/vm/prims/jvmtiClassFileReconstituter.cpp > line 178: ++attr_count; > line 421: // Write LocalVariableTable attribute > Bug fixes for the previous LVT fix? Just making sure. Generally speaking, I do not think it is a real problem. Just wanted to make it consistent with other attributes. > > line 456: // JVMSpec| { u2 start_pc; > Breaking this line into the following would be more readable: > > 456 // JVMSpec| { > 457 u2 start_pc; > Will do it. Thanks! Serguei > Dan >> >> I also changed the line: >> 196 if (elem[idx].signature_cp_index > 0) { >> to this: >> 196 if (elem[idx].signature_cp_index != 0) { >> >> Both are correct as the signature_cp_index is u2. >> But "signature_cp_index != 0" is more clear. >> >> >> Thanks, >> Serguei >> >> >> On 8/21/12 12:45 PM, serguei.spitsyn at oracle.com wrote: >>> On 8/21/12 12:11 PM, Dmitry Samersoff wrote: >>>> Serguei, >>>> >>>> On 2012-08-21 23:05, serguei.spitsyn at oracle.com wrote: >>>>> You can see the same pattern for all attributes (for instance, >>>>> has_stackmap_table - L160). >>>> OK. >>>> >>>>>> 202: local_variable_type_table_length >>>>>> is always 0 if local_variable_table_length == 0 >>>>>> >>>>>> so I think if should be nested. >>>>> It does not matter. >>>> It saves one if in some cases and makes logic better readable, >>>> so I would like to have it changed. >>>> >>>> Sorry! >>> >>> In fact, I initially considered this option and can change it as you >>> prefer. >>> But let's wait for other reviewers input. >>> >>> Thanks, >>> Serguei >>> >>>> >>>>>> 216: It might be better to place both attr_size changes together. >>>>> I'm trying to follow the existing style. >>>> OK >>>> >>>> -Dmitry >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2012-08-21 22:13, serguei.spitsyn at oracle.com wrote: >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> Please, review the fix for: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7191786 >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> The following CR was recently fixed: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7064927 >>>>>>> >>>>>>> But the same issue exists for the LocalVariableTypeTable >>>>>>> attribute. >>>>>>> >>>>>>> The fix was tested with the modified test: >>>>>>> test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh >>>>>>> >>>>>>> >>>>>>> The modification is that a local variable with generic signature >>>>>>> is added >>>>>>> to the class DummyClassWithLVT.java: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JLI-Test-For-JVMTI-LVTT/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> The test patch will be integrated into the jdk8/tl after the >>>>>>> HotSpot fix >>>>>>> is promoted. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>> >>> >> From yumin.qi at oracle.com Tue Aug 28 16:48:28 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 28 Aug 2012 16:48:28 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: <503D58CC.9090806@oracle.com> Hi, all Updated with feedback suggestions. Please have a look again at the same link. Thanks Yumin On 2012/8/27 14:07, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > > The SA has Java based disassemblers for x86 and sparc but amd64. > Instead of porting to amd64 we should switch over to using hsdis for > it like the JVM does. This requires a new entry point into hsdis, > decode_instructions_virtual, which separates the address of the code > being disassembled from the buffer containing the code. The existing > uses of decode_instructions have been updated to use the new interface > and SA Disassembler has Java native methods that call into hsdis and > call back up to Java to perform the disassembly. Also changed makefile > for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible > with the new disassembly interface. Also deleted are dbx based SA > interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) > > Thanks > Yumin Qi > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120828/3428ba46/attachment.html From christian.thalinger at oracle.com Tue Aug 28 17:54:21 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Aug 2012 17:54:21 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503D58CC.9090806@oracle.com> References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: Looks good. -- Chris On Aug 28, 2012, at 4:48 PM, Yumin Qi wrote: > Hi, all > > Updated with feedback suggestions. Please have a look again at the same link. > > Thanks > Yumin > > > > > On 2012/8/27 14:07, Yumin Qi wrote: >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> From weijun.wang at oracle.com Tue Aug 28 20:03:41 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 29 Aug 2012 03:03:41 +0000 Subject: hg: jdk8/tl/jdk: 7184815: [macosx] Need to read Kerberos config in files Message-ID: <20120829030404.891B247793@hg.openjdk.java.net> Changeset: c4c69b4d9ace Author: weijun Date: 2012-08-29 11:03 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace 7184815: [macosx] Need to read Kerberos config in files Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java From yumin.qi at oracle.com Tue Aug 28 20:23:56 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 28 Aug 2012 20:23:56 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: <503D8B4C.7020805@oracle.com> Chris, Now I updated hsdis Makefile, remove platforms related to ppc (not in open). Thanks Yumin On 2012/8/28 17:54, Christian Thalinger wrote: > Looks good. -- Chris > > On Aug 28, 2012, at 4:48 PM, Yumin Qi wrote: > >> Hi, all >> >> Updated with feedback suggestions. Please have a look again at the same link. >> >> Thanks >> Yumin >> >> >> >> >> On 2012/8/27 14:07, Yumin Qi wrote: >>> Hi, all >>> >>> Can I have you code review of >>> 6879063: SA should use hsdis for disassembly >>> >>> http://cr.openjdk.java.net/~minqi/6879063 >>> >>> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >>> >>> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >>> >>> Tested by dumping full assembly from core files. >>> >>> Reviewed-by: >>> Contributed-by: Tom R (never) >>> >>> Thanks >>> Yumin Qi >>> From staffan.larsen at oracle.com Tue Aug 28 23:08:52 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 29 Aug 2012 08:08:52 +0200 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503D58CC.9090806@oracle.com> References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: Yumin, The bsd makefiles are still not updated as far as I can see. I think this should be tested on OS X and Windows as well as Linux and Solaris before it goes in. Thanks, /Staffan On 29 aug 2012, at 01:48, Yumin Qi wrote: > Hi, all > > Updated with feedback suggestions. Please have a look again at the same link. > > Thanks > Yumin > > > > > On 2012/8/27 14:07, Yumin Qi wrote: >> >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120829/44e4c949/attachment.html From rickard.backman at oracle.com Wed Aug 29 00:24:26 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 29 Aug 2012 09:24:26 +0200 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives Message-ID: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> Hi all, can I get a couple of reviews for the following bug fix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ Thanks /R From markus.gronlund at oracle.com Wed Aug 29 00:57:48 2012 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Wed, 29 Aug 2012 00:57:48 -0700 (PDT) Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> Message-ID: <136b54e9-ca77-44ef-b594-18523adb2700@default> Nice find Rickard! Looks good! /Markus -----Original Message----- From: Rickard B?ckman Sent: den 29 augusti 2012 09:24 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives Hi all, can I get a couple of reviews for the following bug fix: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ Thanks /R From david.holmes at oracle.com Wed Aug 29 01:08:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Aug 2012 18:08:26 +1000 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> Message-ID: <503DCDFA.7000005@oracle.com> Hi Rickard, On 29/08/2012 5:24 PM, Rickard B?ckman wrote: > can I get a couple of reviews for the following bug fix: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 > webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ Finding the field in the class_mirror certainly seems correct. But the CR stated this used to work in 6u26, so I'm wondering what changed to cause this to break? Plus is it feasible to add a regression test for this? We don't seem to be covering this functionality otherwise. :( Thanks, David From rickard.backman at oracle.com Wed Aug 29 01:46:18 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 29 Aug 2012 10:46:18 +0200 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503DCDFA.7000005@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503DCDFA.7000005@oracle.com> Message-ID: <5C3015F2-CC07-4BAB-B411-2FA4F7F8010A@oracle.com> David, I'll try to find the sources and see if I can find any obvious difference. I've considered adding a regression test, however I couldn't come up with an idea that wouldn't involve native libraries. I've seen a couple of "solutions" of native libraries but none of them seem especially practical. I'm considering asking SQE if they could add a test for this? Thanks /R On Aug 29, 2012, at 10:08 AM, David Holmes wrote: > Hi Rickard, > > On 29/08/2012 5:24 PM, Rickard B?ckman wrote: >> can I get a couple of reviews for the following bug fix: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 >> webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ > > Finding the field in the class_mirror certainly seems correct. > > But the CR stated this used to work in 6u26, so I'm wondering what changed to cause this to break? > > Plus is it feasible to add a regression test for this? We don't seem to be covering this functionality otherwise. :( > > Thanks, > David From Dmitry.Samersoff at oracle.com Wed Aug 29 03:28:12 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Aug 2012 14:28:12 +0400 Subject: RR, M, 02 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <5038ECB7.3080609@oracle.com> References: <5038ECB7.3080609@oracle.com> Message-ID: <503DEEBC.1050800@oracle.com> Hi Everybody, Second version - busy code rewritten. http://cr.openjdk.java.net/~dsamersoff/7186723/webrev.02/ -Dmitry On 2012-08-25 19:18, Dmitry Samersoff wrote: > Hi Everybody, > > Test was changed to better support windows. > > http://cr.openjdk.java.net/~dsamersoff/7186723/webrev.01/ > > -Dmitry > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Dmitry.Samersoff at oracle.com Wed Aug 29 03:34:09 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 29 Aug 2012 14:34:09 +0400 Subject: RR, M 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh In-Reply-To: <5039C1DB.2010504@oracle.com> References: <5038ECB7.3080609@oracle.com> <50392EEE.1040809@oracle.com> <50393293.9050608@oracle.com> <5039C1DB.2010504@oracle.com> Message-ID: <503DF021.1080109@oracle.com> Alan, Thank you for your help. Please see comments below in-line. On 2012-08-26 10:27, Alan Bateman wrote: > On 25/08/2012 21:16, Dmitry Samersoff wrote: >> : >> The test sends couple of jcmd commands to the single server process. >> jcmd do attach, call, detach for each command. So I have to keep server >> running for some time. >> >> Server process with just while(true) sleep(1); would run forever if >> test doesn't kill it for some reason - it's why I use busy code. >> >> So I'm open for any advice here. >> >> -Dmitry >> > Our tests need to be very reliable and fast to be useful. With this one > then I'm concerned that this busy code is going to hog a core on busy > machines and just run too quickly on fast machines (although looking at > the code I assume Quicksort(data,1000,0); will cause it to immediately > barf so I don't think it actual runs). Agree. > > If I were writing this test then I would control the target process via > a socket connection. That way you can instruct it to shutdown when > required. You'll see an example in > java/nio/channels/AsynchronousFileChannel/Lock.java. Closer to your home > then com/sun/tools/attach/BasicTests.sh also uses the socket connection > to shutdown the "application". I checked the tests above, socket trick save us from using PID and kill on windows, but if nobody connects to the socket, - e.g. jtreg kills the test by timeout, server application will run forever. Also a port could be not available for some reason (e.g. McAfee) and we would have hard to debug intermittent test failure. so I use this idea but implemented it using tmp file. Generally speaking, we should work with jtreg team to add a support for client-server tests to the harness and get rid of all of these tricks. > The other thing I would do is re-write as > much as the test in java as possible, just to keep it portable and > easier to maintain. I realize there is a slight complication here in > that you need the pid but otherwise I don't see any reason to use a > shell test. I'm absolutely agree with you - we should avoid shell tests when possible. -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From rickard.backman at oracle.com Wed Aug 29 05:47:53 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 29 Aug 2012 14:47:53 +0200 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <5C3015F2-CC07-4BAB-B411-2FA4F7F8010A@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503DCDFA.7000005@oracle.com> <5C3015F2-CC07-4BAB-B411-2FA4F7F8010A@oracle.com> Message-ID: <38116D72-A7B5-4289-9E03-C1369A1D1A2C@oracle.com> David, I did some research (archeology), the change that introduced this: changeset: 2223:c7f3d0b4570f user: never date: Fri Mar 18 16:00:34 2011 -0700 summary: 7017732: move static fields into Class to prepare for perm ten removal None of the 6u I tried have the problem. Makes sense to me? /R On Aug 29, 2012, at 10:46 AM, Rickard B?ckman wrote: > David, > > I'll try to find the sources and see if I can find any obvious difference. > > I've considered adding a regression test, however I couldn't come up with an idea that wouldn't > involve native libraries. I've seen a couple of "solutions" of native libraries but none of them seem > especially practical. I'm considering asking SQE if they could add a test for this? > > Thanks > /R > > On Aug 29, 2012, at 10:08 AM, David Holmes wrote: > >> Hi Rickard, >> >> On 29/08/2012 5:24 PM, Rickard B?ckman wrote: >>> can I get a couple of reviews for the following bug fix: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 >>> webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ >> >> Finding the field in the class_mirror certainly seems correct. >> >> But the CR stated this used to work in 6u26, so I'm wondering what changed to cause this to break? >> >> Plus is it feasible to add a regression test for this? We don't seem to be covering this functionality otherwise. :( >> >> Thanks, >> David > From yumin.qi at oracle.com Wed Aug 29 07:01:10 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 29 Aug 2012 07:01:10 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: References: <503BE193.6090807@oracle.com> <503D58CC.9090806@oracle.com> Message-ID: <503E20A6.8090909@oracle.com> This version of webrev diff is messed up. Please ignore it. Will let you know when it is OK. Thanks for the suggestion I will test on Windows and OS X. Thanks Yumin On 2012/8/28 23:08, Staffan Larsen wrote: > Yumin, > > The bsd makefiles are still not updated as far as I can see. I think > this should be tested on OS X and Windows as well as Linux and Solaris > before it goes in. > > Thanks, > /Staffan > > > > On 29 aug 2012, at 01:48, Yumin Qi > wrote: > >> Hi, all >> >> Updated with feedback suggestions. Please have a look again at the >> same link. >> >> Thanks >> Yumin >> >> >> >> >> On 2012/8/27 14:07, Yumin Qi wrote: >>> Hi, all >>> >>> Can I have you code review of >>> 6879063: SA should use hsdis for disassembly >>> >>> http://cr.openjdk.java.net/~minqi/6879063 >>> >>> >>> The SA has Java based disassemblers for x86 and sparc but amd64. >>> Instead of porting to amd64 we should switch over to using hsdis for >>> it like the JVM does. This requires a new entry point into hsdis, >>> decode_instructions_virtual, which separates the address of the code >>> being disassembled from the buffer containing the code. The >>> existing uses of decode_instructions have been updated to use the >>> new interface and SA Disassembler has Java native methods that call >>> into hsdis and call back up to Java to perform the disassembly. Also >>> changed makefile for hsdis build for both(i386/amd64). >>> >>> All the old disassembler logic was deleted since it's incompatible >>> with the new disassembly interface. Also deleted are dbx based SA >>> interface and few other dead files. >>> >>> Tested by dumping full assembly from core files. >>> >>> Reviewed-by: >>> Contributed-by: Tom R (never) >>> >>> Thanks >>> Yumin Qi >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120829/69471f31/attachment.html From daniel.daugherty at oracle.com Wed Aug 29 07:16:31 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Aug 2012 08:16:31 -0600 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> Message-ID: <503E243F.1000508@oracle.com> Logistics issue: This review request went out to OpenJDK alias, but I think this webrev is not accessible outside of Oracle. The webrev should be publicly accessible when the review is public. However, in this case, this is a one line fix so IMHO you could get away with a context diff in the suggested fix of the bug report. On 8/29/12 1:24 AM, Rickard B?ckman wrote: > Hi all, > > can I get a couple of reviews for the following bug fix: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 > webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ > > Thanks > /R Thumbs up. src/share/vm/prims/jvmtiTagMap.cpp No content comments. This is a perfect example of how casting can bite you. :-) The buggy line: 1165 address addr = (address)k + offset; dates back to the original implementation of this function: src/share/vm/prims/SCCS/s.jvmtiTagMap.cpp D 1.47 05/08/22 20:30:26 ab23780 77 76 01476/01330/01852 MRs: COMMENTS: 6195957: further clean-up and caching of field maps In the buggy code, a value is copied from the instanceKlass at the offset instead of from the Java mirror. If the value copied from the instanceKlass happened to match the expected value, then that was pure luck. The bug report claims that this last "worked" in 6u26. I suspect that "working" is defined as returning a non-zero value. Dan From daniel.daugherty at oracle.com Wed Aug 29 07:25:16 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Aug 2012 08:25:16 -0600 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503E243F.1000508@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503E243F.1000508@oracle.com> Message-ID: <503E264C.8070706@oracle.com> On 8/29/12 8:16 AM, Daniel D. Daugherty wrote: > Logistics issue: This review request went out to OpenJDK alias, but > I think this webrev is not accessible outside of Oracle. The webrev > should be publicly accessible when the review is public. However, > in this case, this is a one line fix so IMHO you could get away with > a context diff in the suggested fix of the bug report. > > On 8/29/12 1:24 AM, Rickard B?ckman wrote: >> Hi all, >> >> can I get a couple of reviews for the following bug fix: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 >> webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ >> >> Thanks >> /R > > Thumbs up. > > src/share/vm/prims/jvmtiTagMap.cpp > No content comments. > > This is a perfect example of how casting can bite you. :-) > > The buggy line: > > 1165 address addr = (address)k + offset; > > dates back to the original implementation of this function: > > src/share/vm/prims/SCCS/s.jvmtiTagMap.cpp > D 1.47 05/08/22 20:30:26 ab23780 77 76 01476/01330/01852 > MRs: > COMMENTS: > 6195957: further clean-up and caching of field maps > > In the buggy code, a value is copied from the instanceKlass > at the offset instead of from the Java mirror. If the value > copied from the instanceKlass happened to match the expected > value, then that was pure luck. > > The bug report claims that this last "worked" in 6u26. I suspect > that "working" is defined as returning a non-zero value. > > Dan Rickard, Very nice find: > I did some research (archeology), the change that introduced this: > > changeset: 2223:c7f3d0b4570f > user: never > date: Fri Mar 18 16:00:34 2011 -0700 > summary: 7017732: move static fields into Class to prepare for perm ten removal I had forgotten that static fields moved from the instanceKlass into Class. The original code from 2005 did indeed work as expected way back then. In fact, there were three such uses in jvmtiTagMap.cpp back then and it looks like the other two uses were updated to use the Java mirror and one was missed. Dan From daniel.daugherty at oracle.com Wed Aug 29 07:48:06 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Aug 2012 08:48:06 -0600 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503E2A42.3030702@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503E243F.1000508@oracle.com> <503E264C.8070706@oracle.com> <503E2A42.3030702@oracle.com> Message-ID: <503E2BA6.2090105@oracle.com> Adding serviceability-dev at openjdk.java.net back into the thread... "Reply list" seems to only pick one list... The JCK team has opened a bug for adding a test: 7194847 4/3 Need JCK JVM TI tests for IterateThroughHeap to cover issue reported by 7093328 I don't know if the VM/SQE team will be adding a test to the VM/NSK testbase for this. I don't think a JavaTest/JTREG test is a good fit for this since it has to be a native test. Dan On 8/29/12 8:42 AM, Coleen Phillimore wrote: > > Rickard, > This change looks good. Is there a test for this? Is it possible to > add a jtreg test for this and add it to test/serviceability directory? > This code is different in the permgen elimination repository because > we don't pass klasses as oops. I'll start with the test in the bug > but it would be great to have a jtreg test for it so we know if we > broke it. > > thanks, > Coleen > > On 8/29/2012 10:25 AM, Daniel D. Daugherty wrote: >> On 8/29/12 8:16 AM, Daniel D. Daugherty wrote: >>> Logistics issue: This review request went out to OpenJDK alias, but >>> I think this webrev is not accessible outside of Oracle. The webrev >>> should be publicly accessible when the review is public. However, >>> in this case, this is a one line fix so IMHO you could get away with >>> a context diff in the suggested fix of the bug report. >>> >>> On 8/29/12 1:24 AM, Rickard B?ckman wrote: >>>> Hi all, >>>> >>>> can I get a couple of reviews for the following bug fix: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 >>>> webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ >>>> >>>> Thanks >>>> /R >>> >>> Thumbs up. >>> >>> src/share/vm/prims/jvmtiTagMap.cpp >>> No content comments. >>> >>> This is a perfect example of how casting can bite you. :-) >>> >>> The buggy line: >>> >>> 1165 address addr = (address)k + offset; >>> >>> dates back to the original implementation of this function: >>> >>> src/share/vm/prims/SCCS/s.jvmtiTagMap.cpp >>> D 1.47 05/08/22 20:30:26 ab23780 77 76 01476/01330/01852 >>> MRs: >>> COMMENTS: >>> 6195957: further clean-up and caching of field maps >>> >>> In the buggy code, a value is copied from the instanceKlass >>> at the offset instead of from the Java mirror. If the value >>> copied from the instanceKlass happened to match the expected >>> value, then that was pure luck. >>> >>> The bug report claims that this last "worked" in 6u26. I suspect >>> that "working" is defined as returning a non-zero value. >>> >>> Dan >> >> Rickard, >> >> Very nice find: >> >>> I did some research (archeology), the change that introduced this: >>> >>> changeset: 2223:c7f3d0b4570f >>> user: never >>> date: Fri Mar 18 16:00:34 2011 -0700 >>> summary: 7017732: move static fields into Class to prepare for >>> perm ten removal >> >> I had forgotten that static fields moved from the instanceKlass >> into Class. The original code from 2005 did indeed work as expected >> way back then. In fact, there were three such uses in jvmtiTagMap.cpp >> back then and it looks like the other two uses were updated to use >> the Java mirror and one was missed. >> >> Dan >> From serguei.spitsyn at oracle.com Wed Aug 29 09:46:49 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Aug 2012 09:46:49 -0700 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> Message-ID: <503E4779.8040807@oracle.com> Hi Richard, I see you've already got enough reviewers. The fix looks good. Nice finding! Thanks, Serguei On 8/29/12 12:24 AM, Rickard B?ckman wrote: > Hi all, > > can I get a couple of reviews for the following bug fix: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 > webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ > > Thanks > /R > From serguei.spitsyn at oracle.com Wed Aug 29 10:17:07 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 Aug 2012 10:17:07 -0700 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503E264C.8070706@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503E243F.1000508@oracle.com> <503E264C.8070706@oracle.com> Message-ID: <503E4E93.7030008@oracle.com> On 8/29/12 7:25 AM, Daniel D. Daugherty wrote: > . . . > > Very nice find: > >> I did some research (archeology), the change that introduced this: >> >> changeset: 2223:c7f3d0b4570f >> user: never >> date: Fri Mar 18 16:00:34 2011 -0700 >> summary: 7017732: move static fields into Class to prepare for >> perm ten removal > > I had forgotten that static fields moved from the instanceKlass > into Class. The original code from 2005 did indeed work as expected > way back then. In fact, there were three such uses in jvmtiTagMap.cpp > back then and it looks like the other two uses were updated to use > the Java mirror and one was missed. Right. This explains how it did happened. Thanks, Serguei > > Dan > From kelly.ohair at oracle.com Wed Aug 29 10:22:16 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 29 Aug 2012 10:22:16 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> Message-ID: <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> Makefiles buried in the src tree have a good chance of being completely ignored by the new build-infra project. We need some very solid control over all Makefiles used in the build process. The only exceptions have been test, sample, and demo makefiles, which are not used in the jdk build process. So if these Makefiles are used in the normal hotspot build process, it would be much much better if they were moved into the make directory with the rest of the makefiles. -kto On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote: > Thanks for picking up Tom's work and completing it. Anything that removes 20k lines of code must be good :-) > > Is there a way we can write a jtreg test for this? Either by debugging a live JVM or a core file? Having a test would be very helpful, although it may be impossible because of the requirement to download and build binutils. Any other way we can add automatic testing for this? > > What platforms have you done manual testing on? > > I noticed that the makefile changes are missing from the bsd makefiles. > > Unrelated comment: we should remove the ia64 code from SA... > > Thanks, > /Staffan > > On 27 aug 2012, at 23:07, Yumin Qi wrote: > >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120829/8e7f7d6f/attachment.html From daniel.daugherty at oracle.com Wed Aug 29 10:25:06 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 29 Aug 2012 11:25:06 -0600 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503E4E93.7030008@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503E243F.1000508@oracle.com> <503E264C.8070706@oracle.com> <503E4E93.7030008@oracle.com> Message-ID: <503E5072.1080201@oracle.com> On 8/29/12 11:17 AM, serguei.spitsyn at oracle.com wrote: > On 8/29/12 7:25 AM, Daniel D. Daugherty wrote: >> . . . >> >> Very nice find: >> >>> I did some research (archeology), the change that introduced this: >>> >>> changeset: 2223:c7f3d0b4570f >>> user: never >>> date: Fri Mar 18 16:00:34 2011 -0700 >>> summary: 7017732: move static fields into Class to prepare for >>> perm ten removal >> >> I had forgotten that static fields moved from the instanceKlass >> into Class. The original code from 2005 did indeed work as expected >> way back then. In fact, there were three such uses in jvmtiTagMap.cpp >> back then and it looks like the other two uses were updated to use >> the Java mirror and one was missed. > > Right. This explains how it did happened. Yup. I just read through 7017732. I've added a note to this bug (7093328) and added 7017732 to the "See also" list. Rickard, you need to make yourself the RE for the bug and update the evaluation... Dan > > Thanks, > Serguei >> >> Dan >> > From rickard.backman at oracle.com Wed Aug 29 23:29:37 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 30 Aug 2012 08:29:37 +0200 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503E243F.1000508@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503E243F.1000508@oracle.com> Message-ID: On Aug 29, 2012, at 4:16 PM, Daniel D. Daugherty wrote: > Logistics issue: This review request went out to OpenJDK alias, but > I think this webrev is not accessible outside of Oracle. The webrev > should be publicly accessible when the review is public. However, > in this case, this is a one line fix so IMHO you could get away with > a context diff in the suggested fix of the bug report. Sorry, I pasted the wrong url, the public one is available here: http://cr.openjdk.java.net/~rbackman/7093328/ Thanks for the review Dan! /R > > On 8/29/12 1:24 AM, Rickard B?ckman wrote: >> Hi all, >> >> can I get a couple of reviews for the following bug fix: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 >> webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ >> >> Thanks >> /R > > Thumbs up. > > src/share/vm/prims/jvmtiTagMap.cpp > No content comments. > > This is a perfect example of how casting can bite you. :-) > > The buggy line: > > 1165 address addr = (address)k + offset; > > dates back to the original implementation of this function: > > src/share/vm/prims/SCCS/s.jvmtiTagMap.cpp > D 1.47 05/08/22 20:30:26 ab23780 77 76 01476/01330/01852 > MRs: > COMMENTS: > 6195957: further clean-up and caching of field maps > > In the buggy code, a value is copied from the instanceKlass > at the offset instead of from the Java mirror. If the value > copied from the instanceKlass happened to match the expected > value, then that was pure luck. > > The bug report claims that this last "worked" in 6u26. I suspect > that "working" is defined as returning a non-zero value. > > Dan From rickard.backman at oracle.com Wed Aug 29 23:30:04 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Thu, 30 Aug 2012 08:30:04 +0200 Subject: RFR: 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives In-Reply-To: <503E4779.8040807@oracle.com> References: <12EB21F1-58CB-46A9-8018-735E0A676907@oracle.com> <503E4779.8040807@oracle.com> Message-ID: <0A7E8A92-645B-43C6-B926-5D994A32F819@oracle.com> Thanks Serguei. /R On Aug 29, 2012, at 6:46 PM, serguei.spitsyn at oracle.com wrote: > Hi Richard, > > I see you've already got enough reviewers. > > The fix looks good. > Nice finding! > > Thanks, > Serguei > > On 8/29/12 12:24 AM, Rickard B?ckman wrote: >> Hi all, >> >> can I get a couple of reviews for the following bug fix: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328 >> webrev: http://rbackman.se.oracle.com/~rbackman/7093328/ >> >> Thanks >> /R >> > From dmytro_sheyko at hotmail.com Thu Aug 30 00:18:32 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 30 Aug 2012 10:18:32 +0300 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <4D492D77.5070209@oracle.com> References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>,<4D492D77.5070209@oracle.com> Message-ID: Hi, Could you please review the patch and apply it if it's correct? https://bugs.openjdk.java.net/show_bug.cgi?id=100077 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 Thanks, Dmytro > Date: Wed, 2 Feb 2011 20:09:59 +1000 > From: David.Holmes at oracle.com > To: Alan.Bateman at oracle.com > CC: dmytro_sheyko at hotmail.com; serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jmx-dev at openjdk.java.net > Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value > > Alan Bateman said the following on 02/02/11 20:05: > > David Holmes wrote: > >> It looks like this was actually fixed under 6840305 back in July 2009: > >> > >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 > >> > >> This CR was not updated however. > >> > >> Does the problem still exist? > >> > >> David Holmes > > I think this is separate and 6853676 is about > > com.sun.management.OperatingSystemMXBean. The code for that is in jdk > > repo in src/windows/native/com/sun/management. It should be using > > GlobalMemoryStatusEx rather than GlobalMemoryStatus. > > Thanks Alan, the comments in 6853676 led me astray. > > As a P4 it looks like this has just slipped through the cracks. > > David > > > > Dmytro - to your question, serviceability-dev is the right place to > > bring it. > > > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120830/b530dd14/attachment.html From staffan.larsen at oracle.com Thu Aug 30 00:34:58 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Aug 2012 09:34:58 +0200 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> Message-ID: <8C6F70C2-3F50-48DB-9388-33AE8A8CD79B@oracle.com> My understanding is that the makefiles in the agent/make are not used by normal build. Normal builds use make//makefiles/sa.make. It's unclear to me why the files under agent/make exist at all (except for historical reasons). /Staffan On 29 aug 2012, at 19:22, Kelly O'Hair wrote: > Makefiles buried in the src tree have a good chance of being completely ignored by the new build-infra project. > > We need some very solid control over all Makefiles used in the build process. > The only exceptions have been test, sample, and demo makefiles, which are not used in the jdk build process. > > So if these Makefiles are used in the normal hotspot build process, it would be much much better if they > were moved into the make directory with the rest of the makefiles. > > -kto > > On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote: > >> Thanks for picking up Tom's work and completing it. Anything that removes 20k lines of code must be good :-) >> >> Is there a way we can write a jtreg test for this? Either by debugging a live JVM or a core file? Having a test would be very helpful, although it may be impossible because of the requirement to download and build binutils. Any other way we can add automatic testing for this? >> >> What platforms have you done manual testing on? >> >> I noticed that the makefile changes are missing from the bsd makefiles. >> >> Unrelated comment: we should remove the ia64 code from SA... >> >> Thanks, >> /Staffan >> >> On 27 aug 2012, at 23:07, Yumin Qi wrote: >> >>> Hi, all >>> >>> Can I have you code review of >>> 6879063: SA should use hsdis for disassembly >>> >>> http://cr.openjdk.java.net/~minqi/6879063 >>> >>> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >>> >>> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >>> >>> Tested by dumping full assembly from core files. >>> >>> Reviewed-by: >>> Contributed-by: Tom R (never) >>> >>> Thanks >>> Yumin Qi >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120830/e9dbfb0c/attachment.html From staffan.larsen at oracle.com Thu Aug 30 00:50:27 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Aug 2012 09:50:27 +0200 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>, <4D492D77.5070209@oracle.com> Message-ID: <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> The patch looks good to me and I can sponsor the push to JDK8-TL. However, you need a review from an official Reviewer as well. BTW, I suggest we remove the confusing comment in Java_com_sun_management_OperatingSystem_getTotalPhysicalMemorySize() while we are at it. /Staffan On 30 aug 2012, at 09:18, Dmytro Sheyko wrote: > Hi, > > Could you please review the patch and apply it if it's correct? > https://bugs.openjdk.java.net/show_bug.cgi?id=100077 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 > > Thanks, > Dmytro > > > Date: Wed, 2 Feb 2011 20:09:59 +1000 > > From: David.Holmes at oracle.com > > To: Alan.Bateman at oracle.com > > CC: dmytro_sheyko at hotmail.com; serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; jmx-dev at openjdk.java.net > > Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value > > > > Alan Bateman said the following on 02/02/11 20:05: > > > David Holmes wrote: > > >> It looks like this was actually fixed under 6840305 back in July 2009: > > >> > > >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 > > >> > > >> This CR was not updated however. > > >> > > >> Does the problem still exist? > > >> > > >> David Holmes > > > I think this is separate and 6853676 is about > > > com.sun.management.OperatingSystemMXBean. The code for that is in jdk > > > repo in src/windows/native/com/sun/management. It should be using > > > GlobalMemoryStatusEx rather than GlobalMemoryStatus. > > > > Thanks Alan, the comments in 6853676 led me astray. > > > > As a P4 it looks like this has just slipped through the cracks. > > > > David > > > > > > > Dmytro - to your question, serviceability-dev is the right place to > > > bring it. > > > > > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120830/7ef2b36a/attachment-0001.html From suenaga.yasumasa at lab.ntt.co.jp Thu Aug 30 01:19:37 2012 From: suenaga.yasumasa at lab.ntt.co.jp (Yasumasa Suenaga) Date: Thu, 30 Aug 2012 17:19:37 +0900 Subject: 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not In-Reply-To: <8BC7EB53-6BA2-40AF-819B-4C5DA9A4E7D3@oracle.com> References: <4F4F1A36.4000702@oss.ntt.co.jp> <8BC7EB53-6BA2-40AF-819B-4C5DA9A4E7D3@oracle.com> Message-ID: <503F2219.30400@lab.ntt.co.jp> Hi, 7 months ago, I submitted a patch to fix this CR. I can't find this CR in list of bugfixes in 7u6 . Which version this CR will be fixed ? Thanks, Yasumasa On 2012/03/01 23:06, Staffan Larsen wrote: > The CR is currently assigned to me, but I haven't had the time to look at it yet. It is targeted for the 7u6 release. > > Sorry for the delay, > /Staffan > > On 1 mar 2012, at 07:41, Yasumasa Suenaga wrote: > >> Hi, >> >> About a month ago, I submitted a patch to fix this CR. >> How is the status of this CR? >> >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-January/005174.html >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-January/005175.html >> >> >> If java system is crashed, I want to get Java-level stack trace from core image >> to understand detail of troubles. >> So I would like to contribute this patch. >> >> >> Thanks, >> Yasumasa >> > From david.holmes at oracle.com Thu Aug 30 02:31:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Aug 2012 19:31:24 +1000 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>, <4D492D77.5070209@oracle.com> <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> Message-ID: <503F32EC.20106@oracle.com> On 30/08/2012 5:50 PM, Staffan Larsen wrote: > The patch looks good to me and I can sponsor the push to JDK8-TL. > However, you need a review from an official Reviewer as well. Reviewed. Any way we can get a regression test too? David ----- > BTW, I suggest we remove the confusing comment in > Java_com_sun_management_OperatingSystem_getTotalPhysicalMemorySize() > while we are at it. > > /Staffan > > On 30 aug 2012, at 09:18, Dmytro Sheyko > wrote: > >> Hi, >> >> Could you please review the patch and apply it if it's correct? >> https://bugs.openjdk.java.net/show_bug.cgi?id=100077 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 >> >> Thanks, >> Dmytro >> >> > Date: Wed, 2 Feb 2011 20:09:59 +1000 >> > From:David.Holmes at oracle.com >> > To:Alan.Bateman at oracle.com >> > CC:dmytro_sheyko at hotmail.com ; >> serviceability-dev at openjdk.java.net >> ;hotspot-dev at openjdk.java.net >> ;core-libs-dev at openjdk.java.net >> ;jmx-dev at openjdk.java.net >> >> > Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize >> has incorrect value >> > >> > Alan Bateman said the following on 02/02/11 20:05: >> > > David Holmes wrote: >> > >> It looks like this was actually fixed under 6840305 back in July >> 2009: >> > >> >> > >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 >> > >> >> > >> This CR was not updated however. >> > >> >> > >> Does the problem still exist? >> > >> >> > >> David Holmes >> > > I think this is separate and 6853676 is about >> > > com.sun.management.OperatingSystemMXBean. The code for that is in jdk >> > > repo in src/windows/native/com/sun/management. It should be using >> > > GlobalMemoryStatusEx rather than GlobalMemoryStatus. >> > >> > Thanks Alan, the comments in 6853676 led me astray. >> > >> > As a P4 it looks like this has just slipped through the cracks. >> > >> > David >> > >> > >> > > Dmytro - to your question, serviceability-dev is the right place to >> > > bring it. >> > > >> > > -Alan > From staffan.larsen at oracle.com Thu Aug 30 03:06:09 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 30 Aug 2012 12:06:09 +0200 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <503F32EC.20106@oracle.com> References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>, <4D492D77.5070209@oracle.com> <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> <503F32EC.20106@oracle.com> Message-ID: <0389E5BB-8B04-46A5-B78A-9194AB7A08E8@oracle.com> On 30 aug 2012, at 11:31, David Holmes wrote: > On 30/08/2012 5:50 PM, Staffan Larsen wrote: >> The patch looks good to me and I can sponsor the push to JDK8-TL. >> However, you need a review from an official Reviewer as well. > > Reviewed. > > Any way we can get a regression test too? That would be great - I wonder what the test would check, though? That the value returned is not -1? And hope that sometimes the test will be run on a machine with > 4GB ram. /Staffan > > David > ----- > >> BTW, I suggest we remove the confusing comment in >> Java_com_sun_management_OperatingSystem_getTotalPhysicalMemorySize() >> while we are at it. >> >> /Staffan >> >> On 30 aug 2012, at 09:18, Dmytro Sheyko > > wrote: >> >>> Hi, >>> >>> Could you please review the patch and apply it if it's correct? >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100077 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 >>> >>> Thanks, >>> Dmytro >>> >>> > Date: Wed, 2 Feb 2011 20:09:59 +1000 >>> > From:David.Holmes at oracle.com >>> > To:Alan.Bateman at oracle.com >>> > CC:dmytro_sheyko at hotmail.com ; >>> serviceability-dev at openjdk.java.net >>> ;hotspot-dev at openjdk.java.net >>> ;core-libs-dev at openjdk.java.net >>> ;jmx-dev at openjdk.java.net >>> >>> > Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize >>> has incorrect value >>> > >>> > Alan Bateman said the following on 02/02/11 20:05: >>> > > David Holmes wrote: >>> > >> It looks like this was actually fixed under 6840305 back in July >>> 2009: >>> > >> >>> > >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 >>> > >> >>> > >> This CR was not updated however. >>> > >> >>> > >> Does the problem still exist? >>> > >> >>> > >> David Holmes >>> > > I think this is separate and 6853676 is about >>> > > com.sun.management.OperatingSystemMXBean. The code for that is in jdk >>> > > repo in src/windows/native/com/sun/management. It should be using >>> > > GlobalMemoryStatusEx rather than GlobalMemoryStatus. >>> > >>> > Thanks Alan, the comments in 6853676 led me astray. >>> > >>> > As a P4 it looks like this has just slipped through the cracks. >>> > >>> > David >>> > >>> > >>> > > Dmytro - to your question, serviceability-dev is the right place to >>> > > bring it. >>> > > >>> > > -Alan >> From alan.bateman at oracle.com Thu Aug 30 05:00:15 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 30 Aug 2012 12:00:15 +0000 Subject: hg: jdk8/tl/jdk: 7193710: ByteArrayOutputStream Javadoc contains unclosed element Message-ID: <20120830120101.5E081477E8@hg.openjdk.java.net> Changeset: cf492d1199dc Author: dxu Date: 2012-08-30 12:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf492d1199dc 7193710: ByteArrayOutputStream Javadoc contains unclosed element Reviewed-by: dholmes, alanb, ulfzibis ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/InputStreamReader.java From Dmitry.Samersoff at oracle.com Thu Aug 30 06:55:46 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 30 Aug 2012 17:55:46 +0400 Subject: RR,XS, 7194597 Typeo in com.sun.management.VMOption.toString() Message-ID: <503F70E2.9050401@oracle.com> Hi Everybody. Please review the fix. com.sun.management.VMOption.toString() returns "...(read-only)" if writable is true and "...(read-write)" otherwise. http://cr.openjdk.java.net/~dsamersoff/7194597/webrev.01/ -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From Alan.Bateman at oracle.com Thu Aug 30 07:15:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Aug 2012 15:15:42 +0100 Subject: RR,XS, 7194597 Typeo in com.sun.management.VMOption.toString() In-Reply-To: <503F70E2.9050401@oracle.com> References: <503F70E2.9050401@oracle.com> Message-ID: <503F758E.4020902@oracle.com> On 30/08/2012 14:55, Dmitry Samersoff wrote: > Hi Everybody. > > Please review the fix. > > com.sun.management.VMOption.toString() returns "...(read-only)" if > writable is true and "...(read-write)" otherwise. > > http://cr.openjdk.java.net/~dsamersoff/7194597/webrev.01/ > > Looks okay to me. -Alan From yumin.qi at oracle.com Thu Aug 30 09:02:49 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 30 Aug 2012 09:02:49 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <8C6F70C2-3F50-48DB-9388-33AE8A8CD79B@oracle.com> References: <503BE193.6090807@oracle.com> <1CF54F62-6F3E-4DAB-BF5D-20ED59BD09A7@oracle.com> <6C7642AF-853F-4EAD-B68A-50F5BE076448@oracle.com> <8C6F70C2-3F50-48DB-9388-33AE8A8CD79B@oracle.com> Message-ID: <503F8EA9.7080805@oracle.com> You are right, agent/make is historic make for engineers who only want build SA alone. Certainly they can do this by make -f sa.make from different platform locations. But that is only for building sa-jdi.jar, for build libsaproc, they have to build after whole hotspot built. In hotspot build the building order is sa-jdi.jar, libjvm, libsaproc. I think to build libsaproc, we can do make -f saproc.make But I never try that. Thanks Yumin On 2012/8/30 0:34, Staffan Larsen wrote: > My understanding is that the makefiles in the agent/make are not used > by normal build. Normal builds use make//makefiles/sa.make. > It's unclear to me why the files under agent/make exist at all (except > for historical reasons). > > /Staffan > > On 29 aug 2012, at 19:22, Kelly O'Hair > wrote: > >> Makefiles buried in the src tree have a good chance of being >> completely ignored by the new build-infra project. >> >> We need some very solid control over all Makefiles used in the build >> process. >> The only exceptions have been test, sample, and demo makefiles, which >> are not used in the jdk build process. >> >> So if these Makefiles are used in the normal hotspot build process, >> it would be much much better if they >> were moved into the make directory with the rest of the makefiles. >> >> -kto >> >> On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote: >> >>> Thanks for picking up Tom's work and completing it. Anything that >>> removes 20k lines of code must be good :-) >>> >>> Is there a way we can write a jtreg test for this? Either by >>> debugging a live JVM or a core file? Having a test would be very >>> helpful, although it may be impossible because of the requirement to >>> download and build binutils. Any other way we can add automatic >>> testing for this? >>> >>> What platforms have you done manual testing on? >>> >>> I noticed that the makefile changes are missing from the bsd makefiles. >>> >>> Unrelated comment: we should remove the ia64 code from SA... >>> >>> Thanks, >>> /Staffan >>> >>> On 27 aug 2012, at 23:07, Yumin Qi >> > wrote: >>> >>>> Hi, all >>>> >>>> Can I have you code review of >>>> 6879063: SA should use hsdis for disassembly >>>> >>>> http://cr.openjdk.java.net/~minqi/6879063 >>>> >>>> >>>> The SA has Java based disassemblers for x86 and sparc but amd64. >>>> Instead of porting to amd64 we should switch over to using hsdis >>>> for it like the JVM does. This requires a new entry point into >>>> hsdis, decode_instructions_virtual, which separates the address of >>>> the code being disassembled from the buffer containing the code. >>>> The existing uses of decode_instructions have been updated to use >>>> the new interface and SA Disassembler has Java native methods that >>>> call into hsdis and call back up to Java to perform the >>>> disassembly. Also changed makefile for hsdis build for >>>> both(i386/amd64). >>>> >>>> All the old disassembler logic was deleted since it's >>>> incompatible with the new disassembly interface. Also deleted are >>>> dbx based SA interface and few other dead files. >>>> >>>> Tested by dumping full assembly from core files. >>>> >>>> Reviewed-by: >>>> Contributed-by: Tom R (never) >>>> >>>> Thanks >>>> Yumin Qi >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120830/0b65cf62/attachment-0001.html From mandy.chung at oracle.com Thu Aug 30 09:19:18 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 30 Aug 2012 09:19:18 -0700 Subject: RR,XS, 7194597 Typeo in com.sun.management.VMOption.toString() In-Reply-To: <503F70E2.9050401@oracle.com> References: <503F70E2.9050401@oracle.com> Message-ID: <503F9286.80607@oracle.com> On 8/30/2012 6:55 AM, Dmitry Samersoff wrote: > Hi Everybody. > > Please review the fix. > > com.sun.management.VMOption.toString() returns "...(read-only)" if > writable is true and "...(read-write)" otherwise. > > http://cr.openjdk.java.net/~dsamersoff/7194597/webrev.01/ Thumbs up. Mandy From lance.andersen at oracle.com Thu Aug 30 10:38:39 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 30 Aug 2012 17:38:39 +0000 Subject: hg: jdk8/tl/jdk: 7193683: DriverManager Iterator Warning cleanup Message-ID: <20120830173900.5451A477FC@hg.openjdk.java.net> Changeset: 11bfec75d333 Author: lancea Date: 2012-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11bfec75d333 7193683: DriverManager Iterator Warning cleanup Reviewed-by: lancea Contributed-by: Dan Xu ! src/share/classes/java/sql/DriverManager.java From sean.mullan at oracle.com Thu Aug 30 14:47:52 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 30 Aug 2012 21:47:52 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120830214825.E8E1E47802@hg.openjdk.java.net> Changeset: 0a2565113920 Author: mullan Date: 2012-08-30 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2565113920 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory Reviewed-by: mullan, vinnie Contributed-by: stephen.flores at oracle.com ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECKeyFactory.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 47f8ba39265c Author: mullan Date: 2012-08-30 14:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47f8ba39265c Merge From lana.steuck at oracle.com Thu Aug 30 17:01:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 31 Aug 2012 00:01:05 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120831000154.815484780D@hg.openjdk.java.net> Changeset: baf30df50ce3 Author: andrew Date: 2012-08-23 15:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baf30df50ce3 7192804: Build should not install jvisualvm man page for OpenJDK Summary: OpenJDK builds don't ship VisualVM so shouldn't ship its man page either. Reviewed-by: dholmes ! make/common/Release.gmk ! makefiles/Images.gmk Changeset: 70ad0ed1d6ce Author: katleman Date: 2012-08-29 15:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70ad0ed1d6ce Merge Changeset: 334b6f0c547f Author: lana Date: 2012-08-30 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/334b6f0c547f Merge From lana.steuck at oracle.com Thu Aug 30 17:01:08 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 31 Aug 2012 00:01:08 +0000 Subject: hg: jdk8/tl/hotspot: 31 new changesets Message-ID: <20120831000218.EFDD04780E@hg.openjdk.java.net> Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, 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/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0254b13eb8 Merge Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! 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/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c32dee9b8023 Merge Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags From stuart.marks at oracle.com Thu Aug 30 18:53:29 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 31 Aug 2012 01:53:29 +0000 Subject: hg: jdk8/tl/jdk: 7195099: update problem list with RMI test failures Message-ID: <20120831015350.8702947819@hg.openjdk.java.net> Changeset: f9b11772c4b2 Author: smarks Date: 2012-08-30 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9b11772c4b2 7195099: update problem list with RMI test failures Reviewed-by: alanb ! test/ProblemList.txt From john.coomes at oracle.com Fri Aug 31 01:38:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:38:37 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b54 for changeset c1a277c6022a Message-ID: <20120831083837.22CCB4782C@hg.openjdk.java.net> Changeset: d5e73011bde2 Author: katleman Date: 2012-08-30 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/d5e73011bde2 Added tag jdk8-b54 for changeset c1a277c6022a ! .hgtags From john.coomes at oracle.com Fri Aug 31 01:38:41 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:38:41 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b54 for changeset 16c82fc74695 Message-ID: <20120831083845.082CF4782D@hg.openjdk.java.net> Changeset: 6b2a363213f4 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/6b2a363213f4 Added tag jdk8-b54 for changeset 16c82fc74695 ! .hgtags From john.coomes at oracle.com Fri Aug 31 01:38:49 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:38:49 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b54 for changeset 7dd81ccb7c11 Message-ID: <20120831083859.761F24782E@hg.openjdk.java.net> Changeset: 0cb5f2471628 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/0cb5f2471628 Added tag jdk8-b54 for changeset 7dd81ccb7c11 ! .hgtags From john.coomes at oracle.com Fri Aug 31 01:39:05 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 31 Aug 2012 08:39:05 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b54 for changeset 91970935926a Message-ID: <20120831083910.EA9E14782F@hg.openjdk.java.net> Changeset: 109c9e1f2d85 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/109c9e1f2d85 Added tag jdk8-b54 for changeset 91970935926a ! .hgtags From jonathan.gibbons at oracle.com Fri Aug 31 02:32:20 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 31 Aug 2012 09:32:20 +0000 Subject: hg: jdk8/tl/jdk: 7151010: Add compiler support for repeating annotations Message-ID: <20120831093502.8291647830@hg.openjdk.java.net> Changeset: bdfcc13ddeb4 Author: jfranck Date: 2012-08-31 10:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdfcc13ddeb4 7151010: Add compiler support for repeating annotations Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainerFor.java From jonathan.gibbons at oracle.com Fri Aug 31 02:38:54 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 31 Aug 2012 09:38:54 +0000 Subject: hg: jdk8/tl/langtools: 7151010: Add compiler support for repeating annotations Message-ID: <20120831093903.4FE7A47831@hg.openjdk.java.net> Changeset: 873ddd9f4900 Author: jfranck Date: 2012-08-31 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/873ddd9f4900 7151010: Add compiler support for repeating annotations Reviewed-by: jjg, mcimadamore + src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java + test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java + test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java + test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java + test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java + test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java + test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java + test/tools/javac/diags/examples/ContainedByInheritedMismatch.java + test/tools/javac/diags/examples/ContainedByNoValue.java + test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/ContainedByRetentionMismatch.java + test/tools/javac/diags/examples/ContainedByTargetMismatch.java + test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationJava8.java + test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java + test/tools/javac/diags/examples/WrongContainedBy.java + test/tools/javac/diags/examples/WrongContainerFor.java From sean.coffey at oracle.com Fri Aug 31 04:22:45 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 31 Aug 2012 11:22:45 +0000 Subject: hg: jdk8/tl/jdk: 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Message-ID: <20120831112311.A2D4547834@hg.openjdk.java.net> Changeset: da1436b21bc2 Author: coffeys Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da1436b21bc2 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Reviewed-by: chegar ! test/com/sun/corba/cachedSocket/7056731.sh From alan.bateman at oracle.com Fri Aug 31 04:26:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 31 Aug 2012 11:26:16 +0000 Subject: hg: jdk8/tl/jdk: 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Message-ID: <20120831112639.482B947835@hg.openjdk.java.net> Changeset: 33f8ca2b4ba3 Author: alanb Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33f8ca2b4ba3 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Reviewed-by: chegar ! test/java/nio/file/Files/CopyAndMove.java From dmytro_sheyko at hotmail.com Fri Aug 31 08:55:34 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 31 Aug 2012 18:55:34 +0300 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <0389E5BB-8B04-46A5-B78A-9194AB7A08E8@oracle.com> References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>,<4D492D77.5070209@oracle.com> <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> <503F32EC.20106@oracle.com>, <0389E5BB-8B04-46A5-B78A-9194AB7A08E8@oracle.com> Message-ID: Prepared test (attached). Thanks, Dmytro > Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value > From: staffan.larsen at oracle.com > Date: Thu, 30 Aug 2012 12:06:09 +0200 > CC: dmytro_sheyko at hotmail.com; alan.bateman at oracle.com; serviceability-dev at openjdk.java.net > To: David.Holmes at oracle.com > > > On 30 aug 2012, at 11:31, David Holmes wrote: > > > On 30/08/2012 5:50 PM, Staffan Larsen wrote: > >> The patch looks good to me and I can sponsor the push to JDK8-TL. > >> However, you need a review from an official Reviewer as well. > > > > Reviewed. > > > > Any way we can get a regression test too? > > That would be great - I wonder what the test would check, though? That the value returned is not -1? And hope that sometimes the test will be run on a machine with > 4GB ram. > > /Staffan > > > > > David > > ----- > > > >> BTW, I suggest we remove the confusing comment in > >> Java_com_sun_management_OperatingSystem_getTotalPhysicalMemorySize() > >> while we are at it. > >> > >> /Staffan > >> > >> On 30 aug 2012, at 09:18, Dmytro Sheyko >> > wrote: > >> > >>> Hi, > >>> > >>> Could you please review the patch and apply it if it's correct? > >>> https://bugs.openjdk.java.net/show_bug.cgi?id=100077 > >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 > >>> > >>> Thanks, > >>> Dmytro > >>> > >>> > Date: Wed, 2 Feb 2011 20:09:59 +1000 > >>> > From:David.Holmes at oracle.com > >>> > To:Alan.Bateman at oracle.com > >>> > CC:dmytro_sheyko at hotmail.com ; > >>> serviceability-dev at openjdk.java.net > >>> ;hotspot-dev at openjdk.java.net > >>> ;core-libs-dev at openjdk.java.net > >>> ;jmx-dev at openjdk.java.net > >>> > >>> > Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize > >>> has incorrect value > >>> > > >>> > Alan Bateman said the following on 02/02/11 20:05: > >>> > > David Holmes wrote: > >>> > >> It looks like this was actually fixed under 6840305 back in July > >>> 2009: > >>> > >> > >>> > >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 > >>> > >> > >>> > >> This CR was not updated however. > >>> > >> > >>> > >> Does the problem still exist? > >>> > >> > >>> > >> David Holmes > >>> > > I think this is separate and 6853676 is about > >>> > > com.sun.management.OperatingSystemMXBean. The code for that is in jdk > >>> > > repo in src/windows/native/com/sun/management. It should be using > >>> > > GlobalMemoryStatusEx rather than GlobalMemoryStatus. > >>> > > >>> > Thanks Alan, the comments in 6853676 led me astray. > >>> > > >>> > As a P4 it looks like this has just slipped through the cracks. > >>> > > >>> > David > >>> > > >>> > > >>> > > Dmytro - to your question, serviceability-dev is the right place to > >>> > > bring it. > >>> > > > >>> > > -Alan > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120831/a10ea86e/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: MemoryStatusOverflow.java Url: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120831/a10ea86e/MemoryStatusOverflow.java From Alan.Bateman at oracle.com Fri Aug 31 09:45:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 Aug 2012 17:45:47 +0100 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>, <4D492D77.5070209@oracle.com> <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> <503F32EC.20106@oracle.com>, <0389E5BB-8B04-46A5-B78A-9194AB7A08E8@oracle.com> Message-ID: <5040EA3B.60408@oracle.com> On 31/08/2012 16:55, Dmytro Sheyko wrote: > Prepared test (attached). The test code okay to me but it will need a copyright header. Also you will need a @test tag so that it run by jtreg. I think it's more normal to put this before the imports. Finally, I think it would be good to get the indentation consistent, looks like you are using 8-spaces instead of 4. Otherwise it is good to finally get this issue fixed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120831/f3b7e483/attachment-0001.html From dmytro_sheyko at hotmail.com Fri Aug 31 10:29:05 2012 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 31 Aug 2012 20:29:05 +0300 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <5040EA3B.60408@oracle.com> References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com>,<4D492D77.5070209@oracle.com> <08CAF6F7-4DB7-4F7C-B8A4-C969123334C4@oracle.com> <503F32EC.20106@oracle.com>, <0389E5BB-8B04-46A5-B78A-9194AB7A08E8@oracle.com> , <5040EA3B.60408@oracle.com> Message-ID: Alan, Thank you for your comments. Uploaded corrected version to https://bugs.openjdk.java.net/show_bug.cgi?id=100077 Dmytro Date: Fri, 31 Aug 2012 17:45:47 +0100 From: Alan.Bateman at oracle.com To: dmytro_sheyko at hotmail.com CC: serviceability-dev at openjdk.java.net Subject: Re: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value On 31/08/2012 16:55, Dmytro Sheyko wrote: Prepared test (attached). The test code okay to me but it will need a copyright header. Also you will need a @test tag so that it run by jtreg. I think it's more normal to put this before the imports. Finally, I think it would be good to get the indentation consistent, looks like you are using 8-spaces instead of 4. Otherwise it is good to finally get this issue fixed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20120831/b1481159/attachment.html From john.coomes at oracle.com Fri Aug 31 20:57:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 01 Sep 2012 03:57:10 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 20 new changesets Message-ID: <20120901035754.B1EC647853@hg.openjdk.java.net> Changeset: 3b77f0c58018 Author: katleman Date: 2012-08-30 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3b77f0c58018 Added tag jdk8-b54 for changeset e8fb566b9466 ! .hgtags Changeset: bb3f6194fedb Author: brutisso Date: 2012-08-23 10:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bb3f6194fedb 7178363: G1: Remove the serial code for PrintGCDetails and make it a special case of the parallel code Summary: Also reviewed by vitalyd at gmail.com. Introduced the WorkerDataArray class. Fixed some minor logging bugs. Reviewed-by: johnc, mgerdin ! 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/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/runtime/arguments.cpp Changeset: c9814fadeb38 Author: johnc Date: 2012-08-28 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9814fadeb38 7041879: G1: introduce stress testing parameter to cause frequent evacuation failures Summary: Add the flags G1EvacuationFailureALot flag (and supporting flags) to force trigger evacuation failures. The support flags control how often to trigger an evacuation failure and during which types of evacuation pause. This functionality is analogous to that of PromotionFailureALot for the other collectors. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fa9253dcd4df Author: johnc Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fa9253dcd4df 7194409: os::javaTimeNanos() shows hot on CPU_CLK_UNHALTED profiles Summary: Add inline directives to os::Linux::supports_monotonic_clock() and os::Bsd::supports_monotonic_clock(). Reviewed-by: johnc, azeemj, mikael Contributed-by: Brandon Mitchell ! src/os/bsd/vm/os_bsd.hpp ! src/os/linux/vm/os_linux.hpp Changeset: 220b59f8413f Author: brutisso Date: 2012-08-31 08:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/220b59f8413f Merge Changeset: a1c7f6472621 Author: kvn Date: 2012-08-27 09:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a1c7f6472621 7148109: C2 compiler consumes too much heap resources Summary: Add split_arena to allocate temporary arrays in PhaseChaitin::Split() and free them on method's exit. Reviewed-by: twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/reg_split.cpp Changeset: a5dd6e3ef9f3 Author: twisti Date: 2012-08-27 15:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a5dd6e3ef9f3 6677625: Move platform specific flags from globals.hpp to globals_.hpp Reviewed-by: kvn, dholmes, coleenp Contributed-by: Tao Mao ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 7f813940ac35 Author: twisti Date: 2012-08-28 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7f813940ac35 7192406: JSR 292: C2 needs exact return type information for invokedynamic and invokehandle call sites Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 83b6305a5638 Author: coleenp Date: 2012-08-29 14:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/83b6305a5638 7191926: Remove MKS dependency in Hotspot regression tests Summary: Add case for CYGWIN in .sh files. Reviewed-by: coleenp, kvn Contributed-by: pavel.punegov at oracle.com ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 0acd345fd810 Author: kvn Date: 2012-08-29 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0acd345fd810 7160161: Missed safepoint in non-Counted loop Summary: Do not remove safepoints during peeling optimization. Reviewed-by: twisti ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 4d318b1e73ca Author: twisti Date: 2012-08-31 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4d318b1e73ca Merge Changeset: 0771839a29ab Author: jprovino Date: 2012-08-08 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0771839a29ab 7153374: ARM ONLY .. linking problem with new compilers.. Need to use -fPIC Summary: add "arm" to the list of processors that need -fPIC Reviewed-by: vladidan, dholmes ! make/pic.make Changeset: 892ec0920ccd Author: vladidan Date: 2012-08-08 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/892ec0920ccd Merge Changeset: e2cc1fe53845 Author: amurillo Date: 2012-08-17 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e2cc1fe53845 Merge Changeset: a9fed06c01d2 Author: bpittore Date: 2012-08-30 11:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a9fed06c01d2 7154641: Servicability agent should work on platforms other than x86, sparc Summary: Added capability to load support classes for other cpus Reviewed-by: coleenp, bobv, sla Contributed-by: Bill Pittore ! agent/make/saenv.sh ! agent/make/start-debug-server-proc.sh ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java + agent/src/share/classes/sun/jvm/hotspot/utilities/AltPlatformInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/defs.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! src/share/vm/runtime/vmStructs.cpp Changeset: 6dcb17434873 Author: jiangli Date: 2012-08-31 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6dcb17434873 Merge Changeset: 1eb74cd5994b Author: jiangli Date: 2012-08-31 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1eb74cd5994b Merge Changeset: 09ea7e0752b3 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/09ea7e0752b3 Merge Changeset: af0c8a080851 Author: jcoomes Date: 2012-08-31 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/af0c8a080851 Added tag hs24-b22 for changeset 09ea7e0752b3 ! .hgtags Changeset: 36d1d483d5d6 Author: jcoomes Date: 2012-08-31 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/36d1d483d5d6 7195615: new hotspot build - hs25-b01 Reviewed-by: johnc ! make/hotspot_version