From paul.hohensee at oracle.com Sun Jan 1 14:28:35 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Sun, 01 Jan 2012 22:28:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Message-ID: <20120101222837.D612B47859@hg.openjdk.java.net> Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp From paul.hohensee at oracle.com Tue Jan 3 12:13:43 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 03 Jan 2012 15:13:43 -0500 Subject: Pls review (S) 7126185: Clean up lasterror handling, add os::get_last_error() Message-ID: <4F036177.3060803@oracle.com> Webrev here http://cr.openjdk.java.net/~phh/7126185.00/ Delete getLastErrorString() from os_windows.cpp and replace its uses by calls to os::lasterror(). getLastErrorString() was functionally identical to os::lasterror(). Add os::get_last_error() to get the last error number. Used only by closed source code right now, but logically belongs in the open. Use the correct DWORD type for the result of GetLastError(). Thanks, Paul From john.coomes at oracle.com Tue Jan 3 12:56:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 03 Jan 2012 20:56:50 +0000 Subject: hg: hsx/hotspot-emb/langtools: 12 new changesets Message-ID: <20120103205718.E2C3F47864@hg.openjdk.java.net> Changeset: 4822dfe0922b Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4822dfe0922b 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 3809292620c9 Author: jjg Date: 2011-12-13 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/3809292620c9 7120736: refactor javac option handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Source.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/Lower.java ! src/share/classes/com/sun/tools/javac/file/Locations.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/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! test/tools/javac/diags/examples/UnsupportedEncoding.java Changeset: 4e4fed1d02f9 Author: jjg Date: 2011-12-13 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4e4fed1d02f9 7121164: renamed files not committed Reviewed-by: ksrini - src/share/classes/com/sun/tools/javac/main/JavacOption.java + src/share/classes/com/sun/tools/javac/main/Option.java + src/share/classes/com/sun/tools/javac/main/OptionHelper.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: 4261dc8af622 Author: jjg Date: 2011-12-14 16:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4261dc8af622 7111022: javac no long prints last round of processing 7121323: Sqe tests using -Xstdout option fail with an invalid flag error message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/4846262/Test.sh + test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/util/T6597678.java Changeset: 281eeedf9755 Author: jjg Date: 2011-12-14 17:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/281eeedf9755 7121681: compiler message file broken for javac -fullversion Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: 42ffceeceeca Author: jjg Date: 2011-12-14 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/42ffceeceeca 7121682: remove obsolete import Reviewed-by: jjh ! test/tools/javac/api/T6838467.java Changeset: ab2a880cc23b Author: lana Date: 2011-12-15 19:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/ab2a880cc23b Merge Changeset: 6b773fdeb633 Author: jjg Date: 2011-12-16 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/6b773fdeb633 7121961: javadoc is missing a resource property Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: a7a2720c7897 Author: jjh Date: 2011-12-16 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a7a2720c7897 7122342: testPrintProcessorInfo/TestWithXstdout.java failed for JDK8 nightly build at 12/16/2011 Summary: Do not pass empty args to javac Reviewed-by: jjg ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java Changeset: 1ae5988e201b Author: mcimadamore Date: 2011-12-19 12:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/1ae5988e201b 7120463: Fix method reference parser support in order to avoid ambiguities Summary: Add lookahead routine to disambiguate between method reference in method context and binary expression Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 77b2c066084c Author: lana Date: 2011-12-23 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/77b2c066084c Merge - src/share/classes/com/sun/tools/javac/main/JavacOption.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags From john.coomes at oracle.com Tue Jan 3 13:07:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 03 Jan 2012 21:07:43 +0000 Subject: hg: hsx/hotspot-rt/langtools: 12 new changesets Message-ID: <20120103210813.1544947866@hg.openjdk.java.net> Changeset: 4822dfe0922b Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4822dfe0922b 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 3809292620c9 Author: jjg Date: 2011-12-13 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3809292620c9 7120736: refactor javac option handling Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Source.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/Lower.java ! src/share/classes/com/sun/tools/javac/file/Locations.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/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! test/tools/javac/diags/examples/UnsupportedEncoding.java Changeset: 4e4fed1d02f9 Author: jjg Date: 2011-12-13 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4e4fed1d02f9 7121164: renamed files not committed Reviewed-by: ksrini - src/share/classes/com/sun/tools/javac/main/JavacOption.java + src/share/classes/com/sun/tools/javac/main/Option.java + src/share/classes/com/sun/tools/javac/main/OptionHelper.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: 4261dc8af622 Author: jjg Date: 2011-12-14 16:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4261dc8af622 7111022: javac no long prints last round of processing 7121323: Sqe tests using -Xstdout option fail with an invalid flag error message Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/4846262/Test.sh + test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java ! test/tools/javac/util/T6597678.java Changeset: 281eeedf9755 Author: jjg Date: 2011-12-14 17:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/281eeedf9755 7121681: compiler message file broken for javac -fullversion Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Option.java Changeset: 42ffceeceeca Author: jjg Date: 2011-12-14 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/42ffceeceeca 7121682: remove obsolete import Reviewed-by: jjh ! test/tools/javac/api/T6838467.java Changeset: ab2a880cc23b Author: lana Date: 2011-12-15 19:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ab2a880cc23b Merge Changeset: 6b773fdeb633 Author: jjg Date: 2011-12-16 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6b773fdeb633 7121961: javadoc is missing a resource property Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties Changeset: a7a2720c7897 Author: jjh Date: 2011-12-16 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a7a2720c7897 7122342: testPrintProcessorInfo/TestWithXstdout.java failed for JDK8 nightly build at 12/16/2011 Summary: Do not pass empty args to javac Reviewed-by: jjg ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java Changeset: 1ae5988e201b Author: mcimadamore Date: 2011-12-19 12:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1ae5988e201b 7120463: Fix method reference parser support in order to avoid ambiguities Summary: Add lookahead routine to disambiguate between method reference in method context and binary expression Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 77b2c066084c Author: lana Date: 2011-12-23 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/77b2c066084c Merge - src/share/classes/com/sun/tools/javac/main/JavacOption.java - src/share/classes/com/sun/tools/javac/main/OptionName.java - src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java Changeset: ffd294128a48 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ffd294128a48 Added tag jdk8-b19 for changeset 77b2c066084c ! .hgtags From paul.hohensee at oracle.com Wed Jan 4 14:09:42 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 04 Jan 2012 22:09:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7126185: Clean up lasterror handling, add os::get_last_error() Message-ID: <20120104220945.25D4B47881@hg.openjdk.java.net> Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp From daniel.daugherty at oracle.com Thu Jan 5 07:08:08 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 05 Jan 2012 15:08:08 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Message-ID: <20120105150812.8E6C24789D@hg.openjdk.java.net> Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp From frederic.parain at oracle.com Thu Jan 5 09:47:27 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 05 Jan 2012 17:47:27 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Message-ID: <20120105174731.2239F478A1@hg.openjdk.java.net> Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp From paul.hohensee at oracle.com Thu Jan 5 17:12:50 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Fri, 06 Jan 2012 01:12:50 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120106011256.2B6AE478AC@hg.openjdk.java.net> Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/66259eca2bf7 Merge From john.coomes at oracle.com Thu Jan 5 20:48:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:48:06 +0000 Subject: hg: hsx/hotspot-emb: Added tag jdk8-b20 for changeset 5a5eaf6374bc Message-ID: <20120106044806.B5906478B9@hg.openjdk.java.net> Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:48:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:48:17 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b20 for changeset 51d8b6cb18c0 Message-ID: <20120106044820.59C54478BA@hg.openjdk.java.net> Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:48:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:48:27 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b20 for changeset f052abb8f374 Message-ID: <20120106044828.0A96B478BB@hg.openjdk.java.net> Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:48:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:48:34 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b20 for changeset 2b2818e3386f Message-ID: <20120106044834.D4DD8478BC@hg.openjdk.java.net> Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:49:29 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:49:29 +0000 Subject: hg: hsx/hotspot-emb/jdk: 9 new changesets Message-ID: <20120106045121.DD87B478BD@hg.openjdk.java.net> Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags From john.coomes at oracle.com Thu Jan 5 20:52:33 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 04:52:33 +0000 Subject: hg: hsx/hotspot-emb/langtools: Added tag jdk8-b20 for changeset ffd294128a48 Message-ID: <20120106045240.B7A80478BE@hg.openjdk.java.net> Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:16 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:16 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b20 for changeset 5a5eaf6374bc Message-ID: <20120106050416.DDFC8478C5@hg.openjdk.java.net> Changeset: cc771d92284f Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/cc771d92284f Added tag jdk8-b20 for changeset 5a5eaf6374bc ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:23 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b20 for changeset 51d8b6cb18c0 Message-ID: <20120106050425.E038E478C6@hg.openjdk.java.net> Changeset: f157fc2a71a3 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/f157fc2a71a3 Added tag jdk8-b20 for changeset 51d8b6cb18c0 ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:32 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b20 for changeset f052abb8f374 Message-ID: <20120106050433.128E9478C7@hg.openjdk.java.net> Changeset: d41eeadf5c13 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/d41eeadf5c13 Added tag jdk8-b20 for changeset f052abb8f374 ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:04:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:04:39 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b20 for changeset 2b2818e3386f Message-ID: <20120106050439.C5124478C8@hg.openjdk.java.net> Changeset: dc2ee8b87884 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/dc2ee8b87884 Added tag jdk8-b20 for changeset 2b2818e3386f ! .hgtags From john.coomes at oracle.com Thu Jan 5 21:05:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 06 Jan 2012 05:05:26 +0000 Subject: hg: hsx/hotspot-rt/jdk: 9 new changesets Message-ID: <20120106050815.CF997478C9@hg.openjdk.java.net> Changeset: 172d70c50c65 Author: cgruszka Date: 2011-09-15 13:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/172d70c50c65 7066713: Separate demos from the bundles on Solaris and Linux Summary: add new license files to demos and samples, new directory for bundling Reviewed-by: katleman, ohair, billyh ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: eaf967fd25c5 Author: cgruszka Date: 2011-10-18 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eaf967fd25c5 7099017: jdk7u2-dev does not build Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK Reviewed-by: ohair, billyh ! make/common/Release.gmk Changeset: 39b7f01203c9 Author: cgruszka Date: 2011-11-17 16:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39b7f01203c9 Merge Changeset: b64e7263b4fd Author: cgruszka Date: 2011-11-18 01:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b64e7263b4fd Merge Changeset: e98869ff9f1e Author: cgruszka Date: 2011-12-05 12:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e98869ff9f1e Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: ffa36a6a46f5 Author: cgruszka Date: 2011-12-16 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ffa36a6a46f5 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 5fe1525e6e2c Author: cgruszka Date: 2011-12-23 10:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5fe1525e6e2c Merge Changeset: 39e938cd1b82 Author: cgruszka Date: 2012-01-03 14:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/39e938cd1b82 Merge Changeset: fc050750f8a0 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fc050750f8a0 Added tag jdk8-b20 for changeset 39e938cd1b82 ! .hgtags From frederic.parain at oracle.com Mon Jan 9 10:16:25 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Mon, 09 Jan 2012 18:16:25 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7120511: Add diagnostic commands Message-ID: <20120109181628.11A12478F1@hg.openjdk.java.net> Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp From bill.pittore at oracle.com Tue Jan 10 14:40:30 2012 From: bill.pittore at oracle.com (Bill Pittore) Date: Tue, 10 Jan 2012 17:40:30 -0500 Subject: Webrev for 6972759 Message-ID: <4F0CBE5E.2060203@oracle.com> Webrev for fix for 6972759 is at http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ This bug has to do with single stepping after hitting an exception breakpoint. The short story is that JVMTI maintains some thread state information that was not updated correctly if a frame was popped off the stack. When you pop a frame the exception state should go back to _exception_detected=false. Otherwise when MethodExit event is sent at some time in the future the 'was_popped_by_exception' flag will be set and the agent receiving the event may not re-enable single stepping properly. This problem will also affect ForceEarlyReturn code. Hacked up a couple of existing nsk/jvmti tests to issue the necessary sequence of JVMTI calls/events in order to test original bug and this fix. bill From keith.mcguigan at oracle.com Tue Jan 10 16:28:33 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 11 Jan 2012 00:28:33 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 40 new changesets Message-ID: <20120111002957.1C5D34790E@hg.openjdk.java.net> Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 75c0a73eee98 Author: coleenp Date: 2011-11-17 12:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/75c0a73eee98 7102776: Pack instanceKlass boolean fields into single u1 field Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class. Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: da4dd142ea01 Author: bobv Date: 2011-11-29 14:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/da4dd142ea01 Merge ! src/share/vm/code/dependencies.cpp Changeset: 52b5d32fbfaf Author: coleenp Date: 2011-12-06 18:28 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/52b5d32fbfaf 7117052: instanceKlass::_init_state can be u1 type Summary: Change instanceKlass::_init_state field to u1 type. Reviewed-by: bdelsart, coleenp, dholmes, phh, never Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: eccc4b1f8945 Author: vladidan Date: 2011-12-07 16:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eccc4b1f8945 7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle Summary: missing release barrier in Monitor::IUnlock Reviewed-by: dholmes, dice ! src/share/vm/runtime/mutex.cpp Changeset: 2685ea97b89f Author: jiangli Date: 2011-12-09 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2685ea97b89f Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 8fdf463085e1 Author: jiangli Date: 2011-12-16 17:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8fdf463085e1 Merge Changeset: dca455dea3a7 Author: bdelsart Date: 2011-12-20 12:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dca455dea3a7 7116216: StackOverflow GC crash Summary: GC crash for explicit stack overflow checks after a C2I transition. Reviewed-by: coleenp, never Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp + test/compiler/7116216/LargeFrame.java + test/compiler/7116216/StackOverflow.java Changeset: cd5d8cafcc84 Author: jiangli Date: 2011-12-28 12:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd5d8cafcc84 7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type. Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type. Reviewed-by: never, bdelsart, dholmes Contributed-by: Jiangli Zhou ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ee4167627a3 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From paul.hohensee at oracle.com Wed Jan 11 23:19:01 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Thu, 12 Jan 2012 07:19:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120112071909.60DBA47933@hg.openjdk.java.net> Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp From david.holmes at oracle.com Wed Jan 11 23:54:58 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Jan 2012 17:54:58 +1000 Subject: Webrev for 6972759 In-Reply-To: <4F0CBE5E.2060203@oracle.com> References: <4F0CBE5E.2060203@oracle.com> Message-ID: <4F0E91D2.5060801@oracle.com> Hi Bill, I believe this should have gone out to the Serviceability list (cc'ed) instead of, or perhaps as well as, the runtime list. The change looks okay to me in that is does what you described it would. With JVMTI the proof-of-the-pudding is always in the testing and I assume the various JVMTI test suites have been thoroughly exercised ? Thanks, David On 11/01/2012 8:40 AM, Bill Pittore wrote: > Webrev for fix for 6972759 is at > http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ > > This bug has to do with single stepping after hitting an exception > breakpoint. The short story is that JVMTI maintains some thread state > information that was not updated correctly if a frame was popped off the > stack. When you pop a frame the exception state should go back to > _exception_detected=false. Otherwise when MethodExit event is sent at > some time in the future the 'was_popped_by_exception' flag will be set > and the agent receiving the event may not re-enable single stepping > properly. This problem will also affect ForceEarlyReturn code. Hacked up > a couple of existing nsk/jvmti tests to issue the necessary sequence of > JVMTI calls/events in order to test original bug and this fix. > > bill > > From john.coomes at oracle.com Thu Jan 12 10:28:33 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 12 Jan 2012 18:28:33 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b20 for changeset ffd294128a48 Message-ID: <20120112182838.CEBA847943@hg.openjdk.java.net> Changeset: 020819eb56d2 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/020819eb56d2 Added tag jdk8-b20 for changeset ffd294128a48 ! .hgtags From bill.pittore at oracle.com Thu Jan 12 12:24:38 2012 From: bill.pittore at oracle.com (Bill Pittore) Date: Thu, 12 Jan 2012 15:24:38 -0500 Subject: Webrev for 6972759 In-Reply-To: <4F0E91D2.5060801@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> Message-ID: <4F0F4186.9040409@oracle.com> Hi David, Thanks for forwarding this to the SA list. I did run the nsk/jvmti tests from the UTE area on sqenfs-1.us.oracle.com. There were no new failures with this change. bill On 1/12/2012 2:54 AM, David Holmes wrote: > Hi Bill, > > I believe this should have gone out to the Serviceability list (cc'ed) > instead of, or perhaps as well as, the runtime list. > > The change looks okay to me in that is does what you described it > would. With JVMTI the proof-of-the-pudding is always in the testing > and I assume the various JVMTI test suites have been thoroughly > exercised ? > > Thanks, > David > > On 11/01/2012 8:40 AM, Bill Pittore wrote: >> Webrev for fix for 6972759 is at >> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >> >> This bug has to do with single stepping after hitting an exception >> breakpoint. The short story is that JVMTI maintains some thread state >> information that was not updated correctly if a frame was popped off the >> stack. When you pop a frame the exception state should go back to >> _exception_detected=false. Otherwise when MethodExit event is sent at >> some time in the future the 'was_popped_by_exception' flag will be set >> and the agent receiving the event may not re-enable single stepping >> properly. This problem will also affect ForceEarlyReturn code. Hacked up >> a couple of existing nsk/jvmti tests to issue the necessary sequence of >> JVMTI calls/events in order to test original bug and this fix. >> >> bill >> >> From yumin.qi at oracle.com Thu Jan 12 12:34:08 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Thu, 12 Jan 2012 12:34:08 -0800 Subject: Webrev for 6972759 In-Reply-To: <4F0F4186.9040409@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> <4F0F4186.9040409@oracle.com> Message-ID: <4F0F43C0.6030606@oracle.com> Looks OK. One comment, should we include the CR in comment? I remember it should not be there. --Yumin On 1/12/2012 12:24 PM, Bill Pittore wrote: > Hi David, > Thanks for forwarding this to the SA list. I did run the nsk/jvmti > tests from the UTE area on sqenfs-1.us.oracle.com. There were no new > failures with this change. > > bill > > > > On 1/12/2012 2:54 AM, David Holmes wrote: >> Hi Bill, >> >> I believe this should have gone out to the Serviceability list >> (cc'ed) instead of, or perhaps as well as, the runtime list. >> >> The change looks okay to me in that is does what you described it >> would. With JVMTI the proof-of-the-pudding is always in the testing >> and I assume the various JVMTI test suites have been thoroughly >> exercised ? >> >> Thanks, >> David >> >> On 11/01/2012 8:40 AM, Bill Pittore wrote: >>> Webrev for fix for 6972759 is at >>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >>> >>> This bug has to do with single stepping after hitting an exception >>> breakpoint. The short story is that JVMTI maintains some thread state >>> information that was not updated correctly if a frame was popped off >>> the >>> stack. When you pop a frame the exception state should go back to >>> _exception_detected=false. Otherwise when MethodExit event is sent at >>> some time in the future the 'was_popped_by_exception' flag will be set >>> and the agent receiving the event may not re-enable single stepping >>> properly. This problem will also affect ForceEarlyReturn code. >>> Hacked up >>> a couple of existing nsk/jvmti tests to issue the necessary sequence of >>> JVMTI calls/events in order to test original bug and this fix. >>> >>> bill >>> >>> > > From bill.pittore at oracle.com Thu Jan 12 13:39:47 2012 From: bill.pittore at oracle.com (Bill Pittore) Date: Thu, 12 Jan 2012 16:39:47 -0500 Subject: Webrev for 6972759 In-Reply-To: <4F0F43C0.6030606@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> <4F0F4186.9040409@oracle.com> <4F0F43C0.6030606@oracle.com> Message-ID: <4F0F5323.1020805@oracle.com> Thanks for the comment. I dug up a slightly dated (refers to SCCS ) coding convention document that recommends not to put bug IDs in the comments. I'll delete it. thanks, bill On 1/12/2012 3:34 PM, yumin.qi at oracle.com wrote: > Looks OK. One comment, should we include the CR in comment? I > remember it should not be there. > > --Yumin > > On 1/12/2012 12:24 PM, Bill Pittore wrote: >> Hi David, >> Thanks for forwarding this to the SA list. I did run the nsk/jvmti >> tests from the UTE area on sqenfs-1.us.oracle.com. There were no new >> failures with this change. >> >> bill >> >> >> >> On 1/12/2012 2:54 AM, David Holmes wrote: >>> Hi Bill, >>> >>> I believe this should have gone out to the Serviceability list >>> (cc'ed) instead of, or perhaps as well as, the runtime list. >>> >>> The change looks okay to me in that is does what you described it >>> would. With JVMTI the proof-of-the-pudding is always in the testing >>> and I assume the various JVMTI test suites have been thoroughly >>> exercised ? >>> >>> Thanks, >>> David >>> >>> On 11/01/2012 8:40 AM, Bill Pittore wrote: >>>> Webrev for fix for 6972759 is at >>>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >>>> >>>> This bug has to do with single stepping after hitting an exception >>>> breakpoint. The short story is that JVMTI maintains some thread state >>>> information that was not updated correctly if a frame was popped >>>> off the >>>> stack. When you pop a frame the exception state should go back to >>>> _exception_detected=false. Otherwise when MethodExit event is sent at >>>> some time in the future the 'was_popped_by_exception' flag will be set >>>> and the agent receiving the event may not re-enable single stepping >>>> properly. This problem will also affect ForceEarlyReturn code. >>>> Hacked up >>>> a couple of existing nsk/jvmti tests to issue the necessary >>>> sequence of >>>> JVMTI calls/events in order to test original bug and this fix. >>>> >>>> bill >>>> >>>> >> >> From david.holmes at oracle.com Thu Jan 12 15:03:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Jan 2012 09:03:21 +1000 Subject: Webrev for 6972759 In-Reply-To: <4F0F5323.1020805@oracle.com> References: <4F0CBE5E.2060203@oracle.com> <4F0E91D2.5060801@oracle.com> <4F0F4186.9040409@oracle.com> <4F0F43C0.6030606@oracle.com> <4F0F5323.1020805@oracle.com> Message-ID: <4F0F66B9.90907@oracle.com> On 13/01/2012 7:39 AM, Bill Pittore wrote: > Thanks for the comment. I dug up a slightly dated (refers to SCCS ) > coding convention document that recommends not to put bug IDs in the > comments. I'll delete it. There are numerous places in the hotspot code where comments refer to a specific CR so I wouldn't be too concerned. Normally they serve as an external link for where to find out more info about why particular code was changed/used. David > thanks, > bill > > > > On 1/12/2012 3:34 PM, yumin.qi at oracle.com wrote: >> Looks OK. One comment, should we include the CR in comment? I >> remember it should not be there. >> >> --Yumin >> >> On 1/12/2012 12:24 PM, Bill Pittore wrote: >>> Hi David, >>> Thanks for forwarding this to the SA list. I did run the nsk/jvmti >>> tests from the UTE area on sqenfs-1.us.oracle.com. There were no new >>> failures with this change. >>> >>> bill >>> >>> >>> >>> On 1/12/2012 2:54 AM, David Holmes wrote: >>>> Hi Bill, >>>> >>>> I believe this should have gone out to the Serviceability list >>>> (cc'ed) instead of, or perhaps as well as, the runtime list. >>>> >>>> The change looks okay to me in that is does what you described it >>>> would. With JVMTI the proof-of-the-pudding is always in the testing >>>> and I assume the various JVMTI test suites have been thoroughly >>>> exercised ? >>>> >>>> Thanks, >>>> David >>>> >>>> On 11/01/2012 8:40 AM, Bill Pittore wrote: >>>>> Webrev for fix for 6972759 is at >>>>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/ >>>>> >>>>> This bug has to do with single stepping after hitting an exception >>>>> breakpoint. The short story is that JVMTI maintains some thread state >>>>> information that was not updated correctly if a frame was popped >>>>> off the >>>>> stack. When you pop a frame the exception state should go back to >>>>> _exception_detected=false. Otherwise when MethodExit event is sent at >>>>> some time in the future the 'was_popped_by_exception' flag will be set >>>>> and the agent receiving the event may not re-enable single stepping >>>>> properly. This problem will also affect ForceEarlyReturn code. >>>>> Hacked up >>>>> a couple of existing nsk/jvmti tests to issue the necessary >>>>> sequence of >>>>> JVMTI calls/events in order to test original bug and this fix. >>>>> >>>>> bill >>>>> >>>>> >>> >>> > > From bertrand.delsart at oracle.com Mon Jan 16 08:06:22 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 16 Jan 2012 17:06:22 +0100 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe Message-ID: <4F144AFE.6020308@oracle.com> Here is simple review for the first of a series of fixes and extensions for frame::describe. http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ This is the first of a series of fixes and extensions for frame::describe. frame::describe() was calling the platform dependent frame::fp() to get the frame pointer. Unfortunately, the semantic of frame::fp() is not clearly defined. On compiled x86 frames, the value could be arbitrary. That could cause frame::describe to dump misleading information and useless memory slots. Defined a new frame::real_fp() with a more precise semantic for portable shared code. This is the value expected by the platform ABI when it defines a frame pointer register. It may differ from the effective value of the FP register when that register is used in the JVM for other purposes (like compiled frames on some platforms). On other platforms, it is defined so that the stack area used by this frame goes from real_fp() to sp(). By default, the new definition is equivalent to the old frame::fp() definition. x86 is the only OpenJDK supported platform which required a different definition. Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vladimir.kozlov at oracle.com Tue Jan 17 09:30:56 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jan 2012 09:30:56 -0800 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe In-Reply-To: <4F144AFE.6020308@oracle.com> References: <4F144AFE.6020308@oracle.com> Message-ID: <4F15B050.5060601@oracle.com> I think it looks good. Small note, we need to start updating Copyright year to 2012. Thanks, Vladimir Bertrand Delsart wrote: > Here is simple review for the first of a series of fixes and > extensions for frame::describe. > > http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ > > This is the first of a series of fixes and extensions for > frame::describe. > > frame::describe() was calling the platform dependent frame::fp() to > get the frame pointer. Unfortunately, the semantic of frame::fp() is > not clearly defined. On compiled x86 frames, the value could be > arbitrary. That could cause frame::describe to dump misleading > information and useless memory slots. > > Defined a new frame::real_fp() with a more precise semantic for > portable shared code. > > This is the value expected by the platform ABI when it defines a frame > pointer register. It may differ from the effective value of the FP > register when that register is used in the JVM for other purposes > (like compiled frames on some platforms). On other platforms, it is > defined so that the stack area used by this frame goes from real_fp() > to sp(). > > By default, the new definition is equivalent to the old frame::fp() > definition. x86 is the only OpenJDK supported platform which required > a different definition. > > Bertrand. > From bertrand.delsart at oracle.com Tue Jan 17 10:19:50 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 17 Jan 2012 19:19:50 +0100 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe In-Reply-To: <4F15B050.5060601@oracle.com> References: <4F144AFE.6020308@oracle.com> <4F15B050.5060601@oracle.com> Message-ID: <4F15BBC6.6050503@oracle.com> Thanks Vlad, Bertrand. On 01/17/12 06:30 PM, Vladimir Kozlov wrote: > I think it looks good. > > Small note, we need to start updating Copyright year to 2012. > > Thanks, > Vladimir > > Bertrand Delsart wrote: >> Here is simple review for the first of a series of fixes and >> extensions for frame::describe. >> >> http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ >> >> This is the first of a series of fixes and extensions for >> frame::describe. >> >> frame::describe() was calling the platform dependent frame::fp() to >> get the frame pointer. Unfortunately, the semantic of frame::fp() is >> not clearly defined. On compiled x86 frames, the value could be >> arbitrary. That could cause frame::describe to dump misleading >> information and useless memory slots. >> >> Defined a new frame::real_fp() with a more precise semantic for >> portable shared code. >> >> This is the value expected by the platform ABI when it defines a frame >> pointer register. It may differ from the effective value of the FP >> register when that register is used in the JVM for other purposes >> (like compiled frames on some platforms). On other platforms, it is >> defined so that the stack area used by this frame goes from real_fp() >> to sp(). >> >> By default, the new definition is equivalent to the old frame::fp() >> definition. x86 is the only OpenJDK supported platform which required >> a different definition. >> >> Bertrand. >> -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From tom.rodriguez at oracle.com Tue Jan 17 10:30:56 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 17 Jan 2012 10:30:56 -0800 Subject: RFR, XS, 7120448, Fix FP values for compiled frames in frame::describe In-Reply-To: <4F144AFE.6020308@oracle.com> References: <4F144AFE.6020308@oracle.com> Message-ID: Looks good. tom On Jan 16, 2012, at 8:06 AM, Bertrand Delsart wrote: > Here is simple review for the first of a series of fixes and > extensions for frame::describe. > > http://cr.openjdk.java.net/~bdelsart/7120448/webrev.01/webrev/ > > This is the first of a series of fixes and extensions for > frame::describe. > > frame::describe() was calling the platform dependent frame::fp() to > get the frame pointer. Unfortunately, the semantic of frame::fp() is > not clearly defined. On compiled x86 frames, the value could be > arbitrary. That could cause frame::describe to dump misleading > information and useless memory slots. > > Defined a new frame::real_fp() with a more precise semantic for > portable shared code. > > This is the value expected by the platform ABI when it defines a frame > pointer register. It may differ from the effective value of the FP > register when that register is used in the JVM for other purposes > (like compiled frames on some platforms). On other platforms, it is > defined so that the stack area used by this frame goes from real_fp() > to sp(). > > By default, the new definition is equivalent to the old frame::fp() > definition. x86 is the only OpenJDK supported platform which required > a different definition. > > Bertrand. > > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From vitalyd at gmail.com Tue Jan 17 16:09:02 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 19:09:02 -0500 Subject: Struct/value types + stack allocations Message-ID: Hi, I asked this question on hotspot-compiler dev mailing list (it was tied in with an escape analysis question) but Vladimir Kozlov suggested I try this group instead. Copy/paste of my question: Also, are there any plans to support struct/value-type like (ala CLR's struct) constructs in the JVM (presumably java can then target it)? This would allow developer to control where something gets allocated without relying on EA, and it would also reduce the amount of indirection in object graphs (and the mem/cpu performance hit of them) since struct members of a heap allocated object could be allocated "inline". Thanks Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120117/8271265e/attachment.html From zhengyu.gu at oracle.com Tue Jan 17 18:21:04 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 18 Jan 2012 02:21:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7071311: Decoder enhancement Message-ID: <20120118022110.3E448479AF@hg.openjdk.java.net> Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp From david.holmes at oracle.com Tue Jan 17 19:21:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2012 13:21:55 +1000 Subject: Struct/value types + stack allocations In-Reply-To: References: Message-ID: <4F163AD3.2000108@oracle.com> Hi Vitaly, On 18/01/2012 10:09 AM, Vitaly Davidovich wrote: > I asked this question on hotspot-compiler dev mailing list (it was tied > in with an escape analysis question) but Vladimir Kozlov suggested I try > this group instead. Copy/paste of my question: > > Also, are there any plans to support struct/value-type like (ala CLR's > struct) constructs in the JVM (presumably java can then target it)? This > would allow developer to control where something gets allocated without > relying on EA, and it would also reduce the amount of indirection in > object graphs (and the mem/cpu performance hit of them) since struct > members of a heap allocated object could be allocated "inline". I would say that anything in this direction would have to be driven by languages running on the JVM. In particular if Java doesn't propose to add stack-allocation (it doesn't) then it seems unlikely to me that the VM would add support for it. I'm pretty sure this would require new bytecodes. David > Thanks > > Sent from my phone > From rednaxelafx at gmail.com Tue Jan 17 19:41:29 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 18 Jan 2012 11:41:29 +0800 Subject: Struct/value types + stack allocations In-Reply-To: References: Message-ID: Hi Vitaly, You could try mlvm-dev [1], too. There are a lot of experiments going on over there. There's a proposal on tuples and value-oriented types [2]. There's even an experimental implemention for it, developed by Michael Barker. You can follow its progress on mlvm-dev list [3]. - Kris [1]: http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev [2]: http://openjdk.java.net/projects/mlvm/subprojects.html#TupleSignatures [3]: http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-July/003570.html On Wed, Jan 18, 2012 at 8:09 AM, Vitaly Davidovich wrote: > Hi, > > I asked this question on hotspot-compiler dev mailing list (it was tied in > with an escape analysis question) but Vladimir Kozlov suggested I try this > group instead. Copy/paste of my question: > > Also, are there any plans to support struct/value-type like (ala CLR's > struct) constructs in the JVM (presumably java can then target it)? This > would allow developer to control where something gets allocated without > relying on EA, and it would also reduce the amount of indirection in object > graphs (and the mem/cpu performance hit of them) since struct members of a > heap allocated object could be allocated "inline". > > Thanks > > Sent from my phone > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/173a7e7c/attachment.html From vitalyd at gmail.com Tue Jan 17 20:00:22 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Jan 2012 23:00:22 -0500 Subject: Struct/value types + stack allocations In-Reply-To: <4F163AD3.2000108@oracle.com> References: <4F163AD3.2000108@oracle.com> Message-ID: Hi David, Yeah, I completely appreciate how much work this would entail, but I do see some awesome work being done in the various areas of the JVM (and java the language) so thought I'd ask :). The reason I ask is because I think the achilles heal of java performance is the memory consumption (this is something you often hear in discussions about java performance). Granted, some of this is probably poor data structure/data modeling choices, but I definitely think there's some truth to it. For example, as I mentioned in my original email to hotspot-compiler-dev, there are a lot of utility/wrapper classes in the wild that are thin veneers over a primitive or two (e.g. Apache Commons HashCodeBuilder, EqualsBuilder). People use these inside hashCode()/equals(), and then lo and behold, you start getting significant GC pressure when the # of instances goes up. Another example of this is iterators -- they should be cheap but use them enough, across multiple cores, and you'll be doing young GC before long, with possibly premature promotion and such and then you're either removing these abstractions somehow, or tuning the GC algorithm. Now, escape analysis may eliminate these allocations, but that's still a bit of a black box and hard to count on for sure. So then you're left with a choice of basically removing the wrapper and inlining the code or creating static helper methods. It would be nice if these types of constructs could be modeled with a struct, stack allocated, still provides some abstraction, and very low cost (basically, CLR's struct). Additionally, there's a paper published recently about how to build memory efficient java applications: http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf. It's nothing revolutionary, but it is astounding, when you think about it, just how much space is wasted due to JVM object overhead and delegation/references (compressed oops help, but still). It's unfortunate that there's no good way to model certain abstractions in a very lightweight manner without incurring GC penalty (write barriers/card marks on pointer refs, extra marking/copying/scanning/etc), cpu penalty (pointer chasing memory fetches instead of "inline" members), and other things of the sort. RAM is cheap these days, but the cpu caches haven't grown that much, and cache lines are still in the 64 (and 128) bytes range. Anyway, it would be great to see something where these heap costs could be reduced explicitly (i.e. escape analysis is awesome, but explicit control is nice too). But, I totally understand that it's a large undertaking, so feel free to ignore ... :) Thanks! On Tue, Jan 17, 2012 at 10:21 PM, David Holmes wrote: > Hi Vitaly, > > > On 18/01/2012 10:09 AM, Vitaly Davidovich wrote: > >> I asked this question on hotspot-compiler dev mailing list (it was tied >> in with an escape analysis question) but Vladimir Kozlov suggested I try >> this group instead. Copy/paste of my question: >> >> Also, are there any plans to support struct/value-type like (ala CLR's >> struct) constructs in the JVM (presumably java can then target it)? This >> would allow developer to control where something gets allocated without >> relying on EA, and it would also reduce the amount of indirection in >> object graphs (and the mem/cpu performance hit of them) since struct >> members of a heap allocated object could be allocated "inline". >> > > I would say that anything in this direction would have to be driven by > languages running on the JVM. In particular if Java doesn't propose to add > stack-allocation (it doesn't) then it seems unlikely to me that the VM > would add support for it. I'm pretty sure this would require new bytecodes. > > David > > > Thanks >> >> Sent from my phone >> >> -- Vitaly 617-548-7007 (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120117/942aa18b/attachment.html From david.holmes at oracle.com Tue Jan 17 20:38:23 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Jan 2012 14:38:23 +1000 Subject: Struct/value types + stack allocations In-Reply-To: References: <4F163AD3.2000108@oracle.com> Message-ID: <4F164CBF.6030702@oracle.com> Getting somewhat OT for this list but the Real-Time Specification for Java's ScopedMemory started out from a basic desire to be able to do stack allocation. But it morphed into something immensely complex which didn't support stack allocation afterall (some implementations and derivations constrain its use in a way that allows stack allocation but it isn't part of the spec). Unmanaged languages require the programmer to take full control of memory management. Managed languages go to the other extreme and have the GC take full control. There has always been a middle ground where knowledgeable programmers could assume some memory management responsibilities safely and efficiently. In a managed language like Java the platform would have to be able to enforce/verify the safety aspect eg. not allowing references to stack-allocated objects to escape. Cheers, David ----- On 18/01/2012 2:00 PM, Vitaly Davidovich wrote: > Hi David, > > Yeah, I completely appreciate how much work this would entail, but I do > see some awesome work being done in the various areas of the JVM (and > java the language) so thought I'd ask :). > > The reason I ask is because I think the achilles heal of java > performance is the memory consumption (this is something you often hear > in discussions about java performance). Granted, some of this is > probably poor data structure/data modeling choices, but I definitely > think there's some truth to it. For example, as I mentioned in my > original email to hotspot-compiler-dev, there are a lot of > utility/wrapper classes in the wild that are thin veneers over a > primitive or two (e.g. Apache Commons HashCodeBuilder, EqualsBuilder). > People use these inside hashCode()/equals(), and then lo and behold, > you start getting significant GC pressure when the # of instances goes > up. Another example of this is iterators -- they should be cheap but > use them enough, across multiple cores, and you'll be doing young GC > before long, with possibly premature promotion and such and then you're > either removing these abstractions somehow, or tuning the GC algorithm. > > Now, escape analysis may eliminate these allocations, but that's still a > bit of a black box and hard to count on for sure. So then you're left > with a choice of basically removing the wrapper and inlining the code or > creating static helper methods. It would be nice if these types of > constructs could be modeled with a struct, stack allocated, still > provides some abstraction, and very low cost (basically, CLR's struct). > > Additionally, there's a paper published recently about how to build > memory efficient java applications: > http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf. > It's nothing revolutionary, but it is astounding, when you think about > it, just how much space is wasted due to JVM object overhead and > delegation/references (compressed oops help, but still). It's > unfortunate that there's no good way to model certain abstractions in a > very lightweight manner without incurring GC penalty (write > barriers/card marks on pointer refs, extra > marking/copying/scanning/etc), cpu penalty (pointer chasing memory > fetches instead of "inline" members), and other things of the sort. RAM > is cheap these days, but the cpu caches haven't grown that much, and > cache lines are still in the 64 (and 128) bytes range. > > Anyway, it would be great to see something where these heap costs could > be reduced explicitly (i.e. escape analysis is awesome, but explicit > control is nice too). But, I totally understand that it's a large > undertaking, so feel free to ignore ... :) > > Thanks! > > On Tue, Jan 17, 2012 at 10:21 PM, David Holmes > wrote: > > Hi Vitaly, > > > On 18/01/2012 10:09 AM, Vitaly Davidovich wrote: > > I asked this question on hotspot-compiler dev mailing list (it > was tied > in with an escape analysis question) but Vladimir Kozlov > suggested I try > this group instead. Copy/paste of my question: > > Also, are there any plans to support struct/value-type like (ala > CLR's > struct) constructs in the JVM (presumably java can then target > it)? This > would allow developer to control where something gets allocated > without > relying on EA, and it would also reduce the amount of indirection in > object graphs (and the mem/cpu performance hit of them) since struct > members of a heap allocated object could be allocated "inline". > > > I would say that anything in this direction would have to be driven > by languages running on the JVM. In particular if Java doesn't > propose to add stack-allocation (it doesn't) then it seems unlikely > to me that the VM would add support for it. I'm pretty sure this > would require new bytecodes. > > David > > > Thanks > > Sent from my phone > > > > > -- > Vitaly > 617-548-7007 (mobile) From keith.mcguigan at oracle.com Tue Jan 17 21:08:55 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 18 Jan 2012 05:08:55 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 28 new changesets Message-ID: <20120118050949.D0361479B0@hg.openjdk.java.net> Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! 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/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5acd82522540 Merge Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e504fd26c073 Merge Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f1cd52d6ce02 Merge Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6520f9861937 Merge From vitalyd at gmail.com Wed Jan 18 07:53:43 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Jan 2012 10:53:43 -0500 Subject: Struct/value types + stack allocations In-Reply-To: <4F164CBF.6030702@oracle.com> References: <4F163AD3.2000108@oracle.com> <4F164CBF.6030702@oracle.com> Message-ID: David, I think if the VM allowed for structs which are copied by value then you wouldn't have to worry about stack allocated objects escaping - it would behave just like a primitive. You would need to have generic boxing ability for them but I don't think that's too difficult. This is basically how .NET's structs behave. I think the CLR struck a nice balance between managed/safe features yet allowing developer room for more control in certain situations. I realize that the CLR has just one os platform to worry about (and as a result fewer CPU architectures) but it would be great to have something similar in the JVM. Wishful thinking pehaps ... :) Thanks Sent from my phone On Jan 17, 2012 11:38 PM, "David Holmes" wrote: > Getting somewhat OT for this list but the Real-Time Specification for > Java's ScopedMemory started out from a basic desire to be able to do stack > allocation. But it morphed into something immensely complex which didn't > support stack allocation afterall (some implementations and derivations > constrain its use in a way that allows stack allocation but it isn't part > of the spec). > > Unmanaged languages require the programmer to take full control of memory > management. Managed languages go to the other extreme and have the GC take > full control. There has always been a middle ground where knowledgeable > programmers could assume some memory management responsibilities safely and > efficiently. In a managed language like Java the platform would have to be > able to enforce/verify the safety aspect eg. not allowing references to > stack-allocated objects to escape. > > Cheers, > David > ----- > > On 18/01/2012 2:00 PM, Vitaly Davidovich wrote: > >> Hi David, >> >> Yeah, I completely appreciate how much work this would entail, but I do >> see some awesome work being done in the various areas of the JVM (and >> java the language) so thought I'd ask :). >> >> The reason I ask is because I think the achilles heal of java >> performance is the memory consumption (this is something you often hear >> in discussions about java performance). Granted, some of this is >> probably poor data structure/data modeling choices, but I definitely >> think there's some truth to it. For example, as I mentioned in my >> original email to hotspot-compiler-dev, there are a lot of >> utility/wrapper classes in the wild that are thin veneers over a >> primitive or two (e.g. Apache Commons HashCodeBuilder, EqualsBuilder). >> People use these inside hashCode()/equals(), and then lo and behold, >> you start getting significant GC pressure when the # of instances goes >> up. Another example of this is iterators -- they should be cheap but >> use them enough, across multiple cores, and you'll be doing young GC >> before long, with possibly premature promotion and such and then you're >> either removing these abstractions somehow, or tuning the GC algorithm. >> >> Now, escape analysis may eliminate these allocations, but that's still a >> bit of a black box and hard to count on for sure. So then you're left >> with a choice of basically removing the wrapper and inlining the code or >> creating static helper methods. It would be nice if these types of >> constructs could be modeled with a struct, stack allocated, still >> provides some abstraction, and very low cost (basically, CLR's struct). >> >> Additionally, there's a paper published recently about how to build >> memory efficient java applications: >> http://www.cs.virginia.edu/**kim/publicity/pldi09tutorials/** >> memory-efficient-java-**tutorial.pdf >> . >> It's nothing revolutionary, but it is astounding, when you think about >> it, just how much space is wasted due to JVM object overhead and >> delegation/references (compressed oops help, but still). It's >> unfortunate that there's no good way to model certain abstractions in a >> very lightweight manner without incurring GC penalty (write >> barriers/card marks on pointer refs, extra >> marking/copying/scanning/etc), cpu penalty (pointer chasing memory >> fetches instead of "inline" members), and other things of the sort. RAM >> is cheap these days, but the cpu caches haven't grown that much, and >> cache lines are still in the 64 (and 128) bytes range. >> >> Anyway, it would be great to see something where these heap costs could >> be reduced explicitly (i.e. escape analysis is awesome, but explicit >> control is nice too). But, I totally understand that it's a large >> undertaking, so feel free to ignore ... :) >> >> Thanks! >> >> On Tue, Jan 17, 2012 at 10:21 PM, David Holmes > >> wrote: >> >> Hi Vitaly, >> >> >> On 18/01/2012 10:09 AM, Vitaly Davidovich wrote: >> >> I asked this question on hotspot-compiler dev mailing list (it >> was tied >> in with an escape analysis question) but Vladimir Kozlov >> suggested I try >> this group instead. Copy/paste of my question: >> >> Also, are there any plans to support struct/value-type like (ala >> CLR's >> struct) constructs in the JVM (presumably java can then target >> it)? This >> would allow developer to control where something gets allocated >> without >> relying on EA, and it would also reduce the amount of indirection >> in >> object graphs (and the mem/cpu performance hit of them) since >> struct >> members of a heap allocated object could be allocated "inline". >> >> >> I would say that anything in this direction would have to be driven >> by languages running on the JVM. In particular if Java doesn't >> propose to add stack-allocation (it doesn't) then it seems unlikely >> to me that the VM would add support for it. I'm pretty sure this >> would require new bytecodes. >> >> David >> >> >> Thanks >> >> Sent from my phone >> >> >> >> >> -- >> Vitaly >> 617-548-7007 (mobile) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/c4327089/attachment.html From bertrand.delsart at oracle.com Wed Jan 18 08:29:18 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 18 Jan 2012 17:29:18 +0100 Subject: RFR, S, 7120450: complete information dumped by frame_describe Message-ID: <4F16F35E.1040200@oracle.com> Second RFR related to frame_describe: http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ This comes on top of 7120448, currently being submitted. Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). We did fix a small issue in frame::describe. is_deoptimized() could fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. Thanks, Bertrand. -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From vitalyd at gmail.com Wed Jan 18 09:39:28 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Jan 2012 12:39:28 -0500 Subject: Struct/value types + stack allocations In-Reply-To: References: Message-ID: Hi Kris, I will definitely take a peek at that mailing list and your links - thanks for the pointers. Vitaly Sent from my phone On Jan 17, 2012 10:41 PM, "Krystal Mok" wrote: > Hi Vitaly, > > You could try mlvm-dev [1], too. There are a lot of experiments going on > over there. > > There's a proposal on tuples and value-oriented types [2]. There's even an > experimental implemention for it, developed by Michael Barker. You can > follow its progress on mlvm-dev list [3]. > > - Kris > > [1]: http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > [2]: > http://openjdk.java.net/projects/mlvm/subprojects.html#TupleSignatures > [3]: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-July/003570.html > > On Wed, Jan 18, 2012 at 8:09 AM, Vitaly Davidovich wrote: > >> Hi, >> >> I asked this question on hotspot-compiler dev mailing list (it was tied >> in with an escape analysis question) but Vladimir Kozlov suggested I try >> this group instead. Copy/paste of my question: >> >> Also, are there any plans to support struct/value-type like (ala CLR's >> struct) constructs in the JVM (presumably java can then target it)? This >> would allow developer to control where something gets allocated without >> relying on EA, and it would also reduce the amount of indirection in object >> graphs (and the mem/cpu performance hit of them) since struct members of a >> heap allocated object could be allocated "inline". >> >> Thanks >> >> Sent from my phone >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/1ee7bbc6/attachment.html From bob.vandette at oracle.com Wed Jan 18 09:56:23 2012 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Wed, 18 Jan 2012 17:56:23 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 80 new changesets Message-ID: <20120118175905.99DD8479C0@hg.openjdk.java.net> Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/698a22e99f74 Added tag jdk8-b17 for changeset d1f29d4e0bc6 ! .hgtags Changeset: 09f3b8a372b2 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/09f3b8a372b2 Added tag jdk8-b16 for changeset d1f29d4e0bc6 ! .hgtags Changeset: e46c2339d0fc Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/61165f53f165 Added tag hs23-b08 for changeset a2fef924d8e6 ! .hgtags Changeset: 434acc838772 Author: amurillo Date: 2011-12-16 12:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3c648b9ad052 7121373: Clean up CollectedHeap::is_in Summary: Fixed G1CollectedHeap::is_in, added tests, cleaned up comments and made Space::is_in pure virtual. Reviewed-by: brutisso, tonyp, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/quickSort.hpp Changeset: fd2b426c30db Author: johnc Date: 2011-12-14 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fd2b426c30db 7119908: G1: Cache CSet start region for each worker for subsequent reuse Summary: Cache workers' calculated starting heap region, used for parallel iteration over the collcection set, for subsequent reuse. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 41406797186b Author: tonyp Date: 2011-12-16 02:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/41406797186b 7113012: G1: rename not-fully-young GCs as "mixed" Summary: Renamed partially-young GCs as mixed and fully-young GCs as young. Change all external output that includes those terms (GC log and GC ergo log) as well as any comments, fields, methods, etc. The changeset also includes very minor code tidying up (added some curly brackets). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp Changeset: adedfbbf0360 Author: johnc Date: 2011-12-16 11:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/adedfbbf0360 7120038: G1: ParallelGCThreads==0 is broken Summary: Running G1 with ParallelGCThreads==0 results in various crashes and asserts. Most of these are caused by unguarded references to the worker threads array or an incorrect number of active workers. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: e7dead7e90af Author: johnc Date: 2011-12-19 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e7dead7e90af 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp. Reviewed-by: dholmes, ysr ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 129cd462ae89 Author: jmasa Date: 2011-12-20 12:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/129cd462ae89 Merge Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/96ce4c27112f 7122939: TraceBytecodes broken with UseCompressedOops Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register Reviewed-by: coleenp, phh Contributed-by: Volker Simonis ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6c995c08526c 7122880: Extend vendor-specific command interface to include manageable switches Summary: Add Flag::external_ext()/writable_ext(), both return false. Reviewed-by: coleenp, zgu ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_ext.hpp ! src/share/vm/services/management.cpp Changeset: 4502fd5c7698 Author: phh Date: 2011-12-19 21:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4502fd5c7698 Merge Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/11c26bfcf8c7 7091417: recvfrom's 6th input should be of type socklen_t Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp. Reviewed-by: coleenp, dholmes Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c01e115b095e 7064927: retransformClasses() does not pass in LocalVariableTable of a method Summary: Handle LVT attribute in the class file reconstitutor. Reviewed-by: phh, coleenp Contributed-by: thomaswue ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: d532160c55f7 Author: coleenp Date: 2011-12-21 18:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d532160c55f7 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4b18532913c7 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 7e075537835d Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7e075537835d Added tag jdk8-b18 for changeset 61165f53f165 ! .hgtags Changeset: 4bcf61041217 Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9232e0ecbc2c Added tag hs23-b09 for changeset 4bcf61041217 ! .hgtags Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d15b458c4225 Merge Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp Changeset: 4ceaf61479fc Author: dcubed Date: 2011-12-22 12:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4ceaf61479fc 7122253: Instrumentation.retransformClasses() leaks class bytes Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache. Reviewed-by: coleenp, acorn, poonam ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4ec93d767458 Author: vladidan Date: 2011-12-26 20:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4ec93d767458 Merge Changeset: 3db6ea5ce021 Author: vladidan Date: 2011-12-29 20:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/3db6ea5ce021 Merge Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 5ee33ff9b1c4 Author: jmasa Date: 2012-01-03 10:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5ee33ff9b1c4 Merge Changeset: 05de27e852c4 Author: jiangli Date: 2012-01-04 12:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/05de27e852c4 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: b6a04c79ccbc Author: stefank Date: 2012-01-02 10:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b6a04c79ccbc 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Summary: Used uintptr_t and void* for all the casts and checks in test_is_in. Reviewed-by: tonyp, jmasa ! src/share/vm/gc_interface/collectedHeap.cpp Changeset: 4753e3dda3c8 Author: jmasa Date: 2012-01-04 07:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4753e3dda3c8 Merge Changeset: 2ee4167627a3 Author: jmasa Date: 2012-01-05 21:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ee4167627a3 Merge Changeset: 7ab5f6318694 Author: phh Date: 2012-01-01 11:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7ab5f6318694 7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64 Summary: Add rdtsc detection and inline generation. Reviewed-by: kamg, dholmes Contributed-by: karen.kinnear at oracle.com ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp + src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp + src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp + src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp + src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp + src/share/vm/runtime/os_ext.hpp Changeset: b16494a69d3d Author: phh Date: 2012-01-03 15:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b16494a69d3d 7126185: Clean up lasterror handling, add os::get_last_error() Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp. Reviewed-by: kamg, dholmes Contributed-by: erik.gahlin at oracle.com ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 5b58979183f9 Author: dcubed Date: 2012-01-05 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5b58979183f9 7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for(). Reviewed-by: coleenp, poonam, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: 8a63c6323842 Author: fparain Date: 2012-01-05 07:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8a63c6323842 7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint Reviewed-by: sspitsyn, dcubed, mchung, dholmes ! src/share/vm/services/threadService.cpp Changeset: 2e0ef19fc891 Author: phh Date: 2012-01-05 17:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2e0ef19fc891 7126480: Make JVM start time in milliseconds since the Java epoch available Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time(). Reviewed-by: acorn, dcubed ! src/share/vm/services/management.hpp Changeset: 66259eca2bf7 Author: phh Date: 2012-01-05 17:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/66259eca2bf7 Merge Changeset: 2b3acb34791f Author: dcubed Date: 2012-01-06 16:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2b3acb34791f Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/os.hpp Changeset: abcceac2f7cd Author: iveresov Date: 2011-12-12 12:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/abcceac2f7cd 7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop) Summary: Added handles for references to methods in select_task() Reviewed-by: twisti, kvn ! src/share/vm/runtime/advancedThresholdPolicy.cpp Changeset: 7bca37d28f32 Author: roland Date: 2011-12-13 10:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/7bca37d28f32 7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now Summary: fix C1's CEE to take inlining into account when the stacks in states are compared. Reviewed-by: iveresov, never ! src/share/vm/c1/c1_Optimizer.cpp Changeset: d725f0affb1a Author: iveresov Date: 2011-12-13 17:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d725f0affb1a 7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler Summary: Exercise C2 more in tiered mode with Xcomp Reviewed-by: kvn, never ! src/share/vm/runtime/arguments.cpp Changeset: 127b3692c168 Author: kvn Date: 2011-12-14 14:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/127b3692c168 7116452: Add support for AVX instructions Summary: Added support for AVX extension to the x86 instruction set. Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: 669f6a7d5b70 Author: never Date: 2011-12-19 14:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/669f6a7d5b70 7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type Reviewed-by: kvn ! src/share/vm/opto/compile.cpp Changeset: 65149e74c706 Author: kvn Date: 2011-12-20 00:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/65149e74c706 7121648: Use 3-operands SIMD instructions on x86 with AVX Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX. Reviewed-by: never ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp + src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.cpp Changeset: 069ab3f976d3 Author: stefank Date: 2011-12-07 11:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/069ab3f976d3 7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix. Reviewed-by: never, bdelsart, coleenp, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 1dc233a8c7fe Author: roland Date: 2011-12-20 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1dc233a8c7fe 7121140: Allocation paths require explicit memory synchronization operations for RMO systems Summary: adds store store barrier after initialization of header and body of objects. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp Changeset: e5ac210043cd Author: roland Date: 2011-12-22 10:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e5ac210043cd 7123108: C1: assert(if_state != NULL) failed: states do not match up Summary: In CEE, ensure if and common successor state are at the same inline level Reviewed-by: never ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/7123108/Test7123108.java Changeset: b642b49f9738 Author: roland Date: 2011-12-23 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b642b49f9738 7123253: C1: in store check code, usage of registers may be incorrect Summary: fix usage of input register in assembly code for store check. Reviewed-by: never ! src/share/vm/c1/c1_LIR.cpp Changeset: 40c2484c09e1 Author: kvn Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/40c2484c09e1 7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM Summary: Distance is too large for one short branch in string_indexofC8(). Reviewed-by: iveresov ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: d12a66fa3820 Author: kvn Date: 2011-12-27 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d12a66fa3820 7123954: Some CTW test crash with SIGSEGV Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated. Reviewed-by: iveresov ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 8940fd98d540 Author: kvn Date: 2011-12-29 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8940fd98d540 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9c87bcb3b4dd Author: kvn Date: 2011-12-30 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9c87bcb3b4dd 7125879: assert(proj != NULL) failed: must be found Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call. Reviewed-by: iveresov, twisti ! src/share/vm/opto/macro.cpp + test/compiler/7125879/Test7125879.java Changeset: 1cb50d7a9d95 Author: iveresov Date: 2012-01-05 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1cb50d7a9d95 7119294: Two command line options cause JVM to crash Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64 Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 22cee0ee8927 Author: kvn Date: 2012-01-06 20:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/22cee0ee8927 Merge ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parseHelper.cpp Changeset: 8f8b94305aff Author: dcubed Date: 2012-01-11 19:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/8f8b94305aff 7129240: backout fix for 7102776 until 7128770 is resolved Reviewed-by: phh, bobv, coleenp, dcubed Contributed-by: Jiangli Zhou ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 4f25538b54c9 Author: fparain Date: 2012-01-09 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4f25538b54c9 7120511: Add diagnostic commands Reviewed-by: acorn, phh, dcubed, sspitsyn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 865e0817f32b Author: kamg Date: 2012-01-10 15:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/865e0817f32b Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: efdf6985a3a2 Author: kamg Date: 2012-01-12 09:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/efdf6985a3a2 Merge Changeset: 5da7201222d5 Author: kvn Date: 2012-01-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5da7201222d5 7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM Summary: Change yank_if_dead() to recursive method to remove all dead inputs. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp Changeset: e9a5e0a812c8 Author: kvn Date: 2012-01-07 13:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e9a5e0a812c8 7125896: Eliminate nested locks Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 35acf8f0a2e4 Author: kvn Date: 2012-01-10 18:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/35acf8f0a2e4 7128352: assert(obj_node == obj) failed Summary: Compare uncasted object nodes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! test/compiler/7116216/StackOverflow.java Changeset: c8d8e124380c Author: kvn Date: 2012-01-12 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/c8d8e124380c 7064302: JDK7 build 147 crashed after testing my java 6-compiled web app Summary: Don't split CMove node if it's control edge is different from split region. Reviewed-by: never ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 31a5b9aad4bc Author: jrose Date: 2012-01-13 00:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/31a5b9aad4bc Merge ! src/share/vm/runtime/arguments.cpp Changeset: bacb651cf5bf Author: tonyp Date: 2012-01-05 05:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/bacb651cf5bf 7113006: G1: excessive ergo output when an evac failure happens Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5fd354a959c5 Author: jmasa Date: 2012-01-05 21:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5fd354a959c5 Merge Changeset: 023652e49ac0 Author: johnc Date: 2011-12-23 11:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/023652e49ac0 7121496: G1: do the per-region evacuation failure handling work in parallel Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask. Reviewed-by: tonyp, iveresov ! 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/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 02838862dec8 Author: tonyp Date: 2012-01-07 00:43 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/02838862dec8 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects. Reviewed-by: johnc, ysr, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 97c00e21fecb Author: tonyp Date: 2012-01-09 23:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/97c00e21fecb 7125281: G1: heap expansion code is replicated Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 1d6185f732aa Author: brutisso Date: 2012-01-10 20:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1d6185f732aa 7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80 Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2ace1c4ee8da Author: tonyp Date: 2012-01-10 18:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ace1c4ee8da 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 9d4f4a1825e4 Author: brutisso Date: 2012-01-13 01:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9d4f4a1825e4 Merge Changeset: 5acd82522540 Author: brutisso Date: 2012-01-13 06:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5acd82522540 Merge From john.pampuch at oracle.com Wed Jan 18 10:51:26 2012 From: john.pampuch at oracle.com (John Pampuch) Date: Wed, 18 Jan 2012 10:51:26 -0800 Subject: Struct/value types + stack allocations In-Reply-To: References: Message-ID: <4F1714AE.8000302@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/9e89d66f/attachment.html From mlists at juma.me.uk Wed Jan 18 13:52:09 2012 From: mlists at juma.me.uk (Ismael Juma) Date: Wed, 18 Jan 2012 21:52:09 +0000 (UTC) Subject: Struct/value types + stack allocations References: <4F163AD3.2000108@oracle.com> Message-ID: Hi all, Vitaly Davidovich writes: > The reason I ask is because I think the achilles heal of java performance > is the memory consumption (this is something you often hear in discussions > about java performance). Agreed. I've seen and written tons of code to workaround the fact that there are no structs in the language. Examples of popular open-source projects that use parallel arrays (with much worse cache locality) to avoid objects and their memory overhead are many (Lucene, Mahout, fastutil, Trove, JGit, etc.). Best, Ismael From zhengyu.gu at oracle.com Wed Jan 18 15:25:04 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 18 Jan 2012 23:25:04 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Message-ID: <20120118232508.72AE8479E2@hg.openjdk.java.net> Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp From vitalyd at gmail.com Wed Jan 18 16:39:48 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Jan 2012 19:39:48 -0500 Subject: Struct/value types + stack allocations In-Reply-To: References: <4F163AD3.2000108@oracle.com> Message-ID: I also see my phone auto-corrected as heal instead of heel ... :) To John, albeit selfishly :), I'd love to see structs prioritized over fixnums and maybe some of the other things (reification would be great too and would go a long way in reducing bloat due to boxed numerics). Is there something akin to public voting on prioritization of features that Oracle agrees to dedicate resources to? Maybe I'm overestimating demand, but I think structs would get a lot of backing. Thanks Sent from my phone On Jan 18, 2012 5:01 PM, "Ismael Juma" wrote: > Hi all, > > Vitaly Davidovich writes: > > The reason I ask is because I think the achilles heal of java performance > > is the memory consumption (this is something you often hear in > discussions > > about java performance). > > Agreed. I've seen and written tons of code to workaround the fact that > there are > no structs in the language. Examples of popular open-source projects that > use > parallel arrays (with much worse cache locality) to avoid objects and their > memory overhead are many (Lucene, Mahout, fastutil, Trove, JGit, etc.). > > Best, > Ismael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/42cf0edc/attachment.html From john.pampuch at oracle.com Wed Jan 18 17:58:34 2012 From: john.pampuch at oracle.com (John Pampuch) Date: Wed, 18 Jan 2012 17:58:34 -0800 Subject: Struct/value types + stack allocations In-Reply-To: References: <4F163AD3.2000108@oracle.com> Message-ID: <4F1778CA.9080000@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/b316ef89/attachment.html From vitalyd at gmail.com Wed Jan 18 20:41:43 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Jan 2012 23:41:43 -0500 Subject: Struct/value types + stack allocations In-Reply-To: <4F1778CA.9080000@oracle.com> References: <4F163AD3.2000108@oracle.com> <4F1778CA.9080000@oracle.com> Message-ID: Hi John, Sorry, let me clarify - I'm not saying that this is a priority for me in the sense that it's preventing me from accomplishing something concrete. Rather, it's something that I (and I think a substantial populace of other java developers) would really like to see in java and the VM. I'm not sure how projects are selected for implementation by Oracle (e.g. how did invokedynamic, which is mostly useful for dynamic languages and not java, get Oracle engineers allocated to it? Did someone external contribute a preliminary prototype first?) but I was hoping that I could make a decent case for why something like this would be very welcomed by the java community and why I think it should get *relative* priority to other projects under consideration. Feel free to move this conversation to mlvm (or something else) as it's getting a bit exploratory. Thanks Sent from my phone On Jan 18, 2012 8:59 PM, "John Pampuch" wrote: > ** > Vitaly- > > I think contributing to OpenJDK is the best way to express your priorities > :) > > The Java language probably wouldn't have constructs in it that could > leverage a mechanism like this for a long time (if ever). Would you mind > sharing why this is a priority for you? > > -John > > On 1/18/12 4:39 PM, Vitaly Davidovich wrote: > > I also see my phone auto-corrected as heal instead of heel ... :) > > To John, albeit selfishly :), I'd love to see structs prioritized over > fixnums and maybe some of the other things (reification would be great too > and would go a long way in reducing bloat due to boxed numerics). Is there > something akin to public voting on prioritization of features that Oracle > agrees to dedicate resources to? Maybe I'm overestimating demand, but I > think structs would get a lot of backing. > > Thanks > > Sent from my phone > On Jan 18, 2012 5:01 PM, "Ismael Juma" wrote: > >> Hi all, >> >> Vitaly Davidovich writes: >> > The reason I ask is because I think the achilles heal of java >> performance >> > is the memory consumption (this is something you often hear in >> discussions >> > about java performance). >> >> Agreed. I've seen and written tons of code to workaround the fact that >> there are >> no structs in the language. Examples of popular open-source projects that >> use >> parallel arrays (with much worse cache locality) to avoid objects and >> their >> memory overhead are many (Lucene, Mahout, fastutil, Trove, JGit, etc.). >> >> Best, >> Ismael >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/6b6ea9cd/attachment.html From vitalyd at gmail.com Wed Jan 18 20:48:33 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Jan 2012 23:48:33 -0500 Subject: Struct/value types + stack allocations In-Reply-To: References: <4F163AD3.2000108@oracle.com> <4F1778CA.9080000@oracle.com> Message-ID: Sorry, forgot to ask - in terms of OpenJDK contribution, how would the process work? Would there be an Oracle "mentor" who could help guide external contributors? Or is the expectation that contributors use the mailing lists to ask questions, and try to work out implementation details on their own? Cheers Sent from my phone On Jan 18, 2012 11:41 PM, "Vitaly Davidovich" wrote: > Hi John, > > Sorry, let me clarify - I'm not saying that this is a priority for me in > the sense that it's preventing me from accomplishing something concrete. > Rather, it's something that I (and I think a substantial populace of other > java developers) would really like to see in java and the VM. I'm not sure > how projects are selected for implementation by Oracle (e.g. how did > invokedynamic, which is mostly useful for dynamic languages and not java, > get Oracle engineers allocated to it? Did someone external contribute a > preliminary prototype first?) but I was hoping that I could make a decent > case for why something like this would be very welcomed by the java > community and why I think it should get *relative* priority to other > projects under consideration. > > Feel free to move this conversation to mlvm (or something else) as it's > getting a bit exploratory. > > Thanks > > Sent from my phone > On Jan 18, 2012 8:59 PM, "John Pampuch" wrote: > >> ** >> Vitaly- >> >> I think contributing to OpenJDK is the best way to express your >> priorities :) >> >> The Java language probably wouldn't have constructs in it that could >> leverage a mechanism like this for a long time (if ever). Would you mind >> sharing why this is a priority for you? >> >> -John >> >> On 1/18/12 4:39 PM, Vitaly Davidovich wrote: >> >> I also see my phone auto-corrected as heal instead of heel ... :) >> >> To John, albeit selfishly :), I'd love to see structs prioritized over >> fixnums and maybe some of the other things (reification would be great too >> and would go a long way in reducing bloat due to boxed numerics). Is there >> something akin to public voting on prioritization of features that Oracle >> agrees to dedicate resources to? Maybe I'm overestimating demand, but I >> think structs would get a lot of backing. >> >> Thanks >> >> Sent from my phone >> On Jan 18, 2012 5:01 PM, "Ismael Juma" wrote: >> >>> Hi all, >>> >>> Vitaly Davidovich writes: >>> > The reason I ask is because I think the achilles heal of java >>> performance >>> > is the memory consumption (this is something you often hear in >>> discussions >>> > about java performance). >>> >>> Agreed. I've seen and written tons of code to workaround the fact that >>> there are >>> no structs in the language. Examples of popular open-source projects >>> that use >>> parallel arrays (with much worse cache locality) to avoid objects and >>> their >>> memory overhead are many (Lucene, Mahout, fastutil, Trove, JGit, etc.). >>> >>> Best, >>> Ismael >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/8aa5ec7a/attachment-0001.html From kirk at kodewerk.com Wed Jan 18 22:07:49 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 19 Jan 2012 07:07:49 +0100 Subject: Struct/value types + stack allocations In-Reply-To: References: <4F163AD3.2000108@oracle.com> Message-ID: <5A0BA358-4848-4A05-A379-ED58CAD5D78C@kodewerk.com> Hi all, What would this look like in the language or are we only talking about changes in the JVM? Regards, Kirk On 2012-01-19, at 1:39 AM, Vitaly Davidovich wrote: > I also see my phone auto-corrected as heal instead of heel ... :) > > To John, albeit selfishly :), I'd love to see structs prioritized over fixnums and maybe some of the other things (reification would be great too and would go a long way in reducing bloat due to boxed numerics). Is there something akin to public voting on prioritization of features that Oracle agrees to dedicate resources to? Maybe I'm overestimating demand, but I think structs would get a lot of backing. > > Thanks > > Sent from my phone > > On Jan 18, 2012 5:01 PM, "Ismael Juma" wrote: > Hi all, > > Vitaly Davidovich writes: > > The reason I ask is because I think the achilles heal of java performance > > is the memory consumption (this is something you often hear in discussions > > about java performance). > > Agreed. I've seen and written tons of code to workaround the fact that there are > no structs in the language. Examples of popular open-source projects that use > parallel arrays (with much worse cache locality) to avoid objects and their > memory overhead are many (Lucene, Mahout, fastutil, Trove, JGit, etc.). > > Best, > Ismael > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120119/658959a0/attachment.html From kirk at kodewerk.com Wed Jan 18 22:23:54 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 19 Jan 2012 07:23:54 +0100 Subject: Struct/value types + stack allocations In-Reply-To: References: <4F163AD3.2000108@oracle.com> <4F1778CA.9080000@oracle.com> Message-ID: <585E6699-2486-4DF6-A9DE-3FDF57B561E2@kodewerk.com> Hi Vitaly, Sorry, but I'm still not seeing a use case for this. What is it that you're trying to do that you can't accomplish with a class? Oracle finally released invokedynamic after a lot of discussion but only after a number of people from both in and out side of Sun/Oracle made significant efforts to make it happen. it's hard to get changes like this into the JVM and IMHO, it should/needs to be because OpenJDK shouldn't shouldn't become a grab bag of everything that's cool new and shiny. Instead there is a conservative yet responsible path to innovation and it is that path that the invokedynamic people took. Same story with closures. Not quite the same story with generics and so.... Regards, Kirk On 2012-01-19, at 5:41 AM, Vitaly Davidovich wrote: > Hi John, > > Sorry, let me clarify - I'm not saying that this is a priority for me in the sense that it's preventing me from accomplishing something concrete. Rather, it's something that I (and I think a substantial populace of other java developers) would really like to see in java and the VM. I'm not sure how projects are selected for implementation by Oracle (e.g. how did invokedynamic, which is mostly useful for dynamic languages and not java, get Oracle engineers allocated to it? Did someone external contribute a preliminary prototype first?) but I was hoping that I could make a decent case for why something like this would be very welcomed by the java community and why I think it should get *relative* priority to other projects under consideration. > > Feel free to move this conversation to mlvm (or something else) as it's getting a bit exploratory. > > Thanks > > Sent from my phone > > On Jan 18, 2012 8:59 PM, "John Pampuch" wrote: > Vitaly- > > I think contributing to OpenJDK is the best way to express your priorities :) > > The Java language probably wouldn't have constructs in it that could leverage a mechanism like this for a long time (if ever). Would you mind sharing why this is a priority for you? > > -John > > On 1/18/12 4:39 PM, Vitaly Davidovich wrote: >> >> I also see my phone auto-corrected as heal instead of heel ... :) >> >> To John, albeit selfishly :), I'd love to see structs prioritized over fixnums and maybe some of the other things (reification would be great too and would go a long way in reducing bloat due to boxed numerics). Is there something akin to public voting on prioritization of features that Oracle agrees to dedicate resources to? Maybe I'm overestimating demand, but I think structs would get a lot of backing. >> >> Thanks >> >> Sent from my phone >> >> On Jan 18, 2012 5:01 PM, "Ismael Juma" wrote: >> Hi all, >> >> Vitaly Davidovich writes: >> > The reason I ask is because I think the achilles heal of java performance >> > is the memory consumption (this is something you often hear in discussions >> > about java performance). >> >> Agreed. I've seen and written tons of code to workaround the fact that there are >> no structs in the language. Examples of popular open-source projects that use >> parallel arrays (with much worse cache locality) to avoid objects and their >> memory overhead are many (Lucene, Mahout, fastutil, Trove, JGit, etc.). >> >> Best, >> Ismael >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120119/1a28de3d/attachment.html From david.holmes at oracle.com Wed Jan 18 22:52:51 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2012 16:52:51 +1000 Subject: Struct/value types + stack allocations In-Reply-To: <585E6699-2486-4DF6-A9DE-3FDF57B561E2@kodewerk.com> References: <4F163AD3.2000108@oracle.com> <4F1778CA.9080000@oracle.com> <585E6699-2486-4DF6-A9DE-3FDF57B561E2@kodewerk.com> Message-ID: <4F17BDC3.4010207@oracle.com> I think it is time to take this off hotspot-runtime-dev ... On 19/01/2012 4:23 PM, Kirk Pepperdine wrote: > Hi Vitaly, > > Sorry, but I'm still not seeing a use case for this. What is it that > you're trying to do that you can't accomplish with a class? The "struct" has different assignment semantics to allow it to be stack allocated but not allow it to escape from a scope where it is valid. If you used a Class, and perhaps an annotation to indicate stack allocation, you'd then need additional things in place to ensure it didn't escape. The RTSJ uses runtime assignment checks which are both a performance hit and introduce a whole new range of unexpected failure modes (assignment can now throw exceptions!). Other possibilities would involve some form of escape analysis that perhaps promoted the stack-object to being a heap-object if it escaped. But as has been said this is not really a discussion for this mailing list. David ----- > Oracle finally released invokedynamic after a lot of discussion but only > after a number of people from both in and out side of Sun/Oracle made > significant efforts to make it happen. it's hard to get changes like > this into the JVM and IMHO, it should/needs to be because OpenJDK > shouldn't shouldn't become a grab bag of everything that's cool new and > shiny. Instead there is a conservative yet responsible path to > innovation and it is that path that the invokedynamic people took. Same > story with closures. Not quite the same story with generics and so.... > > Regards, > Kirk > > On 2012-01-19, at 5:41 AM, Vitaly Davidovich wrote: > >> Hi John, >> >> Sorry, let me clarify - I'm not saying that this is a priority for me >> in the sense that it's preventing me from accomplishing something >> concrete. Rather, it's something that I (and I think a substantial >> populace of other java developers) would really like to see in java >> and the VM. I'm not sure how projects are selected for implementation >> by Oracle (e.g. how did invokedynamic, which is mostly useful for >> dynamic languages and not java, get Oracle engineers allocated to it? >> Did someone external contribute a preliminary prototype first?) but I >> was hoping that I could make a decent case for why something like this >> would be very welcomed by the java community and why I think it should >> get *relative* priority to other projects under consideration. >> >> Feel free to move this conversation to mlvm (or something else) as >> it's getting a bit exploratory. >> >> Thanks >> >> Sent from my phone >> >> On Jan 18, 2012 8:59 PM, "John Pampuch" > > wrote: >> >> __ >> Vitaly- >> >> I think contributing to OpenJDK is the best way to express your >> priorities :) >> >> The Java language probably wouldn't have constructs in it that >> could leverage a mechanism like this for a long time (if ever). >> Would you mind sharing why this is a priority for you? >> >> -John >> >> On 1/18/12 4:39 PM, Vitaly Davidovich wrote: >>> >>> I also see my phone auto-corrected as heal instead of heel ... :) >>> >>> To John, albeit selfishly :), I'd love to see structs prioritized >>> over fixnums and maybe some of the other things (reification >>> would be great too and would go a long way in reducing bloat due >>> to boxed numerics). Is there something akin to public voting on >>> prioritization of features that Oracle agrees to dedicate >>> resources to? Maybe I'm overestimating demand, but I think >>> structs would get a lot of backing. >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 18, 2012 5:01 PM, "Ismael Juma" >> > wrote: >>> >>> Hi all, >>> >>> Vitaly Davidovich writes: >>> > The reason I ask is because I think the achilles heal of >>> java performance >>> > is the memory consumption (this is something you often hear >>> in discussions >>> > about java performance). >>> >>> Agreed. I've seen and written tons of code to workaround the >>> fact that there are >>> no structs in the language. Examples of popular open-source >>> projects that use >>> parallel arrays (with much worse cache locality) to avoid >>> objects and their >>> memory overhead are many (Lucene, Mahout, fastutil, Trove, >>> JGit, etc.). >>> >>> Best, >>> Ismael >>> > From mlists at juma.me.uk Thu Jan 19 00:18:10 2012 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 19 Jan 2012 08:18:10 +0000 (UTC) Subject: Struct/value types + stack allocations References: <4F163AD3.2000108@oracle.com> <4F1778CA.9080000@oracle.com> <585E6699-2486-4DF6-A9DE-3FDF57B561E2@kodewerk.com> Message-ID: Kirk Pepperdine writes: > Sorry, but I'm still not seeing a use case for this. > What is it that you're trying to do that you can't accomplish with a class? The issue is that objects have a lot of memory overhead. John Rose talks about the Complex example with a description of a potential implementation here: http://blogs.oracle.com/jrose/entry/tuples_in_the_vm Say you want to store a long array of a tuple of ints. The common way to avoid overhead these days is to use 3 int arrays with inferior cache locality to avoid the huge memory overhead (Yes, I know an alternative is to use one long array for two ints for better cache locality for the pair and I've done that at times). This is not great. "What would this look like in the language or are we only talking about changes in the JVM?" If Java the language decided to adopt this (which is not a strict requirement), then the C# model seems like the obvious one to draw inspiration from. Best, Ismael From mark.reinhold at oracle.com Thu Jan 19 21:50:10 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Jan 2012 21:50:10 -0800 (PST) Subject: JEP 136: Enhanced Verification Errors Message-ID: <20120120055010.E9EF2DC0@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/136 - Mark From paul.hohensee at oracle.com Fri Jan 20 09:13:21 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 20 Jan 2012 12:13:21 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) Message-ID: <4F19A0B1.7080100@oracle.com> Webrev here http://cr.openjdk.java.net/~phh/7091418.00/ This change defines a new Java pseudo-priority called CriticalPriority, just above MaxPriority. Compiler threads, the CMS background thread, and Java threads can have the os equivalent of this priority. On Solaris, this is the FX/60 scheduling class/priority. On other platforms, it's the same as MaxPriority's os priority. There are 3 new command line switches, all gated by UseExperimentalVMOptions. -XX:+UseCriticalJavaThreadPriority Maps Java MAX_PRIORITY to critical priority. -XX:+UseCriticalCompilerThreadPriority All compiler threads run at critical priority. -XX:+UseCriticalCMSThreadPriority The CMS background thread runs at critical priority. On Solaris, one must in addition use -XX:+UseThreadPriorities to use native priorities at all. Otherwise, Hotspot just accepts whatever Solaris decides. Before this change, the Solaris implementation could only change priorities within the process scheduling class. It didn't change scheduling classes on a per-thread basis. I added that capability and used it for the critical thread work. I also fixed a bug where we were using thr_setprio() to save the original native priority during thread creation and reading it back when the thread started via thr_getprio(). Since thr_setprio() can change the user-supplied priority, this resulted in an unintended (lower) priority being used. Thanks, Paul From azeem.jiva at oracle.com Fri Jan 20 10:18:01 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Fri, 20 Jan 2012 12:18:01 -0600 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: <4F19A0B1.7080100@oracle.com> References: <4F19A0B1.7080100@oracle.com> Message-ID: <4F19AFD9.10103@oracle.com> Looks good. Thanks for working on this. Azeem Jiva @javawithjiva On 01/20/2012 11:13 AM, Paul Hohensee wrote: > Webrev here > > http://cr.openjdk.java.net/~phh/7091418.00/ > > This change defines a new Java pseudo-priority called > CriticalPriority, just > above MaxPriority. Compiler threads, the CMS background thread, and > Java threads can have the os equivalent of this priority. On Solaris, > this is > the FX/60 scheduling class/priority. On other platforms, it's the same > as MaxPriority's os priority. > > There are 3 new command line switches, all gated by > UseExperimentalVMOptions. > > -XX:+UseCriticalJavaThreadPriority > > Maps Java MAX_PRIORITY to critical priority. > > -XX:+UseCriticalCompilerThreadPriority > > All compiler threads run at critical priority. > > -XX:+UseCriticalCMSThreadPriority > > The CMS background thread runs at critical priority. > > On Solaris, one must in addition use -XX:+UseThreadPriorities to use > native > priorities at all. Otherwise, Hotspot just accepts whatever Solaris > decides. > > Before this change, the Solaris implementation could only change > priorities > within the process scheduling class. It didn't change scheduling > classes on > a per-thread basis. I added that capability and used it for the > critical thread > work. I also fixed a bug where we were using thr_setprio() to save the > original native priority during thread creation and reading it back when > the thread started via thr_getprio(). Since thr_setprio() can change the > user-supplied priority, this resulted in an unintended (lower) priority > being used. > > Thanks, > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120120/51888687/attachment.html From paul.hohensee at oracle.com Fri Jan 20 13:26:02 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 20 Jan 2012 16:26:02 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: <4F19AFD9.10103@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F19AFD9.10103@oracle.com> Message-ID: <4F19DBEA.6010105@oracle.com> Thanks for the review, Paul On 1/20/12 1:18 PM, Azeem Jiva wrote: > Looks good. Thanks for working on this. > Azeem Jiva > @javawithjiva > > On 01/20/2012 11:13 AM, Paul Hohensee wrote: >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7091418.00/ >> >> This change defines a new Java pseudo-priority called >> CriticalPriority, just >> above MaxPriority. Compiler threads, the CMS background thread, and >> Java threads can have the os equivalent of this priority. On >> Solaris, this is >> the FX/60 scheduling class/priority. On other platforms, it's the same >> as MaxPriority's os priority. >> >> There are 3 new command line switches, all gated by >> UseExperimentalVMOptions. >> >> -XX:+UseCriticalJavaThreadPriority >> >> Maps Java MAX_PRIORITY to critical priority. >> >> -XX:+UseCriticalCompilerThreadPriority >> >> All compiler threads run at critical priority. >> >> -XX:+UseCriticalCMSThreadPriority >> >> The CMS background thread runs at critical priority. >> >> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >> native >> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >> decides. >> >> Before this change, the Solaris implementation could only change >> priorities >> within the process scheduling class. It didn't change scheduling >> classes on >> a per-thread basis. I added that capability and used it for the >> critical thread >> work. I also fixed a bug where we were using thr_setprio() to save the >> original native priority during thread creation and reading it back when >> the thread started via thr_getprio(). Since thr_setprio() can change >> the >> user-supplied priority, this resulted in an unintended (lower) priority >> being used. >> >> Thanks, >> >> Paul >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120120/158dd2f9/attachment.html From john.coomes at oracle.com Sat Jan 21 15:27:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:27:04 +0000 Subject: hg: hsx/hotspot-emb: 2 new changesets Message-ID: <20120121232704.8BC6147102@hg.openjdk.java.net> Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:27:09 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:27:09 +0000 Subject: hg: hsx/hotspot-emb/corba: 2 new changesets Message-ID: <20120121232712.9AADF47103@hg.openjdk.java.net> Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:27:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:27:17 +0000 Subject: hg: hsx/hotspot-emb/jaxp: 2 new changesets Message-ID: <20120121232718.191C447104@hg.openjdk.java.net> Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:27:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:27:23 +0000 Subject: hg: hsx/hotspot-emb/jaxws: 4 new changesets Message-ID: <20120121232723.9331C47105@hg.openjdk.java.net> Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:27:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:27:53 +0000 Subject: hg: hsx/hotspot-emb/jdk: 23 new changesets Message-ID: <20120121233156.AD0284710B@hg.openjdk.java.net> Changeset: 1c4fffa22930 Author: okutsu Date: 2011-12-21 17:09 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/1c4fffa22930 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: b1814b3ea6d3 Author: michaelm Date: 2011-12-21 10:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b1814b3ea6d3 7078386: NetworkInterface.getNetworkInterfaces() may return corrupted results on linux Reviewed-by: michaelm, alanb, chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/NetworkInterface.c Changeset: a9dfdc523c2c Author: valeriep Date: 2011-12-21 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a9dfdc523c2c 6839886: Array overrun in pkcs11 Summary: Fix the wrong value when dealing w/ month and day. Reviewed-by: mullan ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: 11698dedbe79 Author: weijun Date: 2011-12-22 15:35 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/11698dedbe79 7122169: TcpTimeout fail for various reasons Reviewed-by: alanb ! test/sun/security/krb5/auto/TcpTimeout.java Changeset: 559e07ed1f56 Author: alanb Date: 2011-12-22 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/559e07ed1f56 7076310: (file) AclEntry.Builder setFlags throws IllegalArgumentException if set argument is empty Reviewed-by: alanb Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/nio/file/attribute/AclEntry.java + test/java/nio/file/attribute/AclEntry/EmptySet.java Changeset: 3c1ab134db71 Author: dcubed Date: 2011-12-22 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3c1ab134db71 7121600: Instrumentation.redefineClasses() leaks class bytes Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253. Reviewed-by: acorn, poonam ! src/share/instrument/JPLISAgent.c + test/java/lang/instrument/BigClass.java + test/java/lang/instrument/MakeJAR4.sh + test/java/lang/instrument/RedefineBigClass.sh + test/java/lang/instrument/RedefineBigClassAgent.java + test/java/lang/instrument/RedefineBigClassApp.java + test/java/lang/instrument/RetransformBigClass.sh + test/java/lang/instrument/RetransformBigClassAgent.java + test/java/lang/instrument/RetransformBigClassApp.java Changeset: 437255d15e76 Author: lana Date: 2011-12-28 10:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/437255d15e76 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 3a7ea63302f8 Author: smarks Date: 2011-12-29 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3a7ea63302f8 7122061: add -Xlint:all -Werror to warning-free build steps Reviewed-by: chegar, alanb, dholmes, ohair ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/java/instrument/Makefile ! make/java/rmi/Makefile ! make/java/text/base/Makefile ! make/java/text/bidi/Makefile ! make/java/util/Makefile ! make/javax/accessibility/Makefile ! make/javax/others/Makefile ! make/javax/security/Makefile ! make/jpda/tty/Makefile ! make/sun/launcher/Makefile ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/util/Makefile Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/81a2629aa2a2 Merge From john.coomes at oracle.com Sat Jan 21 15:34:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:34:50 +0000 Subject: hg: hsx/hotspot-rt: 2 new changesets Message-ID: <20120121233450.F40854710C@hg.openjdk.java.net> Changeset: 7ad075c80995 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/7ad075c80995 Added tag jdk8-b21 for changeset cc771d92284f ! .hgtags Changeset: 60d6f64a86b1 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/60d6f64a86b1 Added tag jdk8-b22 for changeset 7ad075c80995 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:34:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:34:56 +0000 Subject: hg: hsx/hotspot-rt/corba: 2 new changesets Message-ID: <20120121233459.24FAC4710D@hg.openjdk.java.net> Changeset: a11d0062c445 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/a11d0062c445 Added tag jdk8-b21 for changeset f157fc2a71a3 ! .hgtags Changeset: 5218eb256658 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/5218eb256658 Added tag jdk8-b22 for changeset a11d0062c445 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:35:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:35:04 +0000 Subject: hg: hsx/hotspot-rt/jaxp: 2 new changesets Message-ID: <20120121233504.CAE9B4710E@hg.openjdk.java.net> Changeset: cf9d6ec44f89 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/cf9d6ec44f89 Added tag jdk8-b21 for changeset d41eeadf5c13 ! .hgtags Changeset: 95102fd33418 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/95102fd33418 Added tag jdk8-b22 for changeset cf9d6ec44f89 ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:35:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:35:10 +0000 Subject: hg: hsx/hotspot-rt/jaxws: 4 new changesets Message-ID: <20120121233510.589E34710F@hg.openjdk.java.net> Changeset: e67d51254533 Author: ohair Date: 2012-01-09 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/e67d51254533 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar Reviewed-by: dholmes ! build-defs.xml Changeset: c266cab0e3ff Author: katleman Date: 2012-01-11 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/c266cab0e3ff Merge Changeset: 8d3df89b0f2d Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/8d3df89b0f2d Added tag jdk8-b21 for changeset c266cab0e3ff ! .hgtags Changeset: 25ce7a000487 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/25ce7a000487 Added tag jdk8-b22 for changeset 8d3df89b0f2d ! .hgtags From john.coomes at oracle.com Sat Jan 21 15:35:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 21 Jan 2012 23:35:40 +0000 Subject: hg: hsx/hotspot-rt/jdk: 23 new changesets Message-ID: <20120121233953.CCB6D47111@hg.openjdk.java.net> Changeset: 1c4fffa22930 Author: okutsu Date: 2011-12-21 17:09 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1c4fffa22930 7122054: (tz) Windows-only: tzmappings needs update for KB2633952 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: b1814b3ea6d3 Author: michaelm Date: 2011-12-21 10:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b1814b3ea6d3 7078386: NetworkInterface.getNetworkInterfaces() may return corrupted results on linux Reviewed-by: michaelm, alanb, chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/NetworkInterface.c Changeset: a9dfdc523c2c Author: valeriep Date: 2011-12-21 14:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a9dfdc523c2c 6839886: Array overrun in pkcs11 Summary: Fix the wrong value when dealing w/ month and day. Reviewed-by: mullan ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: 11698dedbe79 Author: weijun Date: 2011-12-22 15:35 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11698dedbe79 7122169: TcpTimeout fail for various reasons Reviewed-by: alanb ! test/sun/security/krb5/auto/TcpTimeout.java Changeset: 559e07ed1f56 Author: alanb Date: 2011-12-22 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/559e07ed1f56 7076310: (file) AclEntry.Builder setFlags throws IllegalArgumentException if set argument is empty Reviewed-by: alanb Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/nio/file/attribute/AclEntry.java + test/java/nio/file/attribute/AclEntry/EmptySet.java Changeset: 3c1ab134db71 Author: dcubed Date: 2011-12-22 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3c1ab134db71 7121600: Instrumentation.redefineClasses() leaks class bytes Summary: Call JNI ReleaseByteArrayElements() on memory returned by JNI GetByteArrayElements(). Also push test for 7122253. Reviewed-by: acorn, poonam ! src/share/instrument/JPLISAgent.c + test/java/lang/instrument/BigClass.java + test/java/lang/instrument/MakeJAR4.sh + test/java/lang/instrument/RedefineBigClass.sh + test/java/lang/instrument/RedefineBigClassAgent.java + test/java/lang/instrument/RedefineBigClassApp.java + test/java/lang/instrument/RetransformBigClass.sh + test/java/lang/instrument/RetransformBigClassAgent.java + test/java/lang/instrument/RetransformBigClassApp.java Changeset: 437255d15e76 Author: lana Date: 2011-12-28 10:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/437255d15e76 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 3a7ea63302f8 Author: smarks Date: 2011-12-29 16:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3a7ea63302f8 7122061: add -Xlint:all -Werror to warning-free build steps Reviewed-by: chegar, alanb, dholmes, ohair ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/java/instrument/Makefile ! make/java/rmi/Makefile ! make/java/text/base/Makefile ! make/java/text/bidi/Makefile ! make/java/util/Makefile ! make/javax/accessibility/Makefile ! make/javax/others/Makefile ! make/javax/security/Makefile ! make/jpda/tty/Makefile ! make/sun/launcher/Makefile ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/util/Makefile Changeset: 5aeefe0e5d8c Author: chegar Date: 2012-01-01 09:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5aeefe0e5d8c 7125055: ContentHandler.getContent API changed in error Reviewed-by: alanb ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java Changeset: 8952a5f494f9 Author: ksrini Date: 2012-01-03 08:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8952a5f494f9 7123582: (launcher) display the -version and -XshowSettings Reviewed-by: alanb ! src/share/bin/java.c ! test/tools/launcher/Settings.java Changeset: 5e34726cb4bb Author: ksrini Date: 2012-01-03 08:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/5e34726cb4bb 7124443: (launcher) test DefaultsLocaleTest fails with Windows shells. Reviewed-by: darcy ! test/tools/launcher/DefaultLocaleTest.java - test/tools/launcher/DefaultLocaleTest.sh + test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 0194fe5ca404 Author: fparain Date: 2012-01-04 03:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0194fe5ca404 7104647: Adding a diagnostic command framework Reviewed-by: mchung, dholmes ! make/common/Release.gmk ! make/java/management/mapfile-vers ! make/launchers/Makefile ! make/sun/tools/Makefile + src/linux/doc/man/jcmd.1 + src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java + src/share/classes/com/sun/management/DiagnosticCommandInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java + src/share/classes/sun/tools/jcmd/Arguments.java + src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/HotSpotDiagnostic.c + src/solaris/doc/sun/man/man1/jcmd.1 + test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java + test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java ! test/sun/tools/common/CommonSetup.sh + test/sun/tools/jcmd/dcmd-script.txt + test/sun/tools/jcmd/help_help.out + test/sun/tools/jcmd/jcmd-Defaults.sh + test/sun/tools/jcmd/jcmd-f.sh + test/sun/tools/jcmd/jcmd-help-help.sh + test/sun/tools/jcmd/jcmd-help.sh + test/sun/tools/jcmd/jcmd-pid.sh + test/sun/tools/jcmd/jcmd_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output1.awk + test/sun/tools/jcmd/jcmd_pid_Output2.awk + test/sun/tools/jcmd/usage.out Changeset: 38a318502e19 Author: lana Date: 2012-01-04 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/38a318502e19 Merge ! make/common/Release.gmk - test/tools/launcher/DefaultLocaleTest.sh Changeset: 93ab1df09d11 Author: lana Date: 2012-01-09 19:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/93ab1df09d11 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: ddb97d4fa83d Author: ohair Date: 2012-01-04 17:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ddb97d4fa83d 7127104: Build issue with prtconf and zones, also using := to avoid extra execs Reviewed-by: katleman ! make/common/shared/Platform.gmk Changeset: 7c8c16f2c05e Author: ohair Date: 2012-01-09 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7c8c16f2c05e 7128320: Fix freetype sanity check to make it more generic Reviewed-by: luchsh, katleman Contributed-by: Jonathan Lu ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/tools/freetypecheck/Makefile Changeset: 664fa4fb0ee4 Author: katleman Date: 2012-01-11 16:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/664fa4fb0ee4 Merge Changeset: dda27c73d8db Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dda27c73d8db Added tag jdk8-b21 for changeset 664fa4fb0ee4 ! .hgtags Changeset: 76bfd08d8cc5 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76bfd08d8cc5 Added tag jdk8-b22 for changeset dda27c73d8db ! .hgtags Changeset: db189e2f3cdb Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/db189e2f3cdb 7117167: Misc warnings in java.lang.invoke and sun.invoke.* Reviewed-by: smarks ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 01014596ada1 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/01014596ada1 7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init Summary: Use correct access token for unreflecting MHs where setAccessible(true) Reviewed-by: never, twisti ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 92d2cba30f08 Author: jrose Date: 2012-01-18 17:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/92d2cba30f08 7030453: JSR 292 ClassValue.get method is too slow Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread. Reviewed-by: twisti, mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! test/java/lang/invoke/ClassValueTest.java Changeset: 81a2629aa2a2 Author: amurillo Date: 2012-01-20 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/81a2629aa2a2 Merge From ysr1729 at gmail.com Sat Jan 21 21:27:54 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sat, 21 Jan 2012 21:27:54 -0800 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: <4F19A0B1.7080100@oracle.com> References: <4F19A0B1.7080100@oracle.com> Message-ID: Hi Paul -- First a couple of high level questions: Is it the intention that just the CMS thread run at critical priority? In the event that one is running with multiple concurrent threads, is the intention that some subset of these also run at critical priority or is this narrowly targeted at this time to the case of a single GC thread? (One related question is whether the Solaris API is robust under abuse by having CT priority applied to "too many" threads -- have you tested for the case where we run with all Java threads designated at critical priority.) Obviously, all those comments apply also to G1 for which this work has not yet been done, but looks like what one would ideally want is UseCriticalPriorityForConcurrentGC or some such for general flag to cover CMS and G1 equally (with perhaps specific suboptions specific to each). thanks. -- ramki On Fri, Jan 20, 2012 at 9:13 AM, Paul Hohensee wrote: > Webrev here > > http://cr.openjdk.java.net/~**phh/7091418.00/ > > This change defines a new Java pseudo-priority called CriticalPriority, > just > above MaxPriority. Compiler threads, the CMS background thread, and > Java threads can have the os equivalent of this priority. On Solaris, > this is > the FX/60 scheduling class/priority. On other platforms, it's the same > as MaxPriority's os priority. > > There are 3 new command line switches, all gated by > UseExperimentalVMOptions. > > -XX:+**UseCriticalJavaThreadPriority > > Maps Java MAX_PRIORITY to critical priority. > > -XX:+**UseCriticalCompilerThreadPrior**ity > > All compiler threads run at critical priority. > > -XX:+**UseCriticalCMSThreadPriority > > The CMS background thread runs at critical priority. > > On Solaris, one must in addition use -XX:+UseThreadPriorities to use native > priorities at all. Otherwise, Hotspot just accepts whatever Solaris > decides. > > Before this change, the Solaris implementation could only change priorities > within the process scheduling class. It didn't change scheduling classes > on > a per-thread basis. I added that capability and used it for the critical > thread > work. I also fixed a bug where we were using thr_setprio() to save the > original native priority during thread creation and reading it back when > the thread started via thr_getprio(). Since thr_setprio() can change the > user-supplied priority, this resulted in an unintended (lower) priority > being used. > > Thanks, > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120121/ef9f0da0/attachment.html From paul.hohensee at oracle.com Sun Jan 22 03:56:00 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Sun, 22 Jan 2012 06:56:00 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: References: <4F19A0B1.7080100@oracle.com> Message-ID: <4F1BF950.5020100@oracle.com> It the intention that just the CMS background thread (of all the GC threads) run at critical priority. That's because it's the serial bottleneck in CMS. At least, that's what it appears to me to be: pls correct me if I'm wrong. The Solaris guys tell me that Solaris is indeed robust under having more critical threads than there are cores. I don't know that we need critical thread priority for G1, since we intend that everything in G1 be parallel. If we ever change CMS so that the serial parts go parallel, then we wouldn't need critical thread priority for CMS. Paul On 1/22/12 12:27 AM, Srinivas Ramakrishna wrote: > Hi Paul -- First a couple of high level questions: > > Is it the intention that just the CMS thread run at critical priority? > In the event that one is running > with multiple concurrent threads, is the intention that some subset of > these also run at critical priority > or is this narrowly targeted at this time to the case of a single GC > thread? (One related question is whether > the Solaris API is robust under abuse by having CT priority applied to > "too many" threads -- have you > tested for the case where we run with all Java threads designated at > critical priority.) > > Obviously, all those comments apply also to G1 for which this work has > not yet been done, but looks > like what one would ideally want is UseCriticalPriorityForConcurrentGC > or some such for general flag to > cover CMS and G1 equally (with perhaps specific suboptions specific to > each). > > thanks. > -- ramki > > > On Fri, Jan 20, 2012 at 9:13 AM, Paul Hohensee > > wrote: > > Webrev here > > http://cr.openjdk.java.net/~phh/7091418.00/ > > > This change defines a new Java pseudo-priority called > CriticalPriority, just > above MaxPriority. Compiler threads, the CMS background thread, and > Java threads can have the os equivalent of this priority. On > Solaris, this is > the FX/60 scheduling class/priority. On other platforms, it's the > same > as MaxPriority's os priority. > > There are 3 new command line switches, all gated by > UseExperimentalVMOptions. > > -XX:+UseCriticalJavaThreadPriority > > Maps Java MAX_PRIORITY to critical priority. > > -XX:+UseCriticalCompilerThreadPriority > > All compiler threads run at critical priority. > > -XX:+UseCriticalCMSThreadPriority > > The CMS background thread runs at critical priority. > > On Solaris, one must in addition use -XX:+UseThreadPriorities to > use native > priorities at all. Otherwise, Hotspot just accepts whatever > Solaris decides. > > Before this change, the Solaris implementation could only change > priorities > within the process scheduling class. It didn't change scheduling > classes on > a per-thread basis. I added that capability and used it for the > critical thread > work. I also fixed a bug where we were using thr_setprio() to > save the > original native priority during thread creation and reading it > back when > the thread started via thr_getprio(). Since thr_setprio() can > change the > user-supplied priority, this resulted in an unintended (lower) > priority > being used. > > Thanks, > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120122/6ce1bbaa/attachment-0001.html From paul.hohensee at oracle.com Sun Jan 22 05:17:56 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Sun, 22 Jan 2012 08:17:56 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: <4F1BF950.5020100@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1BF950.5020100@oracle.com> Message-ID: <4F1C0C84.4020606@oracle.com> "It the" -> "It's the" Paul On 1/22/12 6:56 AM, Paul Hohensee wrote: > It the intention that just the CMS background thread (of all the GC > threads) > run at critical priority. That's because it's the serial bottleneck > in CMS. At > least, that's what it appears to me to be: pls correct me if I'm wrong. > > The Solaris guys tell me that Solaris is indeed robust under having more > critical threads than there are cores. > > I don't know that we need critical thread priority for G1, since we intend > that everything in G1 be parallel. If we ever change CMS so that the > serial > parts go parallel, then we wouldn't need critical thread priority for CMS. > > Paul > > On 1/22/12 12:27 AM, Srinivas Ramakrishna wrote: >> Hi Paul -- First a couple of high level questions: >> >> Is it the intention that just the CMS thread run at critical >> priority? In the event that one is running >> with multiple concurrent threads, is the intention that some subset >> of these also run at critical priority >> or is this narrowly targeted at this time to the case of a single GC >> thread? (One related question is whether >> the Solaris API is robust under abuse by having CT priority applied >> to "too many" threads -- have you >> tested for the case where we run with all Java threads designated at >> critical priority.) >> >> Obviously, all those comments apply also to G1 for which this work >> has not yet been done, but looks >> like what one would ideally want is >> UseCriticalPriorityForConcurrentGC or some such for general flag to >> cover CMS and G1 equally (with perhaps specific suboptions specific >> to each). >> >> thanks. >> -- ramki >> >> >> On Fri, Jan 20, 2012 at 9:13 AM, Paul Hohensee >> > wrote: >> >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7091418.00/ >> >> >> This change defines a new Java pseudo-priority called >> CriticalPriority, just >> above MaxPriority. Compiler threads, the CMS background thread, and >> Java threads can have the os equivalent of this priority. On >> Solaris, this is >> the FX/60 scheduling class/priority. On other platforms, it's >> the same >> as MaxPriority's os priority. >> >> There are 3 new command line switches, all gated by >> UseExperimentalVMOptions. >> >> -XX:+UseCriticalJavaThreadPriority >> >> Maps Java MAX_PRIORITY to critical priority. >> >> -XX:+UseCriticalCompilerThreadPriority >> >> All compiler threads run at critical priority. >> >> -XX:+UseCriticalCMSThreadPriority >> >> The CMS background thread runs at critical priority. >> >> On Solaris, one must in addition use -XX:+UseThreadPriorities to >> use native >> priorities at all. Otherwise, Hotspot just accepts whatever >> Solaris decides. >> >> Before this change, the Solaris implementation could only change >> priorities >> within the process scheduling class. It didn't change scheduling >> classes on >> a per-thread basis. I added that capability and used it for the >> critical thread >> work. I also fixed a bug where we were using thr_setprio() to >> save the >> original native priority during thread creation and reading it >> back when >> the thread started via thr_getprio(). Since thr_setprio() can >> change the >> user-supplied priority, this resulted in an unintended (lower) >> priority >> being used. >> >> Thanks, >> >> Paul >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120122/e9014e14/attachment.html From ysr1729 at gmail.com Sun Jan 22 10:11:13 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sun, 22 Jan 2012 10:11:13 -0800 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: <4F1BF950.5020100@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1BF950.5020100@oracle.com> Message-ID: Thanks Paul; yes, what you say makes sense about the serial parts becoming a possible bottleneck that might require this kind of intervention. So I am good with your current change. I am curious if there are any performance numbers that may be available for sharing here (i understand that may not be possible, perhaps because this is still somewhat of an experiment in progress). Thanks for the work! -- ramki On Sun, Jan 22, 2012 at 3:56 AM, Paul Hohensee wrote: > It the intention that just the CMS background thread (of all the GC > threads) > run at critical priority. That's because it's the serial bottleneck in > CMS. At > least, that's what it appears to me to be: pls correct me if I'm wrong. > > The Solaris guys tell me that Solaris is indeed robust under having more > critical threads than there are cores. > > I don't know that we need critical thread priority for G1, since we intend > that everything in G1 be parallel. If we ever change CMS so that the > serial > parts go parallel, then we wouldn't need critical thread priority for CMS. > > Paul > > > On 1/22/12 12:27 AM, Srinivas Ramakrishna wrote: > > Hi Paul -- First a couple of high level questions: > > Is it the intention that just the CMS thread run at critical priority? In > the event that one is running > with multiple concurrent threads, is the intention that some subset of > these also run at critical priority > or is this narrowly targeted at this time to the case of a single GC > thread? (One related question is whether > the Solaris API is robust under abuse by having CT priority applied to > "too many" threads -- have you > tested for the case where we run with all Java threads designated at > critical priority.) > > Obviously, all those comments apply also to G1 for which this work has not > yet been done, but looks > like what one would ideally want is UseCriticalPriorityForConcurrentGC or > some such for general flag to > cover CMS and G1 equally (with perhaps specific suboptions specific to > each). > > thanks. > -- ramki > > > On Fri, Jan 20, 2012 at 9:13 AM, Paul Hohensee wrote: > >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7091418.00/ >> >> This change defines a new Java pseudo-priority called CriticalPriority, >> just >> above MaxPriority. Compiler threads, the CMS background thread, and >> Java threads can have the os equivalent of this priority. On Solaris, >> this is >> the FX/60 scheduling class/priority. On other platforms, it's the same >> as MaxPriority's os priority. >> >> There are 3 new command line switches, all gated by >> UseExperimentalVMOptions. >> >> -XX:+UseCriticalJavaThreadPriority >> >> Maps Java MAX_PRIORITY to critical priority. >> >> -XX:+UseCriticalCompilerThreadPriority >> >> All compiler threads run at critical priority. >> >> -XX:+UseCriticalCMSThreadPriority >> >> The CMS background thread runs at critical priority. >> >> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >> native >> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >> decides. >> >> Before this change, the Solaris implementation could only change >> priorities >> within the process scheduling class. It didn't change scheduling classes >> on >> a per-thread basis. I added that capability and used it for the critical >> thread >> work. I also fixed a bug where we were using thr_setprio() to save the >> original native priority during thread creation and reading it back when >> the thread started via thr_getprio(). Since thr_setprio() can change the >> user-supplied priority, this resulted in an unintended (lower) priority >> being used. >> >> Thanks, >> >> Paul >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120122/7884f9d7/attachment.html From david.holmes at oracle.com Sun Jan 22 16:39:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 23 Jan 2012 10:39:41 +1000 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F19A0B1.7080100@oracle.com> References: <4F19A0B1.7080100@oracle.com> Message-ID: <4F1CAC4D.9080509@oracle.com> Hi Paul, The meta-comment here is that there needs to be a clear description of what "critical priority" means and what constraints there are on setting it to some OS specific value. For example the current changes uses the FX scheduling class, but what if someone used the RT scheduling class instead? Would that work? Probably not, in which case we should document that this selection of the "critical priority" is not an arbitrary choice that can be made. Even for FX/60 I'm not certain that using this for Java threads might not prevent safepoints from being reached or induce some other form of livelock. On 21/01/2012 3:13 AM, Paul Hohensee wrote: > Webrev here > > http://cr.openjdk.java.net/~phh/7091418.00/ > > This change defines a new Java pseudo-priority called > CriticalPriority, just above MaxPriority. Compiler threads, the CMS > background thread, and Java threads can have the os equivalent of > this priority. On Solaris, this is the FX/60 scheduling > class/priority. On other platforms, it's the same as MaxPriority's os > priority. For reference this is why the mapping to FX/60 has been proposed: http://blogs.oracle.com/observatory/entry/critical_threads_optimization I still don't fully grok what this optimization does in a general sense and it seems to be geared to providing better single-threaded performance on near-idle systems - which doesn't make any sense to me in a JVM context. But FX/60 also gives you true priority over TS/IA threads so that may be where the gain comes from. I wonder if any experiments were actually done using FX/59 rather than the "magical" FX/60? > There are 3 new command line switches, all gated by > UseExperimentalVMOptions. > > -XX:+UseCriticalJavaThreadPriority > > Maps Java MAX_PRIORITY to critical priority. I found what you have done here to be very confusing. The only place UseCriticalJavaThreadPriority is used is on Solaris. There you re-map the priority mapping for priority 10 to the "critical priority" as described. On all platforms you added an entry to the priority mapping table(s) for a non-existent Java priority 11. This provides a way to lookup the "critical priority" for the CMS/Compiler threads - in essence use of critical priority for those threads says "pretend these have Java priority 11" and then you've added a mapping for a priority 11 that is the same as for priority 10 except on Solaris. On Solaris you had to use a sentinel value to say "this really means use the "critical priority" because there is no way to convey a change of scheduling class. It seems to me that we are pretending to have "critical priority" support on all platforms when in reality we don't. If we want to go that way then we should extend it to the UseCriticalJavaThreadPriority case as well. It should be all or nothing. Further it needs to be made clear that these may still be dependent on the value of ThreadPriorityPolicy. > -XX:+UseCriticalCompilerThreadPriority > > All compiler threads run at critical priority. It should be more clear that UseCriticalCompilerThreadPriority only applies if CompilerThreadPriority is not set. Perhaps there should also be a startup check for both being used? Thinking more though we really shouldn't need both flags. The basic problem is that the current "api" only supports setting a simple number and to use FX/60 also requires a change of scheduling class. You could add a hack that CompilerThreadPriority=60 means FX/60. Or, as I've suggested in past email we could generalize the format of the option to allow both a scheduling class designator and priority to be passed - that would be a more general mechanism. Adding a psuedo-priority 11 is just means to work within the current limitations of the priority scheme. > -XX:+UseCriticalCMSThreadPriority > > The CMS background thread runs at critical priority. This doesn't make a lot of sense when you consider the comments in src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp which still states: "Priority should be just less than that of VMThread" This seems to indicate that we don't really understand what the priority relationship between GC threads and the VMThread should be. Should we be able to run the VMThread at FX/60? > On Solaris, one must in addition use -XX:+UseThreadPriorities to use native > priorities at all. Otherwise, Hotspot just accepts whatever Solaris > decides. Is it also dependent on the value of ThreadPriorityPolicy? Should it be? Does it make sense to use it with either policy value? > > Before this change, the Solaris implementation could only change priorities > within the process scheduling class. It didn't change scheduling classes on > a per-thread basis. I added that capability and used it for the critical > thread > work. I also fixed a bug where we were using thr_setprio() to save the > original native priority during thread creation and reading it back when > the thread started via thr_getprio(). Since thr_setprio() can change the > user-supplied priority, this resulted in an unintended (lower) priority > being used. I don't quite follow this. We used thr_setprio to set the native OS priority, and we then read it back using thr_getprio and then used that to pass to thr_setprio again (and also set_lwp_priority). If thr_setprio can change the user-supplied priority then it can make that change on the second call too can't it? Does the fact we now have a lwp affect this? I'm curious about the fact we still both use thr_setprio and set the LWP priority directly ??? Cheers, David > Thanks, > > Paul > From fredrik.ohrstrom at oracle.com Mon Jan 23 09:05:43 2012 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 23 Jan 2012 18:05:43 +0100 Subject: Patch to enable ccache to work most of the time. Message-ID: <4F1D9367.3000801@oracle.com> Simple fix to prevent the version define to be passed to all Hotspot c++ files. Since the version define contains a time and date (when the build nr is not set),the ccache can only be used for 1 minute after the build.... This fix makes sure that only vm_version.o depends on the version number. Thus all the other files can be ccached efficiently. http://cr.openjdk.java.net/~ohrstrom/webrev-2012-01-23-prep-for-ccache/ Jim, can you make me an author on HSX? Robert, can you sponsor me? //Fredrik From kelly.ohair at oracle.com Mon Jan 23 09:42:48 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 23 Jan 2012 09:42:48 -0800 Subject: Patch to enable ccache to work most of the time. In-Reply-To: <4F1D9367.3000801@oracle.com> References: <4F1D9367.3000801@oracle.com> Message-ID: <5F13B1B5-6B51-4275-AC7A-781836F9B727@oracle.com> I can be a reviewer. Looks good. And I appreciate the makefile comment :^) I think this also explains some strange behaviors with pre-compiled headers. If the version number definition gets into the pre-compiled header file, it becomes invalid with any version string change and can cause build failures, or at least on windows it has. -kto On Jan 23, 2012, at 9:05 AM, Fredrik ?hrstr?m wrote: > Simple fix to prevent the version define to be passed to all Hotspot c++ files. > > Since the version define contains a time and date (when the build nr is not set),the ccache can only be used for 1 minute after the build.... > > This fix makes sure that only vm_version.o depends on the version number. Thus all the other files can be ccached efficiently. > > http://cr.openjdk.java.net/~ohrstrom/webrev-2012-01-23-prep-for-ccache/ > > Jim, can you make me an author on HSX? > > Robert, can you sponsor me? > > //Fredrik > From paul.hohensee at oracle.com Mon Jan 23 11:11:23 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 23 Jan 2012 14:11:23 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1CAC4D.9080509@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> Message-ID: <4F1DB0DB.7040409@oracle.com> Thanks for the review. Inline... On 1/22/12 7:39 PM, David Holmes wrote: > Hi Paul, > > The meta-comment here is that there needs to be a clear description of > what "critical priority" means and what constraints there are on > setting it to some OS specific value. For example the current changes > uses the FX scheduling class, but what if someone used the RT > scheduling class instead? Would that work? Probably not, in which case > we should document that this selection of the "critical priority" is > not an arbitrary choice that can be made. > > Even for FX/60 I'm not certain that using this for Java threads might > not prevent safepoints from being reached or induce some other form of > livelock. I added material to the Comments field of the CR. I don't think there's a livelock problem with Java threads, because Solaris takes FX60 as advisory, not as a command. All that should happen is that a critical priority Java thread will get to the safepoint earlier than non-critical ones. I suppose it's possible for critical priority CMS or compiler threads to starve non-critical Java threads, but they run at NearMaxPriority by default now, which can do the same thing. This is definitely an "expert-only" feature though, which is why it's experimental for the time being. > > On 21/01/2012 3:13 AM, Paul Hohensee wrote: >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7091418.00/ >> >> This change defines a new Java pseudo-priority called >> CriticalPriority, just above MaxPriority. Compiler threads, the CMS >> background thread, and Java threads can have the os equivalent of >> this priority. On Solaris, this is the FX/60 scheduling >> class/priority. On other platforms, it's the same as MaxPriority's os >> priority. > > For reference this is why the mapping to FX/60 has been proposed: > > http://blogs.oracle.com/observatory/entry/critical_threads_optimization > > I still don't fully grok what this optimization does in a general > sense and it seems to be geared to providing better single-threaded > performance on near-idle systems - which doesn't make any sense to me > in a JVM context. But FX/60 also gives you true priority over TS/IA > threads so that may be where the gain comes from. I wonder if any > experiments were actually done using FX/59 rather than the "magical" > FX/60? It's meant to be Solaris-Sparc-specific, but it was easier to implement as a general feature than to specialize it. Given enough cores, FX60 does indeed give you true priority over TS/IA threads. If there aren't enough cores to run both critical threads in single-thread mode and non-critical threads at the same time, Solaris will allow non-critical threads to run on the same core(s) as critical ones. I don't know of any FX59 experiments, but given the amount of work it's taken for the Solaris folks to get FX60 working, I doubt using it would have any positive effect. > >> There are 3 new command line switches, all gated by >> UseExperimentalVMOptions. >> >> -XX:+UseCriticalJavaThreadPriority >> >> Maps Java MAX_PRIORITY to critical priority. > > I found what you have done here to be very confusing. The only place > UseCriticalJavaThreadPriority is used is on Solaris. There you re-map > the priority mapping for priority 10 to the "critical priority" as > described. It's actually used on the other OSs. It just maps to MaxPriority on those. > > On all platforms you added an entry to the priority mapping table(s) > for a non-existent Java priority 11. This provides a way to lookup the > "critical priority" for the CMS/Compiler threads - in essence use of > critical priority for those threads says "pretend these have Java > priority 11" and then you've added a mapping for a priority 11 that is > the same as for priority 10 except on Solaris. On Solaris you had to > use a sentinel value to say "this really means use the "critical > priority" because there is no way to convey a change of scheduling class. > > It seems to me that we are pretending to have "critical priority" > support on all platforms when in reality we don't. If we want to go > that way then we should extend it to the UseCriticalJavaThreadPriority > case as well. It should be all or nothing. Extend it beyond making CriticalPriority == MaxPriority on non-Solaris platforms? I.e., we can now change the compiler and CMS thread priority to MaxPriority on non-Solaris platforms. I don't know how to make CriticalPriority higher than that on non-Solaris platforms. > > Further it needs to be made clear that these may still be dependent on > the value of ThreadPriorityPolicy. I added a comment to the CR to that effect. > >> -XX:+UseCriticalCompilerThreadPriority >> >> All compiler threads run at critical priority. > > It should be more clear that UseCriticalCompilerThreadPriority only > applies if CompilerThreadPriority is not set. Perhaps there should > also be a startup check for both being used? I could, but making CompilerThreadPriority rule is what I intended. I'll add a comment to globals.hpp and the CR. > > Thinking more though we really shouldn't need both flags. The basic > problem is that the current "api" only supports setting a simple > number and to use FX/60 also requires a change of scheduling class. > You could add a hack that CompilerThreadPriority=60 means FX/60. Or, > as I've suggested in past email we could generalize the format of the > option to allow both a scheduling class designator and priority to be > passed - that would be a more general mechanism. I didn't want to remove CompilerThreadPriority or change it's effect. I can file a CR to do that though. Current uses of CompilerThreadPriority=60 should work like they always have. I wanted to confine the change as much as possible to Solaris _and_ to limit it to just scheduling classes where we know we're not likely to provoke thread starvation. I can file a CR to add the ability to specify a scheduling class for Java threads. It would probably add 10 switches for scheduling class corresponding to the existing 10 Java priority switches. I don't have any ideas on how to designate particular threads for particular class/priorities. > > Adding a psuedo-priority 11 is just means to work within the current > limitations of the priority scheme. Correct. > >> -XX:+UseCriticalCMSThreadPriority >> >> The CMS background thread runs at critical priority. > > This doesn't make a lot of sense when you consider the comments in > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp > > > which still states: > > "Priority should be just less than that of VMThread" > > This seems to indicate that we don't really understand what the > priority relationship between GC threads and the VMThread should be. No, we don't. That's why this is experimental. > > Should we be able to run the VMThread at FX/60? Perhaps. It only matters for things like serial gc, which isn't used on big iron. > >> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >> native >> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >> decides. > > Is it also dependent on the value of ThreadPriorityPolicy? Should it > be? Does it make sense to use it with either policy value? No, it's not dependent on ThreadPriorityPolicy. Critical priority is the same no matter what the default MaxPriority java_to_os_priority is. I think that's the right thing to do. > >> >> Before this change, the Solaris implementation could only change >> priorities >> within the process scheduling class. It didn't change scheduling >> classes on >> a per-thread basis. I added that capability and used it for the critical >> thread >> work. I also fixed a bug where we were using thr_setprio() to save the >> original native priority during thread creation and reading it back when >> the thread started via thr_getprio(). Since thr_setprio() can change the >> user-supplied priority, this resulted in an unintended (lower) priority >> being used. > > I don't quite follow this. We used thr_setprio to set the native OS > priority, and we then read it back using thr_getprio and then used > that to pass to thr_setprio again (and also set_lwp_priority). If > thr_setprio can change the user-supplied priority then it can make > that change on the second call too can't it? Does the fact we now have > a lwp affect this? I'm curious about the fact we still both use > thr_setprio and set the LWP priority directly ??? Possibly someone like Dave Dice can answer that question. We were already using both thr_setprio and set_lwp_priority together. Likely that was in case set_lwp_priority wasn't available. thr_setprio takes a value between 0 and 127 and map that to "some priority" that may not be the same as its argument. You can, for example, pass it 127 and get 60 back from thr_getprio. So if we set it once with 127 and then set it again with 60, we can ultimately get back 0. Which is what actually used to happen. Paul > > Cheers, > David > >> Thanks, >> >> Paul >> From tom.rodriguez at oracle.com Mon Jan 23 11:16:19 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 23 Jan 2012 11:16:19 -0800 Subject: RFR, S, 7120450: complete information dumped by frame_describe In-Reply-To: <4F16F35E.1040200@oracle.com> References: <4F16F35E.1040200@oracle.com> Message-ID: That looks great. Thanks for improving the output so much. tom On Jan 18, 2012, at 8:29 AM, Bertrand Delsart wrote: > Second RFR related to frame_describe: > http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ > > This comes on top of 7120448, currently being submitted. > > Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). > > We did fix a small issue in frame::describe. is_deoptimized() could > fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). > > Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. > > Thanks, > > Bertrand. > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From dean.long at oracle.com Mon Jan 23 11:25:54 2012 From: dean.long at oracle.com (Dean Long) Date: Mon, 23 Jan 2012 11:25:54 -0800 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1A1935.4090405@oracle.com> References: <4F1A1935.4090405@oracle.com> Message-ID: <4F1DB442.8030602@oracle.com> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ The problem is that the VM thread is trying to exit while another thread is writing to the XML log. The VM thread also wants to write to the log, but notices the tag stack doesn't match up. A similar problem came up before (6295565) and the solution was to relax the assertion if we were shutting down through JNI DestroyJavaVM. The above change follows that pattern and also allows shutdown through JVM_Halt. More details thanks to David Holmes: "To be clear the VMThread is writing to the log (actually closing it) as part of exit_globals() while executing VM_Exit::doit. This happens after it calls set_vm_exited() so we add that as a guard against doing the assertion. The problem arises because the CompilerThread was in the middle of some writing (as part of PrintOptoAssembly) when it entered the safepoint that allows the VM to exit." dl From paul.hohensee at oracle.com Mon Jan 23 11:26:42 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 23 Jan 2012 14:26:42 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM )M) In-Reply-To: <4F19A0B1.7080100@oracle.com> References: <4F19A0B1.7080100@oracle.com> Message-ID: <4F1DB472.8010705@oracle.com> I've got one review (from a Reviewer), need another (doesn't have to be a Reviewer). Thanks, Paul On 1/20/12 12:13 PM, Paul Hohensee wrote: > Webrev here > > http://cr.openjdk.java.net/~phh/7091418.00/ > > This change defines a new Java pseudo-priority called > CriticalPriority, just > above MaxPriority. Compiler threads, the CMS background thread, and > Java threads can have the os equivalent of this priority. On Solaris, > this is > the FX/60 scheduling class/priority. On other platforms, it's the same > as MaxPriority's os priority. > > There are 3 new command line switches, all gated by > UseExperimentalVMOptions. > > -XX:+UseCriticalJavaThreadPriority > > Maps Java MAX_PRIORITY to critical priority. > > -XX:+UseCriticalCompilerThreadPriority > > All compiler threads run at critical priority. > > -XX:+UseCriticalCMSThreadPriority > > The CMS background thread runs at critical priority. > > On Solaris, one must in addition use -XX:+UseThreadPriorities to use > native > priorities at all. Otherwise, Hotspot just accepts whatever Solaris > decides. > > Before this change, the Solaris implementation could only change > priorities > within the process scheduling class. It didn't change scheduling > classes on > a per-thread basis. I added that capability and used it for the > critical thread > work. I also fixed a bug where we were using thr_setprio() to save the > original native priority during thread creation and reading it back when > the thread started via thr_getprio(). Since thr_setprio() can change the > user-supplied priority, this resulted in an unintended (lower) priority > being used. > > Thanks, > > Paul > From paul.hohensee at oracle.com Mon Jan 23 12:59:57 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 23 Jan 2012 15:59:57 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM In-Reply-To: <4F1DC71E.1060207@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1DB472.8010705@oracle.com> <4F1DC71E.1060207@oracle.com> Message-ID: <4F1DCA4D.8010106@oracle.com> Thanks! paul On 1/23/12 3:46 PM, charlie hunt wrote: > Looks good. > > hths, > > charlie ... > > On 01/23/12 01:26 PM, Paul Hohensee wrote: >> I've got one review (from a Reviewer), need another (doesn't have to >> be a Reviewer). >> >> Thanks, >> >> Paul >> >> On 1/20/12 12:13 PM, Paul Hohensee wrote: >>> Webrev here >>> >>> http://cr.openjdk.java.net/~phh/7091418.00/ >>> >>> This change defines a new Java pseudo-priority called >>> CriticalPriority, just >>> above MaxPriority. Compiler threads, the CMS background thread, and >>> Java threads can have the os equivalent of this priority. On >>> Solaris, this is >>> the FX/60 scheduling class/priority. On other platforms, it's the same >>> as MaxPriority's os priority. >>> >>> There are 3 new command line switches, all gated by >>> UseExperimentalVMOptions. >>> >>> -XX:+UseCriticalJavaThreadPriority >>> >>> Maps Java MAX_PRIORITY to critical priority. >>> >>> -XX:+UseCriticalCompilerThreadPriority >>> >>> All compiler threads run at critical priority. >>> >>> -XX:+UseCriticalCMSThreadPriority >>> >>> The CMS background thread runs at critical priority. >>> >>> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >>> native >>> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >>> decides. >>> >>> Before this change, the Solaris implementation could only change >>> priorities >>> within the process scheduling class. It didn't change scheduling >>> classes on >>> a per-thread basis. I added that capability and used it for the >>> critical thread >>> work. I also fixed a bug where we were using thr_setprio() to save the >>> original native priority during thread creation and reading it back >>> when >>> the thread started via thr_getprio(). Since thr_setprio() can >>> change the >>> user-supplied priority, this resulted in an unintended (lower) priority >>> being used. >>> >>> Thanks, >>> >>> Paul >>> > > From paul.hohensee at oracle.com Mon Jan 23 13:10:41 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 23 Jan 2012 16:10:41 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM In-Reply-To: <4F1DCA4D.8010106@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1DB472.8010705@oracle.com> <4F1DC71E.1060207@oracle.com> <4F1DCA4D.8010106@oracle.com> Message-ID: <4F1DCCD1.6060002@oracle.com> Unfortunately, however, you don't have an openjdk name, so I can't list you as a reviewer. :( Paul On 1/23/12 3:59 PM, Paul Hohensee wrote: > Thanks! > > paul > > On 1/23/12 3:46 PM, charlie hunt wrote: >> Looks good. >> >> hths, >> >> charlie ... >> >> On 01/23/12 01:26 PM, Paul Hohensee wrote: >>> I've got one review (from a Reviewer), need another (doesn't have to >>> be a Reviewer). >>> >>> Thanks, >>> >>> Paul >>> >>> On 1/20/12 12:13 PM, Paul Hohensee wrote: >>>> Webrev here >>>> >>>> http://cr.openjdk.java.net/~phh/7091418.00/ >>>> >>>> This change defines a new Java pseudo-priority called >>>> CriticalPriority, just >>>> above MaxPriority. Compiler threads, the CMS background thread, and >>>> Java threads can have the os equivalent of this priority. On >>>> Solaris, this is >>>> the FX/60 scheduling class/priority. On other platforms, it's the >>>> same >>>> as MaxPriority's os priority. >>>> >>>> There are 3 new command line switches, all gated by >>>> UseExperimentalVMOptions. >>>> >>>> -XX:+UseCriticalJavaThreadPriority >>>> >>>> Maps Java MAX_PRIORITY to critical priority. >>>> >>>> -XX:+UseCriticalCompilerThreadPriority >>>> >>>> All compiler threads run at critical priority. >>>> >>>> -XX:+UseCriticalCMSThreadPriority >>>> >>>> The CMS background thread runs at critical priority. >>>> >>>> On Solaris, one must in addition use -XX:+UseThreadPriorities to >>>> use native >>>> priorities at all. Otherwise, Hotspot just accepts whatever >>>> Solaris decides. >>>> >>>> Before this change, the Solaris implementation could only change >>>> priorities >>>> within the process scheduling class. It didn't change scheduling >>>> classes on >>>> a per-thread basis. I added that capability and used it for the >>>> critical thread >>>> work. I also fixed a bug where we were using thr_setprio() to save >>>> the >>>> original native priority during thread creation and reading it back >>>> when >>>> the thread started via thr_getprio(). Since thr_setprio() can >>>> change the >>>> user-supplied priority, this resulted in an unintended (lower) >>>> priority >>>> being used. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >> >> From paul.hohensee at oracle.com Mon Jan 23 14:00:37 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 23 Jan 2012 17:00:37 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1DB0DB.7040409@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> Message-ID: <4F1DD885.604@oracle.com> I just found 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 which seems like the CR I should actually be using. Ref your last comment on 7082553, we could indeed change the definition of JavaPriority10_To_OSPriority, but that would cover only Java threads, not compiler or the CMS background threads. Paul On 1/23/12 2:11 PM, Paul Hohensee wrote: > Thanks for the review. > > Inline... > > On 1/22/12 7:39 PM, David Holmes wrote: >> Hi Paul, >> >> The meta-comment here is that there needs to be a clear description >> of what "critical priority" means and what constraints there are on >> setting it to some OS specific value. For example the current changes >> uses the FX scheduling class, but what if someone used the RT >> scheduling class instead? Would that work? Probably not, in which >> case we should document that this selection of the "critical >> priority" is not an arbitrary choice that can be made. >> >> Even for FX/60 I'm not certain that using this for Java threads might >> not prevent safepoints from being reached or induce some other form >> of livelock. > > I added material to the Comments field of the CR. > > I don't think there's a livelock problem with Java threads, because > Solaris takes > FX60 as advisory, not as a command. All that should happen is that a > critical > priority Java thread will get to the safepoint earlier than > non-critical ones. > I suppose it's possible for critical priority CMS or compiler threads > to starve > non-critical Java threads, but they run at NearMaxPriority by default > now, > which can do the same thing. This is definitely an "expert-only" feature > though, which is why it's experimental for the time being. >> >> On 21/01/2012 3:13 AM, Paul Hohensee wrote: >>> Webrev here >>> >>> http://cr.openjdk.java.net/~phh/7091418.00/ >>> >>> This change defines a new Java pseudo-priority called >>> CriticalPriority, just above MaxPriority. Compiler threads, the CMS >>> background thread, and Java threads can have the os equivalent of >>> this priority. On Solaris, this is the FX/60 scheduling >>> class/priority. On other platforms, it's the same as MaxPriority's os >>> priority. >> >> For reference this is why the mapping to FX/60 has been proposed: >> >> http://blogs.oracle.com/observatory/entry/critical_threads_optimization >> >> I still don't fully grok what this optimization does in a general >> sense and it seems to be geared to providing better single-threaded >> performance on near-idle systems - which doesn't make any sense to me >> in a JVM context. But FX/60 also gives you true priority over TS/IA >> threads so that may be where the gain comes from. I wonder if any >> experiments were actually done using FX/59 rather than the "magical" >> FX/60? > > It's meant to be Solaris-Sparc-specific, but it was easier to > implement as a > general feature than to specialize it. Given enough cores, FX60 does > indeed > give you true priority over TS/IA threads. If there aren't enough cores > to run both critical threads in single-thread mode and non-critical > threads > at the same time, Solaris will allow non-critical threads to run on the > same core(s) as critical ones. > > I don't know of any FX59 experiments, but given the amount of work > it's taken > for the Solaris folks to get FX60 working, I doubt using it would have > any positive > effect. >> >>> There are 3 new command line switches, all gated by >>> UseExperimentalVMOptions. >>> >>> -XX:+UseCriticalJavaThreadPriority >>> >>> Maps Java MAX_PRIORITY to critical priority. >> >> I found what you have done here to be very confusing. The only place >> UseCriticalJavaThreadPriority is used is on Solaris. There you re-map >> the priority mapping for priority 10 to the "critical priority" as >> described. > > It's actually used on the other OSs. It just maps to MaxPriority on > those. > >> >> On all platforms you added an entry to the priority mapping table(s) >> for a non-existent Java priority 11. This provides a way to lookup >> the "critical priority" for the CMS/Compiler threads - in essence use >> of critical priority for those threads says "pretend these have Java >> priority 11" and then you've added a mapping for a priority 11 that >> is the same as for priority 10 except on Solaris. On Solaris you had >> to use a sentinel value to say "this really means use the "critical >> priority" because there is no way to convey a change of scheduling >> class. >> >> It seems to me that we are pretending to have "critical priority" >> support on all platforms when in reality we don't. If we want to go >> that way then we should extend it to the >> UseCriticalJavaThreadPriority case as well. It should be all or nothing. > > Extend it beyond making CriticalPriority == MaxPriority on non-Solaris > platforms? > I.e., we can now change the compiler and CMS thread priority to > MaxPriority on > non-Solaris platforms. I don't know how to make CriticalPriority > higher than that > on non-Solaris platforms. > >> >> Further it needs to be made clear that these may still be dependent >> on the value of ThreadPriorityPolicy. > > I added a comment to the CR to that effect. > >> >>> -XX:+UseCriticalCompilerThreadPriority >>> >>> All compiler threads run at critical priority. >> >> It should be more clear that UseCriticalCompilerThreadPriority only >> applies if CompilerThreadPriority is not set. Perhaps there should >> also be a startup check for both being used? > > I could, but making CompilerThreadPriority rule is what I intended. I'll > add a comment to globals.hpp and the CR. > >> >> Thinking more though we really shouldn't need both flags. The basic >> problem is that the current "api" only supports setting a simple >> number and to use FX/60 also requires a change of scheduling class. >> You could add a hack that CompilerThreadPriority=60 means FX/60. Or, >> as I've suggested in past email we could generalize the format of the >> option to allow both a scheduling class designator and priority to be >> passed - that would be a more general mechanism. > > I didn't want to remove CompilerThreadPriority or change it's effect. > I can file a CR > to do that though. Current uses of CompilerThreadPriority=60 should > work like > they always have. > > I wanted to confine the change as much as possible to Solaris _and_ to > limit it > to just scheduling classes where we know we're not likely to provoke > thread > starvation. I can file a CR to add the ability to specify a > scheduling class for > Java threads. It would probably add 10 switches for scheduling class > corresponding > to the existing 10 Java priority switches. I don't have any ideas on > how to > designate particular threads for particular class/priorities. > >> >> Adding a psuedo-priority 11 is just means to work within the current >> limitations of the priority scheme. > > Correct. > >> >>> -XX:+UseCriticalCMSThreadPriority >>> >>> The CMS background thread runs at critical priority. >> >> This doesn't make a lot of sense when you consider the comments in >> >> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp >> >> >> which still states: >> >> "Priority should be just less than that of VMThread" >> >> This seems to indicate that we don't really understand what the >> priority relationship between GC threads and the VMThread should be. > > No, we don't. That's why this is experimental. > >> >> Should we be able to run the VMThread at FX/60? > > Perhaps. It only matters for things like serial gc, which isn't used > on big iron. > >> >>> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >>> native >>> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >>> decides. >> >> Is it also dependent on the value of ThreadPriorityPolicy? Should it >> be? Does it make sense to use it with either policy value? > > No, it's not dependent on ThreadPriorityPolicy. Critical priority is > the same > no matter what the default MaxPriority java_to_os_priority is. I > think that's > the right thing to do. > >> >>> >>> Before this change, the Solaris implementation could only change >>> priorities >>> within the process scheduling class. It didn't change scheduling >>> classes on >>> a per-thread basis. I added that capability and used it for the >>> critical >>> thread >>> work. I also fixed a bug where we were using thr_setprio() to save the >>> original native priority during thread creation and reading it back >>> when >>> the thread started via thr_getprio(). Since thr_setprio() can change >>> the >>> user-supplied priority, this resulted in an unintended (lower) priority >>> being used. >> >> I don't quite follow this. We used thr_setprio to set the native OS >> priority, and we then read it back using thr_getprio and then used >> that to pass to thr_setprio again (and also set_lwp_priority). If >> thr_setprio can change the user-supplied priority then it can make >> that change on the second call too can't it? Does the fact we now >> have a lwp affect this? I'm curious about the fact we still both use >> thr_setprio and set the LWP priority directly ??? > > Possibly someone like Dave Dice can answer that question. We were > already using > both thr_setprio and set_lwp_priority together. Likely that was in > case set_lwp_priority > wasn't available. > > thr_setprio takes a value between 0 and 127 and map that to "some > priority" that > may not be the same as its argument. You can, for example, pass it > 127 and > get 60 back from thr_getprio. So if we set it once with 127 and then > set it again > with 60, we can ultimately get back 0. Which is what actually used to > happen. > > Paul >> >> Cheers, >> David >> >>> Thanks, >>> >>> Paul >>> > From john.coomes at oracle.com Mon Jan 23 14:43:50 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 23 Jan 2012 22:43:50 +0000 Subject: hg: hsx/hotspot-emb/langtools: 8 new changesets Message-ID: <20120123224411.AA61447142@hg.openjdk.java.net> Changeset: 116f68a5e677 Author: jjg Date: 2011-12-23 22:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/116f68a5e677 7124605: typos in javac comments Reviewed-by: ksrini ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/inference/7086601/T7086601b.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/LambdaParserTest.java Changeset: 67512b631961 Author: lana Date: 2011-12-28 10:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/67512b631961 Merge Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags From john.coomes at oracle.com Mon Jan 23 15:05:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 23 Jan 2012 23:05:07 +0000 Subject: hg: hsx/hotspot-rt/langtools: 8 new changesets Message-ID: <20120123230526.6EA2A47146@hg.openjdk.java.net> Changeset: 116f68a5e677 Author: jjg Date: 2011-12-23 22:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/116f68a5e677 7124605: typos in javac comments Reviewed-by: ksrini ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/inference/7086601/T7086601b.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/LambdaParserTest.java Changeset: 67512b631961 Author: lana Date: 2011-12-28 10:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/67512b631961 Merge Changeset: 7a836147b266 Author: jjg Date: 2012-01-03 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/7a836147b266 4881269: improve diagnostic for ill-formed tokens Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IllegalDot.java + test/tools/javac/parser/T4881269.java + test/tools/javac/parser/T4881269.out Changeset: a07eef109532 Author: jjh Date: 2012-01-03 17:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a07eef109532 7046929: tools/javac/api/T6397104.java fails Reviewed-by: jjg ! test/tools/javac/api/T6397104.java Changeset: 4e8aa6eca726 Author: lana Date: 2012-01-04 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/4e8aa6eca726 Merge Changeset: bcb21abf1c41 Author: lana Date: 2012-01-09 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/bcb21abf1c41 Merge Changeset: 390a7828ae18 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/390a7828ae18 Added tag jdk8-b21 for changeset bcb21abf1c41 ! .hgtags Changeset: f6191bad139a Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f6191bad139a Added tag jdk8-b22 for changeset 390a7828ae18 ! .hgtags From david.holmes at oracle.com Mon Jan 23 19:01:08 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Jan 2012 13:01:08 +1000 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1DB442.8030602@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> Message-ID: <4F1E1EF4.1080905@oracle.com> Looks good to me. David On 24/01/2012 5:25 AM, Dean Long wrote: > http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ > > The problem is that the VM thread is trying to exit while another > thread is writing to the XML log. The VM thread also wants to write > to the log, but notices the tag stack doesn't match up. A similar > problem came up before (6295565) and the solution was to relax the > assertion if we were shutting down through JNI DestroyJavaVM. The > above change follows that pattern and also allows shutdown > through JVM_Halt. > > More details thanks to David Holmes: > > "To be clear the VMThread is writing to the log (actually closing it) as > part of exit_globals() while executing VM_Exit::doit. This happens after > it calls set_vm_exited() so we add that as a guard against doing the > assertion. The problem arises because the CompilerThread was in the > middle of some writing (as part of PrintOptoAssembly) when it entered > the safepoint that allows the VM to exit." > > dl > > > > From dean.long at oracle.com Mon Jan 23 20:09:58 2012 From: dean.long at oracle.com (Dean Long) Date: Mon, 23 Jan 2012 20:09:58 -0800 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1E1EF4.1080905@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> <4F1E1EF4.1080905@oracle.com> Message-ID: <4F1E2F16.2030908@oracle.com> David, thanks for the review. How many reviews do I need before I can commit? dl On 1/23/2012 7:01 PM, David Holmes wrote: > Looks good to me. > > David > > On 24/01/2012 5:25 AM, Dean Long wrote: >> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ >> >> The problem is that the VM thread is trying to exit while another >> thread is writing to the XML log. The VM thread also wants to write >> to the log, but notices the tag stack doesn't match up. A similar >> problem came up before (6295565) and the solution was to relax the >> assertion if we were shutting down through JNI DestroyJavaVM. The >> above change follows that pattern and also allows shutdown >> through JVM_Halt. >> >> More details thanks to David Holmes: >> >> "To be clear the VMThread is writing to the log (actually closing it) as >> part of exit_globals() while executing VM_Exit::doit. This happens after >> it calls set_vm_exited() so we add that as a guard against doing the >> assertion. The problem arises because the CompilerThread was in the >> middle of some writing (as part of PrintOptoAssembly) when it entered >> the safepoint that allows the VM to exit." >> >> dl >> >> >> >> From david.holmes at oracle.com Mon Jan 23 20:13:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Jan 2012 14:13:39 +1000 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1E2F16.2030908@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> <4F1E1EF4.1080905@oracle.com> <4F1E2F16.2030908@oracle.com> Message-ID: <4F1E2FF3.2020402@oracle.com> On 24/01/2012 2:09 PM, Dean Long wrote: > David, thanks for the review. How many reviews do I need before I can > commit? Two. Though there seems to be some leeway as to whether both must be Reviewers. David > dl > > On 1/23/2012 7:01 PM, David Holmes wrote: >> Looks good to me. >> >> David >> >> On 24/01/2012 5:25 AM, Dean Long wrote: >>> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ >>> >>> The problem is that the VM thread is trying to exit while another >>> thread is writing to the XML log. The VM thread also wants to write >>> to the log, but notices the tag stack doesn't match up. A similar >>> problem came up before (6295565) and the solution was to relax the >>> assertion if we were shutting down through JNI DestroyJavaVM. The >>> above change follows that pattern and also allows shutdown >>> through JVM_Halt. >>> >>> More details thanks to David Holmes: >>> >>> "To be clear the VMThread is writing to the log (actually closing it) as >>> part of exit_globals() while executing VM_Exit::doit. This happens after >>> it calls set_vm_exited() so we add that as a guard against doing the >>> assertion. The problem arises because the CompilerThread was in the >>> middle of some writing (as part of PrintOptoAssembly) when it entered >>> the safepoint that allows the VM to exit." >>> >>> dl >>> >>> >>> >>> From david.holmes at oracle.com Mon Jan 23 20:53:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Jan 2012 14:53:24 +1000 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1DD885.604@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> Message-ID: <4F1E3944.2000300@oracle.com> Hi Paul, Warning: long winded response below Summary: - file RFE to fully support "system" priority for VM internal threads - Fully implement UseCriticalJavaThreadPriority on non-Solaris You'll have to read on to understand what I mean by both of these :) On 24/01/2012 8:00 AM, Paul Hohensee wrote: > I just found > > 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 > on Solaris 10 and 11 > > which seems like the CR I should actually be using. > > Ref your last comment on 7082553, we could indeed change the definition > of JavaPriority10_To_OSPriority, but that would cover only Java threads, > not compiler or the CMS background threads. Thanks for reminding me about this CR - I knew there had been further discussion on this. That CR is not public, which seems a little pointless now. I'll restate my concerns as outlined in that CR. It is very difficult for an application programmer to determine that FX60 will provide any performance benefit, whether assigned to a compiler thread, GC thread or Java thread. The benefits of FX60 only exist when a system has idle cores, so the application programmer and/or the application "deployer" has to know what overall load will exist on the system. For the GC and compiler threads this is not such an issue as the person deploying the app can simply experiment with the flag being on and off and see it it helps in their situation. For Java threads however the application programmer has to use Thread.MAX_PRIORITY. This has two negative consequences. First it encourages people to start thinking about Thread priorities when we have spent a dozen years telling them to forget about them because in 99% of the cases they have no meaning. For them to have meaning you have to select non default ThreadPriorityPolicy settings and use the right OS - even then you get different affects on different OSes. Which leads me to the second consequence: a loss of portability. Using Thread.MAX_PRIORITY can have different consequences on different platforms, even today. Ok - so the response to the above is "These are experimental options which must be unlocked, and its for advanced users and 'caveat emptor'". I can live with that, so lets look at the details of the implementation. There are really two distinct parts to this. First the ability to define a special system thread priority. In that regard I like the idea of creating a pseudo-priority of 11 and using that to map to this system, aka critical, priority (though this could be better documented). You then have flags the say "use the system priority for threads of type X". This is cross-platform. There are two things I find problematic with this though: 1. As priority is simply a number we can't directly use this to implement FX60. Instead we have to put in a hack where a negative value on Solaris tells the system specific code "that means FX 60". 2. There is no mechanism, apart from recompiling the VM, to actually control what this system/critical priority is. So this general purpose mechanism falls somewhat short of being generally useful as a cross-platform mechanism. I find both of these unsatisfactory and a RFE should be filed to address them. The second part is the "map Thread.MAX_PRIORITY to the critical priority" part. On Solaris you use UseCriticalJavaThreadPriority to actually update the priority mapping 10 -> critical. But you don't do this on the other platforms. This is what I object to - if you are going to make this a cross-platform setting then it should be implemented fully on all platforms. It doesn't matter that by default the end result is the same, the code should be there so that if you could define the critical priority at runtime things would work as expected. Cheers, David ----- > > Paul > > On 1/23/12 2:11 PM, Paul Hohensee wrote: >> Thanks for the review. >> >> Inline... >> >> On 1/22/12 7:39 PM, David Holmes wrote: >>> Hi Paul, >>> >>> The meta-comment here is that there needs to be a clear description >>> of what "critical priority" means and what constraints there are on >>> setting it to some OS specific value. For example the current changes >>> uses the FX scheduling class, but what if someone used the RT >>> scheduling class instead? Would that work? Probably not, in which >>> case we should document that this selection of the "critical >>> priority" is not an arbitrary choice that can be made. >>> >>> Even for FX/60 I'm not certain that using this for Java threads might >>> not prevent safepoints from being reached or induce some other form >>> of livelock. >> >> I added material to the Comments field of the CR. >> >> I don't think there's a livelock problem with Java threads, because >> Solaris takes >> FX60 as advisory, not as a command. All that should happen is that a >> critical >> priority Java thread will get to the safepoint earlier than >> non-critical ones. >> I suppose it's possible for critical priority CMS or compiler threads >> to starve >> non-critical Java threads, but they run at NearMaxPriority by default >> now, >> which can do the same thing. This is definitely an "expert-only" feature >> though, which is why it's experimental for the time being. >>> >>> On 21/01/2012 3:13 AM, Paul Hohensee wrote: >>>> Webrev here >>>> >>>> http://cr.openjdk.java.net/~phh/7091418.00/ >>>> >>>> This change defines a new Java pseudo-priority called >>>> CriticalPriority, just above MaxPriority. Compiler threads, the CMS >>>> background thread, and Java threads can have the os equivalent of >>>> this priority. On Solaris, this is the FX/60 scheduling >>>> class/priority. On other platforms, it's the same as MaxPriority's os >>>> priority. >>> >>> For reference this is why the mapping to FX/60 has been proposed: >>> >>> http://blogs.oracle.com/observatory/entry/critical_threads_optimization >>> >>> I still don't fully grok what this optimization does in a general >>> sense and it seems to be geared to providing better single-threaded >>> performance on near-idle systems - which doesn't make any sense to me >>> in a JVM context. But FX/60 also gives you true priority over TS/IA >>> threads so that may be where the gain comes from. I wonder if any >>> experiments were actually done using FX/59 rather than the "magical" >>> FX/60? >> >> It's meant to be Solaris-Sparc-specific, but it was easier to >> implement as a >> general feature than to specialize it. Given enough cores, FX60 does >> indeed >> give you true priority over TS/IA threads. If there aren't enough cores >> to run both critical threads in single-thread mode and non-critical >> threads >> at the same time, Solaris will allow non-critical threads to run on the >> same core(s) as critical ones. >> >> I don't know of any FX59 experiments, but given the amount of work >> it's taken >> for the Solaris folks to get FX60 working, I doubt using it would have >> any positive >> effect. >>> >>>> There are 3 new command line switches, all gated by >>>> UseExperimentalVMOptions. >>>> >>>> -XX:+UseCriticalJavaThreadPriority >>>> >>>> Maps Java MAX_PRIORITY to critical priority. >>> >>> I found what you have done here to be very confusing. The only place >>> UseCriticalJavaThreadPriority is used is on Solaris. There you re-map >>> the priority mapping for priority 10 to the "critical priority" as >>> described. >> >> It's actually used on the other OSs. It just maps to MaxPriority on >> those. >> >>> >>> On all platforms you added an entry to the priority mapping table(s) >>> for a non-existent Java priority 11. This provides a way to lookup >>> the "critical priority" for the CMS/Compiler threads - in essence use >>> of critical priority for those threads says "pretend these have Java >>> priority 11" and then you've added a mapping for a priority 11 that >>> is the same as for priority 10 except on Solaris. On Solaris you had >>> to use a sentinel value to say "this really means use the "critical >>> priority" because there is no way to convey a change of scheduling >>> class. >>> >>> It seems to me that we are pretending to have "critical priority" >>> support on all platforms when in reality we don't. If we want to go >>> that way then we should extend it to the >>> UseCriticalJavaThreadPriority case as well. It should be all or nothing. >> >> Extend it beyond making CriticalPriority == MaxPriority on non-Solaris >> platforms? >> I.e., we can now change the compiler and CMS thread priority to >> MaxPriority on >> non-Solaris platforms. I don't know how to make CriticalPriority >> higher than that >> on non-Solaris platforms. >> >>> >>> Further it needs to be made clear that these may still be dependent >>> on the value of ThreadPriorityPolicy. >> >> I added a comment to the CR to that effect. >> >>> >>>> -XX:+UseCriticalCompilerThreadPriority >>>> >>>> All compiler threads run at critical priority. >>> >>> It should be more clear that UseCriticalCompilerThreadPriority only >>> applies if CompilerThreadPriority is not set. Perhaps there should >>> also be a startup check for both being used? >> >> I could, but making CompilerThreadPriority rule is what I intended. I'll >> add a comment to globals.hpp and the CR. >> >>> >>> Thinking more though we really shouldn't need both flags. The basic >>> problem is that the current "api" only supports setting a simple >>> number and to use FX/60 also requires a change of scheduling class. >>> You could add a hack that CompilerThreadPriority=60 means FX/60. Or, >>> as I've suggested in past email we could generalize the format of the >>> option to allow both a scheduling class designator and priority to be >>> passed - that would be a more general mechanism. >> >> I didn't want to remove CompilerThreadPriority or change it's effect. >> I can file a CR >> to do that though. Current uses of CompilerThreadPriority=60 should >> work like >> they always have. >> >> I wanted to confine the change as much as possible to Solaris _and_ to >> limit it >> to just scheduling classes where we know we're not likely to provoke >> thread >> starvation. I can file a CR to add the ability to specify a scheduling >> class for >> Java threads. It would probably add 10 switches for scheduling class >> corresponding >> to the existing 10 Java priority switches. I don't have any ideas on >> how to >> designate particular threads for particular class/priorities. >> >>> >>> Adding a psuedo-priority 11 is just means to work within the current >>> limitations of the priority scheme. >> >> Correct. >> >>> >>>> -XX:+UseCriticalCMSThreadPriority >>>> >>>> The CMS background thread runs at critical priority. >>> >>> This doesn't make a lot of sense when you consider the comments in >>> >>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp >>> >>> >>> which still states: >>> >>> "Priority should be just less than that of VMThread" >>> >>> This seems to indicate that we don't really understand what the >>> priority relationship between GC threads and the VMThread should be. >> >> No, we don't. That's why this is experimental. >> >>> >>> Should we be able to run the VMThread at FX/60? >> >> Perhaps. It only matters for things like serial gc, which isn't used >> on big iron. >> >>> >>>> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >>>> native >>>> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >>>> decides. >>> >>> Is it also dependent on the value of ThreadPriorityPolicy? Should it >>> be? Does it make sense to use it with either policy value? >> >> No, it's not dependent on ThreadPriorityPolicy. Critical priority is >> the same >> no matter what the default MaxPriority java_to_os_priority is. I think >> that's >> the right thing to do. >> >>> >>>> >>>> Before this change, the Solaris implementation could only change >>>> priorities >>>> within the process scheduling class. It didn't change scheduling >>>> classes on >>>> a per-thread basis. I added that capability and used it for the >>>> critical >>>> thread >>>> work. I also fixed a bug where we were using thr_setprio() to save the >>>> original native priority during thread creation and reading it back >>>> when >>>> the thread started via thr_getprio(). Since thr_setprio() can change >>>> the >>>> user-supplied priority, this resulted in an unintended (lower) priority >>>> being used. >>> >>> I don't quite follow this. We used thr_setprio to set the native OS >>> priority, and we then read it back using thr_getprio and then used >>> that to pass to thr_setprio again (and also set_lwp_priority). If >>> thr_setprio can change the user-supplied priority then it can make >>> that change on the second call too can't it? Does the fact we now >>> have a lwp affect this? I'm curious about the fact we still both use >>> thr_setprio and set the LWP priority directly ??? >> >> Possibly someone like Dave Dice can answer that question. We were >> already using >> both thr_setprio and set_lwp_priority together. Likely that was in >> case set_lwp_priority >> wasn't available. >> >> thr_setprio takes a value between 0 and 127 and map that to "some >> priority" that >> may not be the same as its argument. You can, for example, pass it 127 >> and >> get 60 back from thr_getprio. So if we set it once with 127 and then >> set it again >> with 60, we can ultimately get back 0. Which is what actually used to >> happen. >> >> Paul >>> >>> Cheers, >>> David >>> >>>> Thanks, >>>> >>>> Paul >>>> >> From coleen.phillimore at oracle.com Mon Jan 23 23:55:38 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 24 Jan 2012 07:55:38 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120124075544.82F584714D@hg.openjdk.java.net> Changeset: af739d5ab23c Author: bpittore Date: 2012-01-21 23:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/af739d5ab23c 6972759: Step over not working after thrown exception and Pop Summary: reset jvmtithreadstate exception state after frame pop and forceearlyreturn processed Reviewed-by: minqi, dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: 583b428aa858 Author: coleenp Date: 2012-01-23 17:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/583b428aa858 Merge - src/os/bsd/vm/decoder_bsd.cpp From christian.thalinger at oracle.com Tue Jan 24 01:57:51 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 24 Jan 2012 10:57:51 +0100 Subject: RFR, S, 7120450: complete information dumped by frame_describe In-Reply-To: <4F16F35E.1040200@oracle.com> References: <4F16F35E.1040200@oracle.com> Message-ID: Looks good. Only one little nit: + intptr_t* esp = * interpreter_frame_esp_addr(); Could you remove that extra space for the dereference? It looked like a multiplication at first sight :-) -- Chris On Jan 18, 2012, at 5:29 PM, Bertrand Delsart wrote: > Second RFR related to frame_describe: > http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ > > This comes on top of 7120448, currently being submitted. > > Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). > > We did fix a small issue in frame::describe. is_deoptimized() could > fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). > > Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. > > Thanks, > > Bertrand. > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE From bertrand.delsart at oracle.com Tue Jan 24 05:06:28 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 24 Jan 2012 14:06:28 +0100 Subject: RFR, S, 7120450: complete information dumped by frame_describe In-Reply-To: References: <4F16F35E.1040200@oracle.com> Message-ID: <4F1EACD4.2010508@oracle.com> Thanks Chris, will do. Bertrand. On 01/24/12 10:57 AM, Christian Thalinger wrote: > Looks good. Only one little nit: > > + intptr_t* esp = * interpreter_frame_esp_addr(); > > Could you remove that extra space for the dereference? It looked like a multiplication at first sight :-) > > -- Chris > > On Jan 18, 2012, at 5:29 PM, Bertrand Delsart wrote: > >> Second RFR related to frame_describe: >> http://cr.openjdk.java.net/~bdelsart/7120450/00/webrev/ >> >> This comes on top of 7120448, currently being submitted. >> >> Goal of that RFR was to enhance x86/PPC with stuff we had added to our embedded plarforms, namely information about ricochet frames and basic information for non standard frames. This only impacts debugging code (dumps generated by pfl() calls or temporarily added to the JVM during development). >> >> We did fix a small issue in frame::describe. is_deoptimized() could >> fail on assertions for some frames. This was discovered by stress testing the calls with (non submited) print_frame_layout() calls in in the transitions back from the JVM to Java (to ensure the robustness of the dump and the adequacy of the information). >> >> Also called print_frame_layout() from trace_method_handle to debug ricochet frames information. This is not part of this RFR since the changes are more intrusive. >> >> Thanks, >> >> Bertrand. >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From paul.hohensee at oracle.com Tue Jan 24 06:16:18 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 09:16:18 -0500 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1E2FF3.2020402@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> <4F1E1EF4.1080905@oracle.com> <4F1E2F16.2030908@oracle.com> <4F1E2FF3.2020402@oracle.com> Message-ID: <4F1EBD32.20601@oracle.com> You only need 1 Reviewer, the other doesn't have to be a Reviewer, but does need an openjdk name. Paul On 1/23/12 11:13 PM, David Holmes wrote: > On 24/01/2012 2:09 PM, Dean Long wrote: >> David, thanks for the review. How many reviews do I need before I can >> commit? > > Two. Though there seems to be some leeway as to whether both must be > Reviewers. > > David > >> dl >> >> On 1/23/2012 7:01 PM, David Holmes wrote: >>> Looks good to me. >>> >>> David >>> >>> On 24/01/2012 5:25 AM, Dean Long wrote: >>>> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ >>>> >>>> The problem is that the VM thread is trying to exit while another >>>> thread is writing to the XML log. The VM thread also wants to write >>>> to the log, but notices the tag stack doesn't match up. A similar >>>> problem came up before (6295565) and the solution was to relax the >>>> assertion if we were shutting down through JNI DestroyJavaVM. The >>>> above change follows that pattern and also allows shutdown >>>> through JVM_Halt. >>>> >>>> More details thanks to David Holmes: >>>> >>>> "To be clear the VMThread is writing to the log (actually closing >>>> it) as >>>> part of exit_globals() while executing VM_Exit::doit. This happens >>>> after >>>> it calls set_vm_exited() so we add that as a guard against doing the >>>> assertion. The problem arises because the CompilerThread was in the >>>> middle of some writing (as part of PrintOptoAssembly) when it entered >>>> the safepoint that allows the VM to exit." >>>> >>>> dl >>>> >>>> >>>> >>>> From charlie.hunt at oracle.com Mon Jan 23 12:46:22 2012 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 23 Jan 2012 14:46:22 -0600 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM In-Reply-To: <4F1DB472.8010705@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1DB472.8010705@oracle.com> Message-ID: <4F1DC71E.1060207@oracle.com> Looks good. hths, charlie ... On 01/23/12 01:26 PM, Paul Hohensee wrote: > I've got one review (from a Reviewer), need another (doesn't have to > be a Reviewer). > > Thanks, > > Paul > > On 1/20/12 12:13 PM, Paul Hohensee wrote: >> Webrev here >> >> http://cr.openjdk.java.net/~phh/7091418.00/ >> >> This change defines a new Java pseudo-priority called >> CriticalPriority, just >> above MaxPriority. Compiler threads, the CMS background thread, and >> Java threads can have the os equivalent of this priority. On >> Solaris, this is >> the FX/60 scheduling class/priority. On other platforms, it's the same >> as MaxPriority's os priority. >> >> There are 3 new command line switches, all gated by >> UseExperimentalVMOptions. >> >> -XX:+UseCriticalJavaThreadPriority >> >> Maps Java MAX_PRIORITY to critical priority. >> >> -XX:+UseCriticalCompilerThreadPriority >> >> All compiler threads run at critical priority. >> >> -XX:+UseCriticalCMSThreadPriority >> >> The CMS background thread runs at critical priority. >> >> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >> native >> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >> decides. >> >> Before this change, the Solaris implementation could only change >> priorities >> within the process scheduling class. It didn't change scheduling >> classes on >> a per-thread basis. I added that capability and used it for the >> critical thread >> work. I also fixed a bug where we were using thr_setprio() to save the >> original native priority during thread creation and reading it back when >> the thread started via thr_getprio(). Since thr_setprio() can change >> the >> user-supplied priority, this resulted in an unintended (lower) priority >> being used. >> >> Thanks, >> >> Paul >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5166 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120123/ead52844/smime.p7s From dean.long at oracle.com Tue Jan 24 08:24:10 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 24 Jan 2012 08:24:10 -0800 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1EBD32.20601@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> <4F1E1EF4.1080905@oracle.com> <4F1E2F16.2030908@oracle.com> <4F1E2FF3.2020402@oracle.com> <4F1EBD32.20601@oracle.com> Message-ID: <4F1EDB2A.3010607@oracle.com> So that includes Authors? For some reason I thought you had to be a Committer. dl On 1/24/2012 6:16 AM, Paul Hohensee wrote: > You only need 1 Reviewer, the other doesn't have to be a Reviewer, but > does need an openjdk name. > > Paul > > On 1/23/12 11:13 PM, David Holmes wrote: >> On 24/01/2012 2:09 PM, Dean Long wrote: >>> David, thanks for the review. How many reviews do I need before I can >>> commit? >> >> Two. Though there seems to be some leeway as to whether both must be >> Reviewers. >> >> David >> >>> dl >>> >>> On 1/23/2012 7:01 PM, David Holmes wrote: >>>> Looks good to me. >>>> >>>> David >>>> >>>> On 24/01/2012 5:25 AM, Dean Long wrote: >>>>> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ >>>>> >>>>> The problem is that the VM thread is trying to exit while another >>>>> thread is writing to the XML log. The VM thread also wants to write >>>>> to the log, but notices the tag stack doesn't match up. A similar >>>>> problem came up before (6295565) and the solution was to relax the >>>>> assertion if we were shutting down through JNI DestroyJavaVM. The >>>>> above change follows that pattern and also allows shutdown >>>>> through JVM_Halt. >>>>> >>>>> More details thanks to David Holmes: >>>>> >>>>> "To be clear the VMThread is writing to the log (actually closing >>>>> it) as >>>>> part of exit_globals() while executing VM_Exit::doit. This happens >>>>> after >>>>> it calls set_vm_exited() so we add that as a guard against doing the >>>>> assertion. The problem arises because the CompilerThread was in the >>>>> middle of some writing (as part of PrintOptoAssembly) when it entered >>>>> the safepoint that allows the VM to exit." >>>>> >>>>> dl >>>>> >>>>> >>>>> >>>>> From tom.rodriguez at oracle.com Tue Jan 24 08:38:19 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 24 Jan 2012 08:38:19 -0800 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1DB442.8030602@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> Message-ID: Looks good. tom On Jan 23, 2012, at 11:25 AM, Dean Long wrote: > http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ > > The problem is that the VM thread is trying to exit while another > thread is writing to the XML log. The VM thread also wants to write > to the log, but notices the tag stack doesn't match up. A similar > problem came up before (6295565) and the solution was to relax the > assertion if we were shutting down through JNI DestroyJavaVM. The > above change follows that pattern and also allows shutdown > through JVM_Halt. > > More details thanks to David Holmes: > > "To be clear the VMThread is writing to the log (actually closing it) as part of exit_globals() while executing VM_Exit::doit. This happens after it calls set_vm_exited() so we add that as a guard against doing the assertion. The problem arises because the CompilerThread was in the middle of some writing (as part of PrintOptoAssembly) when it entered the safepoint that allows the VM to exit." > > dl > > > > From paul.hohensee at oracle.com Tue Jan 24 10:03:01 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 13:03:01 -0500 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: <4F1EDB2A.3010607@oracle.com> References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> <4F1E1EF4.1080905@oracle.com> <4F1E2F16.2030908@oracle.com> <4F1E2FF3.2020402@oracle.com> <4F1EBD32.20601@oracle.com> <4F1EDB2A.3010607@oracle.com> Message-ID: <4F1EF255.8090502@oracle.com> Yes, Authors can review code, all you need is an openjdk name. In practice, it's not a problem, because the responsible engineer knows who's capable of doing a review and who isn't. And you still need one Reviewer. Paul On 1/24/12 11:24 AM, Dean Long wrote: > So that includes Authors? For some reason I thought you had to be a > Committer. > > dl > > On 1/24/2012 6:16 AM, Paul Hohensee wrote: >> You only need 1 Reviewer, the other doesn't have to be a Reviewer, but >> does need an openjdk name. >> >> Paul >> >> On 1/23/12 11:13 PM, David Holmes wrote: >>> On 24/01/2012 2:09 PM, Dean Long wrote: >>>> David, thanks for the review. How many reviews do I need before I can >>>> commit? >>> >>> Two. Though there seems to be some leeway as to whether both must be >>> Reviewers. >>> >>> David >>> >>>> dl >>>> >>>> On 1/23/2012 7:01 PM, David Holmes wrote: >>>>> Looks good to me. >>>>> >>>>> David >>>>> >>>>> On 24/01/2012 5:25 AM, Dean Long wrote: >>>>>> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ >>>>>> >>>>>> The problem is that the VM thread is trying to exit while another >>>>>> thread is writing to the XML log. The VM thread also wants to write >>>>>> to the log, but notices the tag stack doesn't match up. A similar >>>>>> problem came up before (6295565) and the solution was to relax the >>>>>> assertion if we were shutting down through JNI DestroyJavaVM. The >>>>>> above change follows that pattern and also allows shutdown >>>>>> through JVM_Halt. >>>>>> >>>>>> More details thanks to David Holmes: >>>>>> >>>>>> "To be clear the VMThread is writing to the log (actually closing >>>>>> it) as >>>>>> part of exit_globals() while executing VM_Exit::doit. This >>>>>> happens after >>>>>> it calls set_vm_exited() so we add that as a guard against doing the >>>>>> assertion. The problem arises because the CompilerThread was in the >>>>>> middle of some writing (as part of PrintOptoAssembly) when it >>>>>> entered >>>>>> the safepoint that allows the VM to exit." >>>>>> >>>>>> dl >>>>>> >>>>>> >>>>>> >>>>>> From paul.hohensee at oracle.com Tue Jan 24 11:55:08 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 14:55:08 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1E3944.2000300@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> Message-ID: <4F1F0C9C.3020007@oracle.com> Thanks for the review. Inline... On 1/23/12 11:53 PM, David Holmes wrote: > Hi Paul, > > Warning: long winded response below Looking forward to it. :) > > Summary: > - file RFE to fully support "system" priority for VM internal threads > - Fully implement UseCriticalJavaThreadPriority on non-Solaris > > You'll have to read on to understand what I mean by both of these :) > > On 24/01/2012 8:00 AM, Paul Hohensee wrote: >> I just found >> >> 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 >> on Solaris 10 and 11 >> >> which seems like the CR I should actually be using. >> >> Ref your last comment on 7082553, we could indeed change the definition >> of JavaPriority10_To_OSPriority, but that would cover only Java threads, >> not compiler or the CMS background threads. > > Thanks for reminding me about this CR - I knew there had been further > discussion on this. That CR is not public, which seems a little > pointless now. Yes. I've made 7082553 public and make 7091418 a dup of 7082553. > > I'll restate my concerns as outlined in that CR. It is very difficult > for an application programmer to determine that FX60 will provide any > performance benefit, whether assigned to a compiler thread, GC thread > or Java thread. The benefits of FX60 only exist when a system has idle > cores, so the application programmer and/or the application "deployer" > has to know what overall load will exist on the system. For the GC and > compiler threads this is not such an issue as the person deploying the > app can simply experiment with the flag being on and off and see it it > helps in their situation. Undoubtedly true that only experts should be using it. There are significant Oracle applications running on T4 that contain serial bottlenecks, so by definition there are idle cores available. > > For Java threads however the application programmer has to use > Thread.MAX_PRIORITY. This has two negative consequences. First it > encourages people to start thinking about Thread priorities when we > have spent a dozen years telling them to forget about them because in > 99% of the cases they have no meaning. For them to have meaning you > have to select non default ThreadPriorityPolicy settings and use the > right OS - even then you get different affects on different OSes. > Which leads me to the second consequence: a loss of portability. Using > Thread.MAX_PRIORITY can have different consequences on different > platforms, even today. That's true. Imo, the correct solution is to invent a QOS API at a higher abstraction level, e.g., something like Thread.prefer(SYSTEM_THROUGHPUT) or Thread.prefer(FAST_RESPONSE_TIME). We wanted to get something useful sooner than that though, hence this RFE. Note that it's very much experimental, which is why it's use is gated by -XX:+UseExperimentalVMOptions. There's no guarantee at all that we'll continue to support these switches. > > Ok - so the response to the above is "These are experimental options > which must be unlocked, and its for advanced users and 'caveat > emptor'". I can live with that, so lets look at the details of the > implementation. Ah, didn't need to write the above. :) > > There are really two distinct parts to this. First the ability to > define a special system thread priority. In that regard I like the > idea of creating a pseudo-priority of 11 and using that to map to this > system, aka critical, priority (though this could be better > documented). You then have flags the say "use the system priority for > threads of type X". This is cross-platform. There are two things I > find problematic with this though: > > 1. As priority is simply a number we can't directly use this to > implement FX60. Instead we have to put in a hack where a negative > value on Solaris tells the system specific code "that means FX 60". Yes. I could make things a little better by having a negative number mean "FX" and to use the positive equivalent directly (i.e., not scale it). An alternative would be to add a second mapping array (or make an array of structs) that contains the desired scheduling class. This seemed like overkill to me given the limited goal of this change. > 2. There is no mechanism, apart from recompiling the VM, to actually > control what this system/critical priority is. True. > > So this general purpose mechanism falls somewhat short of being > generally useful as a cross-platform mechanism. I find both of these > unsatisfactory and a RFE should be filed to address them. It's intended to be Solaris-only right now, which is why I didn't implement the full-blown solution on non-Solaris platforms. Rather I made it incidental to an understandable Solaris implementation, esp. the common code parts in compileBroker.cpp and concurrentMarkSweepThread.cpp. I'll file an RFE along the lines of being able to specify a scheduling class and priority for each Java thread priority. Either extend JavaPriority_To_OSPriority to take a CSV list argument (which is coming to the command line parser at some point anyway), or add 10 more switches to specify the scheduling class. > > The second part is the "map Thread.MAX_PRIORITY to the critical > priority" part. On Solaris you use UseCriticalJavaThreadPriority to > actually update the priority mapping 10 -> critical. But you don't do > this on the other platforms. This is what I object to - if you are > going to make this a cross-platform setting then it should be > implemented fully on all platforms. It doesn't matter that by default > the end result is the same, the code should be there so that if you > could define the critical priority at runtime things would work as > expected. I didn't do it on non-Solaris platforms (at least not in the code) because on those platforms CriticalPriority is the same as MaxPriority. No runtime mapping needed. For compiler threads and the CMS background thread on non-Solaris platforms, using critical priority will up their priority, which is new. I don't know what other equivalent (i.e., scheduling classes) to use on non-Solaris platforms. Can you recommend something so I can put it in an RFE? I hesitate to do more than I have because we're at the end of the development cycle for 7u4/hs23. Paul > > Cheers, > David > ----- > >> >> Paul >> >> On 1/23/12 2:11 PM, Paul Hohensee wrote: >>> Thanks for the review. >>> >>> Inline... >>> >>> On 1/22/12 7:39 PM, David Holmes wrote: >>>> Hi Paul, >>>> >>>> The meta-comment here is that there needs to be a clear description >>>> of what "critical priority" means and what constraints there are on >>>> setting it to some OS specific value. For example the current changes >>>> uses the FX scheduling class, but what if someone used the RT >>>> scheduling class instead? Would that work? Probably not, in which >>>> case we should document that this selection of the "critical >>>> priority" is not an arbitrary choice that can be made. >>>> >>>> Even for FX/60 I'm not certain that using this for Java threads might >>>> not prevent safepoints from being reached or induce some other form >>>> of livelock. >>> >>> I added material to the Comments field of the CR. >>> >>> I don't think there's a livelock problem with Java threads, because >>> Solaris takes >>> FX60 as advisory, not as a command. All that should happen is that a >>> critical >>> priority Java thread will get to the safepoint earlier than >>> non-critical ones. >>> I suppose it's possible for critical priority CMS or compiler threads >>> to starve >>> non-critical Java threads, but they run at NearMaxPriority by default >>> now, >>> which can do the same thing. This is definitely an "expert-only" >>> feature >>> though, which is why it's experimental for the time being. >>>> >>>> On 21/01/2012 3:13 AM, Paul Hohensee wrote: >>>>> Webrev here >>>>> >>>>> http://cr.openjdk.java.net/~phh/7091418.00/ >>>>> >>>>> This change defines a new Java pseudo-priority called >>>>> CriticalPriority, just above MaxPriority. Compiler threads, the CMS >>>>> background thread, and Java threads can have the os equivalent of >>>>> this priority. On Solaris, this is the FX/60 scheduling >>>>> class/priority. On other platforms, it's the same as MaxPriority's os >>>>> priority. >>>> >>>> For reference this is why the mapping to FX/60 has been proposed: >>>> >>>> http://blogs.oracle.com/observatory/entry/critical_threads_optimization >>>> >>>> >>>> I still don't fully grok what this optimization does in a general >>>> sense and it seems to be geared to providing better single-threaded >>>> performance on near-idle systems - which doesn't make any sense to me >>>> in a JVM context. But FX/60 also gives you true priority over TS/IA >>>> threads so that may be where the gain comes from. I wonder if any >>>> experiments were actually done using FX/59 rather than the "magical" >>>> FX/60? >>> >>> It's meant to be Solaris-Sparc-specific, but it was easier to >>> implement as a >>> general feature than to specialize it. Given enough cores, FX60 does >>> indeed >>> give you true priority over TS/IA threads. If there aren't enough cores >>> to run both critical threads in single-thread mode and non-critical >>> threads >>> at the same time, Solaris will allow non-critical threads to run on the >>> same core(s) as critical ones. >>> >>> I don't know of any FX59 experiments, but given the amount of work >>> it's taken >>> for the Solaris folks to get FX60 working, I doubt using it would have >>> any positive >>> effect. >>>> >>>>> There are 3 new command line switches, all gated by >>>>> UseExperimentalVMOptions. >>>>> >>>>> -XX:+UseCriticalJavaThreadPriority >>>>> >>>>> Maps Java MAX_PRIORITY to critical priority. >>>> >>>> I found what you have done here to be very confusing. The only place >>>> UseCriticalJavaThreadPriority is used is on Solaris. There you re-map >>>> the priority mapping for priority 10 to the "critical priority" as >>>> described. >>> >>> It's actually used on the other OSs. It just maps to MaxPriority on >>> those. >>> >>>> >>>> On all platforms you added an entry to the priority mapping table(s) >>>> for a non-existent Java priority 11. This provides a way to lookup >>>> the "critical priority" for the CMS/Compiler threads - in essence use >>>> of critical priority for those threads says "pretend these have Java >>>> priority 11" and then you've added a mapping for a priority 11 that >>>> is the same as for priority 10 except on Solaris. On Solaris you had >>>> to use a sentinel value to say "this really means use the "critical >>>> priority" because there is no way to convey a change of scheduling >>>> class. >>>> >>>> It seems to me that we are pretending to have "critical priority" >>>> support on all platforms when in reality we don't. If we want to go >>>> that way then we should extend it to the >>>> UseCriticalJavaThreadPriority case as well. It should be all or >>>> nothing. >>> >>> Extend it beyond making CriticalPriority == MaxPriority on non-Solaris >>> platforms? >>> I.e., we can now change the compiler and CMS thread priority to >>> MaxPriority on >>> non-Solaris platforms. I don't know how to make CriticalPriority >>> higher than that >>> on non-Solaris platforms. >>> >>>> >>>> Further it needs to be made clear that these may still be dependent >>>> on the value of ThreadPriorityPolicy. >>> >>> I added a comment to the CR to that effect. >>> >>>> >>>>> -XX:+UseCriticalCompilerThreadPriority >>>>> >>>>> All compiler threads run at critical priority. >>>> >>>> It should be more clear that UseCriticalCompilerThreadPriority only >>>> applies if CompilerThreadPriority is not set. Perhaps there should >>>> also be a startup check for both being used? >>> >>> I could, but making CompilerThreadPriority rule is what I intended. >>> I'll >>> add a comment to globals.hpp and the CR. >>> >>>> >>>> Thinking more though we really shouldn't need both flags. The basic >>>> problem is that the current "api" only supports setting a simple >>>> number and to use FX/60 also requires a change of scheduling class. >>>> You could add a hack that CompilerThreadPriority=60 means FX/60. Or, >>>> as I've suggested in past email we could generalize the format of the >>>> option to allow both a scheduling class designator and priority to be >>>> passed - that would be a more general mechanism. >>> >>> I didn't want to remove CompilerThreadPriority or change it's effect. >>> I can file a CR >>> to do that though. Current uses of CompilerThreadPriority=60 should >>> work like >>> they always have. >>> >>> I wanted to confine the change as much as possible to Solaris _and_ to >>> limit it >>> to just scheduling classes where we know we're not likely to provoke >>> thread >>> starvation. I can file a CR to add the ability to specify a scheduling >>> class for >>> Java threads. It would probably add 10 switches for scheduling class >>> corresponding >>> to the existing 10 Java priority switches. I don't have any ideas on >>> how to >>> designate particular threads for particular class/priorities. >>> >>>> >>>> Adding a psuedo-priority 11 is just means to work within the current >>>> limitations of the priority scheme. >>> >>> Correct. >>> >>>> >>>>> -XX:+UseCriticalCMSThreadPriority >>>>> >>>>> The CMS background thread runs at critical priority. >>>> >>>> This doesn't make a lot of sense when you consider the comments in >>>> >>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp >>>> >>>> >>>> >>>> which still states: >>>> >>>> "Priority should be just less than that of VMThread" >>>> >>>> This seems to indicate that we don't really understand what the >>>> priority relationship between GC threads and the VMThread should be. >>> >>> No, we don't. That's why this is experimental. >>> >>>> >>>> Should we be able to run the VMThread at FX/60? >>> >>> Perhaps. It only matters for things like serial gc, which isn't used >>> on big iron. >>> >>>> >>>>> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >>>>> native >>>>> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >>>>> decides. >>>> >>>> Is it also dependent on the value of ThreadPriorityPolicy? Should it >>>> be? Does it make sense to use it with either policy value? >>> >>> No, it's not dependent on ThreadPriorityPolicy. Critical priority is >>> the same >>> no matter what the default MaxPriority java_to_os_priority is. I think >>> that's >>> the right thing to do. >>> >>>> >>>>> >>>>> Before this change, the Solaris implementation could only change >>>>> priorities >>>>> within the process scheduling class. It didn't change scheduling >>>>> classes on >>>>> a per-thread basis. I added that capability and used it for the >>>>> critical >>>>> thread >>>>> work. I also fixed a bug where we were using thr_setprio() to save >>>>> the >>>>> original native priority during thread creation and reading it back >>>>> when >>>>> the thread started via thr_getprio(). Since thr_setprio() can change >>>>> the >>>>> user-supplied priority, this resulted in an unintended (lower) >>>>> priority >>>>> being used. >>>> >>>> I don't quite follow this. We used thr_setprio to set the native OS >>>> priority, and we then read it back using thr_getprio and then used >>>> that to pass to thr_setprio again (and also set_lwp_priority). If >>>> thr_setprio can change the user-supplied priority then it can make >>>> that change on the second call too can't it? Does the fact we now >>>> have a lwp affect this? I'm curious about the fact we still both use >>>> thr_setprio and set the LWP priority directly ??? >>> >>> Possibly someone like Dave Dice can answer that question. We were >>> already using >>> both thr_setprio and set_lwp_priority together. Likely that was in >>> case set_lwp_priority >>> wasn't available. >>> >>> thr_setprio takes a value between 0 and 127 and map that to "some >>> priority" that >>> may not be the same as its argument. You can, for example, pass it 127 >>> and >>> get 60 back from thr_getprio. So if we set it once with 127 and then >>> set it again >>> with 60, we can ultimately get back 0. Which is what actually used to >>> happen. >>> >>> Paul >>>> >>>> Cheers, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> Paul >>>>> >>> From jiangli.zhou at oracle.com Tue Jan 24 12:04:53 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 12:04:53 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type Message-ID: <4F1F0EE5.5060401@oracle.com> Hi, Please review the change for 7132690: http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ It changes InstanceKlass::_reference_type from ReferenceType to u1. The ReferenceType is defined as an enum with 6 values (src/share/vm/utilities/globalDefinitions.hpp). The change saves 4-byte for each class. Tested with runThese and ute vm.quick.testlist. Ran jprt. Thanks, Jiangli From dean.long at oracle.com Tue Jan 24 12:09:44 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 24 Jan 2012 12:09:44 -0800 Subject: review request for 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log In-Reply-To: References: <4F1A1935.4090405@oracle.com> <4F1DB442.8030602@oracle.com> Message-ID: <4F1F1008.5010001@oracle.com> Thanks for the review. dl On 1/24/2012 8:38 AM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 23, 2012, at 11:25 AM, Dean Long wrote: > >> http://cr.openjdk.java.net/~dlong/7130319/webrev.00/ >> >> The problem is that the VM thread is trying to exit while another >> thread is writing to the XML log. The VM thread also wants to write >> to the log, but notices the tag stack doesn't match up. A similar >> problem came up before (6295565) and the solution was to relax the >> assertion if we were shutting down through JNI DestroyJavaVM. The >> above change follows that pattern and also allows shutdown >> through JVM_Halt. >> >> More details thanks to David Holmes: >> >> "To be clear the VMThread is writing to the log (actually closing it) as part of exit_globals() while executing VM_Exit::doit. This happens after it calls set_vm_exited() so we add that as a guard against doing the assertion. The problem arises because the CompilerThread was in the middle of some writing (as part of PrintOptoAssembly) when it entered the safepoint that allows the VM to exit." >> >> dl >> >> >> >> From paul.hohensee at oracle.com Tue Jan 24 12:16:27 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Tue, 24 Jan 2012 15:16:27 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1F0C9C.3020007@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> Message-ID: <4F1F119B.2080803@oracle.com> I've filed 7132966: Allow mapping of Java thread priorities to OS scheduling classes as well as priorities to track your recommendation. Paul On 1/24/12 2:55 PM, Paul Hohensee wrote: > Thanks for the review. > > Inline... > > On 1/23/12 11:53 PM, David Holmes wrote: >> Hi Paul, >> >> Warning: long winded response below > > Looking forward to it. :) > >> >> Summary: >> - file RFE to fully support "system" priority for VM internal threads >> - Fully implement UseCriticalJavaThreadPriority on non-Solaris >> >> You'll have to read on to understand what I mean by both of these :) >> >> On 24/01/2012 8:00 AM, Paul Hohensee wrote: >>> I just found >>> >>> 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 >>> on Solaris 10 and 11 >>> >>> which seems like the CR I should actually be using. >>> >>> Ref your last comment on 7082553, we could indeed change the definition >>> of JavaPriority10_To_OSPriority, but that would cover only Java >>> threads, >>> not compiler or the CMS background threads. >> >> Thanks for reminding me about this CR - I knew there had been further >> discussion on this. That CR is not public, which seems a little >> pointless now. > > Yes. I've made 7082553 public and make 7091418 a dup of 7082553. > >> >> I'll restate my concerns as outlined in that CR. It is very difficult >> for an application programmer to determine that FX60 will provide any >> performance benefit, whether assigned to a compiler thread, GC thread >> or Java thread. The benefits of FX60 only exist when a system has >> idle cores, so the application programmer and/or the application >> "deployer" has to know what overall load will exist on the system. >> For the GC and compiler threads this is not such an issue as the >> person deploying the app can simply experiment with the flag being on >> and off and see it it helps in their situation. > > Undoubtedly true that only experts should be using it. There are > significant > Oracle applications running on T4 that contain serial bottlenecks, so > by definition > there are idle cores available. > >> >> For Java threads however the application programmer has to use >> Thread.MAX_PRIORITY. This has two negative consequences. First it >> encourages people to start thinking about Thread priorities when we >> have spent a dozen years telling them to forget about them because in >> 99% of the cases they have no meaning. For them to have meaning you >> have to select non default ThreadPriorityPolicy settings and use the >> right OS - even then you get different affects on different OSes. >> Which leads me to the second consequence: a loss of portability. >> Using Thread.MAX_PRIORITY can have different consequences on >> different platforms, even today. > > That's true. Imo, the correct solution is to invent a QOS API at a > higher abstraction > level, e.g., something like Thread.prefer(SYSTEM_THROUGHPUT) or > Thread.prefer(FAST_RESPONSE_TIME). We wanted to get something useful > sooner > than that though, hence this RFE. Note that it's very much > experimental, which > is why it's use is gated by -XX:+UseExperimentalVMOptions. There's no > guarantee at all that we'll continue to support these switches. > >> >> Ok - so the response to the above is "These are experimental options >> which must be unlocked, and its for advanced users and 'caveat >> emptor'". I can live with that, so lets look at the details of the >> implementation. > > Ah, didn't need to write the above. :) > >> >> There are really two distinct parts to this. First the ability to >> define a special system thread priority. In that regard I like the >> idea of creating a pseudo-priority of 11 and using that to map to >> this system, aka critical, priority (though this could be better >> documented). You then have flags the say "use the system priority for >> threads of type X". This is cross-platform. There are two things I >> find problematic with this though: >> >> 1. As priority is simply a number we can't directly use this to >> implement FX60. Instead we have to put in a hack where a negative >> value on Solaris tells the system specific code "that means FX 60". > > Yes. I could make things a little better by having a negative number > mean > "FX" and to use the positive equivalent directly (i.e., not scale > it). An alternative > would be to add a second mapping array (or make an array of structs) that > contains the desired scheduling class. This seemed like overkill to me > given the limited goal of this change. > >> 2. There is no mechanism, apart from recompiling the VM, to actually >> control what this system/critical priority is. > > True. > >> >> So this general purpose mechanism falls somewhat short of being >> generally useful as a cross-platform mechanism. I find both of these >> unsatisfactory and a RFE should be filed to address them. > > It's intended to be Solaris-only right now, which is why I didn't > implement the > full-blown solution on non-Solaris platforms. Rather I made it > incidental to > an understandable Solaris implementation, esp. the common code parts > in compileBroker.cpp and concurrentMarkSweepThread.cpp. > > I'll file an RFE along the lines of being able to specify a scheduling > class > and priority for each Java thread priority. Either extend > JavaPriority_To_OSPriority > to take a CSV list argument (which is coming to the command line > parser at > some point anyway), or add 10 more switches to specify the scheduling > class. > >> >> The second part is the "map Thread.MAX_PRIORITY to the critical >> priority" part. On Solaris you use UseCriticalJavaThreadPriority to >> actually update the priority mapping 10 -> critical. But you don't do >> this on the other platforms. This is what I object to - if you are >> going to make this a cross-platform setting then it should be >> implemented fully on all platforms. It doesn't matter that by default >> the end result is the same, the code should be there so that if you >> could define the critical priority at runtime things would work as >> expected. > > I didn't do it on non-Solaris platforms (at least not in the code) > because on those > platforms CriticalPriority is the same as MaxPriority. No runtime > mapping needed. > For compiler threads and the CMS background thread on non-Solaris > platforms, > using critical priority will up their priority, which is new. > > I don't know what other equivalent (i.e., scheduling classes) to use > on non-Solaris > platforms. Can you recommend something so I can put it in an RFE? I > hesitate to > do more than I have because we're at the end of the development cycle > for 7u4/hs23. > > Paul > >> >> Cheers, >> David >> ----- >> >>> >>> Paul >>> >>> On 1/23/12 2:11 PM, Paul Hohensee wrote: >>>> Thanks for the review. >>>> >>>> Inline... >>>> >>>> On 1/22/12 7:39 PM, David Holmes wrote: >>>>> Hi Paul, >>>>> >>>>> The meta-comment here is that there needs to be a clear description >>>>> of what "critical priority" means and what constraints there are on >>>>> setting it to some OS specific value. For example the current changes >>>>> uses the FX scheduling class, but what if someone used the RT >>>>> scheduling class instead? Would that work? Probably not, in which >>>>> case we should document that this selection of the "critical >>>>> priority" is not an arbitrary choice that can be made. >>>>> >>>>> Even for FX/60 I'm not certain that using this for Java threads might >>>>> not prevent safepoints from being reached or induce some other form >>>>> of livelock. >>>> >>>> I added material to the Comments field of the CR. >>>> >>>> I don't think there's a livelock problem with Java threads, because >>>> Solaris takes >>>> FX60 as advisory, not as a command. All that should happen is that a >>>> critical >>>> priority Java thread will get to the safepoint earlier than >>>> non-critical ones. >>>> I suppose it's possible for critical priority CMS or compiler threads >>>> to starve >>>> non-critical Java threads, but they run at NearMaxPriority by default >>>> now, >>>> which can do the same thing. This is definitely an "expert-only" >>>> feature >>>> though, which is why it's experimental for the time being. >>>>> >>>>> On 21/01/2012 3:13 AM, Paul Hohensee wrote: >>>>>> Webrev here >>>>>> >>>>>> http://cr.openjdk.java.net/~phh/7091418.00/ >>>>>> >>>>>> This change defines a new Java pseudo-priority called >>>>>> CriticalPriority, just above MaxPriority. Compiler threads, the CMS >>>>>> background thread, and Java threads can have the os equivalent of >>>>>> this priority. On Solaris, this is the FX/60 scheduling >>>>>> class/priority. On other platforms, it's the same as >>>>>> MaxPriority's os >>>>>> priority. >>>>> >>>>> For reference this is why the mapping to FX/60 has been proposed: >>>>> >>>>> http://blogs.oracle.com/observatory/entry/critical_threads_optimization >>>>> >>>>> >>>>> I still don't fully grok what this optimization does in a general >>>>> sense and it seems to be geared to providing better single-threaded >>>>> performance on near-idle systems - which doesn't make any sense to me >>>>> in a JVM context. But FX/60 also gives you true priority over TS/IA >>>>> threads so that may be where the gain comes from. I wonder if any >>>>> experiments were actually done using FX/59 rather than the "magical" >>>>> FX/60? >>>> >>>> It's meant to be Solaris-Sparc-specific, but it was easier to >>>> implement as a >>>> general feature than to specialize it. Given enough cores, FX60 does >>>> indeed >>>> give you true priority over TS/IA threads. If there aren't enough >>>> cores >>>> to run both critical threads in single-thread mode and non-critical >>>> threads >>>> at the same time, Solaris will allow non-critical threads to run on >>>> the >>>> same core(s) as critical ones. >>>> >>>> I don't know of any FX59 experiments, but given the amount of work >>>> it's taken >>>> for the Solaris folks to get FX60 working, I doubt using it would have >>>> any positive >>>> effect. >>>>> >>>>>> There are 3 new command line switches, all gated by >>>>>> UseExperimentalVMOptions. >>>>>> >>>>>> -XX:+UseCriticalJavaThreadPriority >>>>>> >>>>>> Maps Java MAX_PRIORITY to critical priority. >>>>> >>>>> I found what you have done here to be very confusing. The only place >>>>> UseCriticalJavaThreadPriority is used is on Solaris. There you re-map >>>>> the priority mapping for priority 10 to the "critical priority" as >>>>> described. >>>> >>>> It's actually used on the other OSs. It just maps to MaxPriority on >>>> those. >>>> >>>>> >>>>> On all platforms you added an entry to the priority mapping table(s) >>>>> for a non-existent Java priority 11. This provides a way to lookup >>>>> the "critical priority" for the CMS/Compiler threads - in essence use >>>>> of critical priority for those threads says "pretend these have Java >>>>> priority 11" and then you've added a mapping for a priority 11 that >>>>> is the same as for priority 10 except on Solaris. On Solaris you had >>>>> to use a sentinel value to say "this really means use the "critical >>>>> priority" because there is no way to convey a change of scheduling >>>>> class. >>>>> >>>>> It seems to me that we are pretending to have "critical priority" >>>>> support on all platforms when in reality we don't. If we want to go >>>>> that way then we should extend it to the >>>>> UseCriticalJavaThreadPriority case as well. It should be all or >>>>> nothing. >>>> >>>> Extend it beyond making CriticalPriority == MaxPriority on non-Solaris >>>> platforms? >>>> I.e., we can now change the compiler and CMS thread priority to >>>> MaxPriority on >>>> non-Solaris platforms. I don't know how to make CriticalPriority >>>> higher than that >>>> on non-Solaris platforms. >>>> >>>>> >>>>> Further it needs to be made clear that these may still be dependent >>>>> on the value of ThreadPriorityPolicy. >>>> >>>> I added a comment to the CR to that effect. >>>> >>>>> >>>>>> -XX:+UseCriticalCompilerThreadPriority >>>>>> >>>>>> All compiler threads run at critical priority. >>>>> >>>>> It should be more clear that UseCriticalCompilerThreadPriority only >>>>> applies if CompilerThreadPriority is not set. Perhaps there should >>>>> also be a startup check for both being used? >>>> >>>> I could, but making CompilerThreadPriority rule is what I intended. >>>> I'll >>>> add a comment to globals.hpp and the CR. >>>> >>>>> >>>>> Thinking more though we really shouldn't need both flags. The basic >>>>> problem is that the current "api" only supports setting a simple >>>>> number and to use FX/60 also requires a change of scheduling class. >>>>> You could add a hack that CompilerThreadPriority=60 means FX/60. Or, >>>>> as I've suggested in past email we could generalize the format of the >>>>> option to allow both a scheduling class designator and priority to be >>>>> passed - that would be a more general mechanism. >>>> >>>> I didn't want to remove CompilerThreadPriority or change it's effect. >>>> I can file a CR >>>> to do that though. Current uses of CompilerThreadPriority=60 should >>>> work like >>>> they always have. >>>> >>>> I wanted to confine the change as much as possible to Solaris _and_ to >>>> limit it >>>> to just scheduling classes where we know we're not likely to provoke >>>> thread >>>> starvation. I can file a CR to add the ability to specify a scheduling >>>> class for >>>> Java threads. It would probably add 10 switches for scheduling class >>>> corresponding >>>> to the existing 10 Java priority switches. I don't have any ideas on >>>> how to >>>> designate particular threads for particular class/priorities. >>>> >>>>> >>>>> Adding a psuedo-priority 11 is just means to work within the current >>>>> limitations of the priority scheme. >>>> >>>> Correct. >>>> >>>>> >>>>>> -XX:+UseCriticalCMSThreadPriority >>>>>> >>>>>> The CMS background thread runs at critical priority. >>>>> >>>>> This doesn't make a lot of sense when you consider the comments in >>>>> >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp >>>>> >>>>> >>>>> >>>>> which still states: >>>>> >>>>> "Priority should be just less than that of VMThread" >>>>> >>>>> This seems to indicate that we don't really understand what the >>>>> priority relationship between GC threads and the VMThread should be. >>>> >>>> No, we don't. That's why this is experimental. >>>> >>>>> >>>>> Should we be able to run the VMThread at FX/60? >>>> >>>> Perhaps. It only matters for things like serial gc, which isn't used >>>> on big iron. >>>> >>>>> >>>>>> On Solaris, one must in addition use -XX:+UseThreadPriorities to use >>>>>> native >>>>>> priorities at all. Otherwise, Hotspot just accepts whatever Solaris >>>>>> decides. >>>>> >>>>> Is it also dependent on the value of ThreadPriorityPolicy? Should it >>>>> be? Does it make sense to use it with either policy value? >>>> >>>> No, it's not dependent on ThreadPriorityPolicy. Critical priority is >>>> the same >>>> no matter what the default MaxPriority java_to_os_priority is. I think >>>> that's >>>> the right thing to do. >>>> >>>>> >>>>>> >>>>>> Before this change, the Solaris implementation could only change >>>>>> priorities >>>>>> within the process scheduling class. It didn't change scheduling >>>>>> classes on >>>>>> a per-thread basis. I added that capability and used it for the >>>>>> critical >>>>>> thread >>>>>> work. I also fixed a bug where we were using thr_setprio() to >>>>>> save the >>>>>> original native priority during thread creation and reading it back >>>>>> when >>>>>> the thread started via thr_getprio(). Since thr_setprio() can change >>>>>> the >>>>>> user-supplied priority, this resulted in an unintended (lower) >>>>>> priority >>>>>> being used. >>>>> >>>>> I don't quite follow this. We used thr_setprio to set the native OS >>>>> priority, and we then read it back using thr_getprio and then used >>>>> that to pass to thr_setprio again (and also set_lwp_priority). If >>>>> thr_setprio can change the user-supplied priority then it can make >>>>> that change on the second call too can't it? Does the fact we now >>>>> have a lwp affect this? I'm curious about the fact we still both use >>>>> thr_setprio and set the LWP priority directly ??? >>>> >>>> Possibly someone like Dave Dice can answer that question. We were >>>> already using >>>> both thr_setprio and set_lwp_priority together. Likely that was in >>>> case set_lwp_priority >>>> wasn't available. >>>> >>>> thr_setprio takes a value between 0 and 127 and map that to "some >>>> priority" that >>>> may not be the same as its argument. You can, for example, pass it 127 >>>> and >>>> get 60 back from thr_getprio. So if we set it once with 127 and then >>>> set it again >>>> with 60, we can ultimately get back 0. Which is what actually used to >>>> happen. >>>> >>>> Paul >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Thanks, >>>>>> >>>>>> Paul >>>>>> >>>> From vitalyd at gmail.com Tue Jan 24 14:13:48 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 24 Jan 2012 17:13:48 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F0EE5.5060401@oracle.com> References: <4F1F0EE5.5060401@oracle.com> Message-ID: Hi Jiangli, This is probably overly paranoid so feel free to ignore, but should the setter in InstanceKlass assert that the passed in ReferenceType fits into a u1 instead of silently narrowing it? Or change the setter to take a u1 and make caller do the cast? This would prevent someone defining another member of the enum with an explicit value that doesn't fit into u1. Like I said, paranoia ... :) Thanks Sent from my phone On Jan 24, 2012 3:06 PM, "Jiangli Zhou" wrote: > Hi, > > Please review the change for 7132690: > > http://cr.openjdk.java.net/~**jiangli/7132690/webrev.00/ > > It changes InstanceKlass::_reference_type from ReferenceType to u1. The > ReferenceType is defined as an enum with 6 values (src/share/vm/utilities/ > **globalDefinitions.hpp). The change saves 4-byte for each class. > > Tested with runThese and ute vm.quick.testlist. Ran jprt. > > Thanks, > > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/962dae2b/attachment-0001.html From jiangli.zhou at oracle.com Tue Jan 24 14:54:38 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 14:54:38 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> Message-ID: <4F1F36AE.6060001@oracle.com> Hi Vitaly, An assert in the setter probably is a good idea. I should have added it when making the change. Thanks for the comments! Thanks, Jiangli On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: > > Hi Jiangli, > > This is probably overly paranoid so feel free to ignore, but should > the setter in InstanceKlass assert that the passed in ReferenceType > fits into a u1 instead of silently narrowing it? Or change the setter > to take a u1 and make caller do the cast? This would prevent someone > defining another member of the enum with an explicit value that > doesn't fit into u1. Like I said, paranoia ... :) > > Thanks > > Sent from my phone > > On Jan 24, 2012 3:06 PM, "Jiangli Zhou" > wrote: > > Hi, > > Please review the change for 7132690: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ > > > It changes InstanceKlass::_reference_type from ReferenceType to > u1. The ReferenceType is defined as an enum with 6 values > (src/share/vm/utilities/globalDefinitions.hpp). The change saves > 4-byte for each class. > > Tested with runThese and ute vm.quick.testlist. Ran jprt. > > Thanks, > > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/d1465722/attachment.html From paul.hohensee at oracle.com Tue Jan 24 15:20:42 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Tue, 24 Jan 2012 23:20:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Message-ID: <20120124232044.7364247177@hg.openjdk.java.net> Changeset: d6660fedbab5 Author: phh Date: 2012-01-24 14:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d6660fedbab5 7126732: MAC: Require Mac OS X builds/tests for JPRT integrate jobs for HotSpot Summary: Modify jprt.properties to run OSX builds and tests. Reviewed-by: dcubed, kamg, ohair, dholmes Contributed-by: james.melvin at oracle.com ! make/jprt.properties From jiangli.zhou at oracle.com Tue Jan 24 15:33:33 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 15:33:33 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F36AE.6060001@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> Message-ID: <4F1F3FCD.4060704@oracle.com> The updated webrev is : http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ Thanks, Jiangli On 01/24/2012 02:54 PM, Jiangli Zhou wrote: > Hi Vitaly, > > An assert in the setter probably is a good idea. I should have added > it when making the change. Thanks for the comments! > > Thanks, > Jiangli > > On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >> >> Hi Jiangli, >> >> This is probably overly paranoid so feel free to ignore, but should >> the setter in InstanceKlass assert that the passed in ReferenceType >> fits into a u1 instead of silently narrowing it? Or change the setter >> to take a u1 and make caller do the cast? This would prevent someone >> defining another member of the enum with an explicit value that >> doesn't fit into u1. Like I said, paranoia ... :) >> >> Thanks >> >> Sent from my phone >> >> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" > > wrote: >> >> Hi, >> >> Please review the change for 7132690: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >> >> >> It changes InstanceKlass::_reference_type from ReferenceType to >> u1. The ReferenceType is defined as an enum with 6 values >> (src/share/vm/utilities/globalDefinitions.hpp). The change saves >> 4-byte for each class. >> >> Tested with runThese and ute vm.quick.testlist. Ran jprt. >> >> Thanks, >> >> Jiangli >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/5bcfb1f6/attachment.html From vitalyd at gmail.com Tue Jan 24 16:17:06 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 24 Jan 2012 19:17:06 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F3FCD.4060704@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> Message-ID: I think you'll be fully covered (including negative values) by doing the following instead of hard coding max value in the assert: assert(t == (u1)t, "doesn't fit") Sent from my phone On Jan 24, 2012 6:33 PM, "Jiangli Zhou" wrote: > ** > The updated webrev is : > http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ > > Thanks, > Jiangli > > On 01/24/2012 02:54 PM, Jiangli Zhou wrote: > > Hi Vitaly, > > An assert in the setter probably is a good idea. I should have added it > when making the change. Thanks for the comments! > > Thanks, > Jiangli > > On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: > > Hi Jiangli, > > This is probably overly paranoid so feel free to ignore, but should the > setter in InstanceKlass assert that the passed in ReferenceType fits into a > u1 instead of silently narrowing it? Or change the setter to take a u1 and > make caller do the cast? This would prevent someone defining another member > of the enum with an explicit value that doesn't fit into u1. Like I said, > paranoia ... :) > > Thanks > > Sent from my phone > On Jan 24, 2012 3:06 PM, "Jiangli Zhou" wrote: > >> Hi, >> >> Please review the change for 7132690: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >> >> It changes InstanceKlass::_reference_type from ReferenceType to u1. The >> ReferenceType is defined as an enum with 6 values >> (src/share/vm/utilities/globalDefinitions.hpp). The change saves 4-byte for >> each class. >> >> Tested with runThese and ute vm.quick.testlist. Ran jprt. >> >> Thanks, >> >> Jiangli >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/3c2e91f2/attachment.html From jiangli.zhou at oracle.com Tue Jan 24 19:19:45 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 24 Jan 2012 19:19:45 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> Message-ID: <4F1F74D1.1040708@oracle.com> Hi Vitaly, Thanks for catching it! A range check seems to be more explicit in this case: http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ Thanks, Jiangli On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: > > I think you'll be fully covered (including negative values) by doing > the following instead of hard coding max value in the assert: > > assert(t == (u1)t, "doesn't fit") > > Sent from my phone > > On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > wrote: > > The updated webrev is : > http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ > > > Thanks, > Jiangli > > On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >> Hi Vitaly, >> >> An assert in the setter probably is a good idea. I should have >> added it when making the change. Thanks for the comments! >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>> >>> Hi Jiangli, >>> >>> This is probably overly paranoid so feel free to ignore, but >>> should the setter in InstanceKlass assert that the passed in >>> ReferenceType fits into a u1 instead of silently narrowing it? >>> Or change the setter to take a u1 and make caller do the cast? >>> This would prevent someone defining another member of the enum >>> with an explicit value that doesn't fit into u1. Like I said, >>> paranoia ... :) >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >> > wrote: >>> >>> Hi, >>> >>> Please review the change for 7132690: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>> >>> >>> It changes InstanceKlass::_reference_type from ReferenceType >>> to u1. The ReferenceType is defined as an enum with 6 values >>> (src/share/vm/utilities/globalDefinitions.hpp). The change >>> saves 4-byte for each class. >>> >>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>> >>> Thanks, >>> >>> Jiangli >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/c49e9a33/attachment-0001.html From dean.long at oracle.com Tue Jan 24 19:55:48 2012 From: dean.long at oracle.com (Dean Long) Date: Tue, 24 Jan 2012 19:55:48 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F74D1.1040708@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> Message-ID: <4F1F7D44.6000502@oracle.com> I agree with Vitaly. You can find existing examples in the code: interpreter/rewriter.cpp: assert(cache_index == (u1)cache_index, "index overflow"); You could also assert that reference_type == t after the assignment. dl On 1/24/2012 7:19 PM, Jiangli Zhou wrote: > Hi Vitaly, > > Thanks for catching it! A range check seems to be more explicit in > this case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >> >> I think you'll be fully covered (including negative values) by doing >> the following instead of hard coding max value in the assert: >> >> assert(t == (u1)t, "doesn't fit") >> >> Sent from my phone >> >> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > > wrote: >> >> The updated webrev is : >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >> >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>> Hi Vitaly, >>> >>> An assert in the setter probably is a good idea. I should have >>> added it when making the change. Thanks for the comments! >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>> >>>> Hi Jiangli, >>>> >>>> This is probably overly paranoid so feel free to ignore, but >>>> should the setter in InstanceKlass assert that the passed in >>>> ReferenceType fits into a u1 instead of silently narrowing it? >>>> Or change the setter to take a u1 and make caller do the cast? >>>> This would prevent someone defining another member of the enum >>>> with an explicit value that doesn't fit into u1. Like I said, >>>> paranoia ... :) >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>> > wrote: >>>> >>>> Hi, >>>> >>>> Please review the change for 7132690: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>> >>>> >>>> It changes InstanceKlass::_reference_type from >>>> ReferenceType to u1. The ReferenceType is defined as an >>>> enum with 6 values >>>> (src/share/vm/utilities/globalDefinitions.hpp). The change >>>> saves 4-byte for each class. >>>> >>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/7bd69106/attachment.html From vitalyd at gmail.com Tue Jan 24 20:41:55 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 24 Jan 2012 23:41:55 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F74D1.1040708@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> Message-ID: Hi Jiangli, I think doing the comparison via the cast and == check to make sure it "roundtrips" is better than explicit range check because this way you don't have to change the assert if you change the width of the type (e.g. using u2 instead of u1 would require updating the range). Plus as Dean mentioned, it looks like the cast version is already used in the codebase. Cheers Sent from my phone On Jan 24, 2012 10:19 PM, "Jiangli Zhou" wrote: > ** > Hi Vitaly, > > Thanks for catching it! A range check seems to be more explicit in this > case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: > > I think you'll be fully covered (including negative values) by doing the > following instead of hard coding max value in the assert: > > assert(t == (u1)t, "doesn't fit") > > Sent from my phone > On Jan 24, 2012 6:33 PM, "Jiangli Zhou" wrote: > >> The updated webrev is : >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >> >> Hi Vitaly, >> >> An assert in the setter probably is a good idea. I should have added it >> when making the change. Thanks for the comments! >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >> >> Hi Jiangli, >> >> This is probably overly paranoid so feel free to ignore, but should the >> setter in InstanceKlass assert that the passed in ReferenceType fits into a >> u1 instead of silently narrowing it? Or change the setter to take a u1 and >> make caller do the cast? This would prevent someone defining another member >> of the enum with an explicit value that doesn't fit into u1. Like I said, >> paranoia ... :) >> >> Thanks >> >> Sent from my phone >> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" wrote: >> >>> Hi, >>> >>> Please review the change for 7132690: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>> >>> It changes InstanceKlass::_reference_type from ReferenceType to u1. The >>> ReferenceType is defined as an enum with 6 values >>> (src/share/vm/utilities/globalDefinitions.hpp). The change saves 4-byte for >>> each class. >>> >>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>> >>> Thanks, >>> >>> Jiangli >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120124/391ea0b1/attachment.html From dmitriy.samersoff at oracle.com Tue Jan 24 22:23:08 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Wed, 25 Jan 2012 06:23:08 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120125062314.2422047187@hg.openjdk.java.net> Changeset: bf864f701a4a Author: dsamersoff Date: 2012-01-25 02:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf864f701a4a 7066129: GarbageCollectorMXBean#getLastGcInfo leaks native memory Summary: Make GCStatInfo a resource object Reviewed-by: phh, coleenp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp Changeset: df88f58f3b61 Author: dsamersoff Date: 2012-01-24 20:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/df88f58f3b61 Merge From david.holmes at oracle.com Tue Jan 24 23:30:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Jan 2012 17:30:04 +1000 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1F0C9C.3020007@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> Message-ID: <4F1FAF7C.1090608@oracle.com> On 25/01/2012 5:55 AM, Paul Hohensee wrote: > Thanks for the review. You're most welcome :) > Inline... >> The second part is the "map Thread.MAX_PRIORITY to the critical >> priority" part. On Solaris you use UseCriticalJavaThreadPriority to >> actually update the priority mapping 10 -> critical. But you don't do >> this on the other platforms. This is what I object to - if you are >> going to make this a cross-platform setting then it should be >> implemented fully on all platforms. It doesn't matter that by default >> the end result is the same, the code should be there so that if you >> could define the critical priority at runtime things would work as >> expected. > > I didn't do it on non-Solaris platforms (at least not in the code) > because on those platforms CriticalPriority is the same as > MaxPriority. No runtime mapping needed. For compiler threads and the > CMS background thread on non-Solaris platforms, using critical > priority will up their priority, which is new. All I'm looking for on linux for example is that in prio_init() you add: if (UseCriticalJavaThreadPriority) { os::java_to_os_priority[MaxPriority] = os::java_to_os_priority[CriticalPriority] ; } That way if someone decides they want to try changing the priority table from -5 // 11 CriticalPriority to -25 // 11 CriticalPriority then UseCriticalJavaThreadPriority will "just work". Thanks, David ----- From david.holmes at oracle.com Tue Jan 24 23:44:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Jan 2012 17:44:59 +1000 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> Message-ID: <4F1FB2FB.5060208@oracle.com> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: > Hi Jiangli, > > I think doing the comparison via the cast and == check to make sure it > "roundtrips" is better than explicit range check because this way you > don't have to change the assert if you change the width of the type > (e.g. using u2 instead of u1 would require updating the range). Plus as > Dean mentioned, it looks like the cast version is already used in the > codebase. Plus the range check assumes that the enum will never have negative values (not likely here but why preclude it). David > Cheers > > Sent from my phone > > On Jan 24, 2012 10:19 PM, "Jiangli Zhou" > wrote: > > __ > Hi Vitaly, > > Thanks for catching it! A range check seems to be more explicit in > this case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >> >> I think you'll be fully covered (including negative values) by >> doing the following instead of hard coding max value in the assert: >> >> assert(t == (u1)t, "doesn't fit") >> >> Sent from my phone >> >> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > > wrote: >> >> The updated webrev is : >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >> >> >> Thanks, >> Jiangli >> >> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>> Hi Vitaly, >>> >>> An assert in the setter probably is a good idea. I should >>> have added it when making the change. Thanks for the comments! >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>> >>>> Hi Jiangli, >>>> >>>> This is probably overly paranoid so feel free to ignore, but >>>> should the setter in InstanceKlass assert that the passed in >>>> ReferenceType fits into a u1 instead of silently narrowing >>>> it? Or change the setter to take a u1 and make caller do the >>>> cast? This would prevent someone defining another member of >>>> the enum with an explicit value that doesn't fit into u1. >>>> Like I said, paranoia ... :) >>>> >>>> Thanks >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review the change for 7132690: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>> >>>> >>>> It changes InstanceKlass::_reference_type from >>>> ReferenceType to u1. The ReferenceType is defined as an >>>> enum with 6 values >>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>> change saves 4-byte for each class. >>>> >>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>> >> > From paul.hohensee at oracle.com Wed Jan 25 03:38:15 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Wed, 25 Jan 2012 11:38:15 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120125113821.382CC4718E@hg.openjdk.java.net> Changeset: e8a4934564b2 Author: phh Date: 2012-01-24 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8a4934564b2 7125793: MAC: test_gamma should always work Summary: Fix gamma launcher on Mac OS X and reconcile test_gamma script on Unix platforms Reviewed-by: dcubed, ohair, jcoomes, dholmes, ksrini Contributed-by: james.melvin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/solaris/makefiles/buildtree.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/posix/launcher/java_md.c Changeset: 78dadb7b16ab Author: phh Date: 2012-01-25 01:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/78dadb7b16ab Merge From paul.hohensee at oracle.com Wed Jan 25 05:42:49 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 25 Jan 2012 08:42:49 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1FAF7C.1090608@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> <4F1FAF7C.1090608@oracle.com> Message-ID: <4F2006D9.60604@oracle.com> Good idea, will do. Paul On 1/25/12 2:30 AM, David Holmes wrote: > On 25/01/2012 5:55 AM, Paul Hohensee wrote: >> Thanks for the review. > > You're most welcome :) > >> Inline... > > > >>> The second part is the "map Thread.MAX_PRIORITY to the critical >>> priority" part. On Solaris you use UseCriticalJavaThreadPriority to >>> actually update the priority mapping 10 -> critical. But you don't do >>> this on the other platforms. This is what I object to - if you are >>> going to make this a cross-platform setting then it should be >>> implemented fully on all platforms. It doesn't matter that by default >>> the end result is the same, the code should be there so that if you >>> could define the critical priority at runtime things would work as >>> expected. >> >> I didn't do it on non-Solaris platforms (at least not in the code) >> because on those platforms CriticalPriority is the same as >> MaxPriority. No runtime mapping needed. For compiler threads and the >> CMS background thread on non-Solaris platforms, using critical >> priority will up their priority, which is new. > > All I'm looking for on linux for example is that in prio_init() you add: > > if (UseCriticalJavaThreadPriority) { > os::java_to_os_priority[MaxPriority] = > os::java_to_os_priority[CriticalPriority] ; > } > > That way if someone decides they want to try changing the priority > table from > > -5 // 11 CriticalPriority > > to > > -25 // 11 CriticalPriority > > then UseCriticalJavaThreadPriority will "just work". > > Thanks, > David > ----- > From bob.vandette at oracle.com Wed Jan 25 06:07:38 2012 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Wed, 25 Jan 2012 14:07:38 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 25 new changesets Message-ID: <20120125140830.9F66F47191@hg.openjdk.java.net> Changeset: b0ff910edfc9 Author: kvn Date: 2012-01-12 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/b0ff910edfc9 7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed Summary: Do not common BoxLock nodes and avoid creating phis of boxes. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/parse1.cpp Changeset: f4d8930a45b9 Author: jrose Date: 2012-01-13 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f4d8930a45b9 Merge Changeset: 89d0a5d40008 Author: kvn Date: 2012-01-13 12:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/89d0a5d40008 7129618: assert(obj_node->eqv_uncast(obj),""); Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks). Reviewed-by: iveresov ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/macro.cpp Changeset: e504fd26c073 Author: kvn Date: 2012-01-13 14:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e504fd26c073 Merge Changeset: fe2c87649981 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/fe2c87649981 Added tag jdk8-b19 for changeset 9232e0ecbc2c ! .hgtags Changeset: 9952d1c439d6 Author: katleman Date: 2012-01-05 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/9952d1c439d6 Added tag jdk8-b20 for changeset fe2c87649981 ! .hgtags Changeset: ed621d125d02 Author: katleman Date: 2012-01-13 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/ed621d125d02 Added tag jdk8-b21 for changeset 9952d1c439d6 ! .hgtags Changeset: 513351373923 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/513351373923 Merge Changeset: 24727fb37561 Author: amurillo Date: 2012-01-14 00:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/24727fb37561 Added tag hs23-b10 for changeset 513351373923 ! .hgtags Changeset: 4e80db53c323 Author: amurillo Date: 2012-01-14 00:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4e80db53c323 7129512: new hotspot build - hs23-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 94ec88ca68e2 Author: phh Date: 2012-01-11 17:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/94ec88ca68e2 7115199: Add event tracing hooks and Java Flight Recorder infrastructure Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR. Reviewed-by: acorn, sspitsyn Contributed-by: markus.gronlund at oracle.com ! make/Makefile ! make/bsd/makefiles/vm.make ! make/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jni.cpp + src/share/vm/prims/jniExport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp + src/share/vm/trace/traceEventTypes.hpp + src/share/vm/trace/traceMacros.hpp + src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4f3ce9284781 Author: phh Date: 2012-01-11 17:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/4f3ce9284781 Merge ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp Changeset: f1cd52d6ce02 Author: kamg Date: 2012-01-17 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f1cd52d6ce02 Merge Changeset: d7e3846464d0 Author: zgu Date: 2012-01-17 13:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d7e3846464d0 7071311: Decoder enhancement Summary: Made decoder thread-safe Reviewed-by: coleenp, kamg - src/os/bsd/vm/decoder_bsd.cpp + src/os/bsd/vm/decoder_machO.cpp + src/os/bsd/vm/decoder_machO.hpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp + src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp + src/share/vm/utilities/decoder_elf.cpp + src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 6520f9861937 Author: kamg Date: 2012-01-17 21:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/6520f9861937 Merge Changeset: db18ca98d237 Author: zgu Date: 2012-01-18 11:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/db18ca98d237 7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X Summary: Decoder API changes did not reflect in os_bsd Reviewed-by: kamg, dcubed ! src/os/bsd/vm/os_bsd.cpp Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/50d9b7a0072c Merge Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version From bertrand.delsart at oracle.com Wed Jan 25 08:42:26 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 25 Jan 2012 17:42:26 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle Message-ID: <4F2030F2.1060606@oracle.com> Hi all, Here is the third (and last) frame::describe related CR I wanted to putback: http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ Goal of that RFE was to use the frame::describe debugging output to enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. The change in fact fixes a few minor bugs in the current version of trace_method_handle. Main changes are: - make frame::describe available in all non-product builds (else we could no longer build in "optimized" mode) - improvements of trace_method_handle for SPARC * protect FP result register, which was corrupted by traces * protect all globals (G6 corruption caused an issue) * walk up to the right frame to dump * safely build a frame on which to call describe (see below) - improvements of trace_method_handle for x86 * properly pass r13 (and not rsi) as the saved_sp on LP64 * protect FP result register, which was corrupted by traces * build a real frame in the stub wrapper to allow stack walking * walk up to the right frame to dump * safely build a frame on which to call describe (see below) Note on the "safely build a frame": trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. Regards, Bertrand -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: TRACE_EXAMPLE Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120125/fa4cabac/TRACE_EXAMPLE-0001.ksh From jiangli.zhou at oracle.com Wed Jan 25 09:19:41 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 09:19:41 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1F7D44.6000502@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1F7D44.6000502@oracle.com> Message-ID: <4F2039AD.2030600@oracle.com> Hi Dean, I was looking for existing code for hotspot conventions. My quick search didn't reveal any. Thanks for the pointer. Thanks, Jiangli Dean Long wrote: > I agree with Vitaly. You can find existing examples in the code: > > interpreter/rewriter.cpp: assert(cache_index == > (u1)cache_index, "index overflow"); > > You could also assert that reference_type == t after the assignment. > > dl > > On 1/24/2012 7:19 PM, Jiangli Zhou wrote: >> Hi Vitaly, >> >> Thanks for catching it! A range check seems to be more explicit in >> this case: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>> >>> I think you'll be fully covered (including negative values) by doing >>> the following instead of hard coding max value in the assert: >>> >>> assert(t == (u1)t, "doesn't fit") >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >> > wrote: >>> >>> The updated webrev is : >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>> >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>> Hi Vitaly, >>>> >>>> An assert in the setter probably is a good idea. I should have >>>> added it when making the change. Thanks for the comments! >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> This is probably overly paranoid so feel free to ignore, but >>>>> should the setter in InstanceKlass assert that the passed in >>>>> ReferenceType fits into a u1 instead of silently narrowing it? >>>>> Or change the setter to take a u1 and make caller do the cast? >>>>> This would prevent someone defining another member of the enum >>>>> with an explicit value that doesn't fit into u1. Like I said, >>>>> paranoia ... :) >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the change for 7132690: >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>> >>>>> >>>>> It changes InstanceKlass::_reference_type from >>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>> enum with 6 values >>>>> (src/share/vm/utilities/globalDefinitions.hpp). The change >>>>> saves 4-byte for each class. >>>>> >>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>>> >>> >> From jiangli.zhou at oracle.com Wed Jan 25 10:32:10 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 10:32:10 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F1FB2FB.5060208@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> Message-ID: <4F204AAA.2070003@oracle.com> Hi Vitaly and David, I've updated the webrev to do a == check via the cast. http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ Thanks, Jiangli On 01/24/2012 11:44 PM, David Holmes wrote: > On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >> Hi Jiangli, >> >> I think doing the comparison via the cast and == check to make sure it >> "roundtrips" is better than explicit range check because this way you >> don't have to change the assert if you change the width of the type >> (e.g. using u2 instead of u1 would require updating the range). Plus as >> Dean mentioned, it looks like the cast version is already used in the >> codebase. > > Plus the range check assumes that the enum will never have negative > values (not likely here but why preclude it). > > David > >> Cheers >> >> Sent from my phone >> >> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" > > wrote: >> >> __ >> Hi Vitaly, >> >> Thanks for catching it! A range check seems to be more explicit in >> this case: >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>> >>> I think you'll be fully covered (including negative values) by >>> doing the following instead of hard coding max value in the assert: >>> >>> assert(t == (u1)t, "doesn't fit") >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >> > wrote: >>> >>> The updated webrev is : >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>> >>> >>> Thanks, >>> Jiangli >>> >>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>> Hi Vitaly, >>>> >>>> An assert in the setter probably is a good idea. I should >>>> have added it when making the change. Thanks for the comments! >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> This is probably overly paranoid so feel free to ignore, but >>>>> should the setter in InstanceKlass assert that the passed in >>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>> it? Or change the setter to take a u1 and make caller do the >>>>> cast? This would prevent someone defining another member of >>>>> the enum with an explicit value that doesn't fit into u1. >>>>> Like I said, paranoia ... :) >>>>> >>>>> Thanks >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the change for 7132690: >>>>> >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>> >>>>> >>>>> It changes InstanceKlass::_reference_type from >>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>> enum with 6 values >>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>> change saves 4-byte for each class. >>>>> >>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>>> >>> >> From vitalyd at gmail.com Wed Jan 25 10:34:26 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 25 Jan 2012 13:34:26 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F204AAA.2070003@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: looks good although I'm not a reviewer :) Vitaly Sent from my phone On Jan 25, 2012 1:33 PM, "Jiangli Zhou" wrote: > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~**jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: > >> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >> >>> Hi Jiangli, >>> >>> I think doing the comparison via the cast and == check to make sure it >>> "roundtrips" is better than explicit range check because this way you >>> don't have to change the assert if you change the width of the type >>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>> Dean mentioned, it looks like the cast version is already used in the >>> codebase. >>> >> >> Plus the range check assumes that the enum will never have negative >> values (not likely here but why preclude it). >> >> David >> >> Cheers >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >> >> wrote: >>> >>> __ >>> Hi Vitaly, >>> >>> Thanks for catching it! A range check seems to be more explicit in >>> this case: >>> >>> http://cr.openjdk.java.net/~**jiangli/7132690/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>> >>>> >>>> I think you'll be fully covered (including negative values) by >>>> doing the following instead of hard coding max value in the assert: >>>> >>>> assert(t == (u1)t, "doesn't fit") >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>> >> wrote: >>>> >>>> The updated webrev is : >>>> http://cr.openjdk.java.net/~**jiangli/7132690/webrev.01/ >>>> >>>> > >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>> >>>>> Hi Vitaly, >>>>> >>>>> An assert in the setter probably is a good idea. I should >>>>> have added it when making the change. Thanks for the comments! >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>> >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>> should the setter in InstanceKlass assert that the passed in >>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>> cast? This would prevent someone defining another member of >>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>> Like I said, paranoia ... :) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>> >>>>>> >> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the change for 7132690: >>>>>> >>>>>> http://cr.openjdk.java.net/~**jiangli/7132690/webrev.00/ >>>>>> >>>>>> > >>>>>> >>>>>> It changes InstanceKlass::_reference_type from >>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>> enum with 6 values >>>>>> (src/share/vm/utilities/**globalDefinitions.hpp). The >>>>>> change saves 4-byte for each class. >>>>>> >>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120125/25f7ebd8/attachment.html From jiangli.zhou at oracle.com Wed Jan 25 10:36:33 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 10:36:33 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: <4F204BB1.8070504@oracle.com> Thanks for the review in any case! :) Jiangli On 01/25/2012 10:34 AM, Vitaly Davidovich wrote: > > looks good although I'm not a reviewer :) > > Vitaly > > Sent from my phone > > On Jan 25, 2012 1:33 PM, "Jiangli Zhou" > wrote: > > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: > > On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: > > Hi Jiangli, > > I think doing the comparison via the cast and == check to > make sure it > "roundtrips" is better than explicit range check because > this way you > don't have to change the assert if you change the width of > the type > (e.g. using u2 instead of u1 would require updating the > range). Plus as > Dean mentioned, it looks like the cast version is already > used in the > codebase. > > > Plus the range check assumes that the enum will never have > negative values (not likely here but why preclude it). > > David > > Cheers > > Sent from my phone > > On Jan 24, 2012 10:19 PM, "Jiangli Zhou" > > >> wrote: > > __ > Hi Vitaly, > > Thanks for catching it! A range check seems to be more > explicit in > this case: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > > Thanks, > > Jiangli > > On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: > > > I think you'll be fully covered (including negative > values) by > doing the following instead of hard coding max > value in the assert: > > assert(t == (u1)t, "doesn't fit") > > Sent from my phone > > On Jan 24, 2012 6:33 PM, "Jiangli Zhou" > > >> wrote: > > The updated webrev is : > http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ > > > > Thanks, > Jiangli > > On 01/24/2012 02:54 PM, Jiangli Zhou wrote: > > Hi Vitaly, > > An assert in the setter probably is a good > idea. I should > have added it when making the change. > Thanks for the comments! > > Thanks, > Jiangli > > On 01/24/2012 02:13 PM, Vitaly Davidovich > wrote: > > > Hi Jiangli, > > This is probably overly paranoid so > feel free to ignore, but > should the setter in InstanceKlass > assert that the passed in > ReferenceType fits into a u1 instead of > silently narrowing > it? Or change the setter to take a u1 > and make caller do the > cast? This would prevent someone > defining another member of > the enum with an explicit value that > doesn't fit into u1. > Like I said, paranoia ... :) > > Thanks > > Sent from my phone > > On Jan 24, 2012 3:06 PM, "Jiangli Zhou" > > >> > wrote: > > Hi, > > Please review the change for 7132690: > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ > > > > It changes > InstanceKlass::_reference_type from > ReferenceType to u1. The > ReferenceType is defined as an > enum with 6 values > > (src/share/vm/utilities/globalDefinitions.hpp). > The > change saves 4-byte for each class. > > Tested with runThese and ute > vm.quick.testlist. Ran jprt. > > Thanks, > > Jiangli > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120125/472ead1a/attachment-0001.html From karen.kinnear at oracle.com Wed Jan 25 10:48:02 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 25 Jan 2012 13:48:02 -0500 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F204AAA.2070003@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: Jiangli, Looks good. thanks, Karen On Jan 25, 2012, at 1:32 PM, Jiangli Zhou wrote: > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: >> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>> Hi Jiangli, >>> >>> I think doing the comparison via the cast and == check to make sure it >>> "roundtrips" is better than explicit range check because this way you >>> don't have to change the assert if you change the width of the type >>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>> Dean mentioned, it looks like the cast version is already used in the >>> codebase. >> >> Plus the range check assumes that the enum will never have negative values (not likely here but why preclude it). >> >> David >> >>> Cheers >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >> > wrote: >>> >>> __ >>> Hi Vitaly, >>> >>> Thanks for catching it! A range check seems to be more explicit in >>> this case: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>> >>>> I think you'll be fully covered (including negative values) by >>>> doing the following instead of hard coding max value in the assert: >>>> >>>> assert(t == (u1)t, "doesn't fit") >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>> > wrote: >>>> >>>> The updated webrev is : >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>> Hi Vitaly, >>>>> >>>>> An assert in the setter probably is a good idea. I should >>>>> have added it when making the change. Thanks for the comments! >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>> should the setter in InstanceKlass assert that the passed in >>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>> cast? This would prevent someone defining another member of >>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>> Like I said, paranoia ... :) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the change for 7132690: >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>> >>>>>> >>>>>> It changes InstanceKlass::_reference_type from >>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>> enum with 6 values >>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>> change saves 4-byte for each class. >>>>>> >>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>> >>>> >>> > From jiangli.zhou at oracle.com Wed Jan 25 11:03:43 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 11:03:43 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: <4F20520F.5060400@oracle.com> Hi Karen, Thanks for the review. Jiangli On 01/25/2012 10:48 AM, Karen Kinnear wrote: > Jiangli, > > Looks good. > > thanks, > Karen > > On Jan 25, 2012, at 1:32 PM, Jiangli Zhou wrote: > >> Hi Vitaly and David, >> >> I've updated the webrev to do a == check via the cast. >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 11:44 PM, David Holmes wrote: >>> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>>> Hi Jiangli, >>>> >>>> I think doing the comparison via the cast and == check to make sure it >>>> "roundtrips" is better than explicit range check because this way you >>>> don't have to change the assert if you change the width of the type >>>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>>> Dean mentioned, it looks like the cast version is already used in the >>>> codebase. >>> Plus the range check assumes that the enum will never have negative values (not likely here but why preclude it). >>> >>> David >>> >>>> Cheers >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou">>> > wrote: >>>> >>>> __ >>>> Hi Vitaly, >>>> >>>> Thanks for catching it! A range check seems to be more explicit in >>>> this case: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>>> I think you'll be fully covered (including negative values) by >>>>> doing the following instead of hard coding max value in the assert: >>>>> >>>>> assert(t == (u1)t, "doesn't fit") >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou">>>> > wrote: >>>>> >>>>> The updated webrev is : >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>>> Hi Vitaly, >>>>>> >>>>>> An assert in the setter probably is a good idea. I should >>>>>> have added it when making the change. Thanks for the comments! >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>>> should the setter in InstanceKlass assert that the passed in >>>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>>> cast? This would prevent someone defining another member of >>>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>>> Like I said, paranoia ... :) >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the change for 7132690: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>>> >>>>>>> >>>>>>> It changes InstanceKlass::_reference_type from >>>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>>> enum with 6 values >>>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>>> change saves 4-byte for each class. >>>>>>> >>>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> From tom.rodriguez at oracle.com Wed Jan 25 11:36:24 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 25 Jan 2012 11:36:24 -0800 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <4F2030F2.1060606@oracle.com> References: <4F2030F2.1060606@oracle.com> Message-ID: <76FD9630-6354-428F-A105-3DE88B28CC0F@oracle.com> Looks good. tom On Jan 25, 2012, at 8:42 AM, Bertrand Delsart wrote: > Hi all, > > Here is the third (and last) frame::describe related CR I wanted to putback: > > http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ > > Goal of that RFE was to use the frame::describe debugging output to > enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. > > The change in fact fixes a few minor bugs in the current version of trace_method_handle. > > Main changes are: > - make frame::describe available in all non-product builds > (else we could no longer build in "optimized" mode) > - improvements of trace_method_handle for SPARC > * protect FP result register, which was corrupted by traces > * protect all globals (G6 corruption caused an issue) > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > - improvements of trace_method_handle for x86 > * properly pass r13 (and not rsi) as the saved_sp on LP64 > * protect FP result register, which was corrupted by traces > * build a real frame in the stub wrapper to allow stack walking > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > > Note on the "safely build a frame": > > trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. > > The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. > > If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. > > Regards, > > Bertrand > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE > From keith.mcguigan at oracle.com Wed Jan 25 11:48:16 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Wed, 25 Jan 2012 19:48:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 10 new changesets Message-ID: <20120125194835.C83EA4719B@hg.openjdk.java.net> Changeset: eaa9557116a2 Author: bdelsart Date: 2012-01-18 16:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/eaa9557116a2 7120448: Fix FP values for compiled frames in frame::describe Summary: fix for debug method frame::describe Reviewed-by: never, kvn ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp Changeset: 15d394228cfa Author: jrose Date: 2012-01-19 13:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/15d394228cfa 7111138: delete the obsolete flag -XX:+UseRicochetFrames Reviewed-by: dholmes, bdelsart, kvn, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 898522ae3c32 Author: iveresov Date: 2012-01-19 10:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/898522ae3c32 7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier) Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 469e0a46f2fe Author: jrose Date: 2012-01-19 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/469e0a46f2fe Merge Changeset: 50d9b7a0072c Author: jrose Date: 2012-01-19 18:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/50d9b7a0072c Merge Changeset: 338d438ee229 Author: katleman Date: 2012-01-20 13:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/338d438ee229 Added tag jdk8-b22 for changeset 24727fb37561 ! .hgtags Changeset: dcc292399a39 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dcc292399a39 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: e850d8e7ea54 Author: amurillo Date: 2012-01-20 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e850d8e7ea54 Added tag hs23-b11 for changeset dcc292399a39 ! .hgtags Changeset: 5f3fcd591768 Author: amurillo Date: 2012-01-20 17:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f3fcd591768 7131979: new hotspot build - hs23-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d708a8cdd022 Author: kamg Date: 2012-01-25 10:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d708a8cdd022 Merge From paul.hohensee at oracle.com Wed Jan 25 15:08:22 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 25 Jan 2012 18:08:22 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F1FAF7C.1090608@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> <4F1FAF7C.1090608@oracle.com> Message-ID: <4F208B66.5000503@oracle.com> New webrev at http://cr.openjdk.java.net/~phh/7091418.01/ It incorporates your suggestion. I need another review, pls. Any takers? Thanks, Paul On 1/25/12 2:30 AM, David Holmes wrote: > On 25/01/2012 5:55 AM, Paul Hohensee wrote: >> Thanks for the review. > > You're most welcome :) > >> Inline... > > > >>> The second part is the "map Thread.MAX_PRIORITY to the critical >>> priority" part. On Solaris you use UseCriticalJavaThreadPriority to >>> actually update the priority mapping 10 -> critical. But you don't do >>> this on the other platforms. This is what I object to - if you are >>> going to make this a cross-platform setting then it should be >>> implemented fully on all platforms. It doesn't matter that by default >>> the end result is the same, the code should be there so that if you >>> could define the critical priority at runtime things would work as >>> expected. >> >> I didn't do it on non-Solaris platforms (at least not in the code) >> because on those platforms CriticalPriority is the same as >> MaxPriority. No runtime mapping needed. For compiler threads and the >> CMS background thread on non-Solaris platforms, using critical >> priority will up their priority, which is new. > > All I'm looking for on linux for example is that in prio_init() you add: > > if (UseCriticalJavaThreadPriority) { > os::java_to_os_priority[MaxPriority] = > os::java_to_os_priority[CriticalPriority] ; > } > > That way if someone decides they want to try changing the priority > table from > > -5 // 11 CriticalPriority > > to > > -25 // 11 CriticalPriority > > then UseCriticalJavaThreadPriority will "just work". > > Thanks, > David > ----- > From david.holmes at oracle.com Wed Jan 25 15:31:07 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2012 09:31:07 +1000 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F208B66.5000503@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> <4F1FAF7C.1090608@oracle.com> <4F208B66.5000503@oracle.com> Message-ID: <4F2090BB.6040104@oracle.com> Thanks Paul. Thumbs up from me. David On 26/01/2012 9:08 AM, Paul Hohensee wrote: > New webrev at > > http://cr.openjdk.java.net/~phh/7091418.01/ > > It incorporates your suggestion. > > I need another review, pls. Any takers? > > Thanks, > > Paul > > On 1/25/12 2:30 AM, David Holmes wrote: >> On 25/01/2012 5:55 AM, Paul Hohensee wrote: >>> Thanks for the review. >> >> You're most welcome :) >> >>> Inline... >> >> >> >>>> The second part is the "map Thread.MAX_PRIORITY to the critical >>>> priority" part. On Solaris you use UseCriticalJavaThreadPriority to >>>> actually update the priority mapping 10 -> critical. But you don't do >>>> this on the other platforms. This is what I object to - if you are >>>> going to make this a cross-platform setting then it should be >>>> implemented fully on all platforms. It doesn't matter that by default >>>> the end result is the same, the code should be there so that if you >>>> could define the critical priority at runtime things would work as >>>> expected. >>> >>> I didn't do it on non-Solaris platforms (at least not in the code) >>> because on those platforms CriticalPriority is the same as >>> MaxPriority. No runtime mapping needed. For compiler threads and the >>> CMS background thread on non-Solaris platforms, using critical >>> priority will up their priority, which is new. >> >> All I'm looking for on linux for example is that in prio_init() you add: >> >> if (UseCriticalJavaThreadPriority) { >> os::java_to_os_priority[MaxPriority] = >> os::java_to_os_priority[CriticalPriority] ; >> } >> >> That way if someone decides they want to try changing the priority >> table from >> >> -5 // 11 CriticalPriority >> >> to >> >> -25 // 11 CriticalPriority >> >> then UseCriticalJavaThreadPriority will "just work". >> >> Thanks, >> David >> ----- >> From paul.hohensee at oracle.com Wed Jan 25 15:39:31 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 25 Jan 2012 18:39:31 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F2090BB.6040104@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> <4F1FAF7C.1090608@oracle.com> <4F208B66.5000503@oracle.com> <4F2090BB.6040104@oracle.com> Message-ID: <4F2092B3.6040102@oracle.com> Thanks! Paul On 1/25/12 6:31 PM, David Holmes wrote: > Thanks Paul. Thumbs up from me. > > David > > On 26/01/2012 9:08 AM, Paul Hohensee wrote: >> New webrev at >> >> http://cr.openjdk.java.net/~phh/7091418.01/ >> >> It incorporates your suggestion. >> >> I need another review, pls. Any takers? >> >> Thanks, >> >> Paul >> >> On 1/25/12 2:30 AM, David Holmes wrote: >>> On 25/01/2012 5:55 AM, Paul Hohensee wrote: >>>> Thanks for the review. >>> >>> You're most welcome :) >>> >>>> Inline... >>> >>> >>> >>>>> The second part is the "map Thread.MAX_PRIORITY to the critical >>>>> priority" part. On Solaris you use UseCriticalJavaThreadPriority to >>>>> actually update the priority mapping 10 -> critical. But you don't do >>>>> this on the other platforms. This is what I object to - if you are >>>>> going to make this a cross-platform setting then it should be >>>>> implemented fully on all platforms. It doesn't matter that by default >>>>> the end result is the same, the code should be there so that if you >>>>> could define the critical priority at runtime things would work as >>>>> expected. >>>> >>>> I didn't do it on non-Solaris platforms (at least not in the code) >>>> because on those platforms CriticalPriority is the same as >>>> MaxPriority. No runtime mapping needed. For compiler threads and the >>>> CMS background thread on non-Solaris platforms, using critical >>>> priority will up their priority, which is new. >>> >>> All I'm looking for on linux for example is that in prio_init() you >>> add: >>> >>> if (UseCriticalJavaThreadPriority) { >>> os::java_to_os_priority[MaxPriority] = >>> os::java_to_os_priority[CriticalPriority] ; >>> } >>> >>> That way if someone decides they want to try changing the priority >>> table from >>> >>> -5 // 11 CriticalPriority >>> >>> to >>> >>> -25 // 11 CriticalPriority >>> >>> then UseCriticalJavaThreadPriority will "just work". >>> >>> Thanks, >>> David >>> ----- >>> From david.holmes at oracle.com Wed Jan 25 17:09:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Jan 2012 11:09:44 +1000 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F204AAA.2070003@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> Message-ID: <4F20A7D8.9030702@oracle.com> Looks good to me. David On 26/01/2012 4:32 AM, Jiangli Zhou wrote: > Hi Vitaly and David, > > I've updated the webrev to do a == check via the cast. > > http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ > > Thanks, > > Jiangli > > On 01/24/2012 11:44 PM, David Holmes wrote: >> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>> Hi Jiangli, >>> >>> I think doing the comparison via the cast and == check to make sure it >>> "roundtrips" is better than explicit range check because this way you >>> don't have to change the assert if you change the width of the type >>> (e.g. using u2 instead of u1 would require updating the range). Plus as >>> Dean mentioned, it looks like the cast version is already used in the >>> codebase. >> >> Plus the range check assumes that the enum will never have negative >> values (not likely here but why preclude it). >> >> David >> >>> Cheers >>> >>> Sent from my phone >>> >>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >> > wrote: >>> >>> __ >>> Hi Vitaly, >>> >>> Thanks for catching it! A range check seems to be more explicit in >>> this case: >>> >>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>> >>> Thanks, >>> >>> Jiangli >>> >>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>> >>>> I think you'll be fully covered (including negative values) by >>>> doing the following instead of hard coding max value in the assert: >>>> >>>> assert(t == (u1)t, "doesn't fit") >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>> > wrote: >>>> >>>> The updated webrev is : >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>> Hi Vitaly, >>>>> >>>>> An assert in the setter probably is a good idea. I should >>>>> have added it when making the change. Thanks for the comments! >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>> >>>>>> Hi Jiangli, >>>>>> >>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>> should the setter in InstanceKlass assert that the passed in >>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>> cast? This would prevent someone defining another member of >>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>> Like I said, paranoia ... :) >>>>>> >>>>>> Thanks >>>>>> >>>>>> Sent from my phone >>>>>> >>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the change for 7132690: >>>>>> >>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>> >>>>>> >>>>>> It changes InstanceKlass::_reference_type from >>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>> enum with 6 values >>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>> change saves 4-byte for each class. >>>>>> >>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>>> >>>> >>> > From jiangli.zhou at oracle.com Wed Jan 25 17:18:02 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 25 Jan 2012 17:18:02 -0800 Subject: Request for review: 7132690 InstanceKlass:_reference_type should be u1 type In-Reply-To: <4F20A7D8.9030702@oracle.com> References: <4F1F0EE5.5060401@oracle.com> <4F1F36AE.6060001@oracle.com> <4F1F3FCD.4060704@oracle.com> <4F1F74D1.1040708@oracle.com> <4F1FB2FB.5060208@oracle.com> <4F204AAA.2070003@oracle.com> <4F20A7D8.9030702@oracle.com> Message-ID: <4F20A9CA.3050207@oracle.com> Thanks, David. Jiangli On 01/25/2012 05:09 PM, David Holmes wrote: > Looks good to me. > > David > > On 26/01/2012 4:32 AM, Jiangli Zhou wrote: >> Hi Vitaly and David, >> >> I've updated the webrev to do a == check via the cast. >> >> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >> >> Thanks, >> >> Jiangli >> >> On 01/24/2012 11:44 PM, David Holmes wrote: >>> On 25/01/2012 2:41 PM, Vitaly Davidovich wrote: >>>> Hi Jiangli, >>>> >>>> I think doing the comparison via the cast and == check to make sure it >>>> "roundtrips" is better than explicit range check because this way you >>>> don't have to change the assert if you change the width of the type >>>> (e.g. using u2 instead of u1 would require updating the range). >>>> Plus as >>>> Dean mentioned, it looks like the cast version is already used in the >>>> codebase. >>> >>> Plus the range check assumes that the enum will never have negative >>> values (not likely here but why preclude it). >>> >>> David >>> >>>> Cheers >>>> >>>> Sent from my phone >>>> >>>> On Jan 24, 2012 10:19 PM, "Jiangli Zhou" >>> > wrote: >>>> >>>> __ >>>> Hi Vitaly, >>>> >>>> Thanks for catching it! A range check seems to be more explicit in >>>> this case: >>>> >>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.02/ >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>> On 01/24/2012 04:17 PM, Vitaly Davidovich wrote: >>>>> >>>>> I think you'll be fully covered (including negative values) by >>>>> doing the following instead of hard coding max value in the assert: >>>>> >>>>> assert(t == (u1)t, "doesn't fit") >>>>> >>>>> Sent from my phone >>>>> >>>>> On Jan 24, 2012 6:33 PM, "Jiangli Zhou" >>>> > wrote: >>>>> >>>>> The updated webrev is : >>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On 01/24/2012 02:54 PM, Jiangli Zhou wrote: >>>>>> Hi Vitaly, >>>>>> >>>>>> An assert in the setter probably is a good idea. I should >>>>>> have added it when making the change. Thanks for the comments! >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> On 01/24/2012 02:13 PM, Vitaly Davidovich wrote: >>>>>>> >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> This is probably overly paranoid so feel free to ignore, but >>>>>>> should the setter in InstanceKlass assert that the passed in >>>>>>> ReferenceType fits into a u1 instead of silently narrowing >>>>>>> it? Or change the setter to take a u1 and make caller do the >>>>>>> cast? This would prevent someone defining another member of >>>>>>> the enum with an explicit value that doesn't fit into u1. >>>>>>> Like I said, paranoia ... :) >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Sent from my phone >>>>>>> >>>>>>> On Jan 24, 2012 3:06 PM, "Jiangli Zhou" >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please review the change for 7132690: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jiangli/7132690/webrev.00/ >>>>>>> >>>>>>> >>>>>>> It changes InstanceKlass::_reference_type from >>>>>>> ReferenceType to u1. The ReferenceType is defined as an >>>>>>> enum with 6 values >>>>>>> (src/share/vm/utilities/globalDefinitions.hpp). The >>>>>>> change saves 4-byte for each class. >>>>>>> >>>>>>> Tested with runThese and ute vm.quick.testlist. Ran jprt. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>>> >>>>> >>>> >> From frederic.parain at oracle.com Wed Jan 25 18:55:35 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 26 Jan 2012 02:55:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120126025539.9D18F471BB@hg.openjdk.java.net> Changeset: 520830f632e7 Author: fparain Date: 2012-01-25 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/520830f632e7 7131346: Parsing of boolean arguments to diagnostic commands is broken Reviewed-by: dholmes, dcubed ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 24ec1a6d6ef3 Author: fparain Date: 2012-01-25 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24ec1a6d6ef3 Merge From david.holmes at oracle.com Wed Jan 25 19:31:39 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 26 Jan 2012 03:31:39 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 2 new changesets Message-ID: <20120126033143.B1A2E471BC@hg.openjdk.java.net> Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp From dmitriy.samersoff at oracle.com Wed Jan 25 21:19:48 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Thu, 26 Jan 2012 05:19:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20120126051954.66E6B471BD@hg.openjdk.java.net> Changeset: a42c07c38c47 Author: dsamersoff Date: 2012-01-25 21:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a42c07c38c47 7132515: Add dcmd to manage UnlockingCommercialFeature flag Summary: Added dcmd to unlock or check status of UnlockingCommercialFeature flag Reviewed-by: fparain, rottenha ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/management.cpp Changeset: 6d00795f99a1 Author: dsamersoff Date: 2012-01-25 15:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6d00795f99a1 Merge Changeset: 6db63e782d3d Author: dsamersoff Date: 2012-01-25 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6db63e782d3d Merge From bob.vandette at oracle.com Wed Jan 25 23:51:20 2012 From: bob.vandette at oracle.com (bob.vandette at oracle.com) Date: Thu, 26 Jan 2012 07:51:20 +0000 Subject: hg: hsx/hotspot-emb/hotspot: 2 new changesets Message-ID: <20120126075124.F2ECA471C0@hg.openjdk.java.net> Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/f3fa16bd7159 Merge From bertrand.delsart at oracle.com Thu Jan 26 00:49:52 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 26 Jan 2012 09:49:52 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <76FD9630-6354-428F-A105-3DE88B28CC0F@oracle.com> References: <4F2030F2.1060606@oracle.com> <76FD9630-6354-428F-A105-3DE88B28CC0F@oracle.com> Message-ID: <4F2113B0.8080809@oracle.com> Thanks Tom, Bertrand. On 01/25/12 08:36 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jan 25, 2012, at 8:42 AM, Bertrand Delsart wrote: > >> Hi all, >> >> Here is the third (and last) frame::describe related CR I wanted to putback: >> >> http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ >> >> Goal of that RFE was to use the frame::describe debugging output to >> enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. >> >> The change in fact fixes a few minor bugs in the current version of trace_method_handle. >> >> Main changes are: >> - make frame::describe available in all non-product builds >> (else we could no longer build in "optimized" mode) >> - improvements of trace_method_handle for SPARC >> * protect FP result register, which was corrupted by traces >> * protect all globals (G6 corruption caused an issue) >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> - improvements of trace_method_handle for x86 >> * properly pass r13 (and not rsi) as the saved_sp on LP64 >> * protect FP result register, which was corrupted by traces >> * build a real frame in the stub wrapper to allow stack walking >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> >> Note on the "safely build a frame": >> >> trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. >> >> The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. >> >> If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. >> >> Regards, >> >> Bertrand >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE >> > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From christian.thalinger at oracle.com Thu Jan 26 07:22:07 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 26 Jan 2012 16:22:07 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <4F2030F2.1060606@oracle.com> References: <4F2030F2.1060606@oracle.com> Message-ID: <05E002BE-0DBF-4E81-B9CF-500B29CF48C7@oracle.com> Looks good. Thanks for fixing the tracing! -- Chris On Jan 25, 2012, at 5:42 PM, Bertrand Delsart wrote: > Hi all, > > Here is the third (and last) frame::describe related CR I wanted to putback: > > http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ > > Goal of that RFE was to use the frame::describe debugging output to > enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. > > The change in fact fixes a few minor bugs in the current version of trace_method_handle. > > Main changes are: > - make frame::describe available in all non-product builds > (else we could no longer build in "optimized" mode) > - improvements of trace_method_handle for SPARC > * protect FP result register, which was corrupted by traces > * protect all globals (G6 corruption caused an issue) > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > - improvements of trace_method_handle for x86 > * properly pass r13 (and not rsi) as the saved_sp on LP64 > * protect FP result register, which was corrupted by traces > * build a real frame in the stub wrapper to allow stack walking > * walk up to the right frame to dump > * safely build a frame on which to call describe (see below) > > Note on the "safely build a frame": > > trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. > > The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. > > If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. > > Regards, > > Bertrand > -- > Bertrand Delsart, bertrand.delsart at oracle.com, > Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, > 38334 Saint Ismier, FRANCE > From bertrand.delsart at oracle.com Thu Jan 26 07:34:46 2012 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 26 Jan 2012 16:34:46 +0100 Subject: Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle In-Reply-To: <05E002BE-0DBF-4E81-B9CF-500B29CF48C7@oracle.com> References: <4F2030F2.1060606@oracle.com> <05E002BE-0DBF-4E81-B9CF-500B29CF48C7@oracle.com> Message-ID: <4F217296.3000603@oracle.com> Thanks Chris, Bertrand. On 01/26/12 04:22 PM, Christian Thalinger wrote: > Looks good. Thanks for fixing the tracing! -- Chris > > On Jan 25, 2012, at 5:42 PM, Bertrand Delsart wrote: > >> Hi all, >> >> Here is the third (and last) frame::describe related CR I wanted to putback: >> >> http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/ >> >> Goal of that RFE was to use the frame::describe debugging output to >> enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. >> >> The change in fact fixes a few minor bugs in the current version of trace_method_handle. >> >> Main changes are: >> - make frame::describe available in all non-product builds >> (else we could no longer build in "optimized" mode) >> - improvements of trace_method_handle for SPARC >> * protect FP result register, which was corrupted by traces >> * protect all globals (G6 corruption caused an issue) >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> - improvements of trace_method_handle for x86 >> * properly pass r13 (and not rsi) as the saved_sp on LP64 >> * protect FP result register, which was corrupted by traces >> * build a real frame in the stub wrapper to allow stack walking >> * walk up to the right frame to dump >> * safely build a frame on which to call describe (see below) >> >> Note on the "safely build a frame": >> >> trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. >> >> The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames. >> >> If you are curious, I attached an example (an amd64) that shows a ricocher sequence, including both walkable and non walkable frames. >> >> Regards, >> >> Bertrand >> -- >> Bertrand Delsart, bertrand.delsart at oracle.com, >> Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, >> 38334 Saint Ismier, FRANCE >> > -- Bertrand Delsart, bertrand.delsart at oracle.com, Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE From daniel.daugherty at oracle.com Thu Jan 26 09:34:58 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 26 Jan 2012 10:34:58 -0700 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F208B66.5000503@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> <4F1FAF7C.1090608@oracle.com> <4F208B66.5000503@oracle.com> Message-ID: <4F218EC2.8010100@oracle.com> On 1/25/12 4:08 PM, Paul Hohensee wrote: > New webrev at > > http://cr.openjdk.java.net/~phh/7091418.01/ Thumbs up! Don't forget to use this bug ID when you commit: 7082553 2/3 Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 It would be nice to update the copyrights... src/os/bsd/vm/os_bsd.cpp No comments. src/os/linux/vm/os_linux.cpp No comments. src/os/solaris/vm/osThread_solaris.hpp typo line 36: 'create' -> 'created' src/os/solaris/vm/os_solaris.cpp nit line 3798 - deleted a blank line - why? lines 3998-4031 are pretty domain specific; I can't vouch for the correctness one way or the other lines 4000, 4012, 4022 seem a bit long nit lines 4036-7 - deleted blanks lines - why? src/os/windows/vm/os_windows.cpp No comments. src/share/vm/compiler/compileBroker.cpp No comments. src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp line 78: The comment on line 75 in os.hpp says that the VMThread uses NearMaxPriority so this comment (nor the original comment) make sense. src/share/vm/runtime/globals.hpp nit line 3491: "VM thread" -> "the VM thread" src/share/vm/runtime/os.hpp Why am I reminded of the scene in "Spinal Tap" where they are talking about the amp that goes up to 11 instead of 10? No (real) comments. From paul.hohensee at oracle.com Thu Jan 26 12:22:31 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 26 Jan 2012 15:22:31 -0500 Subject: Pls review 7091418: FX priority class from Solaris should be available to JVM ) In-Reply-To: <4F218EC2.8010100@oracle.com> References: <4F19A0B1.7080100@oracle.com> <4F1CAC4D.9080509@oracle.com> <4F1DB0DB.7040409@oracle.com> <4F1DD885.604@oracle.com> <4F1E3944.2000300@oracle.com> <4F1F0C9C.3020007@oracle.com> <4F1FAF7C.1090608@oracle.com> <4F208B66.5000503@oracle.com> <4F218EC2.8010100@oracle.com> Message-ID: <4F21B607.1060409@oracle.com> Thanks for the quick review. :) Inline... On 1/26/12 12:34 PM, Daniel D. Daugherty wrote: > On 1/25/12 4:08 PM, Paul Hohensee wrote: >> New webrev at >> >> http://cr.openjdk.java.net/~phh/7091418.01/ > > Thumbs up! > > > Don't forget to use this bug ID when you commit: > > 7082553 2/3 Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean > FX60 on Solaris 10 and 11 Yes, I'll remember. :) > > It would be nice to update the copyrights... Will do. > > > src/os/bsd/vm/os_bsd.cpp > No comments. > > src/os/linux/vm/os_linux.cpp > No comments. > > src/os/solaris/vm/osThread_solaris.hpp > typo line 36: 'create' -> 'created' Will fix. > > src/os/solaris/vm/os_solaris.cpp > nit line 3798 - deleted a blank line - why? Source code hygiene (general rule, be able to see as much as possible in an editor window). I tend to sneak at least one of these into every fix I make. Too many, and people rightly say they can't see the real change, but I can usually get away with a few. There's another one at 3831. > > lines 3998-4031 are pretty domain specific; I can't vouch for the > correctness one way or the other I had Steve Sistare in Solaris scheduler land look at these. > > lines 4000, 4012, 4022 seem a bit long Will fix. > > nit lines 4036-7 - deleted blanks lines - why? See above. > > src/os/windows/vm/os_windows.cpp > No comments. > > src/share/vm/compiler/compileBroker.cpp > No comments. > > src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp > > line 78: The comment on line 75 in os.hpp says that the VMThread > uses NearMaxPriority so this comment (nor the original > comment) make sense. The original comment didn't make sense with the original code, so I left it (both the comment and the original default) alone. :) I'll change it to note that if CriticalPriority is used then there's a small risk of VMThread starvation (because it does indeed run at NearMaxPriority). On T4, there's no risk, because (1) there's a lot of extra cores, so there's going to be a core to run the VMThread on, and (2) Solaris doesn't take CriticalPriority as a command, but rather as advisory, so the VMThread won't starve. On other platforms, there might be an issue, but that's why this is experimental. > > src/share/vm/runtime/globals.hpp > nit line 3491: "VM thread" -> "the VM thread" Will fix. > > src/share/vm/runtime/os.hpp > Why am I reminded of the scene in "Spinal Tap" where they > are talking about the amp that goes up to 11 instead of 10? Exactly. > > No (real) comments. Thanks again, Paul From john.coomes at oracle.com Thu Jan 26 20:42:33 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:42:33 +0000 Subject: hg: hsx/hotspot-emb: Added tag jdk8-b23 for changeset 60d6f64a86b1 Message-ID: <20120127044233.B894347209@hg.openjdk.java.net> Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:42:42 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:42:42 +0000 Subject: hg: hsx/hotspot-emb/corba: Added tag jdk8-b23 for changeset 5218eb256658 Message-ID: <20120127044245.4530C4720A@hg.openjdk.java.net> Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:42:52 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:42:52 +0000 Subject: hg: hsx/hotspot-emb/jaxp: Added tag jdk8-b23 for changeset 95102fd33418 Message-ID: <20120127044252.7E0B04720B@hg.openjdk.java.net> Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:42:58 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:42:58 +0000 Subject: hg: hsx/hotspot-emb/jaxws: Added tag jdk8-b23 for changeset 25ce7a000487 Message-ID: <20120127044258.E2DDD4720C@hg.openjdk.java.net> Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:43:58 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:43:58 +0000 Subject: hg: hsx/hotspot-emb/jdk: 43 new changesets Message-ID: <20120127045139.149A847212@hg.openjdk.java.net> Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/4d8b49a45cff Merge Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e6ef778c1df4 Merge Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/a7ad2fcd7291 Merge Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/b14e13237498 Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:07 +0000 Subject: hg: hsx/hotspot-rt: Added tag jdk8-b23 for changeset 60d6f64a86b1 Message-ID: <20120127045307.BE6DC47213@hg.openjdk.java.net> Changeset: 1a5f1d6b98d6 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/1a5f1d6b98d6 Added tag jdk8-b23 for changeset 60d6f64a86b1 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:15 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b23 for changeset 5218eb256658 Message-ID: <20120127045317.8CAA747214@hg.openjdk.java.net> Changeset: b98f0e6dddf9 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/b98f0e6dddf9 Added tag jdk8-b23 for changeset 5218eb256658 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:26 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b23 for changeset 95102fd33418 Message-ID: <20120127045326.BA11A47215@hg.openjdk.java.net> Changeset: 7836655e2495 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/7836655e2495 Added tag jdk8-b23 for changeset 95102fd33418 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:53:42 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:53:42 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b23 for changeset 25ce7a000487 Message-ID: <20120127045342.ACEF947216@hg.openjdk.java.net> Changeset: e0d90803439b Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/e0d90803439b Added tag jdk8-b23 for changeset 25ce7a000487 ! .hgtags From john.coomes at oracle.com Thu Jan 26 20:54:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 04:54:38 +0000 Subject: hg: hsx/hotspot-rt/jdk: 43 new changesets Message-ID: <20120127050209.DB24147218@hg.openjdk.java.net> Changeset: 44bd765c22f4 Author: prr Date: 2012-01-13 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/44bd765c22f4 7127827: JRE8: javaws fails to launch on oracle linux due to XRender Reviewed-by: bae, jgodinez ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java Changeset: b566004bcb1a Author: dbuck Date: 2012-01-16 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b566004bcb1a 7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates Reviewed-by: bae, prr ! make/sun/awt/Makefile Changeset: 397667460892 Author: lana Date: 2012-01-18 11:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/397667460892 Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: e0f94b9c53a8 Author: alexsch Date: 2012-01-10 15:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e0f94b9c53a8 7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS Reviewed-by: kizune + test/javax/swing/JSplitPane/4885629/bug4885629.java Changeset: 79d14e328670 Author: alexsch Date: 2012-01-10 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/79d14e328670 6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/6505523/bug6505523.java Changeset: ce32a4e1be1d Author: alexsch Date: 2012-01-13 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ce32a4e1be1d 7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F Reviewed-by: rupashka + test/javax/swing/JTextArea/4697612/bug4697612.java + test/javax/swing/JTextArea/4697612/bug4697612.txt Changeset: 59b8875949e1 Author: malenkov Date: 2012-01-16 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/59b8875949e1 7122740: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java Changeset: 3e9d35e6ee4f Author: denis Date: 2012-01-17 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3e9d35e6ee4f 7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: 89bc9d08fe82 Author: anthony Date: 2012-01-18 19:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/89bc9d08fe82 7130662: GTK file dialog crashes with a NPE Summary: Guard adding a back slash to the directory name with an if (!= null) check Reviewed-by: anthony, art Contributed-by: Matt ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: fe1278123fbb Author: lana Date: 2012-01-18 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fe1278123fbb Merge - test/tools/launcher/DefaultLocaleTest.sh Changeset: 4d8b49a45cff Author: lana Date: 2012-01-18 20:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4d8b49a45cff Merge Changeset: 400cc379adb5 Author: alanb Date: 2012-01-06 15:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/400cc379adb5 7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed Reviewed-by: forax, chegar ! src/share/classes/java/nio/file/FileTreeWalker.java Changeset: cdc128128044 Author: valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author: valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e6ef778c1df4 Merge Changeset: 6720ae7b1448 Author: valeriep Date: 2012-01-06 16:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6720ae7b1448 7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException Summary: Changed to always use full transformation as provider properties. Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/javax/crypto/Cipher/GetMaxAllowed.java Changeset: 2050ff9dfc92 Author: darcy Date: 2012-01-06 18:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2050ff9dfc92 7123649: Remove public modifier from Math.powerOfTwoF. Reviewed-by: smarks, alanb ! src/share/classes/java/lang/Math.java Changeset: 74c92c3e66ad Author: gadams Date: 2012-01-09 19:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/74c92c3e66ad 7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space Reviewed-by: alanb ! test/java/io/FileInputStream/LargeFileAvailable.java Changeset: 858038d89fd5 Author: darcy Date: 2012-01-09 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/858038d89fd5 7128441: StrictMath performance improvement note shared with Math Reviewed-by: darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java Changeset: dd69d3695cee Author: darcy Date: 2012-01-09 20:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dd69d3695cee 7128512: Javadoc typo in java.lang.invoke.MethodHandle Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/MethodHandle.java Changeset: d72de8b3fe36 Author: chegar Date: 2012-01-10 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d72de8b3fe36 7123415: Some cases of network interface indexes being read incorrectly Reviewed-by: chegar Contributed-by: brandon.passanisi at oracle.com ! src/solaris/native/java/net/net_util_md.c Changeset: bba276a6aa0d Author: chegar Date: 2012-01-10 12:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/bba276a6aa0d 7128584: Typo in sun.misc.VM's private directMemory field comment Reviewed-by: forax, chegar Contributed-by: Krystal Mok ! src/share/classes/sun/misc/VM.java Changeset: 49e64a8fc18f Author: darcy Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/49e64a8fc18f 7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances Reviewed-by: mduigou ! src/share/classes/java/lang/Object.java Changeset: 62dbcbe4c446 Author: darcy Date: 2012-01-10 17:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/62dbcbe4c446 7128931: Bad HTML escaping in java.lang.Throwable javadoc Reviewed-by: mduigou ! src/share/classes/java/lang/Throwable.java Changeset: 31a1fc60a895 Author: chegar Date: 2012-01-11 10:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/31a1fc60a895 7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/UnmodifiableMaps.java Changeset: 82144054d2d8 Author: alanb Date: 2012-01-11 13:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/82144054d2d8 7068856: (fs) Typo in Files.isSameFile() javadoc 7099208: (fs) Files.newBufferedReader has typo in javadoc Reviewed-by: forax ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: 96fe796fd242 Author: ksrini Date: 2012-01-11 08:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/96fe796fd242 7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2 Reviewed-by: sherman, mchung, darcy ! src/share/bin/java.c + test/tools/launcher/I18NJarTest.java ! test/tools/launcher/TestHelper.java Changeset: 11e52d5ba64e Author: xuelei Date: 2012-01-12 03:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/11e52d5ba64e 7106773: 512 bits RSA key cannot work with SHA384 and SHA512 Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java + src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/Length.java ! src/windows/classes/sun/security/mscapi/Key.java ! src/windows/classes/sun/security/mscapi/RSACipher.java ! src/windows/classes/sun/security/mscapi/RSASignature.java + test/sun/security/mscapi/ShortRSAKey1024.sh + test/sun/security/mscapi/ShortRSAKey512.sh + test/sun/security/mscapi/ShortRSAKey768.sh + test/sun/security/mscapi/ShortRSAKeyWithinTLS.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.java ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java Changeset: 38bf1e9b6979 Author: weijun Date: 2012-01-13 09:50 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/38bf1e9b6979 7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests Reviewed-by: mullan + test/javax/security/auth/x500/X500Principal/NameFormat.java Changeset: ef3b6736c074 Author: valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author: valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a7ad2fcd7291 Merge Changeset: 7e593aa6ad41 Author: littlee Date: 2012-01-13 13:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7e593aa6ad41 7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/sun/nio/fs/genUnixConstants.c Changeset: e8e08d46cc37 Author: weijun Date: 2012-01-16 10:10 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8e08d46cc37 7118809: rcache deadlock Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/ReplayCache.java Changeset: d1b0bda3a3c7 Author: alanb Date: 2012-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d1b0bda3a3c7 7130398: ProblemList.txt updates (1/2012) Reviewed-by: chegar ! test/ProblemList.txt Changeset: e8a143213c65 Author: chegar Date: 2012-01-16 18:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e8a143213c65 7129083: CookieManager does not store cookies if url is read before setting cookie manager Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/sun/net/www/http/HttpClient/CookieHttpClientTest.java + test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 40d699d7f6a1 Author: chegar Date: 2012-01-17 14:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/40d699d7f6a1 6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol) Reviewed-by: alanb ! test/ProblemList.txt - test/java/io/File/BlockIsDirectory.java Changeset: 2f096eb72520 Author: mchung Date: 2012-01-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2f096eb72520 7117570: Warnings in sun.mangement.* and its subpackages Reviewed-by: mchung, dsamersoff Contributed-by: kurchi.subhra.hazra at oracle.com ! src/share/classes/sun/management/Agent.java ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java Changeset: b14e13237498 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b14e13237498 Merge Changeset: e6614f361127 Author: lana Date: 2012-01-18 20:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e6614f361127 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 227fcf5d0bec Author: lana Date: 2012-01-24 13:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/227fcf5d0bec Merge - test/java/io/File/BlockIsDirectory.java Changeset: 954a1c535730 Author: amurillo Date: 2012-01-25 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/954a1c535730 Merge - test/java/io/File/BlockIsDirectory.java Changeset: d3b334e376d3 Author: mr Date: 2012-01-23 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d3b334e376d3 7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems Reviewed-by: ohair ! make/javax/sound/jsoundalsa/Makefile Changeset: 54202e0148ec Author: katleman Date: 2012-01-25 13:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/54202e0148ec Merge Changeset: 34029a0c69bb Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/34029a0c69bb Added tag jdk8-b23 for changeset 54202e0148ec ! .hgtags From paul.hohensee at oracle.com Thu Jan 26 21:15:21 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Fri, 27 Jan 2012 05:15:21 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Message-ID: <20120127051525.40A4C47219@hg.openjdk.java.net> Changeset: de268c8a8075 Author: phh Date: 2012-01-26 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de268c8a8075 7082553: Interpret Thread.setPriority(Thread.MAX_PRIORITY) to mean FX60 on Solaris 10 and 11 Summary: Add CriticalPriority == MaxPriority+1 and enable scheduling class as well as thread priority to change on Solaris. Reviewed-by: dholmes, dcubed ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp From john.coomes at oracle.com Fri Jan 27 12:38:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 20:38:10 +0000 Subject: hg: hsx/hotspot-emb/langtools: 8 new changesets Message-ID: <20120127203832.198E04723B@hg.openjdk.java.net> Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/f00afa80f1f0 Merge Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-emb/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags From john.coomes at oracle.com Fri Jan 27 12:50:36 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 27 Jan 2012 20:50:36 +0000 Subject: hg: hsx/hotspot-rt/langtools: 8 new changesets Message-ID: <20120127205055.45F914723D@hg.openjdk.java.net> Changeset: 70d92518063e Author: mcimadamore Date: 2012-01-11 18:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/70d92518063e 7126754: Generics compilation failure casting List to List Summary: Problems with Types.rewriteQuantifiers not preserving variance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/7126754/T7126754.java + test/tools/javac/cast/7126754/T7126754.out Changeset: 133744729455 Author: mcimadamore Date: 2012-01-12 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/133744729455 7123100: javac fails with java.lang.StackOverflowError Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/cast/7123100/T7123100a.java + test/tools/javac/cast/7123100/T7123100a.out + test/tools/javac/cast/7123100/T7123100b.java + test/tools/javac/cast/7123100/T7123100b.out + test/tools/javac/cast/7123100/T7123100c.java + test/tools/javac/cast/7123100/T7123100c.out + test/tools/javac/cast/7123100/T7123100d.java + test/tools/javac/cast/7123100/T7123100d.out Changeset: 1e2f4f4fb9f7 Author: jjh Date: 2012-01-17 17:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1e2f4f4fb9f7 7127924: langtools regression tests sometimes fail en-masse on windows Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: f00afa80f1f0 Author: lana Date: 2012-01-18 11:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/f00afa80f1f0 Merge Changeset: cf2496340fef Author: darcy Date: 2012-01-18 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/cf2496340fef 7130768: Clarify behavior of Element.getEnclosingElements in subtypes Reviewed-by: mcimadamore, jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 99261fc7d95d Author: jjh Date: 2012-01-18 18:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/99261fc7d95d 7131308: Three regression tests fail due to bad fix for 7127924 Reviewed-by: jjg ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 601ffcc6551d Author: lana Date: 2012-01-24 13:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/601ffcc6551d Merge Changeset: 6c9d21ca92c4 Author: katleman Date: 2012-01-26 18:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6c9d21ca92c4 Added tag jdk8-b23 for changeset 601ffcc6551d ! .hgtags From stefan.karlsson at oracle.com Fri Jan 27 15:21:00 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 27 Jan 2012 23:21:00 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Message-ID: <20120127232104.EF5FA47240@hg.openjdk.java.net> Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp From stefan.karlsson at oracle.com Mon Jan 30 05:03:54 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 30 Jan 2012 13:03:54 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7022100: Method annotations are incorrectly set when redefining classes Message-ID: <20120130130356.9BFEF47284@hg.openjdk.java.net> Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp From bengt.rutisson at oracle.com Mon Jan 30 06:21:13 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Jan 2012 15:21:13 +0100 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE Message-ID: <4F26A759.80605@oracle.com> Hi all, Could I please have a couple of review for this really small change: http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ There is only one line changed, so I'll include the diff here as well: Background: The fix for "7115199: Add event tracing hooks and Java Flight Recorder infrastructure" added this to make\windows\makefiles\vm.make: !ifndef JAVASE_EMBEDDED CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" !endif To keep the Visual Studio projects working the same type of change needs to be made to src\share\tools\ProjectCreator\BuildConfig.java This will only affect Visual Studio projects created with the ProjectCreator tool (create.bat). This does not affect "normal" Windows builds or JPRT builds. Thanks, Bengt From bengt.rutisson at oracle.com Mon Jan 30 07:13:27 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Jan 2012 16:13:27 +0100 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <4F26A759.80605@oracle.com> References: <4F26A759.80605@oracle.com> Message-ID: <4F26B397.3090509@oracle.com> Just realized that I forgot to paste in the diff. Here it is if you want to save one click: diff --git a/src/share/tools/ProjectCreator/BuildConfig.java b/src/share/tools/ProjectCreator/BuildConfig.java --- a/src/share/tools/ProjectCreator/BuildConfig.java +++ b/src/share/tools/ProjectCreator/BuildConfig.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -243,6 +243,7 @@ sysDefines.add("_WINDOWS"); sysDefines.add("HOTSPOT_BUILD_USER=\\\""+System.getProperty("user.name")+"\\\""); sysDefines.add("HOTSPOT_BUILD_TARGET=\\\""+get("Build")+"\\\""); + sysDefines.add("INCLUDE_TRACE"); sysDefines.add("_JNI_IMPLEMENTATION_"); if (vars.get("PlatformName").equals("Win32")) { sysDefines.add("HOTSPOT_LIB_ARCH=\\\"i386\\\""); Bengt On 2012-01-30 15:21, Bengt Rutisson wrote: > > Hi all, > > Could I please have a couple of review for this really small change: > http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ > > There is only one line changed, so I'll include the diff here as well: > > Background: > > The fix for "7115199: Add event tracing hooks and Java Flight Recorder > infrastructure" added this to make\windows\makefiles\vm.make: > > !ifndef JAVASE_EMBEDDED > CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" > !endif > > To keep the Visual Studio projects working the same type of change > needs to be made to src\share\tools\ProjectCreator\BuildConfig.java > > This will only affect Visual Studio projects created with the > ProjectCreator tool (create.bat). This does not affect "normal" > Windows builds or JPRT builds. > > Thanks, > Bengt > From staffan.larsen at oracle.com Mon Jan 30 07:10:36 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 30 Jan 2012 16:10:36 +0100 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <4F26B397.3090509@oracle.com> References: <4F26A759.80605@oracle.com> <4F26B397.3090509@oracle.com> Message-ID: Looks good. /Staffan On 30 jan 2012, at 16:13, Bengt Rutisson wrote: > > Just realized that I forgot to paste in the diff. Here it is if you want to save one click: > > diff --git a/src/share/tools/ProjectCreator/BuildConfig.java b/src/share/tools/ProjectCreator/BuildConfig.java > --- a/src/share/tools/ProjectCreator/BuildConfig.java > +++ b/src/share/tools/ProjectCreator/BuildConfig.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2005, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -243,6 +243,7 @@ > sysDefines.add("_WINDOWS"); > sysDefines.add("HOTSPOT_BUILD_USER=\\\""+System.getProperty("user.name")+"\\\""); > sysDefines.add("HOTSPOT_BUILD_TARGET=\\\""+get("Build")+"\\\""); > + sysDefines.add("INCLUDE_TRACE"); > sysDefines.add("_JNI_IMPLEMENTATION_"); > if (vars.get("PlatformName").equals("Win32")) { > sysDefines.add("HOTSPOT_LIB_ARCH=\\\"i386\\\""); > > > Bengt > > On 2012-01-30 15:21, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I please have a couple of review for this really small change: >> http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ >> >> There is only one line changed, so I'll include the diff here as well: >> >> Background: >> >> The fix for "7115199: Add event tracing hooks and Java Flight Recorder infrastructure" added this to make\windows\makefiles\vm.make: >> >> !ifndef JAVASE_EMBEDDED >> CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" >> !endif >> >> To keep the Visual Studio projects working the same type of change needs to be made to src\share\tools\ProjectCreator\BuildConfig.java >> >> This will only affect Visual Studio projects created with the ProjectCreator tool (create.bat). This does not affect "normal" Windows builds or JPRT builds. >> >> Thanks, >> Bengt >> > From keith.mcguigan at oracle.com Mon Jan 30 07:26:22 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 30 Jan 2012 10:26:22 -0500 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <4F26A759.80605@oracle.com> References: <4F26A759.80605@oracle.com> Message-ID: <4F26B69E.8050209@oracle.com> Looks fine. -- - Keith (openjdk: kamg) On 1/30/2012 9:21 AM, Bengt Rutisson wrote: > > Hi all, > > Could I please have a couple of review for this really small change: > http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ > > There is only one line changed, so I'll include the diff here as well: > > Background: > > The fix for "7115199: Add event tracing hooks and Java Flight Recorder > infrastructure" added this to make\windows\makefiles\vm.make: > > !ifndef JAVASE_EMBEDDED > CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" > !endif > > To keep the Visual Studio projects working the same type of change needs > to be made to src\share\tools\ProjectCreator\BuildConfig.java > > This will only affect Visual Studio projects created with the > ProjectCreator tool (create.bat). This does not affect "normal" Windows > builds or JPRT builds. > > Thanks, > Bengt > From bengt.rutisson at oracle.com Mon Jan 30 07:50:51 2012 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 30 Jan 2012 15:50:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20120130155055.64F7A4728B@hg.openjdk.java.net> Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d96c130c9399 Merge From kelly.ohair at oracle.com Mon Jan 30 08:55:29 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 30 Jan 2012 08:55:29 -0800 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <4F26A759.80605@oracle.com> References: <4F26A759.80605@oracle.com> Message-ID: <202FEA38-A3D3-403B-9EEF-F077F15B2D56@oracle.com> Poking my nose in... It has been my experience that using global macros with very generic names is dangerous. If some day we update to Visual Studio 2032, and they decided to use the macro name INCLUDE_TRACE for something, we could have some interesting bug reports. If this is directly related to hotspot or jfr or anything we have created, I think it would be a much better idea, and also helpful to the code reader, to name it a little more uniquely. Like JFR_INCLUDE_TRACE or something that indicates what it is for or from. -kto On Jan 30, 2012, at 6:21 AM, Bengt Rutisson wrote: > > Hi all, > > Could I please have a couple of review for this really small change: > http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ > > There is only one line changed, so I'll include the diff here as well: > > Background: > > The fix for "7115199: Add event tracing hooks and Java Flight Recorder infrastructure" added this to make\windows\makefiles\vm.make: > > !ifndef JAVASE_EMBEDDED > CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" > !endif > > To keep the Visual Studio projects working the same type of change needs to be made to src\share\tools\ProjectCreator\BuildConfig.java > > This will only affect Visual Studio projects created with the ProjectCreator tool (create.bat). This does not affect "normal" Windows builds or JPRT builds. > > Thanks, > Bengt > From bengt.rutisson at oracle.com Mon Jan 30 09:14:45 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Jan 2012 18:14:45 +0100 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <202FEA38-A3D3-403B-9EEF-F077F15B2D56@oracle.com> References: <4F26A759.80605@oracle.com> <202FEA38-A3D3-403B-9EEF-F077F15B2D56@oracle.com> Message-ID: <4F26D005.4070500@oracle.com> Hi Kelly, On 2012-01-30 17:55, Kelly O'Hair wrote: > Poking my nose in... :-) > It has been my experience that using global macros with very generic names is dangerous. > If some day we update to Visual Studio 2032, and they decided to use the macro > name INCLUDE_TRACE for something, we could have some interesting bug reports. > > If this is directly related to hotspot or jfr or anything we have created, I think it would be a much > better idea, and also helpful to the code reader, to name it a little more uniquely. > Like JFR_INCLUDE_TRACE or something that indicates what it is for or from. I think you have a valid point, but I think we should ask the JFR team to handle this as a separate task. With the change that I am proposing I am just adapting the Visual Studio projects to what the JFR team did to the source and make files. So, if it is ok with you I'd like to go ahead and push this change. Then we can bring up the naming discussion with the JFR team as a separate issue. Thanks for looking at this! Bengt > > -kto > > On Jan 30, 2012, at 6:21 AM, Bengt Rutisson wrote: > >> Hi all, >> >> Could I please have a couple of review for this really small change: >> http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ >> >> There is only one line changed, so I'll include the diff here as well: >> >> Background: >> >> The fix for "7115199: Add event tracing hooks and Java Flight Recorder infrastructure" added this to make\windows\makefiles\vm.make: >> >> !ifndef JAVASE_EMBEDDED >> CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" >> !endif >> >> To keep the Visual Studio projects working the same type of change needs to be made to src\share\tools\ProjectCreator\BuildConfig.java >> >> This will only affect Visual Studio projects created with the ProjectCreator tool (create.bat). This does not affect "normal" Windows builds or JPRT builds. >> >> Thanks, >> Bengt >> From bengt.rutisson at oracle.com Mon Jan 30 09:15:50 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 30 Jan 2012 18:15:50 +0100 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <4F26B69E.8050209@oracle.com> References: <4F26A759.80605@oracle.com> <4F26B69E.8050209@oracle.com> Message-ID: <4F26D046.1030806@oracle.com> Staffan and Keith, thanks for the very quick reviews! Bengt On 2012-01-30 16:26, Keith McGuigan wrote: > > Looks fine. > > -- > - Keith (openjdk: kamg) > > On 1/30/2012 9:21 AM, Bengt Rutisson wrote: >> >> Hi all, >> >> Could I please have a couple of review for this really small change: >> http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ >> >> There is only one line changed, so I'll include the diff here as well: >> >> Background: >> >> The fix for "7115199: Add event tracing hooks and Java Flight Recorder >> infrastructure" added this to make\windows\makefiles\vm.make: >> >> !ifndef JAVASE_EMBEDDED >> CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" >> !endif >> >> To keep the Visual Studio projects working the same type of change needs >> to be made to src\share\tools\ProjectCreator\BuildConfig.java >> >> This will only affect Visual Studio projects created with the >> ProjectCreator tool (create.bat). This does not affect "normal" Windows >> builds or JPRT builds. >> >> Thanks, >> Bengt >> From kelly.ohair at oracle.com Mon Jan 30 09:30:07 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 30 Jan 2012 09:30:07 -0800 Subject: Request for review (XS): 7140909 Visual Studio project builds broken: need to define INCLUDE_TRACE In-Reply-To: <4F26D005.4070500@oracle.com> References: <4F26A759.80605@oracle.com> <202FEA38-A3D3-403B-9EEF-F077F15B2D56@oracle.com> <4F26D005.4070500@oracle.com> Message-ID: On Jan 30, 2012, at 9:14 AM, Bengt Rutisson wrote: > > Hi Kelly, > > On 2012-01-30 17:55, Kelly O'Hair wrote: >> Poking my nose in... > > :-) > >> It has been my experience that using global macros with very generic names is dangerous. >> If some day we update to Visual Studio 2032, and they decided to use the macro >> name INCLUDE_TRACE for something, we could have some interesting bug reports. >> >> If this is directly related to hotspot or jfr or anything we have created, I think it would be a much >> better idea, and also helpful to the code reader, to name it a little more uniquely. >> Like JFR_INCLUDE_TRACE or something that indicates what it is for or from. > > I think you have a valid point, but I think we should ask the JFR team to handle this as a separate task. With the change that I am proposing I am just adapting the Visual Studio projects to what the JFR team did to the source and make files. > > So, if it is ok with you I'd like to go ahead and push this change. Then we can bring up the naming discussion with the JFR team as a separate issue. That is fine. Removing nose. ;^) -kto > > Thanks for looking at this! > Bengt > >> >> -kto >> >> On Jan 30, 2012, at 6:21 AM, Bengt Rutisson wrote: >> >>> Hi all, >>> >>> Could I please have a couple of review for this really small change: >>> http://cr.openjdk.java.net/~brutisso/7140909/webrev.01/ >>> >>> There is only one line changed, so I'll include the diff here as well: >>> >>> Background: >>> >>> The fix for "7115199: Add event tracing hooks and Java Flight Recorder infrastructure" added this to make\windows\makefiles\vm.make: >>> >>> !ifndef JAVASE_EMBEDDED >>> CPP_FLAGS=$(CPP_FLAGS) /D "INCLUDE_TRACE" >>> !endif >>> >>> To keep the Visual Studio projects working the same type of change needs to be made to src\share\tools\ProjectCreator\BuildConfig.java >>> >>> This will only affect Visual Studio projects created with the ProjectCreator tool (create.bat). This does not affect "normal" Windows builds or JPRT builds. >>> >>> Thanks, >>> Bengt >>> > From fredrik.ohrstrom at oracle.com Tue Jan 31 04:31:34 2012 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Tue, 31 Jan 2012 13:31:34 +0100 Subject: Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds. Message-ID: <4F27DF26.7060808@oracle.com> Hello hotspot-runtime-dev and build-dev! This is a patch to enable ccache to work for all builds, not only builds where the build number has been explicitly set. Webrev is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/ Exported hg patch is here: http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch Is it good enough, so that you can commit for me Robert? Thanks! //Fredrik From karen.kinnear at oracle.com Tue Jan 31 07:29:48 2012 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 31 Jan 2012 15:29:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7114376: Make system dictionary hashtable bucket array size configurable Message-ID: <20120131152952.BC56A472B4@hg.openjdk.java.net> Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp From staffan.larsen at oracle.com Tue Jan 31 11:53:52 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 31 Jan 2012 20:53:52 +0100 Subject: Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds. In-Reply-To: <4F27DF26.7060808@oracle.com> References: <4F27DF26.7060808@oracle.com> Message-ID: Looks good, but where is the new jre_release_version() method used? /Staffan On 31 jan 2012, at 13:31, Fredrik ?hrstr?m wrote: > Hello hotspot-runtime-dev and build-dev! > > This is a patch to enable ccache to work for all builds, > not only builds where the build number has been explicitly set. > > Webrev is here: > > http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/ > > Exported hg patch is here: > > http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch > > Is it good enough, so that you can commit for me Robert? > > Thanks! > //Fredrik > From david.holmes at oracle.com Tue Jan 31 13:38:27 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 01 Feb 2012 07:38:27 +1000 Subject: Patch for: 7132779: build-infra merge: Enable ccache to work for most developer builds. In-Reply-To: References: <4F27DF26.7060808@oracle.com> Message-ID: <4F285F53.8070306@oracle.com> On 1/02/2012 5:53 AM, Staffan Larsen wrote: > Looks good, but where is the new jre_release_version() method used? It's currently only used in some closed code. The new method avoids the need to make the JRE_RELEASE_VERSION define available to that closed code. I don't understand the comment on the new method though. Not sure what stringstream has to do with this actual method. Otherwise looks good to me. I'm assuming that the actual problem is the ccache compares the defines used for a compilation and so if the version string contains a timestamp and gets updated on each (incremental?) build then ccache thinks it has to recompile. David ----- > /Staffan > > On 31 jan 2012, at 13:31, Fredrik ?hrstr?m wrote: > >> Hello hotspot-runtime-dev and build-dev! >> >> This is a patch to enable ccache to work for all builds, >> not only builds where the build number has been explicitly set. >> >> Webrev is here: >> >> http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/ >> >> Exported hg patch is here: >> >> http://cr.openjdk.java.net/~ohrstrom/7132779/webrev.00/7132779.patch >> >> Is it good enough, so that you can commit for me Robert? >> >> Thanks! >> //Fredrik >> >