From staffan.larsen at oracle.com Thu Nov 1 05:03:37 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 1 Nov 2012 13:03:37 +0100 Subject: RFR: 8002078: hs_err_pid file should report full JDK version string In-Reply-To: <509196FD.4020609@oracle.com> References: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com> <509196FD.4020609@oracle.com> Message-ID: <04CEEE0C-5D21-42F8-A486-03E9BF7DC6EC@oracle.com> On 31 okt 2012, at 22:24, Krystal Mo wrote: > Hi Staffan, > > Looks good to me. This is helpful especially when dealing with nightlies. Thanks. > But I wonder if it's better to fold get_java_runtime_name() and get_java_runtime_version() into one, something like set_java_runtime_info(), since these two functions are mostly doing the same thing. > I'm okay either way, the choice is up to you :-) I did think about that, but was afraid that resulting code would be harder to read. /Staffan > > Regards, > Kris > > On 2012/11/1 4:59, Staffan Larsen wrote: >> Please review the following change to the crash output. Currently when hotspot crashes the output contains: >> >> # JRE version: Java(TM) SE Runtime Environment (8.0) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops) >> >> With the same installation "java -version" reports: >> >> Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) >> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode) >> >> The first output above should be changed to look like: >> >> # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops) >> >> http://cr.openjdk.java.net/~sla/8002078/webrev.01/ >> >> Thanks, >> /Staffan From staffan.larsen at oracle.com Thu Nov 1 05:03:59 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 1 Nov 2012 13:03:59 +0100 Subject: RFR: 8002078: hs_err_pid file should report full JDK version string In-Reply-To: <5091D87B.1000402@oracle.com> References: <16D24974-73F2-4D7F-B594-D6D76ADAAC07@oracle.com> <5091D87B.1000402@oracle.com> Message-ID: Thanks. Typo fixed. /Staffan On 1 nov 2012, at 03:03, David Holmes wrote: > Hi Staffan, > > thread.cpp - Minor typo: > > // extract the JRE vesion > > > Otherwise looks fine. I don't see any way to reduce the duplication that is obviously better. > > David > > On 1/11/2012 6:59 AM, Staffan Larsen wrote: >> Please review the following change to the crash output. Currently when hotspot crashes the output contains: >> >> # JRE version: Java(TM) SE Runtime Environment (8.0) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops) >> >> With the same installation "java -version" reports: >> >> Java(TM) SE Runtime Environment (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) >> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b20, mixed mode) >> >> The first output above should be changed to look like: >> >> # JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0-internal-staffan_2012_10_09_15_30-b00) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b20 mixed mode bsd-amd64 compressed oops) >> >> http://cr.openjdk.java.net/~sla/8002078/webrev.01/ >> >> Thanks, >> /Staffan From zhengyu.gu at oracle.com Thu Nov 1 06:38:19 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 01 Nov 2012 09:38:19 -0400 Subject: Code review request: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp In-Reply-To: <5091D136.8000801@oracle.com> References: <50914DE1.9050305@oracle.com> <5091D136.8000801@oracle.com> Message-ID: <50927B4B.5010506@oracle.com> Hi David, Thanks for reviewing. On 10/31/2012 9:32 PM, David Holmes wrote: > On 1/11/2012 2:12 AM, Zhengyu Gu wrote: >> NMT did not allow overlapped commit on memory regions, which is >> incorrect. Committing overlapped memory regions should be allowed, as >> long as the regions are within a reserved region. > > So the overlapping stacks that were detected is perfectly valid? > No, it is very disturbing one, now is tracked by 8001743. This one only deals with overlapping committed regions. >> >> http://cr.openjdk.java.net/~zgu/8001591/webrev.00/ > > The renaming from contains_xx to contain_xx is not correct. "contains" > is the correct form to use, and "overlaps" rather than "overlap". > > Why the variable rename in VMMemPointerIterator::add_reserved_region? > Given it is initialized from current() then 'cur' seems quite > acceptable. Otherwise maybe it is current() that has the wrong name? > The renaming generates a lot of noise in the webrev - it is hard to > see the actual substantive changes that were made. > They are the results of recent clean coding discussions. I agree they are noises, I will revert renaming changes. Thanks, -Zhengyu > Cheers, > David > > >> Thanks, >> >> -Zhengyu From coleen.phillimore at oracle.com Thu Nov 1 11:12:58 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 01 Nov 2012 18:12:58 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20121101181314.291CC476F2@hg.openjdk.java.net> Changeset: 5ec0c42da025 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ec0c42da025 7188234: Deprecate VM command line options Summary: Remove support for the UseVectoredExceptions flag Reviewed-by: jcoomes, kamg Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e81fbc04a942 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e81fbc04a942 7191817: -XX:+UseSerialGC -XX:+UseLargePages crashes with SIGFPE on MacOS X Summary: Disable -XX:+UseLargePages for MacOS X Reviewed-by: dholmes, coleenp, sla Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 0af5da0c9d9d Author: sla Date: 2012-10-29 21:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0af5da0c9d9d 8001619: Remove usage of _ALLBSD_SOURCE in bsd files Reviewed-by: coleenp, dholmes ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp Changeset: 39556eae08af Author: sspitsyn Date: 2012-10-29 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/39556eae08af 6533010: SPEC: A few broken links in jvmti.html Summary: Fix the incorrect links in jvmti.html reported by the LinkCheck tool Reviewed-by: jjh, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 845129b692f6 Author: minqi Date: 2012-10-29 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/845129b692f6 Merge Changeset: a1b8cf9cf970 Author: sla Date: 2012-11-01 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a1b8cf9cf970 8002078: hs_err_pid file should report full JDK version string Reviewed-by: dholmes, sspitsyn, kmo ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: cae17c597196 Author: coleenp Date: 2012-11-01 11:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cae17c597196 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp From john.coomes at oracle.com Thu Nov 1 20:32:44 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 03:32:44 +0000 Subject: hg: hsx/hotspot-main: 8 new changesets Message-ID: <20121102033244.84E6A47704@hg.openjdk.java.net> Changeset: 4bde5640fb36 Author: alanb Date: 2012-10-09 13:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4bde5640fb36 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile Changeset: ce2b111ee869 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ce2b111ee869 Merge Changeset: 744e165aaf33 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/744e165aaf33 Merge Changeset: ce212cd7ea69 Author: lana Date: 2012-10-25 20:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ce212cd7ea69 Merge Changeset: e64f2cb57d05 Author: ohair Date: 2012-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e64f2cb57d05 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 + common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.m4 ! common/autoconf/closed.version.numbers ! common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 + common/autoconf/toolchain_windows.m4 ! common/autoconf/version.numbers + common/bin/compare.sh + common/bin/compare_exceptions.sh.incl - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh ! common/bin/hide_important_warnings_from_javac.sh ! common/bin/logger.sh + common/bin/shell-tracer.sh - common/bin/unicode2x.sed ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk + common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk - common/makefiles/compress.post - common/makefiles/compress.pre + common/makefiles/support/ListPathsSafely-post-compress.incl + common/makefiles/support/ListPathsSafely-pre-compress.incl + common/makefiles/support/ListPathsSafely-uncompress.sed + common/makefiles/support/unicode2x.sed - common/makefiles/uncompress.sed + common/src/fixpath.c - common/src/uncygdrive.c + configure Changeset: e3182741ade2 Author: ihse Date: 2012-10-29 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e3182741ade2 8001897: build-infra: misc adjustments to configure script Reviewed-by: ohair ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3229597524ca Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3229597524ca Merge - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c Changeset: cababb9dfce7 Author: katleman Date: 2012-11-01 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/cababb9dfce7 Added tag jdk8-b63 for changeset 3229597524ca ! .hgtags From john.coomes at oracle.com Thu Nov 1 20:33:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 03:33:30 +0000 Subject: hg: hsx/hotspot-main/jaxws: 3 new changesets Message-ID: <20121102033341.3791247707@hg.openjdk.java.net> Changeset: c30a7cb5c587 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c30a7cb5c587 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: 86989f702267 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/86989f702267 Merge Changeset: 5ded18a14bcc Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/5ded18a14bcc Added tag jdk8-b63 for changeset 86989f702267 ! .hgtags From john.coomes at oracle.com Thu Nov 1 20:32:48 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 03:32:48 +0000 Subject: hg: hsx/hotspot-main/corba: 7 new changesets Message-ID: <20121102033255.87A9847705@hg.openjdk.java.net> Changeset: 679e8ad9874f Author: coffeys Date: 2012-10-09 20:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/679e8ad9874f 7196086: update copyright years for files in corba repository (JDK 8) Reviewed-by: lancea ! make/common/Defs-bsd.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Defs-bsd.gmk ! make/common/shared/Defs-utils.gmk ! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java ! make/tools/strip_properties/Makefile Changeset: 706684c5a058 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/706684c5a058 Merge Changeset: 23e0226a31ac Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/23e0226a31ac Merge Changeset: 9094cd4a614f Author: lana Date: 2012-10-25 20:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/9094cd4a614f Merge ! make/common/shared/Defs-utils.gmk Changeset: de2b8def2be5 Author: ohair Date: 2012-10-26 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/de2b8def2be5 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 6ccbf67b68bf Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/6ccbf67b68bf Merge Changeset: b450c07849ab Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/b450c07849ab Added tag jdk8-b63 for changeset 6ccbf67b68bf ! .hgtags From john.coomes at oracle.com Thu Nov 1 20:33:00 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 03:33:00 +0000 Subject: hg: hsx/hotspot-main/jaxp: 7 new changesets Message-ID: <20121102033326.106FB47706@hg.openjdk.java.net> Changeset: 53a2a4893c8f Author: joehw Date: 2012-10-09 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/53a2a4893c8f 8000172: 2 SAX features does not work properly Summary: When external dtd is not loaded, skippedEntity event should be reported for entity references. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Changeset: b545c99e4f5e Author: lana Date: 2012-10-12 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b545c99e4f5e Merge Changeset: 23e1d537224b Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/23e1d537224b Merge Changeset: fc589819b335 Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/fc589819b335 Merge Changeset: 121fc928a361 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/121fc928a361 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: 192d8a244bc3 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/192d8a244bc3 Merge Changeset: 27ab79568c34 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/27ab79568c34 Added tag jdk8-b63 for changeset 192d8a244bc3 ! .hgtags From john.coomes at oracle.com Thu Nov 1 20:35:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 03:35:47 +0000 Subject: hg: hsx/hotspot-main/jdk: 83 new changesets Message-ID: <20121102035438.BB8B347708@hg.openjdk.java.net> Changeset: 117eed515e42 Author: bae Date: 2012-10-23 13:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/117eed515e42 7051394: NullPointerException when running regression tests LoadProfileTest by using openjdk-7-b144 Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: aeb96dec1c6b Author: lana Date: 2012-10-23 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aeb96dec1c6b Merge Changeset: 93e2669f1ac2 Author: leonidr Date: 2012-10-09 18:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/93e2669f1ac2 7185280: Jre7cert: focusgained does not get called for all focus req when do alt + tab Reviewed-by: anthony ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 527f8eeb8e8d Author: leonidr Date: 2012-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/527f8eeb8e8d 7124321: [macosx] TrayIcon MouseListener is never triggered Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m Changeset: d4d0327e36e2 Author: kshefov Date: 2012-10-12 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d4d0327e36e2 7184326: TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Reviewed-by: anthony ! test/java/awt/Frame/7024749/bug7024749.java Changeset: 34d502d14a61 Author: lana Date: 2012-10-12 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/34d502d14a61 Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: f42d178f0452 Author: anthony Date: 2012-10-16 20:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f42d178f0452 6818083: When DISPLAY is bad, InternalError thrown, not AWTError Summary: Throw AWTError instead of InternalError if the DISPLAY is bad Reviewed-by: anthony, serb Contributed-by: Mikhail Cherkasov ! src/solaris/native/sun/awt/awt_GraphicsEnv.c + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 47cdc463b4b0 Author: kizune Date: 2012-10-17 14:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/47cdc463b4b0 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test Reviewed-by: serb, leonidr ! src/macosx/classes/sun/awt/CGraphicsDevice.java Changeset: e6a8ee65d248 Author: alexsch Date: 2012-10-17 17:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6a8ee65d248 8000969: [macosx] Directories are not deselected when JFileChooser has FILES_ONLY selection mode Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java Changeset: 29b7bd890d3a Author: alexsch Date: 2012-10-17 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/29b7bd890d3a 8000626: Implement dead key detection for KeyEvent on Linux Reviewed-by: kizune ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 9c6f60a4e996 Author: alexsch Date: 2012-10-18 17:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c6f60a4e996 7199708: FileChooser crashs when opening large folder Reviewed-by: bagiras ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java Changeset: 8bbc6a5f1e92 Author: alexsch Date: 2012-10-18 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8bbc6a5f1e92 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 6b16f6fc41c5 Author: serb Date: 2012-10-19 15:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6b16f6fc41c5 7124520: [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java + test/java/awt/GraphicsConfiguration/NormalizingTransformTest/NormalizingTransformTest.java Changeset: e0f91b40b8dd Author: alexsch Date: 2012-10-23 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e0f91b40b8dd 6624200: Regression test fails: test/closed/javax/swing/JMenuItem/4654927/bug4654927.java Reviewed-by: rupashka + test/javax/swing/JMenuItem/4654927/bug4654927.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 37a6ead4a357 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37a6ead4a357 Merge Changeset: fecba6a8b78e Author: coffeys Date: 2012-10-09 12:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fecba6a8b78e 7196533: TimeZone.getDefault() slow due to synchronization bottleneck Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java Changeset: 3b79177ebfef Author: alanb Date: 2012-10-09 13:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b79177ebfef 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt Changeset: 036c55976cef Author: lancea Date: 2012-10-09 08:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/036c55976cef 7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC Reviewed-by: alanb, smarks ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: c725ce4bbf12 Author: naoto Date: 2012-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c725ce4bbf12 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java Changeset: 71de5e31d497 Author: coffeys Date: 2012-10-09 19:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71de5e31d497 7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed Reviewed-by: alanb, chegar ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/SocketGrowth.java Changeset: 3c4be36de073 Author: lancea Date: 2012-10-10 11:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c4be36de073 8000687: Correct javadoc typo for getLogWriter and setLogWriter Reviewed-by: alanb ! src/share/classes/java/sql/DriverManager.java Changeset: 6455182d2797 Author: alanb Date: 2012-10-10 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6455182d2797 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods Reviewed-by: mchung, lancea, chegar ! src/share/classes/java/util/logging/LogManager.java Changeset: 734ca9f4719c Author: lancea Date: 2012-10-10 17:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/734ca9f4719c 8000712: Remove unused fields in SyncFactory Reviewed-by: mchung ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: c2be39b27e1c Author: dxu Date: 2012-10-11 11:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c2be39b27e1c 7186817: Remove Windows 95/98/ME Support Reviewed-by: alanb ! make/java/java/Makefile ! makefiles/CompileNativeLibraries.gmk - src/windows/classes/java/io/Win32FileSystem.java ! src/windows/classes/java/io/WinNTFileSystem.java ! src/windows/native/java/io/FileSystem_md.c - src/windows/native/java/io/Win32FileSystem_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/util/TimeZone_md.c ! test/java/io/pathNames/win32/bug6344646.java Changeset: 7c2f5e52863c Author: robm Date: 2012-10-11 18:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7c2f5e52863c 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol] Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java Changeset: daabaafd6798 Author: lancea Date: 2012-10-11 18:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/daabaafd6798 8000763: use XXX.valueOf methods instead of constructors Reviewed-by: mchung, forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java Changeset: e23f8e0a1d89 Author: lana Date: 2012-10-12 14:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e23f8e0a1d89 Merge Changeset: ff641c5b329b Author: jgish Date: 2012-10-13 10:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff641c5b329b 7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java Changeset: fe28e0b035e7 Author: sflores Date: 2012-10-14 22:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fe28e0b035e7 7194449: String resources for Key Tool and Policy Tool should be in their respective packages Reviewed-by: alanb, weijun, mullan ! make/common/Release.gmk ! make/launchers/Makefile ! make/sun/security/tools/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java + src/share/classes/sun/security/tools/jarsigner/Main.java + src/share/classes/sun/security/tools/jarsigner/Resources.java + src/share/classes/sun/security/tools/jarsigner/Resources_ja.java + src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java + src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java + src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java + src/share/classes/sun/security/tools/keytool/Main.java + src/share/classes/sun/security/tools/keytool/Resources.java + src/share/classes/sun/security/tools/keytool/Resources_de.java + src/share/classes/sun/security/tools/keytool/Resources_es.java + src/share/classes/sun/security/tools/keytool/Resources_fr.java + src/share/classes/sun/security/tools/keytool/Resources_it.java + src/share/classes/sun/security/tools/keytool/Resources_ja.java + src/share/classes/sun/security/tools/keytool/Resources_ko.java + src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/keytool/Resources_sv.java + src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/keytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + src/share/classes/sun/security/tools/policytool/Resources.java + src/share/classes/sun/security/tools/policytool/Resources_de.java + src/share/classes/sun/security/tools/policytool/Resources_es.java + src/share/classes/sun/security/tools/policytool/Resources_fr.java + src/share/classes/sun/security/tools/policytool/Resources_it.java + src/share/classes/sun/security/tools/policytool/Resources_ja.java + src/share/classes/sun/security/tools/policytool/Resources_ko.java + src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/policytool/Resources_sv.java + src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/policytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/NewSize7.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Resources/Format.java ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/util/Resources/NewResourcesNames.java ! test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7055257a25c4 Author: robm Date: 2012-10-15 03:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7055257a25c4 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java Reviewed-by: alanb, martin ! test/java/lang/ProcessBuilder/Basic.java Changeset: c0736b62160e Author: robm Date: 2012-10-15 22:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c0736b62160e 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java + test/com/sun/jndi/ldap/LdapTimeoutTest.java - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 32452042b781 Author: naoto Date: 2012-10-16 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/32452042b781 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider 8000615: JRE adapter: timezone name of en_US is changed when extension directory is added Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java Changeset: 3a6b76a468bd Author: khazra Date: 2012-10-16 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a6b76a468bd 7198073: (prefs) user prefs not saved [macosx] Summary: Using class member field to get node instead of argument Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/CheckUserPrefFirst.java + test/java/util/prefs/CheckUserPrefLater.java + test/java/util/prefs/CheckUserPrefsStorage.sh Changeset: 14b9e294d049 Author: alanb Date: 2012-10-17 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/14b9e294d049 8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported Reviewed-by: mchung, chegar ! src/share/classes/java/util/Properties.java ! src/share/classes/sun/util/spi/XmlPropertiesProvider.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java Changeset: 5eed4a92ca8c Author: ngmr Date: 2012-10-17 13:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5eed4a92ca8c 8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour Reviewed-by: mduigou, alanb ! src/share/classes/java/util/Hashtable.java + test/java/util/Map/EntryHashCode.java Changeset: b2d8a99a049e Author: dsamersoff Date: 2012-10-17 18:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b2d8a99a049e 6809322: javax.management.timer.Timer does not fire all notifications Summary: Some notifications get dropped due to ConcurrentModificationException thrown in Timer.notifyAlarmClock() method. Reviewed-by: dholmes, rbackman Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/timer/MissingNotificationTest.java Changeset: 6156b9235758 Author: mchung Date: 2012-10-17 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6156b9235758 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false Reviewed-by: alanb, ohair ! make/common/internal/Defs-jaxws.gmk Changeset: 586028bbf885 Author: psandoz Date: 2012-10-17 20:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/586028bbf885 7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ServiceLoader.java ! test/java/util/ServiceLoader/Basic.java ! test/java/util/ServiceLoader/basic.sh Changeset: b265ead7f331 Author: alanb Date: 2012-10-17 21:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b265ead7f331 8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods Reviewed-by: lancea, chegar, mchung, ksrini ! src/share/classes/java/util/jar/Pack200.java Changeset: 60994591be6b Author: naoto Date: 2012-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60994591be6b 8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing Reviewed-by: okutsu ! test/java/util/PluggableLocale/barprovider.jar Changeset: 3f62cfc4e83d Author: xuelei Date: 2012-10-18 01:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f62cfc4e83d 7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server Reviewed-by: mullan, weijun, wetmore ! src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java + src/share/classes/javax/net/ssl/SNIHostName.java + src/share/classes/javax/net/ssl/SNIMatcher.java + src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java + src/share/classes/javax/net/ssl/StandardConstants.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SunJSSE.java + src/share/classes/sun/security/ssl/Utilities.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java + test/sun/security/ssl/templates/SSLCapabilities.java + test/sun/security/ssl/templates/SSLExplorer.java Changeset: 27f854a1e5c5 Author: chegar Date: 2012-10-19 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27f854a1e5c5 8000206: Uninitialized variable in PlainDatagramSocketImpl.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/PlainDatagramSocketImpl.c Changeset: 21f1b88e68ce Author: xuelei Date: 2012-10-19 20:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/21f1b88e68ce 8000954: Add final keyword to new method in SSLParameters Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java Changeset: 93303f8a4a8e Author: alanb Date: 2012-10-20 21:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/93303f8a4a8e 8000941: Remove ftp from the required list of protocol handlers Reviewed-by: chegar ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html Changeset: a40b0f51613b Author: jjh Date: 2012-10-20 22:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a40b0f51613b 7197401: Add a subset of the org.objectweb.asm packages to jdk8 Reviewed-by: ohair, briangoetz, erikj, iris ! THIRD_PARTY_README ! make/Makefile + make/jdk/Makefile + make/jdk/asm/Makefile + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java + src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Edge.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/Handle.java + src/share/classes/jdk/internal/org/objectweb/asm/Handler.java + src/share/classes/jdk/internal/org/objectweb/asm/Item.java + src/share/classes/jdk/internal/org/objectweb/asm/Label.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java + src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile + test/jdk/asm/AsmSanity.java Changeset: b39ab9c6f4cb Author: weijun Date: 2012-10-22 09:59 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b39ab9c6f4cb 8001204: typo: Unable to obtain Princpal Name for authentication Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: e19dc885da0d Author: weijun Date: 2012-10-22 17:01 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e19dc885da0d 8000624: Move MaxRetries.java to ProblemList for the moment Reviewed-by: alanb ! test/ProblemList.txt Changeset: 2048ce5a12ff Author: twisti Date: 2012-10-22 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2048ce5a12ff 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp Reviewed-by: dholmes, mchung ! test/java/lang/ref/Basic.java Changeset: a1e77f7ed52b Author: weijun Date: 2012-10-23 10:02 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1e77f7ed52b 8001208: Fix for KRB5CCNAME not complete Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! test/sun/security/krb5/ccache/EmptyCC.java Changeset: 29b58cb8e4fc Author: chegar Date: 2012-10-23 11:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/29b58cb8e4fc 8000204: Memory leak in com/sun/security/auth/module/Unix.c Reviewed-by: dsamersoff, wetmore, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/com/sun/security/auth/module/Unix.c Changeset: cdc7f9be3707 Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cdc7f9be3707 Merge - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 0582dc4674c9 Author: wetmore Date: 2012-05-21 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0582dc4674c9 7167656: Multiple Seeders are being created Reviewed-by: smarks, mduigou, ahgross ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: b4f35876d9b5 Author: mullan Date: 2012-06-08 11:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4f35876d9b5 7163198: Tightened package accessibility 7169887: Tightened package accessibility Reviewed-by: vinnie, hawtin ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89a0551b98d8 Author: weijun Date: 2012-06-15 09:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89a0551b98d8 6631398: FilePermission improved path checking Reviewed-by: mullan, skoivu, jdn ! src/share/classes/java/io/FilePermission.java Changeset: 7439e8007e09 Author: mullan Date: 2012-06-18 10:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7439e8007e09 7172522: Improve DomainCombiner checking Reviewed-by: vinnie, ahgross ! src/share/classes/java/security/AccessController.java Changeset: 2a98c51549a8 Author: smarks Date: 2012-06-21 00:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a98c51549a8 7093490: adjust package access in rmiregistry Reviewed-by: ahgross, coffeys, dmocek ! src/share/classes/sun/rmi/registry/RegistryImpl.java Changeset: 263f15439f4b Author: dsamersoff Date: 2012-06-22 16:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/263f15439f4b 7158796: Tighten properties checking in EnvHelp Summary: Move getProperty call out of computeBooleanFromString Reviewed-by: skoivu, sla ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java Changeset: 3a825f6cbc71 Author: dsamersoff Date: 2012-06-22 18:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a825f6cbc71 7169888: Narrowing resource definitions in JMX RMI connector Summary: CPU bug, we can't put offending calls outside doPrivileged, but narrow granted permissions. Reviewed-by: ahgross, fparain ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: 90498c1cc87c Author: xuelei Date: 2012-07-28 19:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90498c1cc87c 7186286: TLS implementation to better adhere to RFC Summary: also reviewed by Alexander Fomin , Andrew Gross, Sean Coffey Reviewed-by: valeriep, wetmore ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 983c17aecdac Author: mullan Date: 2012-08-15 15:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/983c17aecdac 7189490: More improvements to DomainCombiner checking Reviewed-by: ahgross, jdn, vinnie ! src/share/classes/java/security/AccessController.java Changeset: 6cc28cc213b6 Author: chegar Date: 2012-08-16 15:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6cc28cc213b6 7189103: Executors needs to maintain state Reviewed-by: dholmes, hawtin ! src/share/classes/java/util/concurrent/Executors.java Changeset: a09b9ebb61b6 Author: chegar Date: 2012-08-29 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a09b9ebb61b6 7189567: java net obselete protocol Reviewed-by: alanb, ahgross ! make/sun/net/FILES_java.gmk - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! test/java/net/URL/Test.java Changeset: 2ac636f46c5b Author: alanb Date: 2012-09-08 20:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ac636f46c5b 7169884: LogManager checks do not work correctly for sub-types Reviewed-by: mchung, ahgross ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 4488ea026532 Author: asaha Date: 2012-09-08 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4488ea026532 Merge Changeset: e869a8513cb7 Author: smarks Date: 2012-09-10 16:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e869a8513cb7 7195919: (sl) ServiceLoader can throw CCE without needing to create instance Reviewed-by: ahgross, alanb, dmeetry ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/misc/Service.java Changeset: 9a7e2fa3c9c5 Author: malenkov Date: 2012-09-11 12:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9a7e2fa3c9c5 7195549: Better bean object persistence Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java Changeset: 1d1fcf0c1ce8 Author: rupashka Date: 2012-09-11 15:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d1fcf0c1ce8 7195194: Better data validation for Swing Reviewed-by: art, ahgross ! src/share/classes/javax/swing/text/DefaultFormatter.java Changeset: 3b49bd3c392b Author: malenkov Date: 2012-09-19 21:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b49bd3c392b 7195917: XMLDecoder parsing at close-time should be improved Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java ! src/share/classes/java/beans/XMLDecoder.java Changeset: 762eee5e6e16 Author: jrose Date: 2012-09-20 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/762eee5e6e16 7196190: Improve method of handling MethodHandles Summary: Bind callers to caller-sensitive methods. Reviewed-by: twisti, jjh, vlivanov, ahgross ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/anon/AnonymousClassLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/7196190/ClassForNameTest.java + test/java/lang/invoke/7196190/GetUnsafeTest.java + test/java/lang/invoke/7196190/MHProxyTest.java + test/java/lang/invoke/7196190/jtreg.security.policy Changeset: e113ffde452a Author: dsamersoff Date: 2012-09-24 16:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e113ffde452a 7198296: Problem with classloader in JMX Summary: wb classes have to be available for hotspot tests Reviewed-by: ahgross, asaha Contributed-by: frederic.parain at oracle.com, daniel.fuchs at oracle.com, jean-francois.denise at oracle.com ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: ca79b33a0731 Author: dsamersoff Date: 2012-09-24 17:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ca79b33a0731 7192975: Issue with JMX reflection Summary: Make security check unconditional Reviewed-by: ahgross, asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java Changeset: 74eec13c464e Author: asaha Date: 2012-09-25 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/74eec13c464e Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk Changeset: e4ce54b79bb4 Author: asaha Date: 2012-10-10 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e4ce54b79bb4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 28fe37b50e3c Author: asaha Date: 2012-10-11 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28fe37b50e3c Merge Changeset: d3b3fea7d1d7 Author: asaha Date: 2012-10-18 22:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d3b3fea7d1d7 Merge ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/util/ServiceLoader.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: e6fbbb2c610d Author: lana Date: 2012-10-23 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6fbbb2c610d Merge ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: dfd509da3da6 Author: lana Date: 2012-10-25 20:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dfd509da3da6 Merge ! make/common/Release.gmk ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c ! test/ProblemList.txt - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 64dd2aba6d33 Author: ohair Date: 2012-10-26 14:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64dd2aba6d33 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJdk.gmk + makefiles/Bundles.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCLDR.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcCharsetMapping.gmk ! makefiles/GensrcExceptions.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcSwing.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/Tools.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 + makefiles/sun/awt/X11/ToBin.java + makefiles/sun/osxapp/ToBin.java - makefiles/sun/xawt/ToBin.java Changeset: 5b29d6157504 Author: erikj Date: 2012-10-29 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b29d6157504 8001887: build-infra: Correct mapfiles in build-infra area Reviewed-by: ohair ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris Changeset: dcee387cde81 Author: ohrstrom Date: 2012-10-29 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dcee387cde81 8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and sizer compilation Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk ! makefiles/GensrcX11Wrappers.gmk Changeset: 524d1a705f7b Author: erikj Date: 2012-10-29 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/524d1a705f7b 8001898: build-infra: correct exclusion lists for mac jar builds 8001896: build-infra: UNLIMITED_CRYPTO changes Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: f117a3e06f78 Author: katleman Date: 2012-10-31 18:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f117a3e06f78 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: 7ac292e57b5a Author: katleman Date: 2012-11-01 14:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ac292e57b5a Added tag jdk8-b63 for changeset f117a3e06f78 ! .hgtags From john.coomes at oracle.com Thu Nov 1 21:02:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:02:04 +0000 Subject: hg: hsx/hotspot-main/langtools: 15 new changesets Message-ID: <20121102040239.7E50947709@hg.openjdk.java.net> Changeset: c75be5bc5283 Author: jjg Date: 2012-10-09 19:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c75be5bc5283 8000663: clean up langtools imports Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java ! src/share/classes/javax/annotation/processing/Completions.java ! src/share/classes/javax/annotation/processing/FilerException.java ! src/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/share/classes/javax/lang/model/element/AnnotationValue.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/ElementScanner8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/share/classes/javax/tools/JavaFileObject.java Changeset: fc123bdeddb8 Author: jjg Date: 2012-10-09 19:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fc123bdeddb8 8000208: fix langtools javadoc comment issues Reviewed-by: bpatel, mcimadamore ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java Changeset: 25e14ad23cef Author: jjg Date: 2012-10-10 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/25e14ad23cef 8000665: fix "internal API" comments on javadoc files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseExecutableMemberTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseInlineTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritableTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/CommentedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TaggedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TextTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java Changeset: 560d4a5d14e6 Author: jjg Date: 2012-10-10 18:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/560d4a5d14e6 8000743: docencoding not available to stylesheet Reviewed-by: jjg Contributed-by: jviswana at linux.vnet.ibm.com ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testDocEncoding/TestDocEncoding.java + test/com/sun/javadoc/testDocEncoding/pkg/Test.java Changeset: 6517bf8e50d0 Author: jjg Date: 2012-10-10 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6517bf8e50d0 8000418: javadoc should used a standard "generated by javadoc" string Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java + test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java + test/com/sun/javadoc/testGeneratedBy/pkg/MyClass.java Changeset: c46e0c9940d6 Author: jjg Date: 2012-10-10 18:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c46e0c9940d6 8000310: Clean up use of StringBuffer in langtools Reviewed-by: bpatel ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java Changeset: 0d1818e9d4ae Author: lana Date: 2012-10-12 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0d1818e9d4ae Merge Changeset: 8db45b13526e Author: jjg Date: 2012-10-15 17:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8db45b13526e 8000666: javadoc should write directly to Writer instead of composing strings Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 2013982bee34 Author: jjg Date: 2012-10-16 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2013982bee34 8000673: remove dead code from HtmlWriter and subtypes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java Changeset: 12cf6bfd8c05 Author: mcimadamore Date: 2012-10-17 16:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/12cf6bfd8c05 7192245: Add parser support for default methods Summary: Add support for 'default' keyword in modifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/DefaultMethodNotSupported.java Changeset: 5dde04b8bbb3 Author: lana Date: 2012-10-23 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5dde04b8bbb3 Merge Changeset: 669468143a5e Author: lana Date: 2012-10-25 20:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/669468143a5e Merge Changeset: 741cce355ba6 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/741cce355ba6 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 92e6f2190ca0 Author: katleman Date: 2012-10-31 18:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/92e6f2190ca0 Merge Changeset: 26831b6fcc4a Author: katleman Date: 2012-11-01 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/26831b6fcc4a Added tag jdk8-b63 for changeset 92e6f2190ca0 ! .hgtags From john.coomes at oracle.com Fri Nov 2 00:52:33 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 07:52:33 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20121102075241.A2ED347728@hg.openjdk.java.net> Changeset: 3fadc0e8cffe Author: jmasa Date: 2012-10-30 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3fadc0e8cffe 8000988: VM deadlock when running btree006 on windows-i586 Reviewed-by: johnc, jcoomes, ysr ! src/share/vm/memory/collectorPolicy.cpp Changeset: 3dfffc8b9722 Author: brutisso Date: 2012-10-30 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3dfffc8b9722 8001564: The load balancing function steal_1_random in taskqueue is not random Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all Reviewed-by: brutisso, stefank Contributed-by: erik.x.helin at oracle.com ! src/share/vm/utilities/taskqueue.hpp Changeset: ca6d147ed881 Author: jcoomes Date: 2012-11-01 23:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca6d147ed881 Merge From alejandro.murillo at oracle.com Fri Nov 2 05:59:22 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 02 Nov 2012 12:59:22 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20121102125931.21A9747735@hg.openjdk.java.net> Changeset: a3e2f723f2a5 Author: twisti Date: 2012-10-29 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a3e2f723f2a5 8000780: make Zero build and run with JDK8 Reviewed-by: coleenp, dholmes, twisti Contributed-by: Roman Kennke ! make/Makefile ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: d8f9034920f6 Author: amurillo Date: 2012-11-02 04:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d8f9034920f6 Merge From roland.westrelin at oracle.com Fri Nov 2 09:44:45 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 2 Nov 2012 17:44:45 +0100 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <508DF417.7090906@oracle.com> References: <508DF417.7090906@oracle.com> Message-ID: <52DC1C50-1478-4AED-A95D-B5F030293941@oracle.com> Hi Bharadwaj, > I'd like to get a code review of the changes at http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_01/ Shouldn't Compile::_dead_node_count be set to _dead_node_list.size() after/in a call to Compile::identify_useful_nodes()? Roland. From alejandro.murillo at oracle.com Fri Nov 2 09:44:31 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 02 Nov 2012 16:44:31 +0000 Subject: hg: hsx/hsx25/hotspot: 30 new changesets Message-ID: <20121102164537.C983147744@hg.openjdk.java.net> Changeset: bf14ed159fb0 Author: kvn Date: 2012-05-23 12:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bf14ed159fb0 7158801: Improve VM CompileOnly option Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file. Reviewed-by: never ! src/share/vm/compiler/compilerOracle.cpp Changeset: fe4a4ea5bed9 Author: kamg Date: 2012-06-08 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fe4a4ea5bed9 7158804: Improve config file parsing Summary: Check buffer length when reading Reviewed-by: dholmes, dcubed ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7158804/Test7158804.sh Changeset: 6b5a3d18fe0e Author: asaha Date: 2012-08-02 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b5a3d18fe0e Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 000352e00389 Author: asaha Date: 2012-08-02 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/000352e00389 Merge Changeset: defeb6dad7d5 Author: asaha Date: 2012-08-10 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/defeb6dad7d5 Merge Changeset: e4d10261499c Author: asaha Date: 2012-09-07 18:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e4d10261499c Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 521c82b9cbf8 Author: kvn Date: 2012-09-19 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/521c82b9cbf8 7198606: Improve VM optimization Summary: Remove incorrect code in OptimizeFill optimization. Reviewed-by: roland, twisti ! src/share/vm/opto/loopTransform.cpp Changeset: 849cf0480cb9 Author: asaha Date: 2012-09-25 11:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/849cf0480cb9 Merge Changeset: 5a3a6dac85e2 Author: asaha Date: 2012-09-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5a3a6dac85e2 7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match. Reviewed-by: coleenp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 218a94758fe7 Author: asaha Date: 2012-10-10 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/218a94758fe7 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 6ba00f89fbe1 Author: asaha Date: 2012-10-11 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6ba00f89fbe1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d2582a08fa5d Author: asaha Date: 2012-10-18 21:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d2582a08fa5d Merge ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: cb829aa4c98e Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cb829aa4c98e Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: acabb5c282f5 Author: lana Date: 2012-10-30 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/acabb5c282f5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 4d37eb50b9b1 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4d37eb50b9b1 Added tag jdk8-b63 for changeset acabb5c282f5 ! .hgtags Changeset: a516debe2cee Author: amurillo Date: 2012-10-26 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a516debe2cee 8001663: new hotspot build - hs25-b08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5ec0c42da025 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ec0c42da025 7188234: Deprecate VM command line options Summary: Remove support for the UseVectoredExceptions flag Reviewed-by: jcoomes, kamg Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e81fbc04a942 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e81fbc04a942 7191817: -XX:+UseSerialGC -XX:+UseLargePages crashes with SIGFPE on MacOS X Summary: Disable -XX:+UseLargePages for MacOS X Reviewed-by: dholmes, coleenp, sla Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 0af5da0c9d9d Author: sla Date: 2012-10-29 21:04 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0af5da0c9d9d 8001619: Remove usage of _ALLBSD_SOURCE in bsd files Reviewed-by: coleenp, dholmes ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp Changeset: 39556eae08af Author: sspitsyn Date: 2012-10-29 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/39556eae08af 6533010: SPEC: A few broken links in jvmti.html Summary: Fix the incorrect links in jvmti.html reported by the LinkCheck tool Reviewed-by: jjh, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 845129b692f6 Author: minqi Date: 2012-10-29 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/845129b692f6 Merge Changeset: a1b8cf9cf970 Author: sla Date: 2012-11-01 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a1b8cf9cf970 8002078: hs_err_pid file should report full JDK version string Reviewed-by: dholmes, sspitsyn, kmo ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: cae17c597196 Author: coleenp Date: 2012-11-01 11:57 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cae17c597196 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3fadc0e8cffe Author: jmasa Date: 2012-10-30 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3fadc0e8cffe 8000988: VM deadlock when running btree006 on windows-i586 Reviewed-by: johnc, jcoomes, ysr ! src/share/vm/memory/collectorPolicy.cpp Changeset: 3dfffc8b9722 Author: brutisso Date: 2012-10-30 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3dfffc8b9722 8001564: The load balancing function steal_1_random in taskqueue is not random Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all Reviewed-by: brutisso, stefank Contributed-by: erik.x.helin at oracle.com ! src/share/vm/utilities/taskqueue.hpp Changeset: ca6d147ed881 Author: jcoomes Date: 2012-11-01 23:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca6d147ed881 Merge Changeset: a3e2f723f2a5 Author: twisti Date: 2012-10-29 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a3e2f723f2a5 8000780: make Zero build and run with JDK8 Reviewed-by: coleenp, dholmes, twisti Contributed-by: Roman Kennke ! make/Makefile ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: d8f9034920f6 Author: amurillo Date: 2012-11-02 04:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d8f9034920f6 Merge Changeset: 8cb93eadfb6d Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8cb93eadfb6d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 5920f72e799c Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5920f72e799c Added tag hs25-b08 for changeset 8cb93eadfb6d ! .hgtags From zhengyu.gu at oracle.com Fri Nov 2 10:21:08 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 02 Nov 2012 13:21:08 -0400 Subject: Code review request: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp In-Reply-To: <5091D136.8000801@oracle.com> References: <50914DE1.9050305@oracle.com> <5091D136.8000801@oracle.com> Message-ID: <50940104.5050408@oracle.com> Updated the webrev based on David's comment. Overlapping stacks is tracked by 8001743. http://cr.openjdk.java.net/~zgu/8001591/webrev.01/ Thanks, -Zhengyu On 10/31/2012 9:32 PM, David Holmes wrote: > On 1/11/2012 2:12 AM, Zhengyu Gu wrote: >> NMT did not allow overlapped commit on memory regions, which is >> incorrect. Committing overlapped memory regions should be allowed, as >> long as the regions are within a reserved region. > > So the overlapping stacks that were detected is perfectly valid? > >> >> http://cr.openjdk.java.net/~zgu/8001591/webrev.00/ > > The renaming from contains_xx to contain_xx is not correct. "contains" > is the correct form to use, and "overlaps" rather than "overlap". > > Why the variable rename in VMMemPointerIterator::add_reserved_region? > Given it is initialized from current() then 'cur' seems quite > acceptable. Otherwise maybe it is current() that has the wrong name? > The renaming generates a lot of noise in the webrev - it is hard to > see the actual substantive changes that were made. > > Cheers, > David > > >> Thanks, >> >> -Zhengyu From bharadwaj.yadavalli at oracle.com Fri Nov 2 11:16:11 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 02 Nov 2012 14:16:11 -0400 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <52DC1C50-1478-4AED-A95D-B5F030293941@oracle.com> References: <508DF417.7090906@oracle.com> <52DC1C50-1478-4AED-A95D-B5F030293941@oracle.com> Message-ID: <50940DEB.4060209@oracle.com> On 11/2/2012 12:44 PM, Roland Westrelin wrote: > Hi Bharadwaj, > >> I'd like to get a code review of the changes at http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_01/ > Shouldn't Compile::_dead_node_count be set to _dead_node_list.size() after/in a call to Compile::identify_useful_nodes()? Yes. That is correct. I have fixed that. Thanks for reviewing the code. I plan on sending out soon a new webrev incorporating all the review comments I received. Thanks, Bharadwaj From alejandro.murillo at oracle.com Fri Nov 2 10:59:56 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 02 Nov 2012 17:59:56 +0000 Subject: hg: hsx/hotspot-main/hotspot: 18 new changesets Message-ID: <20121102180034.86E7947745@hg.openjdk.java.net> Changeset: bf14ed159fb0 Author: kvn Date: 2012-05-23 12:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bf14ed159fb0 7158801: Improve VM CompileOnly option Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file. Reviewed-by: never ! src/share/vm/compiler/compilerOracle.cpp Changeset: fe4a4ea5bed9 Author: kamg Date: 2012-06-08 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fe4a4ea5bed9 7158804: Improve config file parsing Summary: Check buffer length when reading Reviewed-by: dholmes, dcubed ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7158804/Test7158804.sh Changeset: 6b5a3d18fe0e Author: asaha Date: 2012-08-02 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b5a3d18fe0e Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 000352e00389 Author: asaha Date: 2012-08-02 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/000352e00389 Merge Changeset: defeb6dad7d5 Author: asaha Date: 2012-08-10 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/defeb6dad7d5 Merge Changeset: e4d10261499c Author: asaha Date: 2012-09-07 18:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e4d10261499c Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 521c82b9cbf8 Author: kvn Date: 2012-09-19 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/521c82b9cbf8 7198606: Improve VM optimization Summary: Remove incorrect code in OptimizeFill optimization. Reviewed-by: roland, twisti ! src/share/vm/opto/loopTransform.cpp Changeset: 849cf0480cb9 Author: asaha Date: 2012-09-25 11:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/849cf0480cb9 Merge Changeset: 5a3a6dac85e2 Author: asaha Date: 2012-09-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5a3a6dac85e2 7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match. Reviewed-by: coleenp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 218a94758fe7 Author: asaha Date: 2012-10-10 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/218a94758fe7 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 6ba00f89fbe1 Author: asaha Date: 2012-10-11 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6ba00f89fbe1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d2582a08fa5d Author: asaha Date: 2012-10-18 21:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d2582a08fa5d Merge ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: cb829aa4c98e Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cb829aa4c98e Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: acabb5c282f5 Author: lana Date: 2012-10-30 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/acabb5c282f5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 4d37eb50b9b1 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4d37eb50b9b1 Added tag jdk8-b63 for changeset acabb5c282f5 ! .hgtags Changeset: 8cb93eadfb6d Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8cb93eadfb6d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 5920f72e799c Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5920f72e799c Added tag hs25-b08 for changeset 8cb93eadfb6d ! .hgtags Changeset: ca8168203393 Author: amurillo Date: 2012-11-02 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca8168203393 8002181: new hotspot build - hs25-b09 Reviewed-by: jcoomes ! make/hotspot_version From jiangli.zhou at oracle.com Fri Nov 2 14:33:50 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 2 Nov 2012 14:33:50 -0700 (PDT) Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt In-Reply-To: <50901EC1.3080506@oracle.com> References: <5089C7E1.2040206@oracle.com> <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com> <5089D6D0.3070909@oracle.com> <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com> <50901EC1.3080506@oracle.com> Message-ID: <50943C3E.2020708@oracle.com> Redirecting the review request to core-libs-dev at openjdk.java.net mail list (second try) ... Here is the webrev based on the jdk8/tl/jdk repository: http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ The '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options are added to following tests to reduce workload. The -DRicochetTest.MAX_ARITY of RicochetTest is changed from 50 to10 to reduce execution time on slower device and binary. Timeout settings are also added to each test. The '-esa' option is added to BigArityTest and MethodHandlesTest to enable asserts. java.lang.invoke.BigArityTest java.lang.invoke.MethodHandlesTest java.lang.invoke.CallSiteTest java.lang.invoke.RicochetTest Thanks, Jiangli On 10/30/2012 11:38 AM, Jiangli Zhou wrote: > Hi Chris, > > Here is the updated webrev with added > '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options and > timeout setting for the following tests: > > test.java.lang.invoke.RicochetTest > test.java.lang.invoke.BigArityTest > test.java.lang.invoke.MethodHandlesTest > test.java.lang.invoke.CallSiteTest > > http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/ > > Thanks, > > Jiangli From vladimir.kozlov at oracle.com Fri Nov 2 15:03:35 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Nov 2012 15:03:35 -0700 Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt In-Reply-To: <50943C3E.2020708@oracle.com> References: <5089C7E1.2040206@oracle.com> <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com> <5089D6D0.3070909@oracle.com> <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com> <50901EC1.3080506@oracle.com> <50943C3E.2020708@oracle.com> Message-ID: <50944337.3020006@oracle.com> Looks good. We know that VerifyDependencies has significant effect on debug VM performance. Thanks, Vladimir Jiangli Zhou wrote: > Redirecting the review request to core-libs-dev at openjdk.java.net mail > list (second try) ... > > Here is the webrev based on the jdk8/tl/jdk repository: > > http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ > > The '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options > are added to following tests to reduce workload. The > -DRicochetTest.MAX_ARITY of RicochetTest is changed from 50 to10 to > reduce execution time on slower device and binary. Timeout settings are > also added to each test. The '-esa' option is added to BigArityTest and > MethodHandlesTest to enable asserts. > > java.lang.invoke.BigArityTest > java.lang.invoke.MethodHandlesTest > java.lang.invoke.CallSiteTest > java.lang.invoke.RicochetTest > > Thanks, > Jiangli > > On 10/30/2012 11:38 AM, Jiangli Zhou wrote: >> Hi Chris, >> >> Here is the updated webrev with added >> '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options and >> timeout setting for the following tests: >> >> test.java.lang.invoke.RicochetTest >> test.java.lang.invoke.BigArityTest >> test.java.lang.invoke.MethodHandlesTest >> test.java.lang.invoke.CallSiteTest >> >> http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/ >> >> Thanks, >> >> Jiangli > > From jiangli.zhou at oracle.com Fri Nov 2 15:05:11 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 02 Nov 2012 15:05:11 -0700 Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt In-Reply-To: <50944337.3020006@oracle.com> References: <5089C7E1.2040206@oracle.com> <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com> <5089D6D0.3070909@oracle.com> <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com> <50901EC1.3080506@oracle.com> <50943C3E.2020708@oracle.com> <50944337.3020006@oracle.com> Message-ID: <50944397.8030607@oracle.com> Hi Vladimir, Thanks for the review! Jiangli On 11/02/2012 03:03 PM, Vladimir Kozlov wrote: > Looks good. > > We know that VerifyDependencies has significant effect on debug VM > performance. > > Thanks, > Vladimir > > Jiangli Zhou wrote: >> Redirecting the review request to core-libs-dev at openjdk.java.net mail >> list (second try) ... >> >> Here is the webrev based on the jdk8/tl/jdk repository: >> >> http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ >> >> The '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' >> options are added to following tests to reduce workload. The >> -DRicochetTest.MAX_ARITY of RicochetTest is changed from 50 to10 to >> reduce execution time on slower device and binary. Timeout settings >> are also added to each test. The '-esa' option is added to >> BigArityTest and MethodHandlesTest to enable asserts. >> >> java.lang.invoke.BigArityTest >> java.lang.invoke.MethodHandlesTest >> java.lang.invoke.CallSiteTest >> java.lang.invoke.RicochetTest >> >> Thanks, >> Jiangli >> >> On 10/30/2012 11:38 AM, Jiangli Zhou wrote: >>> Hi Chris, >>> >>> Here is the updated webrev with added >>> '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options >>> and timeout setting for the following tests: >>> >>> test.java.lang.invoke.RicochetTest >>> test.java.lang.invoke.BigArityTest >>> test.java.lang.invoke.MethodHandlesTest >>> test.java.lang.invoke.CallSiteTest >>> >>> http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/ >>> >>> Thanks, >>> >>> Jiangli >> >> From yunda.mly at taobao.com Sun Nov 4 02:14:16 2012 From: yunda.mly at taobao.com (=?gb2312?B?1Ma07w==?=) Date: Sun, 4 Nov 2012 10:14:16 +0000 Subject: Request for review (XXS): inconsistent comments in instanceKlass after 7017732 Message-ID: Hi all, I found a comment in instanceKlass that says ??embedded static fields follows here??. Since it??s no longer true, I made a patch to fix it: diff -r ca8168203393 src/share/vm/oops/instanceKlass.hpp --- a/src/share/vm/oops/instanceKlass.hpp Fri Nov 02 07:44:11 2012 -0700 +++ b/src/share/vm/oops/instanceKlass.hpp Sun Nov 04 17:53:42 2012 +0800 @@ -278,7 +278,6 @@ // embedded Java vtable follows here // embedded Java itables follows here - // embedded static fields follows here // embedded nonstatic oop-map blocks follows here // embedded implementor of this interface follows here // The embedded implementor only exists if the current klass is an And it seems that there??s always no comment of itable below ??// [EMBEDDED Java vtable ] size in words = vtable_len?? of vtable at the beginning of instanceKlass.hpp [1]. Could someone tell me why? Regards, Yunda [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/ca8168203393/src/share/vm/oops/instanceKlass.hpp ________________________________ This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? From coleen.phillimore at oracle.com Mon Nov 5 09:26:07 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 05 Nov 2012 12:26:07 -0500 Subject: Code review request: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp In-Reply-To: <50940104.5050408@oracle.com> References: <50914DE1.9050305@oracle.com> <5091D136.8000801@oracle.com> <50940104.5050408@oracle.com> Message-ID: <5097F6AF.5040601@oracle.com> Zhengyu, *+ address committed_rgn_end = committed_rgn->addr() +* *! _ committed_rgn->size(_); * Should "end" be addr() + size() -1 ? This looks fine otherwise. I like the renames that you did within the code you changed. Thanks, Coleen On 11/2/2012 1:21 PM, Zhengyu Gu wrote: > Updated the webrev based on David's comment. Overlapping stacks is > tracked by 8001743. > > http://cr.openjdk.java.net/~zgu/8001591/webrev.01/ > > Thanks, > > -Zhengyu > > On 10/31/2012 9:32 PM, David Holmes wrote: >> On 1/11/2012 2:12 AM, Zhengyu Gu wrote: >>> NMT did not allow overlapped commit on memory regions, which is >>> incorrect. Committing overlapped memory regions should be allowed, as >>> long as the regions are within a reserved region. >> >> So the overlapping stacks that were detected is perfectly valid? >> >>> >>> http://cr.openjdk.java.net/~zgu/8001591/webrev.00/ >> >> The renaming from contains_xx to contain_xx is not correct. >> "contains" is the correct form to use, and "overlaps" rather than >> "overlap". >> >> Why the variable rename in VMMemPointerIterator::add_reserved_region? >> Given it is initialized from current() then 'cur' seems quite >> acceptable. Otherwise maybe it is current() that has the wrong name? >> The renaming generates a lot of noise in the webrev - it is hard to >> see the actual substantive changes that were made. >> >> Cheers, >> David >> >> >>> Thanks, >>> >>> -Zhengyu From xerox.time.tech at gmail.com Mon Nov 5 09:37:45 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Mon, 5 Nov 2012 12:37:45 -0500 Subject: Embedded Benchmarks for Java Message-ID: I am wondering what kind of workloads and/or benchmarks does developer run to test the performance of Hotspot on embedded system. e.g. SPECJbb may not be a good candidate as embedded systems are not used to do transaction based processing, etc. Xin From zhengyu.gu at oracle.com Mon Nov 5 10:01:29 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 05 Nov 2012 13:01:29 -0500 Subject: Code review request: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp In-Reply-To: <5097F6AF.5040601@oracle.com> References: <50914DE1.9050305@oracle.com> <5091D136.8000801@oracle.com> <50940104.5050408@oracle.com> <5097F6AF.5040601@oracle.com> Message-ID: <5097FEF9.5020606@oracle.com> Coleen, Thanks for reviewing. On 11/5/2012 12:26 PM, Coleen Phillimore wrote: > > Zhengyu, > > *+ address committed_rgn_end = committed_rgn->addr() +* > *! _ committed_rgn->size(_); > > * > > Should "end" be addr() + size() -1 ? > I think we use this formula for end address. For example in stack calculation code, etc. In range checking, the end address is excluded, however. Thanks, -Zhengyu > This looks fine otherwise. I like the renames that you did within > the code you changed. > > Thanks, > Coleen > > On 11/2/2012 1:21 PM, Zhengyu Gu wrote: >> Updated the webrev based on David's comment. Overlapping stacks is >> tracked by 8001743. >> >> http://cr.openjdk.java.net/~zgu/8001591/webrev.01/ >> >> Thanks, >> >> -Zhengyu >> >> On 10/31/2012 9:32 PM, David Holmes wrote: >>> On 1/11/2012 2:12 AM, Zhengyu Gu wrote: >>>> NMT did not allow overlapped commit on memory regions, which is >>>> incorrect. Committing overlapped memory regions should be allowed, as >>>> long as the regions are within a reserved region. >>> >>> So the overlapping stacks that were detected is perfectly valid? >>> >>>> >>>> http://cr.openjdk.java.net/~zgu/8001591/webrev.00/ >>> >>> The renaming from contains_xx to contain_xx is not correct. >>> "contains" is the correct form to use, and "overlaps" rather than >>> "overlap". >>> >>> Why the variable rename in >>> VMMemPointerIterator::add_reserved_region? Given it is initialized >>> from current() then 'cur' seems quite acceptable. Otherwise maybe it >>> is current() that has the wrong name? The renaming generates a lot >>> of noise in the webrev - it is hard to see the actual substantive >>> changes that were made. >>> >>> Cheers, >>> David >>> >>> >>>> Thanks, >>>> >>>> -Zhengyu From xerox.time.tech at gmail.com Mon Nov 5 19:46:14 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Mon, 5 Nov 2012 22:46:14 -0500 Subject: get arguments in interpreter invoke_**** Message-ID: when a new method is about to be invoked in hotspot interpreter, the argument to the method is pushed onto the java stack. what would be the easiest way to get the arguments. i.e. 1. i need to get the number of arguments. 2. i need to get each argument and the type and size of each argument. Xin From rickard.backman at oracle.com Tue Nov 6 08:20:39 2012 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 06 Nov 2012 16:20:39 +0000 Subject: hg: hsx/hsx24/hotspot: 7127792: Add the ability to change an existing PeriodicTask's execution interval Message-ID: <20121106162043.49DFD477B9@hg.openjdk.java.net> Changeset: c2068b6bcf87 Author: rbackman Date: 2012-10-04 14:55 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c2068b6bcf87 7127792: Add the ability to change an existing PeriodicTask's execution interval Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread. Reviewed-by: dholmes, mgronlun ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp From staffan.larsen at oracle.com Wed Nov 7 01:49:12 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 7 Nov 2012 10:49:12 +0100 Subject: Result: New HSX Committer: Nils Loodin Message-ID: Voting for Nils Loodin [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. /Staffan Larsen [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/006996.html From roland.westrelin at oracle.com Wed Nov 7 01:56:56 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Nov 2012 10:56:56 +0100 Subject: New HSX Committer: Dean Long Message-ID: <717F2B9B-71C4-436E-AB5E-4ABC8C574FA6@oracle.com> Voting for Dean Long [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Roland Westrelin [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007020.html From zhengyu.gu at oracle.com Wed Nov 7 08:26:01 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 07 Nov 2012 11:26:01 -0500 Subject: Code review request: JDK-8001592 NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 Message-ID: <509A8B99.8050306@oracle.com> The assertion failure reflects that total memory that backs arenas are greater than total memory chunks for backing all arenas, which is obviously incorrect. The problem is due to Arena object, although it is declared as C-heap object, but it is used as value objects and stack objects as well. Value and stack objects do not have tracking records in NMT, which can leave arena size records alone in NMT. Because NMT uses Arena's deallocation records to cleanup size records, that means those leftover size records are not get cleanup. The solution is to use Arena's destructor to reset arena size to 0, and NMT uses this record to remove the corresponding record. The webrev also cleanup Memsnapshot::merge() routine, since virtual memory records now are stored in separate array, malloc staging area can keep only one record for each address (whoever has higher sequence number win), which should reduce memory usage by NMT. Webrev: http://cr.openjdk.java.net/~zgu/8001592/webrev.00/ Tests: vm.quick.testlist on Linux 32, Windows x64, Solaris AMD64 and Sparcv9 JPTR tests Thanks, -Zhengyu From roland.westrelin at oracle.com Wed Nov 7 08:33:28 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 7 Nov 2012 17:33:28 +0100 Subject: Result: New HSX Committer: Dean Long Message-ID: Voting for Dean Long [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Roland Westrelin [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007020.html From alejandro.murillo at oracle.com Wed Nov 7 15:53:05 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 07 Nov 2012 16:53:05 -0700 Subject: flag day In-Reply-To: <50298367.2050007@oracle.com> References: <50298367.2050007@oracle.com> Message-ID: <509AF461.6090300@oracle.com> Many apologies for the delay sending this info This afternoon I integrated hs24-b24 into jdk7u12 [1]. That integration includes the changes for JSR292 (invoke dynamic) that were integrated into jdk8 back in August. These changes require the hotspot and jdk repos to be in sync. (hotspot and jdk repos must match - i.e., either both must have the JSR292 changes or both must not have them) A JDK with mismatched repos may build but will not be able to handle invoke dynamics appropriately, and will fail with a message similar to this: $ java -showversion -Xbootclasspath/p:$PWD/classes -XX:+UnlockDiagnosticVMOptions -XX:+EnableInvokeDynamic Invalid layout of java.lang.invoke.MemberName at vmindex In particular, users of JPRT who have pulled the changes must build *both* hotspot and jdk until the JSR292 changes are in a promoted jdk7u12 build (expected tomorrow, Thu, November 8, 2012). The simplest coping strategy is to avoid pulling from the jdk7u master repo until the next jdk7u12 build is promoted. If you do pull, make sure to pull both hotspot and jdk, and to build both. [1] http://hg.openjdk.java.net/jdk7u/jdk7u Thanks -- Alejandro E Murillo, Java Performance Phone: (303) 955-2584. Timezone: US/Mountain (UTC-0700) From gary.collins at oracle.com Wed Nov 7 16:05:42 2012 From: gary.collins at oracle.com (gary.collins at oracle.com) Date: Thu, 08 Nov 2012 00:05:42 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8002034: Allow Full Debug Symbols when cross-compiling; ... Message-ID: <20121108000544.70D9147828@hg.openjdk.java.net> Changeset: 857f3ce858dd Author: dholmes Date: 2012-11-05 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/857f3ce858dd 8002034: Allow Full Debug Symbols when cross-compiling 8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances Reviewed-by: dcubed, dsamersoff, erikj, collins ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make From coleen.phillimore at oracle.com Wed Nov 7 17:44:12 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 08 Nov 2012 01:44:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20121108014430.1829347832@hg.openjdk.java.net> Changeset: 3d701c802d01 Author: minqi Date: 2012-11-02 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3d701c802d01 8000489: older builds of hsdis don't work anymore after 6879063 Summary: The old function not defined properly, need a definition for export in dll. Also changes made to let new jvm work with old hsdis. Reviewed-by: jrose, sspitsyn, kmo Contributed-by: yumin.qi at oracle.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 4735d2c84362 Author: kamg Date: 2012-10-11 12:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4735d2c84362 7200776: Implement default methods in interfaces Summary: Add generic type analysis and default method selection algorithms Reviewed-by: coleenp, acorn + src/share/vm/classfile/bytecodeAssembler.cpp + src/share/vm/classfile/bytecodeAssembler.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp + src/share/vm/classfile/defaultMethods.cpp + src/share/vm/classfile/defaultMethods.hpp + src/share/vm/classfile/genericSignatures.cpp + src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/growableArray.hpp + src/share/vm/utilities/pair.hpp + src/share/vm/utilities/resourceHash.hpp Changeset: ec204374e626 Author: kamg Date: 2012-11-02 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec204374e626 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 9cc901118f6b Author: kamg Date: 2012-11-02 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9cc901118f6b Merge Changeset: 69ad7823b1ca Author: zgu Date: 2012-11-05 15:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69ad7823b1ca 8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region Reviewed-by: dholmes, coleenp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp Changeset: 8940ddc1036f Author: zgu Date: 2012-11-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8940ddc1036f Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: c284cf4781f0 Author: rbackman Date: 2012-10-04 14:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c284cf4781f0 7127792: Add the ability to change an existing PeriodicTask's execution interval Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread. Reviewed-by: dholmes, mgronlun ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 18fb7da42534 Author: coleenp Date: 2012-11-06 15:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/18fb7da42534 8000725: NPG: method_holder() and pool_holder() and pool_holder field should be InstanceKlass Summary: Change types of above methods and field to InstanceKlass and remove unneeded casts from the source files. Reviewed-by: dholmes, coleenp, zgu Contributed-by: harold.seigel at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: ead8852dd4ef Author: coleenp Date: 2012-11-07 16:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ead8852dd4ef Merge From david.holmes at oracle.com Wed Nov 7 21:13:20 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 08 Nov 2012 05:13:20 +0000 Subject: hg: hsx/hsx24/hotspot: 8002034: Allow Full Debug Symbols when cross-compiling; ... Message-ID: <20121108051327.E919B4783B@hg.openjdk.java.net> Changeset: b9d9ae5d5525 Author: dholmes Date: 2012-11-05 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b9d9ae5d5525 8002034: Allow Full Debug Symbols when cross-compiling 8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances Reviewed-by: dcubed, dsamersoff, erikj, collins ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make From doug.simon at oracle.com Thu Nov 8 00:25:38 2012 From: doug.simon at oracle.com (Doug Simon @ Oracle) Date: Thu, 8 Nov 2012 09:25:38 +0100 Subject: Escape analysis for objects with injected fields Message-ID: <866A3B46-155B-44D2-9074-DACBC5B8E90A@oracle.com> While debugging a deoptimization issue in Graal[1], I (painfully) learnt of the importance of field ordering in the relationship between escape analyzed (EA) objects and deoptimization. In particular, the values in the DebugInfo for an EA'ed object must correspond with the field order returned by Klass::do_nonstatic_fields(). However, that latter function does not include internal/injected fields such as the 'loader_data' and 'dependencies' fields injected into java.lang.ClassLoader instances. So, my question is what happens when such an object is EA'ed and rematerialized during deoptimization? As far as I can tell, these fields will be left uninitialized. At least, I cannot see any code in c1 or c2 (e.g., line 704 of [2]) that omits such objects from EA. Am I missing something or is HotSpot just getting lucky by never determining that such objects are worthy of EA? -Doug [1] http://openjdk.java.net/projects/graal/ [2] http://hg.openjdk.java.net/hsx/hsx25/hotspot/raw-file/8e47bac5643a/src/share/vm/opto/macro.cpp From goetz.lindenmaier at sap.com Thu Nov 8 00:25:49 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Nov 2012 09:25:49 +0100 Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF4B7FF18@DEWDFECCR03.wdf.sap.corp> Hi Morris, I had a look at your change. As you know we maintain a port for IA64. We basically use all the IA64 specific code, although some of the defines are obviously superfluous. The changes are not that essential that removing them would cause us huge problems, but nevertheless we would prefer if most of them stay in the code to reduce our deviation from your code. In more detail: Code to remove ============= We do not use the agent on ia64, so we don't care about agent/src/os/linux/LinuxDebuggerLocal.c agent/src/os/linux/libproc.h agent/src/os/win32/windbg/sawindbg.cpp We don?t need the code here: src/os/bsd/vm/os_bsd.cpp Here we removed the #define ourselves: src/share/vm/interpreter/bytecodeInterpreter.cpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/runtime/synchronizer.cpp Further you can remove src/share/vm/runtime/vframeArray.cpp We can easily work around need_register_stack_bang(), and as it's rather platform dependent, just remove it in src/share/vm/opto/compile.hpp src/share/vm/opto/output.cpp Code to keep =========== This is basic platform support, so keep it please: src/share/vm/runtime/vm_version.cpp src/share/vm/utilities/macros.hpp Keep this: src/share/vm/prims/forte.cpp Don't care: src/share/vm/runtime/os.cpp We extended the code at this place to cover more cases, see below. Therefore we don't care about the fix in openJDK. Note that our code is also used on AMD64: // Looks like all platforms except IA64 can use the same function to check // if C stack is walkable beyond current frame. The check for fp() is not // necessary on Sparc, but it's harmless. bool os::is_first_C_frame(frame* fr) { #if defined(IA64) && !defined(_WIN32) // On IA64 we have to check if the callers bsp is still valid // (i.e. within the register stack bounds). // Notice: this only works for threads created by the VM and only if // we walk the current stack!!! If we want to be able to walk // arbitrary other threads, we'll have to somehow store the thread // object in the frame. Thread *thread = Thread::current(); if ((address)fr->fp() <= thread->register_stack_base() HPUX_ONLY(+ 0x0) LINUX_ONLY(+ 0x50)) { // This check is a little hacky, because on Linux the frist C // frame's ('start_thread') register stack frame starts at // "register_stack_base + 0x48" while on HPUX, the first C frame's // ('__pthread_bound_body') register stack frame seems to really // start at "register_stack_base". return true; } else { return false; } // On Windows AMD64 link() does not work as there's no back link on the stack. #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) return true; #else // Load up sp, fp, sender sp and sender fp, check for reasonable values. // Check usp first, because if that's bad the other accessors may fault // on some architectures. Ditto ufp second, etc. uintptr_t fp_align_mask = (uintptr_t)(sizeof(address)-1); The extension of the frame_slots in src/share/vm/opto/output.cpp is only needed for the _zap_dead_*_locals stubs. But better keep it. We use most of the code in os_linux.cpp as is, please keep it. src/os/linux/vm/os_linux.cpp There are two patches where you could improve the code: You could use IA64_ONLY(* 2) here: @@ -1174,12 +1170,7 @@ // for initial thread if its stack size exceeds 6M. Cap it at 2M, // in case other parts in glibc still assumes 2M max stack size. // FIXME: alt signal stack is gone, maybe we can relax this constraint? -#ifndef IA64 if (stack_size > 2 * K * K) stack_size = 2 * K * K; -#else - // Problem still exists RH7.2 (IA64 anyway) but 2MB is a little small - if (stack_size > 4 * K * K) stack_size = 4 * K * K; -#endif // Try to figure out where the stack base (top) is. This is harder. // You can apply this patch, instead I implemented the two functions empty in the platform file. @@ -4385,16 +4373,12 @@ if (is_NPTL()) { return pthread_cond_timedwait(_cond, _mutex, _abstime); } else { -#ifndef IA64 // 6292965: LinuxThreads pthread_cond_timedwait() resets FPU control // word back to default 64bit precision if condvar is signaled. Java // wants 53bit precision. Save and restore current value. int fpu = get_fpu_control_word(); -#endif // IA64 int status = pthread_cond_timedwait(_cond, _mutex, _abstime); -#ifndef IA64 set_fpu_control_word(fpu); -#endif // IA64 return status; } } We use all of the #defines/#ifdefs here: src/os/windows/vm/os_windows.cpp But we changed the IA64 specific code a lot. It's unclear whether this change is needed: src/share/vm/oops/oop.inline.hpp but to avoid a regression we would like to keep it. Maybe it would be better to protect the change by #if defined(IA64) && defined(_WIN32) as it's done at other shared code locations. Best regards, Goetz -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Montag, 5. November 2012 11:25 To: Morris Meyer Cc: Lindenmaier, Goetz Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code Hi Morris, we had a long weekend last week because last Thursday was public holiday in Germany, but my colleague Goetz is currently looking at the change and will come back to you. Thank you and best regards, Volker On Fri, Nov 2, 2012 at 10:42 PM, Morris Meyer > wrote: > Volker, > > Have you had a chance to review my changes for this bug? > > Thanks in advance, > > --morris From karen.kinnear at oracle.com Thu Nov 8 08:19:47 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 8 Nov 2012 11:19:47 -0500 Subject: Code review request: JDK-8001592 NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 In-Reply-To: <509A8B99.8050306@oracle.com> References: <509A8B99.8050306@oracle.com> Message-ID: Zhengyu, Code looks good. Thank you for the fixes. Minor comments: 1. memBaseline.cpp line 119 anonymouse -> anonymous 2. Much prefer the new MallocRecordIterator::current() behavior!!! 3. MallocRecordIterator::next() Can you possibly clarify? Lines 194-195 say that if there is an associated arena record it has to be the previous because of sorting order? -- what about sorting order means it is previous? - and it appears that you are looking at next_rec relative to prev_rec. What about the current rec - isn't that in the middle? - and many thanks for the detailed code comments and improved variable names. thanks, Karen On Nov 7, 2012, at 11:26 AM, Zhengyu Gu wrote: > The assertion failure reflects that total memory that backs arenas are greater than total memory chunks for backing all arenas, which is obviously incorrect. > > The problem is due to Arena object, although it is declared as C-heap object, but it is used as value objects and stack objects as well. Value and stack objects do not have tracking records in NMT, which can leave arena size records alone in NMT. Because NMT uses Arena's deallocation records to cleanup size records, that means those leftover size records are not get cleanup. > > The solution is to use Arena's destructor to reset arena size to 0, and NMT uses this record to remove the corresponding record. > > The webrev also cleanup Memsnapshot::merge() routine, since virtual memory records now are stored in separate array, malloc staging area can keep only one record for each address (whoever has higher sequence number win), which should reduce memory usage by NMT. > > Webrev: http://cr.openjdk.java.net/~zgu/8001592/webrev.00/ > > Tests: > vm.quick.testlist on Linux 32, Windows x64, Solaris AMD64 and Sparcv9 > JPTR tests > > > Thanks, > > -Zhengyu From zhengyu.gu at oracle.com Thu Nov 8 09:23:41 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 08 Nov 2012 12:23:41 -0500 Subject: Code review request: 8002273 NMT to report JNI memory leaks when -Xcheck:jni is on Message-ID: <509BEA9D.6090004@oracle.com> This fix is related to JDK-8001743: Overlapped thread stacks. The cause of 8001743 is that, an attached JNI thread exited without detaching the thread, so JVM will leak a JavaThread object that attached to the JNI thread. The patch allows NMT to report such case when -Xcheck:jni VM option is specified. http://cr.openjdk.java.net/~zgu/8002273/webrev.00/ Thanks, -Zhengyu From karen.kinnear at oracle.com Thu Nov 8 11:21:51 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 8 Nov 2012 14:21:51 -0500 Subject: Code review request: 8002273 NMT to report JNI memory leaks when -Xcheck:jni is on In-Reply-To: <509BEA9D.6090004@oracle.com> References: <509BEA9D.6090004@oracle.com> Message-ID: Zhengyu, Looks good and thank you for checking that with -Xcheck:jni. I checked the documentation, and the -Xcheck:jni documentation includes examples, it is not intended to ensure that we document every detailed check that we made, so it appears that we don't need to add documentation here. thanks, Karen On Nov 8, 2012, at 12:23 PM, Zhengyu Gu wrote: > This fix is related to JDK-8001743: Overlapped thread stacks. The cause of 8001743 is that, an attached JNI thread exited without detaching the thread, so JVM will leak a JavaThread object that attached to the JNI thread. > > The patch allows NMT to report such case when -Xcheck:jni VM option is specified. > > http://cr.openjdk.java.net/~zgu/8002273/webrev.00/ > > Thanks, > > -Zhengyu From christian.thalinger at oracle.com Thu Nov 8 14:23:57 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 08 Nov 2012 22:23:57 +0000 Subject: hg: hsx/hsx24/hotspot: 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path Message-ID: <20121108222400.20CDD47864@hg.openjdk.java.net> Changeset: 6bf89f3a38eb Author: twisti Date: 2012-11-08 12:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6bf89f3a38eb 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path Reviewed-by: jrose, kvn ! src/share/vm/ci/ciClassList.hpp + src/share/vm/ci/ciMethodType.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp From vladimir.kozlov at oracle.com Thu Nov 8 15:51:40 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Nov 2012 15:51:40 -0800 Subject: Escape analysis for objects with injected fields In-Reply-To: <866A3B46-155B-44D2-9074-DACBC5B8E90A@oracle.com> References: <866A3B46-155B-44D2-9074-DACBC5B8E90A@oracle.com> Message-ID: <509C458C.9080903@oracle.com> You are right, we are lucky :) File bug, add a test case and I will fix it. Thanks, Vladimir Doug Simon @ Oracle wrote: > While debugging a deoptimization issue in Graal[1], I (painfully) learnt of the importance of field ordering in the relationship between escape analyzed (EA) objects and deoptimization. In particular, the values in the DebugInfo for an EA'ed object must correspond with the field order returned by Klass::do_nonstatic_fields(). However, that latter function does not include internal/injected fields such as the 'loader_data' and 'dependencies' fields injected into java.lang.ClassLoader instances. So, my question is what happens when such an object is EA'ed and rematerialized during deoptimization? As far as I can tell, these fields will be left uninitialized. At least, I cannot see any code in c1 or c2 (e.g., line 704 of [2]) that omits such objects from EA. > > Am I missing something or is HotSpot just getting lucky by never determining that such objects are worthy of EA? > > -Doug > > [1] http://openjdk.java.net/projects/graal/ > [2] http://hg.openjdk.java.net/hsx/hsx25/hotspot/raw-file/8e47bac5643a/src/share/vm/opto/macro.cpp From vladimir.kozlov at oracle.com Thu Nov 8 16:20:11 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 09 Nov 2012 00:20:11 +0000 Subject: hg: hsx/hsx24/hotspot: 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Message-ID: <20121109002013.8370547867@hg.openjdk.java.net> Changeset: a6f5d539ced4 Author: kvn Date: 2012-11-06 15:16 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a6f5d539ced4 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values(). Reviewed-by: roland, twisti, vlivanov ! src/share/vm/opto/escape.cpp + test/compiler/8002069/Test8002069.java From david.holmes at oracle.com Thu Nov 8 20:06:19 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Nov 2012 14:06:19 +1000 Subject: Code review request: 8002273 NMT to report JNI memory leaks when -Xcheck:jni is on In-Reply-To: <509BEA9D.6090004@oracle.com> References: <509BEA9D.6090004@oracle.com> Message-ID: <509C813B.3030800@oracle.com> Hi Zhengyu, On 9/11/2012 3:23 AM, Zhengyu Gu wrote: > This fix is related to JDK-8001743: Overlapped thread stacks. The cause > of 8001743 is that, an attached JNI thread exited without detaching the > thread, so JVM will leak a JavaThread object that attached to the JNI > thread. > > The patch allows NMT to report such case when -Xcheck:jni VM option is > specified. > > http://cr.openjdk.java.net/~zgu/8002273/webrev.00/ I'm a little unclear who is doing the checking here. Is it the case that a regular thread while updating its NMT records, detects that there is an overlap with an existing region, and infers from that that the other region must belong to a thread that failed to detach? This comment doesn't read clearly to me, and we don't generally include references to bug reports: 138 // an attached JNI thread can exit without detaching the thread, that results 139 // JVM to leak JavaThread object (JDK-8001743) If my understanding of the check is correct then to me a clearer comment would be: // Overlapping stack regions indicate that a JNI thread failed to // detach from the VM before exiting. This leaks the JavaThread object. Cheers, David > Thanks, > > -Zhengyu From john.cuthbertson at oracle.com Fri Nov 9 00:52:41 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 09 Nov 2012 08:52:41 +0000 Subject: hg: hsx/hsx24/hotspot: 7200261: G1: Liveness counting inconsistencies during marking verification Message-ID: <20121109085243.C8FE947887@hg.openjdk.java.net> Changeset: cea242198338 Author: johnc Date: 2012-10-30 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/cea242198338 7200261: G1: Liveness counting inconsistencies during marking verification Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures. Reviewed-by: brutisso, jwilhelm ! 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 From john.coomes at oracle.com Fri Nov 9 01:32:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:32:17 +0000 Subject: hg: hsx/hotspot-main: 7 new changesets Message-ID: <20121109093217.CADBB47889@hg.openjdk.java.net> Changeset: dd1a80efa7cf Author: anthony Date: 2012-10-30 15:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dd1a80efa7cf 8001764: vsvars.sh should support VS2012 Summary: Update the vsvars.sh script to support VS2012 Reviewed-by: ohair, tbell ! make/scripts/vsvars.sh Changeset: fc61be4ff6ae Author: lana Date: 2012-10-31 09:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fc61be4ff6ae Merge ! make/scripts/vsvars.sh Changeset: 65dca75b2a26 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/65dca75b2a26 Merge Changeset: e20ffc02e437 Author: erikj Date: 2012-11-03 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e20ffc02e437 8002183: Increased max number of paths to list in ListPathsSafely to 16000. Reviewed-by: ohair ! common/makefiles/MakeBase.gmk Changeset: ed9e5635fc80 Author: erikj Date: 2012-11-03 16:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ed9e5635fc80 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/JavaCompilation.gmk Changeset: 1c8370a55b30 Author: katleman Date: 2012-11-07 15:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1c8370a55b30 Merge Changeset: 838a64965131 Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/838a64965131 Added tag jdk8-b64 for changeset 1c8370a55b30 ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:32:22 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:32:22 +0000 Subject: hg: hsx/hotspot-main/corba: 4 new changesets Message-ID: <20121109093228.271124788A@hg.openjdk.java.net> Changeset: 643e7612cf6d Author: ohrstrom Date: 2012-10-29 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/643e7612cf6d 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK. Reviewed-by: alanb, wetmore ! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java + src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java Changeset: aac74d377a03 Author: lana Date: 2012-10-30 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/aac74d377a03 Merge Changeset: 54d599a5b4aa Author: lana Date: 2012-11-02 17:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/54d599a5b4aa Merge Changeset: 5132f7900a8f Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5132f7900a8f Added tag jdk8-b64 for changeset 54d599a5b4aa ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:32:32 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:32:32 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b64 for changeset 27ab79568c34 Message-ID: <20121109093242.D85034788B@hg.openjdk.java.net> Changeset: 5cf3c69a93d6 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/5cf3c69a93d6 Added tag jdk8-b64 for changeset 27ab79568c34 ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:32:48 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:32:48 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b64 for changeset 5ded18a14bcc Message-ID: <20121109093254.5E9244788C@hg.openjdk.java.net> Changeset: fbe54291c9d3 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/fbe54291c9d3 Added tag jdk8-b64 for changeset 5ded18a14bcc ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:35:04 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:35:04 +0000 Subject: hg: hsx/hotspot-main/jdk: 47 new changesets Message-ID: <20121109094446.498EB4788D@hg.openjdk.java.net> Changeset: cc998992dc32 Author: bae Date: 2012-10-24 05:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc998992dc32 7053526: Upgrade JDK 8 to use Little CMS 2.4 Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/FILES_c_unix.gmk ! make/sun/cmm/lcms/FILES_c_windows.gmk ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c + src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: 00c8ea9ef1cf Author: lana Date: 2012-10-31 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/00c8ea9ef1cf Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: c9523d220bc3 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9523d220bc3 Merge Changeset: 3b889d1218f5 Author: alitvinov Date: 2012-10-24 18:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b889d1218f5 7193219: JComboBox serialization fails in JDK 1.7 Reviewed-by: rupashka, anthony ! src/share/classes/javax/swing/AncestorNotifier.java + test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: c27efe7615f8 Author: bagiras Date: 2012-10-25 09:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c27efe7615f8 8000486: REGRESSION: Three java2d tests fail since jdk8b58 on Windows 7 with NullPointerException Reviewed-by: flar, art ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: 9fb5db444365 Author: bagiras Date: 2012-10-25 19:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9fb5db444365 7082294: nsk/regression/b4265661 crashes on windows Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 7ead109417f0 Author: serb Date: 2012-10-29 23:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ead109417f0 7198229: Painting during resizing of the frame should be more smooth Reviewed-by: anthony, denis, skovatch ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 884402437aad Author: kshefov Date: 2012-10-30 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/884402437aad 7072120: No mac os x support in several regression tests Reviewed-by: anthony, serb ! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 6652efb69459 Author: lana Date: 2012-10-31 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6652efb69459 Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9b5c596a2920 Author: VKARNAUK Date: 2012-11-02 15:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b5c596a2920 2229575: Swing HTML parser can't properly decode codepoints outside the Unicode Plane 0 into a surrogate pair Reviewed-by: rupashka ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/6836089/bug6836089.java Changeset: 3d22bd7d6678 Author: alexp Date: 2012-11-02 16:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3d22bd7d6678 8001633: Wrong alt processing during switching between windows. Reviewed-by: ant, leonidr Contributed-by: Mikhail Cherkasov ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java Changeset: 094c963dca1b Author: leonidr Date: 2012-11-02 19:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/094c963dca1b 7124310: [macosx] "opposite" seems always null in focus events Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: f4a11601680b Author: leonidr Date: 2012-11-02 19:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4a11601680b 8002114: fix failed for JDK-7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: serb ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 509b3b4910ef Author: kshefov Date: 2012-11-02 17:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/509b3b4910ef 8001808: Create a test for 8000327 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 706056a4a6d9 Author: kshefov Date: 2012-11-02 17:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/706056a4a6d9 8001876: Create regtest for 8000283 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ShortcutNotDiplayed/ShortcutNotDisplayedTest.java Changeset: ebd8f16bae1b Author: lana Date: 2012-11-02 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ebd8f16bae1b Merge Changeset: 940c8cc5a5c4 Author: wetmore Date: 2012-10-23 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/940c8cc5a5c4 7197071: Makefiles for various security providers aren't including the default manifest Reviewed-by: valeriep, mullan, katleman ! make/com/oracle/security/ucrypto/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile + test/javax/crypto/sanity/CheckManifestForRelease.java Changeset: 13b46e8eda33 Author: ohrstrom Date: 2012-10-23 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13b46e8eda33 8001419: Build the JCE portion of JDK-8000970 Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/KeyProtector.java + src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java Changeset: e782f3c383fe Author: xuelei Date: 2012-10-24 08:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e782f3c383fe 8001466: Nightly regression test failure of SSLSocketSNISensitive.java Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java Changeset: 8e8fcd44b963 Author: jbachorik Date: 2012-10-24 20:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e8fcd44b963 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated Reviewed-by: alanb ! test/javax/management/remote/mandatory/URLTest.java Changeset: 909676adaefd Author: chegar Date: 2012-10-24 21:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/909676adaefd 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/net_util_md.c Changeset: 37a4b4892e8e Author: jgish Date: 2012-10-25 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37a4b4892e8e 7159567: inconsistent configuration of MemoryHandler Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java + test/java/util/logging/MemoryHandlerTest.java + test/java/util/logging/MemoryHandlerTest.props Changeset: 27677928a937 Author: dxu Date: 2012-10-25 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27677928a937 8001565: (fs) Typo Path.endsWith(String) javadoc Reviewed-by: mchung, jgish, lancea ! src/share/classes/java/nio/file/Path.java Changeset: 6302932b7380 Author: rfield Date: 2012-10-25 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6302932b7380 8000806: Implement runtime lambda metafactory Summary: Implement lambda invokedynamic bootstrap by generating at runtime an inner class that implements the functional interface Reviewed-by: twisti + src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/LambdaConversionException.java + src/share/classes/java/lang/invoke/LambdaMetafactory.java + src/share/classes/java/lang/invoke/MagicLambdaImpl.java + src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java Changeset: 0b52c87c39da Author: dxu Date: 2012-10-26 11:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0b52c87c39da 4239752: FileSystem should be a platform-specific class to avoid native code Reviewed-by: alanb, dholmes, erikj, jgish ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/mapfile-vers ! makefiles/CompileJavaClasses.gmk ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileSystem.java + src/solaris/classes/java/io/DefaultFileSystem.java - src/solaris/native/java/io/FileSystem_md.c + src/windows/classes/java/io/DefaultFileSystem.java - src/windows/native/java/io/FileSystem_md.c Changeset: 3fc5457cf779 Author: dl Date: 2012-10-26 21:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3fc5457cf779 8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012 Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadFactory.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/concurrent/package-info.java Changeset: 615af31cfccc Author: alanb Date: 2012-10-27 09:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/615af31cfccc 7176225: Remove JDBC-ODBC Bridge Reviewed-by: lancea, ohair, tbell ! make/common/Sanity.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Sanity.gmk ! make/sun/Makefile - make/sun/jdbc/Makefile ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 33e29fbc3e5b Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/33e29fbc3e5b 7184246: Simplify Config.get() of krb5 Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/KerberosTime.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/MaxRetries.java + test/sun/security/krb5/config/Duplicates.java + test/sun/security/krb5/config/SCDynamicConfigTest.java + test/sun/security/krb5/config/k1.conf Changeset: cb70077c6370 Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb70077c6370 7195426: kdc_default_options not supported correctly Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/KDCOptions.java + test/sun/security/krb5/config/KdcDefaultOptions.java + test/sun/security/krb5/config/kdc_default_options.conf Changeset: d1ffbdf7e3c6 Author: sla Date: 2012-10-29 09:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d1ffbdf7e3c6 8001621: Update awk scripts that check output from jps/jcmd Reviewed-by: alanb ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk Changeset: 17384fc6b31f Author: ohrstrom Date: 2012-10-29 14:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17384fc6b31f 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, wetmore + make/tools/src/build/tools/generatenimbus/AbstractGradient.java + make/tools/src/build/tools/generatenimbus/Border.java + make/tools/src/build/tools/generatenimbus/Canvas.java + make/tools/src/build/tools/generatenimbus/ComponentColor.java + make/tools/src/build/tools/generatenimbus/Dimension.java + make/tools/src/build/tools/generatenimbus/Ellipse.java + make/tools/src/build/tools/generatenimbus/Gradient.java + make/tools/src/build/tools/generatenimbus/GradientStop.java + make/tools/src/build/tools/generatenimbus/Insets.java + make/tools/src/build/tools/generatenimbus/Layer.java + make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/Path.java + make/tools/src/build/tools/generatenimbus/Point.java + make/tools/src/build/tools/generatenimbus/RadialGradient.java + make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/Typeface.java + make/tools/src/build/tools/generatenimbus/UIColor.java + make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIFont.java + make/tools/src/build/tools/generatenimbus/UIIconRegion.java + make/tools/src/build/tools/generatenimbus/UIProperty.java + make/tools/src/build/tools/generatenimbus/UIRegion.java + make/tools/src/build/tools/generatenimbus/UIState.java + make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! src/share/classes/javax/management/timer/Timer.java + src/share/classes/javax/management/timer/TimerAlarmClock.java + src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputMethodManager.java + src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/net/httpserver/Event.java + src/share/classes/sun/net/httpserver/WriteFinishedEvent.java + src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java + src/share/classes/sun/security/ssl/ExtensionType.java + src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java + src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java + src/share/classes/sun/security/ssl/ServerNameExtension.java + src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java + src/share/classes/sun/security/ssl/UnknownExtension.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java + src/solaris/classes/sun/awt/X11/XChoicePeerListener.java + src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java + src/solaris/classes/sun/java2d/jules/TileTrapContainer.java Changeset: 7fa45c455034 Author: naoto Date: 2012-10-29 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7fa45c455034 8000997: Multiple locale sensitive services cannot be loaded Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider Changeset: e2f976a73afb Author: jgish Date: 2012-10-29 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2f976a73afb 6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder) Reviewed-by: chegar, alanb, mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java + test/java/lang/StringBuffer/AppendStringBuilder.java + test/java/lang/StringBuffer/BufferForwarding.java + test/java/lang/StringBuffer/TestSynchronization.java + test/java/lang/StringBuilder/AppendStringBuffer.java + test/java/lang/StringBuilder/BuilderForwarding.java Changeset: ac97b1cfc0ea Author: lana Date: 2012-10-31 08:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac97b1cfc0ea Merge ! make/common/shared/Sanity.gmk ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: 178618fb4300 Author: naoto Date: 2012-10-31 11:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/178618fb4300 8001231: Move locale data out of rt.jar (except the US locale) Reviewed-by: alanb, erikj ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template Changeset: 8b944ebef8a7 Author: ohrstrom Date: 2012-11-01 10:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b944ebef8a7 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, sla + src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java + src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Changeset: 6420fcd61c10 Author: naoto Date: 2012-11-01 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6420fcd61c10 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormatSymbols.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: 8748331f63cf Author: lancea Date: 2012-11-01 17:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8748331f63cf 8001536: Added readObject,writeObject,clone, equals, hashcode to SerialXLob Reviewed-by: alanb, forax ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java Changeset: 79774104a1f4 Author: alanb Date: 2012-11-01 21:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79774104a1f4 8002120: ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 9b3867244eec Author: dholmes Date: 2012-11-01 18:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b3867244eec 7198815: Add the minimal VM as "known" in jvm.cfg Reviewed-by: alanb, forax, mchung ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg Changeset: 36f962518499 Author: weijun Date: 2012-11-02 10:48 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/36f962518499 7110803: SASL service for multiple hostnames Reviewed-by: mullan ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + test/com/sun/security/sasl/digest/Unbound.java + test/sun/security/krb5/auto/SaslBasic.java Changeset: 98a47dc23296 Author: peytoia Date: 2012-11-02 23:17 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98a47dc23296 8001209: Evaluate findbugs reprot for java.text.ChoiceFormat Reviewed-by: okutsu ! src/share/classes/java/text/ChoiceFormat.java + test/java/text/Format/ChoiceFormat/Bug8001209.java Changeset: cea72c2bf071 Author: alanb Date: 2012-11-02 15:50 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cea72c2bf071 7197491: update copyright year to match last edit in jdk8 jdk repository Reviewed-by: chegar, ksrini ! make/apple/Makefile ! make/apple/applescript/Makefile ! make/com/Makefile ! make/com/apple/Makefile ! make/com/apple/osx/Makefile ! make/com/apple/osxui/Makefile ! make/com/oracle/jfr/Makefile ! make/com/sun/Makefile ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/net/ssl/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Exportedfiles.gmk ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! make/com/sun/security/auth/module/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Exportedfiles.gmk ! make/com/sun/tools/attach/FILES_c.gmk ! make/com/sun/tools/attach/FILES_java.gmk ! make/com/sun/tools/attach/mapfile-bsd ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/common/Demo.gmk ! make/common/Mapfile-vers.gmk ! make/common/Release-macosx.gmk ! make/common/Rules.gmk ! make/common/Sanity.gmk ! make/common/internal/Defs-jaxws.gmk ! make/common/internal/NativeCompileRules.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-llvm.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile ! make/java/awt/Makefile ! make/java/fdlibm/FILES_c.gmk ! make/java/java/genlocales.gmk ! make/java/java/reflect/Makefile ! make/java/jobjc/Makefile ! make/java/jvm/Makefile ! make/java/management/mapfile-vers ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/rmi/Makefile ! make/java/security/Makefile ! make/java/sun_nio/FILES_java.gmk ! make/java/text/bidi/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/mapfile-vers ! make/javax/accessibility/Makefile ! make/javax/crypto/Makefile ! make/javax/sound/FILES_c.gmk ! make/javax/sound/SoundDefs.gmk ! make/javax/sound/jsoundalsa/Makefile ! make/jdk_generic_profile.sh ! make/jpda/back/Makefile ! make/jpda/jdwp/jdwp.spec ! make/jprt.properties ! make/mksample/Makefile ! make/netbeans/common/architectures/name-Bsd.properties ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/jconsole/build.xml ! make/org/ietf/jgss/Makefile ! make/sun/Makefile ! make/sun/awt/FILES_c_macosx.gmk ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mawt.gmk ! make/sun/cmm/lcms/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/FILES.gmk ! make/sun/jconsole/Makefile ! make/sun/jdga/Makefile ! make/sun/lwawt/FILES_c_macosx.gmk ! make/sun/lwawt/FILES_export_macosx.gmk ! make/sun/lwawt/Makefile ! make/sun/net/FILES_java.gmk ! make/sun/net/spi/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/osxapp/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmi/mapfile-vers ! make/sun/rmi/rmid/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/other/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile ! make/sun/tools/Makefile ! make/sun/util/Makefile ! make/tools/CharsetMapping/DoubleByte-X.java.template ! make/tools/CharsetMapping/SingleByte-X.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/GenerateCharacter/CharacterData02.java.template ! make/tools/GenerateCharacter/CharacterData0E.java.template ! make/tools/GenerateCharacter/CharacterDataLatin1.java.template ! make/tools/freetypecheck/Makefile ! make/tools/reorder/Makefile ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! make/tools/src/build/tools/compileproperties/CompileProperties.java ! make/tools/src/build/tools/generatenimbus/AbstractGradient.java ! make/tools/src/build/tools/generatenimbus/Border.java ! make/tools/src/build/tools/generatenimbus/Canvas.java ! make/tools/src/build/tools/generatenimbus/ComponentColor.java ! make/tools/src/build/tools/generatenimbus/Dimension.java ! make/tools/src/build/tools/generatenimbus/Ellipse.java ! make/tools/src/build/tools/generatenimbus/Gradient.java ! make/tools/src/build/tools/generatenimbus/GradientStop.java ! make/tools/src/build/tools/generatenimbus/Insets.java ! make/tools/src/build/tools/generatenimbus/Layer.java ! make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java ! make/tools/src/build/tools/generatenimbus/Path.java ! make/tools/src/build/tools/generatenimbus/Point.java ! make/tools/src/build/tools/generatenimbus/RadialGradient.java ! make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java ! make/tools/src/build/tools/generatenimbus/Typeface.java ! make/tools/src/build/tools/generatenimbus/UIColor.java ! make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java ! make/tools/src/build/tools/generatenimbus/UIFont.java ! make/tools/src/build/tools/generatenimbus/UIIconRegion.java ! make/tools/src/build/tools/generatenimbus/UIProperty.java ! make/tools/src/build/tools/generatenimbus/UIRegion.java ! make/tools/src/build/tools/generatenimbus/UIState.java ! make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/stripproperties/StripProperties.java ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GensrcSwing.gmk ! makefiles/docs/CORE_PKGS.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! makefiles/mapfiles/launchers/mapfile-amd64 ! makefiles/mapfiles/launchers/mapfile-i586 ! makefiles/mapfiles/launchers/mapfile-sparc ! makefiles/mapfiles/launchers/mapfile-sparcv9 ! makefiles/mapfiles/launchers/mapfile-x86 ! makefiles/mapfiles/launchers/mapfile-x86_64 ! makefiles/mapfiles/libattach/mapfile-linux ! makefiles/mapfiles/libattach/mapfile-solaris ! makefiles/mapfiles/libawt/mapfile-mawt-vers ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux ! makefiles/mapfiles/libawt_headless/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! makefiles/mapfiles/libdcpr/mapfile-vers ! makefiles/mapfiles/libdt_socket/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libhprof/mapfile-vers ! makefiles/mapfiles/libinstrument/mapfile-vers ! makefiles/mapfiles/libj2gss/mapfile-vers ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjaas/mapfile-vers ! makefiles/mapfiles/libjava_crw_demo/mapfile-vers ! makefiles/mapfiles/libjawt/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjdwp/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers-closed ! makefiles/mapfiles/libjsdt/mapfile-vers ! makefiles/mapfiles/libjsound/mapfile-vers ! makefiles/mapfiles/libjsoundalsa/mapfile-vers ! makefiles/mapfiles/libkcms/mapfile-vers ! makefiles/mapfiles/liblcms/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! makefiles/mapfiles/libmlib_image/mapfile-vers ! makefiles/mapfiles/libnet/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-bsd ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris ! makefiles/mapfiles/libnpt/mapfile-vers ! makefiles/mapfiles/libsctp/mapfile-vers ! makefiles/mapfiles/libsplashscreen/mapfile-vers ! makefiles/mapfiles/libsunec/mapfile-vers ! makefiles/mapfiles/libt2k/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers-unpack200 ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/mapfiles/libzip/mapfile-vers ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/xawt/ToBin.java ! src/bsd/doc/man/appletviewer.1 ! src/bsd/doc/man/apt.1 ! src/bsd/doc/man/extcheck.1 ! src/bsd/doc/man/idlj.1 ! src/bsd/doc/man/ja/appletviewer.1 ! src/bsd/doc/man/ja/apt.1 ! src/bsd/doc/man/ja/extcheck.1 ! src/bsd/doc/man/ja/idlj.1 ! src/bsd/doc/man/ja/jar.1 ! src/bsd/doc/man/ja/jarsigner.1 ! src/bsd/doc/man/ja/java.1 ! src/bsd/doc/man/ja/javac.1 ! src/bsd/doc/man/ja/javadoc.1 ! src/bsd/doc/man/ja/javah.1 ! src/bsd/doc/man/ja/javap.1 ! src/bsd/doc/man/ja/javaws.1 ! src/bsd/doc/man/ja/jconsole.1 ! src/bsd/doc/man/ja/jdb.1 ! src/bsd/doc/man/ja/jhat.1 ! src/bsd/doc/man/ja/jinfo.1 ! src/bsd/doc/man/ja/jmap.1 ! src/bsd/doc/man/ja/jps.1 ! src/bsd/doc/man/ja/jrunscript.1 ! src/bsd/doc/man/ja/jsadebugd.1 ! src/bsd/doc/man/ja/jstack.1 ! src/bsd/doc/man/ja/jstat.1 ! src/bsd/doc/man/ja/jstatd.1 ! src/bsd/doc/man/ja/keytool.1 ! src/bsd/doc/man/ja/native2ascii.1 ! src/bsd/doc/man/ja/orbd.1 ! src/bsd/doc/man/ja/pack200.1 ! src/bsd/doc/man/ja/policytool.1 ! src/bsd/doc/man/ja/rmic.1 ! src/bsd/doc/man/ja/rmid.1 ! src/bsd/doc/man/ja/rmiregistry.1 ! src/bsd/doc/man/ja/schemagen.1 ! src/bsd/doc/man/ja/serialver.1 ! src/bsd/doc/man/ja/servertool.1 ! src/bsd/doc/man/ja/tnameserv.1 ! src/bsd/doc/man/ja/unpack200.1 ! src/bsd/doc/man/ja/wsgen.1 ! src/bsd/doc/man/ja/wsimport.1 ! src/bsd/doc/man/ja/xjc.1 ! src/bsd/doc/man/jar.1 ! src/bsd/doc/man/java.1 ! src/bsd/doc/man/javac.1 ! src/bsd/doc/man/javah.1 ! src/bsd/doc/man/javap.1 ! src/bsd/doc/man/javaws.1 ! src/bsd/doc/man/jconsole.1 ! src/bsd/doc/man/jdb.1 ! src/bsd/doc/man/jhat.1 ! src/bsd/doc/man/jinfo.1 ! src/bsd/doc/man/jmap.1 ! src/bsd/doc/man/jps.1 ! src/bsd/doc/man/jrunscript.1 ! src/bsd/doc/man/jsadebugd.1 ! src/bsd/doc/man/jstack.1 ! src/bsd/doc/man/jstatd.1 ! src/bsd/doc/man/native2ascii.1 ! src/bsd/doc/man/orbd.1 ! src/bsd/doc/man/pack200.1 ! src/bsd/doc/man/policytool.1 ! src/bsd/doc/man/rmic.1 ! src/bsd/doc/man/rmid.1 ! src/bsd/doc/man/rmiregistry.1 ! src/bsd/doc/man/schemagen.1 ! src/bsd/doc/man/serialver.1 ! src/bsd/doc/man/servertool.1 ! src/bsd/doc/man/tnameserv.1 ! src/bsd/doc/man/unpack200.1 ! src/bsd/doc/man/xjc.1 ! src/linux/doc/man/jcmd.1 ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch ! src/macosx/bundle/JavaAppLauncher/src/main.m ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/AppleProvider.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/Dispatch.java ! src/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/concurrent/LibDispatchQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java ! src/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.h ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.m ! src/macosx/native/apple/applescript/AppleScriptEngine.m ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.h ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.m ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.h ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.m ! src/macosx/native/apple/launcher/JavaAppLauncher.m ! src/macosx/native/com/apple/concurrent/Dispatch.m ! src/macosx/native/com/apple/eio/CFileManager.m ! src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/macosx/native/java/util/MacOSXPreferencesFile.m ! src/macosx/native/java/util/SCDynamicStoreConfig.m ! src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser ! src/macosx/native/jobjc/README.txt ! src/macosx/native/jobjc/TODOS ! src/macosx/native/jobjc/bridgesupport.gmk ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/extract_classes.pl ! src/macosx/native/jobjc/run-and-write-if-okay ! src/macosx/native/jobjc/rungen ! src/macosx/native/jobjc/runjava ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CIF.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/core/native/CIF.m ! src/macosx/native/jobjc/src/core/native/Coder.m ! src/macosx/native/jobjc/src/core/native/FFIType.m ! src/macosx/native/jobjc/src/core/native/Function.m ! src/macosx/native/jobjc/src/core/native/ID.m ! src/macosx/native/jobjc/src/core/native/Invoke.m ! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m ! src/macosx/native/jobjc/src/core/native/MacOSXFramework.m ! src/macosx/native/jobjc/src/core/native/NSClass.m ! src/macosx/native/jobjc/src/core/native/NativeBuffer.h ! src/macosx/native/jobjc/src/core/native/NativeBuffer.m ! src/macosx/native/jobjc/src/core/native/NativeObjectLifecycleManager.m ! src/macosx/native/jobjc/src/core/native/SEL.m ! src/macosx/native/jobjc/src/core/native/Subclassing.m ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/BootClassPathMinus.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassConsolidator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FileCopier.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FrameworkGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FunctionGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Generator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/MethodDisambiguator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/RestrictedKeywords.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Utils.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/AbstractObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CFTypeClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CopiedFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/GeneratedClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/MixedPrimitiveCoderClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OpaqueClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OutputFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/RootJObjCClass.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/StructClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Arg.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/CFType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Category.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Constant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Element.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ElementWType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Framework.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Function.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/FunctionAlias.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/InformalProtocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Method.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/NativeEnum.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Opaque.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/OutputFileGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Protocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ReturnValue.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/StringConstant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Struct.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/TypeElement.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/CoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/PrimitiveCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/JType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/NType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/Type.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeCache.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeToJType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/Fp.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/JavaLang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeMerger.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeParser.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypePrinter.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/ObjectInspector.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/QA.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StringStream.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolver.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolverBigBang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/SuperClassExtractor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/UnsafeRuntimeAccess.java ! src/macosx/native/jobjc/src/runtime-additions/java/com/apple/jobjc/Utils.java ! src/macosx/native/jobjc/src/runtime-additions/native/NativeNumber.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeString.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeThread.m ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BaseBench.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchFunCall.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchIDPop.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchStructCoding.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchUnsafe.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/CategoryTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/FunctionTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/GUIDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IBDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IntroTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NSClassTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeBufferTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeTypeTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/PooledTestCase.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SELTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/StructTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SubclassingTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/TestUtils.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/UtilsTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/VarArgsTest.java ! src/macosx/native/jobjc/src/tests/native/FunCallBench.m ! src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c ! src/macosx/native/sun/osxapp/AWT_debug.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/PropertiesUtilities.h ! src/macosx/native/sun/osxapp/PropertiesUtilities.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m ! src/share/back/commonRef.c ! src/share/back/error_messages.h ! src/share/back/log_messages.h ! src/share/bin/emessages.h ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/package.html ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java ! src/share/classes/com/sun/jmx/snmp/SnmpInt.java ! src/share/classes/com/sun/jmx/snmp/SnmpNull.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java ! src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jndi/toolkit/url/UrlUtil.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java ! src/share/classes/com/sun/rmi/rmid/ExecPermission.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/servicetag/BrowserSupport.java ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/RegistrationDocument.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/Icons.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/InputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/CharacterData.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/Void.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/management/BufferPoolMXBean.java ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InMemoryCookieStore.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocketImpl.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/StandardWatchEventKinds.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/MergeCollation.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/StringCharacterIterator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/IllegalFormatConversionException.java ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/ListIterator.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Observable.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPInputStream.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/metadata/IIOMetadataNode.java ! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/timer/Timer.java ! src/share/classes/javax/management/timer/TimerAlarmClock.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java ! src/share/classes/org/ietf/jgss/Oid.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! 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/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/PerfDataEntry.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.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 ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/MetaIndex.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/Signal.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/NetworkServer.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/WriteFinishedEvent.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/smtp/SmtpClient.java ! src/share/classes/sun/net/spi/DefaultProxySelector.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 ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/share/classes/sun/nio/ch/SelectionKeyImpl.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java ! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java ! src/share/classes/sun/nio/cs/standard-charsets ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java ! src/share/classes/sun/reflect/ClassDefiner.java ! src/share/classes/sun/reflect/ConstantPool.java ! src/share/classes/sun/reflect/Label.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/UTF8.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/rmi/rmic/newrmic/Main.java ! src/share/classes/sun/rmi/rmic/newrmic/Resources.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/ActivationGroupImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastRef2.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/server/WeakClassHashMap.java ! src/share/classes/sun/rmi/transport/ConnectionInputStream.java ! src/share/classes/sun/rmi/transport/DGCAckHandler.java ! src/share/classes/sun/rmi/transport/DGCClient.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/LiveRef.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Target.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/WeakRef.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/security/smartcardio/TerminalImpl.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! src/share/classes/sun/security/x509/URIName.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/classes/sun/tools/javac/resources/javac.properties ! src/share/classes/sun/tools/jcmd/Arguments.java ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/ClassTab.java ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java ! src/share/classes/sun/tools/jconsole/Formatter.java ! src/share/classes/sun/tools/jconsole/HTMLPane.java ! src/share/classes/sun/tools/jconsole/InternalDialog.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/LabeledComponent.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java ! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java ! src/share/classes/sun/tools/jconsole/MemoryTab.java ! src/share/classes/sun/tools/jconsole/OverviewPanel.java ! src/share/classes/sun/tools/jconsole/OverviewTab.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/PlotterPanel.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/Resources.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/Tab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/VMInternalFrame.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/VariableGridLayout.java ! src/share/classes/sun/tools/jconsole/Version.java.template ! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XOperations.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jconsole/inspector/XTree.java ! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java ! src/share/classes/sun/tools/tree/Node.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/share/classes/sun/util/PreHashedMap.java ! src/share/classes/sun/util/calendar/CalendarDate.java ! src/share/classes/sun/util/locale/LocaleUtils.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/ar/CalendarData_ar.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties ! src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties ! src/share/classes/sun/util/resources/be/CalendarData_be.properties ! src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties ! src/share/classes/sun/util/resources/be/LocaleNames_be.properties ! src/share/classes/sun/util/resources/bg/CalendarData_bg.properties ! src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties ! src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties ! src/share/classes/sun/util/resources/ca/CalendarData_ca.properties ! src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties ! src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties ! src/share/classes/sun/util/resources/cs/CalendarData_cs.properties ! src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties ! src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties ! src/share/classes/sun/util/resources/da/CalendarData_da.properties ! src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties ! src/share/classes/sun/util/resources/da/LocaleNames_da.properties ! src/share/classes/sun/util/resources/de/CalendarData_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties ! src/share/classes/sun/util/resources/el/CalendarData_el.properties ! src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties ! src/share/classes/sun/util/resources/en/CalendarData_en.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties ! src/share/classes/sun/util/resources/es/CalendarData_es.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties ! src/share/classes/sun/util/resources/et/CalendarData_et.properties ! src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/et/LocaleNames_et.properties ! src/share/classes/sun/util/resources/fi/CalendarData_fi.properties ! src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties ! src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties ! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties ! src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties ! src/share/classes/sun/util/resources/hi/CalendarData_hi.properties ! src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties ! src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties ! src/share/classes/sun/util/resources/hr/CalendarData_hr.properties ! src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties ! src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties ! src/share/classes/sun/util/resources/hu/CalendarData_hu.properties ! src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties ! src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties ! src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties ! src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties ! src/share/classes/sun/util/resources/in/LocaleNames_in.properties ! src/share/classes/sun/util/resources/is/CalendarData_is.properties ! src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties ! src/share/classes/sun/util/resources/is/LocaleNames_is.properties ! src/share/classes/sun/util/resources/it/CalendarData_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties ! src/share/classes/sun/util/resources/it/LocaleNames_it.properties ! src/share/classes/sun/util/resources/iw/CalendarData_iw.properties ! src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties ! src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties ! src/share/classes/sun/util/resources/ja/CalendarData_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties ! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/ko/CalendarData_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/lt/CalendarData_lt.properties ! src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties ! src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties ! src/share/classes/sun/util/resources/lv/CalendarData_lv.properties ! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties ! src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties ! src/share/classes/sun/util/resources/mk/CalendarData_mk.properties ! src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties ! src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties ! src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties ! src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties ! src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties ! src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties ! src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties ! src/share/classes/sun/util/resources/nl/CalendarData_nl.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties ! src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties ! src/share/classes/sun/util/resources/no/CalendarData_no.properties ! src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties ! src/share/classes/sun/util/resources/pl/CalendarData_pl.properties ! src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties ! src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties ! src/share/classes/sun/util/resources/ro/CalendarData_ro.properties ! src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties ! src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties ! src/share/classes/sun/util/resources/ru/CalendarData_ru.properties ! src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties ! src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties ! src/share/classes/sun/util/resources/sk/CalendarData_sk.properties ! src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties ! src/share/classes/sun/util/resources/sl/CalendarData_sl.properties ! src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties ! src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties ! src/share/classes/sun/util/resources/sq/CalendarData_sq.properties ! src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties ! src/share/classes/sun/util/resources/sv/CalendarData_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/th/CalendarData_th.properties ! src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties ! src/share/classes/sun/util/resources/th/LocaleNames_th.properties ! src/share/classes/sun/util/resources/tr/CalendarData_tr.properties ! src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties ! src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties ! src/share/classes/sun/util/resources/uk/CalendarData_uk.properties ! src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties ! src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties ! src/share/classes/sun/util/resources/vi/CalendarData_vi.properties ! src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties ! src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties ! src/share/classes/sun/util/resources/zh/CalendarData_zh.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! src/share/demo/jfc/Font2DTest/Font2DTest.java ! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jvmti/agent_util/agent_util.c ! src/share/demo/jvmti/agent_util/agent_util.h ! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c ! src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/gctest/gctest.c ! src/share/demo/jvmti/gctest/sample.makefile.txt ! src/share/demo/jvmti/heapTracker/HeapTracker.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/jvmti/heapTracker/heapTracker.h ! src/share/demo/jvmti/heapTracker/sample.makefile.txt ! src/share/demo/jvmti/heapViewer/heapViewer.c ! src/share/demo/jvmti/heapViewer/sample.makefile.txt ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_blocks.c ! src/share/demo/jvmti/hprof/hprof_blocks.h ! src/share/demo/jvmti/hprof/hprof_check.c ! src/share/demo/jvmti/hprof/hprof_check.h ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_class.h ! src/share/demo/jvmti/hprof/hprof_cpu.c ! src/share/demo/jvmti/hprof/hprof_cpu.h ! src/share/demo/jvmti/hprof/hprof_error.c ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_event.h ! src/share/demo/jvmti/hprof/hprof_frame.c ! src/share/demo/jvmti/hprof/hprof_frame.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_init.h ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_io.h ! src/share/demo/jvmti/hprof/hprof_ioname.c ! src/share/demo/jvmti/hprof/hprof_ioname.h ! src/share/demo/jvmti/hprof/hprof_listener.c ! src/share/demo/jvmti/hprof/hprof_listener.h ! src/share/demo/jvmti/hprof/hprof_loader.c ! src/share/demo/jvmti/hprof/hprof_loader.h ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/hprof/hprof_monitor.c ! src/share/demo/jvmti/hprof/hprof_monitor.h ! src/share/demo/jvmti/hprof/hprof_object.c ! src/share/demo/jvmti/hprof/hprof_object.h ! src/share/demo/jvmti/hprof/hprof_reference.c ! src/share/demo/jvmti/hprof/hprof_reference.h ! src/share/demo/jvmti/hprof/hprof_site.c ! src/share/demo/jvmti/hprof/hprof_site.h ! src/share/demo/jvmti/hprof/hprof_stack.c ! src/share/demo/jvmti/hprof/hprof_stack.h ! src/share/demo/jvmti/hprof/hprof_string.c ! src/share/demo/jvmti/hprof/hprof_string.h ! src/share/demo/jvmti/hprof/hprof_table.c ! src/share/demo/jvmti/hprof/hprof_table.h ! src/share/demo/jvmti/hprof/hprof_tag.c ! src/share/demo/jvmti/hprof/hprof_tag.h ! src/share/demo/jvmti/hprof/hprof_tls.c ! src/share/demo/jvmti/hprof/hprof_tls.h ! src/share/demo/jvmti/hprof/hprof_trace.c ! src/share/demo/jvmti/hprof/hprof_trace.h ! src/share/demo/jvmti/hprof/hprof_tracker.c ! src/share/demo/jvmti/hprof/hprof_tracker.h ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h ! src/share/demo/jvmti/java_crw_demo/sample.makefile.txt ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/jvmti/minst/minst.c ! src/share/demo/jvmti/minst/minst.h ! src/share/demo/jvmti/minst/sample.makefile.txt ! src/share/demo/jvmti/mtrace/Mtrace.java ! src/share/demo/jvmti/mtrace/mtrace.c ! src/share/demo/jvmti/mtrace/mtrace.h ! src/share/demo/jvmti/mtrace/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/versionCheck.c ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp ! src/share/demo/jvmti/waiters/Thread.cpp ! src/share/demo/jvmti/waiters/Thread.hpp ! src/share/demo/jvmti/waiters/sample.makefile.txt ! src/share/demo/jvmti/waiters/waiters.cpp ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/FullThreadDump.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/MemoryMonitor/README.txt ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nbproject/project.xml ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js ! src/share/instrument/JPLISAssert.h ! src/share/javavm/export/classfile_constants.h ! src/share/javavm/export/jawt.h ! src/share/javavm/export/jmm.h ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/common/check_code.c ! src/share/native/common/jdk_util.h ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/java/io/io_util.h ! src/share/native/java/lang/System.c ! src/share/native/java/lang/Thread.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/fdlibm/include/jfdlibm.h ! src/share/native/java/lang/java_props.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/krb5/nativeccache.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/npt/utf.h ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java ! src/share/sample/nio/multicast/MulticastAddress.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! src/share/sample/nio/server/AcceptHandler.java ! src/share/sample/nio/server/Acceptor.java ! src/share/sample/nio/server/B1.java ! src/share/sample/nio/server/BN.java ! src/share/sample/nio/server/BP.java ! src/share/sample/nio/server/ChannelIO.java ! src/share/sample/nio/server/ChannelIOSecure.java ! src/share/sample/nio/server/Content.java ! src/share/sample/nio/server/Dispatcher.java ! src/share/sample/nio/server/Dispatcher1.java ! src/share/sample/nio/server/DispatcherN.java ! src/share/sample/nio/server/FileContent.java ! src/share/sample/nio/server/Handler.java ! src/share/sample/nio/server/MalformedRequestException.java ! src/share/sample/nio/server/N1.java ! src/share/sample/nio/server/N2.java ! src/share/sample/nio/server/Reply.java ! src/share/sample/nio/server/Request.java ! src/share/sample/nio/server/RequestHandler.java ! src/share/sample/nio/server/RequestServicer.java ! src/share/sample/nio/server/Sendable.java ! src/share/sample/nio/server/Server.java ! src/share/sample/nio/server/StringContent.java ! src/share/sample/nio/server/URLDumper.java ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js ! src/share/sample/vm/clr-jvm/invoked.java ! src/share/sample/vm/clr-jvm/jinvoker.cpp ! src/share/sample/vm/clr-jvm/jinvokerExp.h ! src/share/sample/vm/jvm-clr/invoker.cpp ! src/share/sample/vm/jvm-clr/invoker.h ! src/share/sample/vm/jvm-clr/invoker.java ! src/share/sample/vm/jvm-clr/invokerExp.h ! src/share/transport/shmem/shmemBase.h ! src/share/transport/socket/socketTransport.c ! src/solaris/back/exec_md.c ! src/solaris/back/linker_md.c ! src/solaris/back/util_md.h ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg ! src/solaris/classes/com/sun/management/UnixOperatingSystem.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/lang/Terminator.java ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java ! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SendFailed.java ! src/solaris/classes/sun/nio/ch/sctp/Shutdown.java ! src/solaris/classes/sun/nio/fs/BsdFileStore.java ! src/solaris/classes/sun/nio/fs/BsdFileSystem.java ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/security/smartcardio/PlatformPCSC.java ! src/solaris/classes/sun/tools/attach/BsdAttachProvider.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! src/solaris/demo/jni/Poller/Client.java ! src/solaris/demo/jni/Poller/LinkedQueue.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jni/Poller/Poller.java ! src/solaris/demo/jni/Poller/PollingServer.java ! src/solaris/demo/jni/Poller/SimpleServer.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/doc/sun/man/man1/jcmd.1 ! src/solaris/instrument/EncodingSupport_md.c ! src/solaris/javavm/export/jvm_md.h ! src/solaris/native/com/sun/management/MacosxOperatingSystem.c ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/java/util/FileSystemPreferences.c ! src/solaris/native/sun/jdga/dgalock.c ! src/solaris/native/sun/management/FileSystemImpl.c ! src/solaris/native/sun/net/dns/ResolverConfigurationImpl.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/FileKey.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SolarisEventPort.c ! src/solaris/native/sun/nio/ch/sctp/Sctp.h ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpNet.c ! src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c ! src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/solaris/npt/npt_md.h ! src/solaris/transport/socket/socket_md.c ! src/windows/classes/com/sun/management/OperatingSystem.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/Terminator.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/management/FileSystemImpl.c ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c ! src/windows/native/sun/nio/ch/nio_util.h ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c ! src/windows/native/sun/security/provider/WinCAPISeedGenerator.c ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h ! src/windows/transport/shmem/shmem_md.c ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/ShellScaffold.sh ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/com/sun/jndi/ldap/LdapTimeoutTest.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test10.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java ! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/tools/attach/CommonSetup.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/MaxPathLength.java ! test/java/io/File/basic.sh ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/IOException/LastErrorString.java ! test/java/io/Serializable/badSubstByReplace/BadSubstByReplace.java ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java ! test/java/io/Serializable/replaceStringArray/ReplaceStringArray.java ! test/java/io/Serializable/replaceWithNull/ReplaceWithNull.java ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/io/Serializable/verifyDynamicObjHandleTable/VerifyDynamicObjHandleTable.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/Double/ToHexString.java ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/lang/ThreadGroup/Stop.java ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/annotation/loaderLeak/Main.java ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/ref/Basic.java ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/CookieHandler/NullUriCookieTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/DatagramPacket/ReuseBuf.java ! test/java/net/DatagramSocket/Send12k.java ! test/java/net/DatagramSocket/SendDatagramToBadAddress.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/NetworkInterface/NetParamsTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/Socket/setReuseAddress/Basic.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/Socks/SocksServer.java ! test/java/net/Socks/SocksV4Test.java ! test/java/net/URL/B5086147.sh ! test/java/net/URL/OpenStream.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URL/Test.java ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/MappedByteBuffer/Truncate.java ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java ! test/java/nio/channels/DatagramChannel/Refused.java ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/FileChannel/ClosedByInterrupt.java ! test/java/nio/channels/Selector/OpRead.java ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Open.sh ! test/java/nio/channels/SocketChannel/Shutdown.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/TestUtil.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/coders/Errors.java ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/CustomOptions.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/WatchService/WithSecurityManager.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/text/Bidi/Bug6850113.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Hashtable/HashCode.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/Locale/Bug6989440.java ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Map/Get.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/Bug6530694.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/Timer/Args.java ! test/java/util/Timer/KillThread.java ! test/java/util/UUID/UUIDTest.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/remote/mandatory/URLTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/naming/spi/DirectoryManager/GetContDirCtx.java ! test/javax/script/CommonSetup.sh ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java ! test/javax/security/auth/Subject/doAs/Test.sh ! test/javax/security/auth/login/LoginContext/ResetConfigModule.java ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/invoke/util/ValueConversionsTest.java ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/misc/Version/Version.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java ! test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java ! test/sun/nio/cs/OLD/PCK_OLD.java ! test/sun/nio/cs/OLD/SJIS_OLD.java ! test/sun/nio/cs/OLD/SingleByteDecoder.java ! test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/StrCodingBenchmark.java ! test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestCp834_SBCS.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestUTF8.java ! test/sun/nio/cs/TestX11JIS0201.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/Krb5NameEquals.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/TcpTimeout.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/fips/TrustManagerTest.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/DSA/TestKeyPairGenerator.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java ! test/sun/tools/common/CommonSetup.sh ! 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/jconsole/ImmutableResourceTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh ! test/sun/util/logging/PlatformLoggerTest.java ! test/tools/launcher/DefaultLocaleTest.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/TimeStamp.java Changeset: 6ffd64541a6c Author: lana Date: 2012-11-02 17:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ffd64541a6c Merge - make/sun/jdbc/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcSwing.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 63726e5b90da Author: erikj Date: 2012-11-03 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/63726e5b90da 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcJObjC.gmk Changeset: 26dbd73fb766 Author: katleman Date: 2012-11-07 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/26dbd73fb766 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: ad5c1d6b1e16 Author: katleman Date: 2012-11-08 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad5c1d6b1e16 Added tag jdk8-b64 for changeset 26dbd73fb766 ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:46:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:46:27 +0000 Subject: hg: hsx/hotspot-main/langtools: 17 new changesets Message-ID: <20121109094710.465E74788E@hg.openjdk.java.net> Changeset: 78962d89f283 Author: jjg Date: 2012-10-23 13:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/78962d89f283 8000741: refactor javadoc to use abstraction to handle relative paths Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/SerialFieldTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java Changeset: 4a1c57a1c410 Author: jjg Date: 2012-10-23 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4a1c57a1c410 8000416: refactor javadoc to provide and use an abstraction for relative URIs Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocLink.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: c002fdee76fd Author: jjg Date: 2012-10-25 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c002fdee76fd 7200915: convert TypeTags from a series of small ints to an enum Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java + src/share/classes/com/sun/tools/javac/code/TypeTag.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.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/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/tree/MakeLiteralTest.java Changeset: ea2616a6bd01 Author: jjg Date: 2012-10-25 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ea2616a6bd01 6725230: Java Compilation with Jsr199 ignores Class-Path in manifest Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/file/Locations.java + test/tools/javac/Paths/TestCompileJARInClassPath.java Changeset: 217c265158fe Author: jjg Date: 2012-10-26 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/217c265158fe 8001219: Clean up use of URLs in javadoc Extern class Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: e6cb81683ffe Author: jjg Date: 2012-10-26 16:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e6cb81683ffe 8001229: refactor javac so that ct.sym is just used for javac, not all clients of JavacFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java Changeset: 64fce9f95b1d Author: jjg Date: 2012-10-26 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/64fce9f95b1d 8001714: add missing tests for 7199925 Reviewed-by: darcy + test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java + test/tools/javac/annotations/repeatingAnnotations/SeparateCompile.java Changeset: 384f7a4beae7 Author: jjg Date: 2012-10-26 18:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/384f7a4beae7 8001717: TypeTags cleanup breaks GenStubs Reviewed-by: jjh ! make/tools/genstubs/GenStubs.java Changeset: a65971893c50 Author: rfield Date: 2012-10-29 10:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a65971893c50 8000694: Add generation of lambda implementation code: invokedynamic call, lambda method, adaptor methods Summary: Add lambda implementation code with calling/supporting code elsewhere in the compiler Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java + src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 23fe1a96bc0f Author: jjg Date: 2012-10-30 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/23fe1a96bc0f 8001929: fix doclint errors in langtools doc comments Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: 27f7952eea3c Author: lana Date: 2012-10-31 08:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/27f7952eea3c Merge Changeset: b980e8e6aabf Author: jjg Date: 2012-10-31 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b980e8e6aabf 8001664: refactor javadoc to use abstraction to handle files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java Changeset: bf54daa9dcd8 Author: ohrstrom Date: 2012-11-01 10:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bf54daa9dcd8 7153951: Add new lint option -Xlint:auxiliaryclass Reviewed-by: jjg, mcimadamore, forax ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out + test/tools/javac/warnings/AuxiliaryClass/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/NotAClassName.java + test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: 75c936d14c6a Author: vromero Date: 2012-11-01 12:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/75c936d14c6a 8000483: cryptic error message when source file contains hash Summary: cryptic error message when source file contains hash Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/quid/T6999438.out Changeset: bf76f4190ef8 Author: jjg Date: 2012-11-02 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bf76f4190ef8 7169362: JDK8: Write compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out + test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out + test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out Changeset: e6ee43b3e247 Author: lana Date: 2012-11-02 17:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e6ee43b3e247 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java Changeset: 056d828ac1e1 Author: katleman Date: 2012-11-08 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/056d828ac1e1 Added tag jdk8-b64 for changeset e6ee43b3e247 ! .hgtags From doug.simon at oracle.com Fri Nov 9 02:38:51 2012 From: doug.simon at oracle.com (Doug Simon @ Oracle) Date: Fri, 9 Nov 2012 11:38:51 +0100 Subject: Escape analysis for objects with injected fields In-Reply-To: <509C458C.9080903@oracle.com> References: <866A3B46-155B-44D2-9074-DACBC5B8E90A@oracle.com> <509C458C.9080903@oracle.com> Message-ID: Upon further investigation, it seems as though HotSpot could not (currently) crash due to this issue as I believe it will never escape analyze objects with injected fields as such objects are either created in native code (e.g., java.lang.Class) or always escape (e.g., java.lang.ClassLoader) along any code path where the injected fields are used or traced by GC. Since Graal performs partial escape analysis, we are not so lucky ;-) Given this context, I'm not sure it's possible to come up with a test case. My recommendation for now would be to add an check in the compiler(s) to prevent performing EA for such objects. -Doug On Nov 9, 2012, at 12:51 AM, Vladimir Kozlov wrote: > You are right, we are lucky :) > > File bug, add a test case and I will fix it. > > Thanks, > Vladimir > > Doug Simon @ Oracle wrote: >> While debugging a deoptimization issue in Graal[1], I (painfully) learnt of the importance of field ordering in the relationship between escape analyzed (EA) objects and deoptimization. In particular, the values in the DebugInfo for an EA'ed object must correspond with the field order returned by Klass::do_nonstatic_fields(). However, that latter function does not include internal/injected fields such as the 'loader_data' and 'dependencies' fields injected into java.lang.ClassLoader instances. So, my question is what happens when such an object is EA'ed and rematerialized during deoptimization? As far as I can tell, these fields will be left uninitialized. At least, I cannot see any code in c1 or c2 (e.g., line 704 of [2]) that omits such objects from EA. >> Am I missing something or is HotSpot just getting lucky by never determining that such objects are worthy of EA? >> -Doug >> [1] http://openjdk.java.net/projects/graal/ >> [2] http://hg.openjdk.java.net/hsx/hsx25/hotspot/raw-file/8e47bac5643a/src/share/vm/opto/macro.cpp From nils.eliasson at oracle.com Fri Nov 9 05:04:44 2012 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Fri, 09 Nov 2012 13:04:44 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20121109130458.23CD5478A8@hg.openjdk.java.net> Changeset: 64672b22ef05 Author: twisti Date: 2012-11-02 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/64672b22ef05 8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common Reviewed-by: twisti Contributed-by: Bharadwaj Yadavalli ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: dbeaeee28bc2 Author: kvn Date: 2012-11-06 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dbeaeee28bc2 8002294: assert(VM_Version::supports_ssse3()) failed Summary: Add missing UseSSE check for AES intrinsics. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: f3da5ff1514c Author: kvn Date: 2012-11-06 15:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f3da5ff1514c 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values(). Reviewed-by: roland, twisti, vlivanov ! src/share/vm/opto/escape.cpp + test/compiler/8002069/Test8002069.java Changeset: a4e1bd941ded Author: neliasso Date: 2012-11-08 22:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a4e1bd941ded Merge ! src/share/vm/oops/cpCache.cpp From vladimir.kozlov at oracle.com Fri Nov 9 08:42:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Nov 2012 08:42:19 -0800 Subject: Escape analysis for objects with injected fields In-Reply-To: References: <866A3B46-155B-44D2-9074-DACBC5B8E90A@oracle.com> <509C458C.9080903@oracle.com> Message-ID: <4785B384-15C4-41E1-AC89-B2B6B3EF0EB7@oracle.com> On Nov 9, 2012, at 2:38 AM, Doug Simon @ Oracle wrote: > Upon further investigation, it seems as though HotSpot could not (currently) crash due to this issue as I believe it will never escape analyze objects with injected fields as such objects are either created in native code (e.g., java.lang.Class) or always escape (e.g., java.lang.ClassLoader) along any code path where the injected fields are used or traced by GC. Since Graal performs partial escape analysis, we are not so lucky ;-) > > Given this context, I'm not sure it's possible to come up with a test case. My recommendation for now would be to add an check in the compiler(s) to prevent performing EA for such objects. I will do that. Thanks, Vladimir > > -Doug > > On Nov 9, 2012, at 12:51 AM, Vladimir Kozlov wrote: > >> You are right, we are lucky :) >> >> File bug, add a test case and I will fix it. >> >> Thanks, >> Vladimir >> >> Doug Simon @ Oracle wrote: >>> While debugging a deoptimization issue in Graal[1], I (painfully) learnt of the importance of field ordering in the relationship between escape analyzed (EA) objects and deoptimization. In particular, the values in the DebugInfo for an EA'ed object must correspond with the field order returned by Klass::do_nonstatic_fields(). However, that latter function does not include internal/injected fields such as the 'loader_data' and 'dependencies' fields injected into java.lang.ClassLoader instances. So, my question is what happens when such an object is EA'ed and rematerialized during deoptimization? As far as I can tell, these fields will be left uninitialized. At least, I cannot see any code in c1 or c2 (e.g., line 704 of [2]) that omits such objects from EA. >>> Am I missing something or is HotSpot just getting lucky by never determining that such objects are worthy of EA? >>> -Doug >>> [1] http://openjdk.java.net/projects/graal/ >>> [2] http://hg.openjdk.java.net/hsx/hsx25/hotspot/raw-file/8e47bac5643a/src/share/vm/opto/macro.cpp > From alejandro.murillo at oracle.com Fri Nov 9 09:39:20 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 09 Nov 2012 17:39:20 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20121109173927.3F7FC478AF@hg.openjdk.java.net> Changeset: 373fcf2269e6 Author: katleman Date: 2012-11-08 18:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/373fcf2269e6 Added tag jdk7u12-b01 for changeset 0601ca30c7b4 ! .hgtags Changeset: 1e5b6a49c06d Author: amurillo Date: 2012-11-09 07:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1e5b6a49c06d Merge Changeset: ce5983a3e0b2 Author: amurillo Date: 2012-11-09 07:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ce5983a3e0b2 Added tag hs24-b25 for changeset 1e5b6a49c06d ! .hgtags From zhengyu.gu at oracle.com Fri Nov 9 10:36:57 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 09 Nov 2012 13:36:57 -0500 Subject: Code review request: JDK-8001592 NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 In-Reply-To: References: <509A8B99.8050306@oracle.com> Message-ID: <509D4D49.4060208@oracle.com> Updated webrev based on Karen and Coleen's comments. http://cr.openjdk.java.net/~zgu/8001592/webrev.01/ Thanks, -Zhengyu On 11/8/2012 11:19 AM, Karen Kinnear wrote: > Zhengyu, > > Code looks good. Thank you for the fixes. > > Minor comments: > 1. memBaseline.cpp line 119 anonymouse -> anonymous > > 2. Much prefer the new MallocRecordIterator::current() behavior!!! > > 3. MallocRecordIterator::next() > Can you possibly clarify? Lines 194-195 say that if there is an associated > arena record it has to be the previous because of sorting order? > -- what about sorting order means it is previous? > - and it appears that you are looking at next_rec relative to prev_rec. What about > the current rec - isn't that in the middle? > > - and many thanks for the detailed code comments and improved variable names. > > thanks, > Karen > > > On Nov 7, 2012, at 11:26 AM, Zhengyu Gu wrote: > >> The assertion failure reflects that total memory that backs arenas are greater than total memory chunks for backing all arenas, which is obviously incorrect. >> >> The problem is due to Arena object, although it is declared as C-heap object, but it is used as value objects and stack objects as well. Value and stack objects do not have tracking records in NMT, which can leave arena size records alone in NMT. Because NMT uses Arena's deallocation records to cleanup size records, that means those leftover size records are not get cleanup. >> >> The solution is to use Arena's destructor to reset arena size to 0, and NMT uses this record to remove the corresponding record. >> >> The webrev also cleanup Memsnapshot::merge() routine, since virtual memory records now are stored in separate array, malloc staging area can keep only one record for each address (whoever has higher sequence number win), which should reduce memory usage by NMT. >> >> Webrev: http://cr.openjdk.java.net/~zgu/8001592/webrev.00/ >> >> Tests: >> vm.quick.testlist on Linux 32, Windows x64, Solaris AMD64 and Sparcv9 >> JPTR tests >> >> >> Thanks, >> >> -Zhengyu From alejandro.murillo at oracle.com Fri Nov 9 11:29:37 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 09 Nov 2012 19:29:37 +0000 Subject: hg: hsx/hsx25/hotspot: 18 new changesets Message-ID: <20121109193016.55307478B3@hg.openjdk.java.net> Changeset: 49bc14aaadcc Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/49bc14aaadcc Added tag jdk8-b64 for changeset 5920f72e799c ! .hgtags Changeset: ca8168203393 Author: amurillo Date: 2012-11-02 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca8168203393 8002181: new hotspot build - hs25-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 857f3ce858dd Author: dholmes Date: 2012-11-05 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/857f3ce858dd 8002034: Allow Full Debug Symbols when cross-compiling 8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances Reviewed-by: dcubed, dsamersoff, erikj, collins ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 3d701c802d01 Author: minqi Date: 2012-11-02 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3d701c802d01 8000489: older builds of hsdis don't work anymore after 6879063 Summary: The old function not defined properly, need a definition for export in dll. Also changes made to let new jvm work with old hsdis. Reviewed-by: jrose, sspitsyn, kmo Contributed-by: yumin.qi at oracle.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 4735d2c84362 Author: kamg Date: 2012-10-11 12:25 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4735d2c84362 7200776: Implement default methods in interfaces Summary: Add generic type analysis and default method selection algorithms Reviewed-by: coleenp, acorn + src/share/vm/classfile/bytecodeAssembler.cpp + src/share/vm/classfile/bytecodeAssembler.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp + src/share/vm/classfile/defaultMethods.cpp + src/share/vm/classfile/defaultMethods.hpp + src/share/vm/classfile/genericSignatures.cpp + src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/growableArray.hpp + src/share/vm/utilities/pair.hpp + src/share/vm/utilities/resourceHash.hpp Changeset: ec204374e626 Author: kamg Date: 2012-11-02 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ec204374e626 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 9cc901118f6b Author: kamg Date: 2012-11-02 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9cc901118f6b Merge Changeset: 69ad7823b1ca Author: zgu Date: 2012-11-05 15:30 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69ad7823b1ca 8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region Reviewed-by: dholmes, coleenp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp Changeset: 8940ddc1036f Author: zgu Date: 2012-11-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8940ddc1036f Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: c284cf4781f0 Author: rbackman Date: 2012-10-04 14:55 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c284cf4781f0 7127792: Add the ability to change an existing PeriodicTask's execution interval Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread. Reviewed-by: dholmes, mgronlun ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 18fb7da42534 Author: coleenp Date: 2012-11-06 15:09 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/18fb7da42534 8000725: NPG: method_holder() and pool_holder() and pool_holder field should be InstanceKlass Summary: Change types of above methods and field to InstanceKlass and remove unneeded casts from the source files. Reviewed-by: dholmes, coleenp, zgu Contributed-by: harold.seigel at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: ead8852dd4ef Author: coleenp Date: 2012-11-07 16:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ead8852dd4ef Merge Changeset: 64672b22ef05 Author: twisti Date: 2012-11-02 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/64672b22ef05 8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common Reviewed-by: twisti Contributed-by: Bharadwaj Yadavalli ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: dbeaeee28bc2 Author: kvn Date: 2012-11-06 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dbeaeee28bc2 8002294: assert(VM_Version::supports_ssse3()) failed Summary: Add missing UseSSE check for AES intrinsics. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: f3da5ff1514c Author: kvn Date: 2012-11-06 15:16 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f3da5ff1514c 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values(). Reviewed-by: roland, twisti, vlivanov ! src/share/vm/opto/escape.cpp + test/compiler/8002069/Test8002069.java Changeset: a4e1bd941ded Author: neliasso Date: 2012-11-08 22:39 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a4e1bd941ded Merge ! src/share/vm/oops/cpCache.cpp Changeset: b4ee7b773144 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b4ee7b773144 Merge Changeset: 0f7290a03b24 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f7290a03b24 Added tag hs25-b09 for changeset b4ee7b773144 ! .hgtags From daniel.daugherty at oracle.com Fri Nov 9 11:30:27 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 09 Nov 2012 12:30:27 -0700 Subject: Code review request: 8002273 NMT to report JNI memory leaks when -Xcheck:jni is on In-Reply-To: <509C813B.3030800@oracle.com> References: <509BEA9D.6090004@oracle.com> <509C813B.3030800@oracle.com> Message-ID: <509D59D3.7050001@oracle.com> Do we have a way of detecting this issue at thread-exit time? In other words, once a JNI thread has attached to the VM and has become a JavaThread, do all exit paths from the JNI thread now go through VM code, e.g., JavaThread::exit()? Or because this is a JNI thread that has attached to the VM, does the thread exit path get done differently? Why am I wondering this? Because it would be good if we could provide a more detailed message about the JNI thread that exited (or is about to exit) without detaching from the VM. Also, thumbs up on the code modulo clearing up the comment lines that David H pointed out... Dan On 11/8/12 9:06 PM, David Holmes wrote: > Hi Zhengyu, > > On 9/11/2012 3:23 AM, Zhengyu Gu wrote: >> This fix is related to JDK-8001743: Overlapped thread stacks. The cause >> of 8001743 is that, an attached JNI thread exited without detaching the >> thread, so JVM will leak a JavaThread object that attached to the JNI >> thread. >> >> The patch allows NMT to report such case when -Xcheck:jni VM option is >> specified. >> >> http://cr.openjdk.java.net/~zgu/8002273/webrev.00/ > > I'm a little unclear who is doing the checking here. Is it the case > that a regular thread while updating its NMT records, detects that > there is an overlap with an existing region, and infers from that that > the other region must belong to a thread that failed to detach? > > This comment doesn't read clearly to me, and we don't generally > include references to bug reports: > > 138 // an attached JNI thread can exit without detaching the > thread, that results > 139 // JVM to leak JavaThread object (JDK-8001743) > > > If my understanding of the check is correct then to me a clearer > comment would be: > > // Overlapping stack regions indicate that a JNI thread failed to > // detach from the VM before exiting. This leaks the JavaThread object. > > Cheers, > David > >> Thanks, >> >> -Zhengyu From zhengyu.gu at oracle.com Fri Nov 9 11:54:14 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 09 Nov 2012 14:54:14 -0500 Subject: Code review request: 8002273 NMT to report JNI memory leaks when -Xcheck:jni is on In-Reply-To: <509D59D3.7050001@oracle.com> References: <509BEA9D.6090004@oracle.com> <509C813B.3030800@oracle.com> <509D59D3.7050001@oracle.com> Message-ID: <509D5F66.2030603@oracle.com> Hi Dan, Thanks for reviewing. On 11/9/2012 2:30 PM, Daniel D. Daugherty wrote: > Do we have a way of detecting this issue at thread-exit time? > > In other words, once a JNI thread has attached to the VM and has > become a JavaThread, do all exit paths from the JNI thread now > go through VM code, e.g., JavaThread::exit()? Or because this is > a JNI thread that has attached to the VM, does the thread exit > path get done differently? > I don't think that VM has any control over JNI thread's exit path. The thread can just call AttachCurrentThread() and exit. > Why am I wondering this? Because it would be good if we could > provide a more detailed message about the JNI thread that exited > (or is about to exit) without detaching from the VM. I thought about this, the alternative is to walk threads (Threads::do_threads()), which we might be able to identify the offender, but what kind of information we can get? its stack is no longer walkable and thread name is something like Thread-nnn. > > Also, thumbs up on the code modulo clearing up the comment lines > that David H pointed out... > I made change. Thanks, -Zhengyu > Dan > > > > On 11/8/12 9:06 PM, David Holmes wrote: >> Hi Zhengyu, >> >> On 9/11/2012 3:23 AM, Zhengyu Gu wrote: >>> This fix is related to JDK-8001743: Overlapped thread stacks. The cause >>> of 8001743 is that, an attached JNI thread exited without detaching the >>> thread, so JVM will leak a JavaThread object that attached to the JNI >>> thread. >>> >>> The patch allows NMT to report such case when -Xcheck:jni VM option is >>> specified. >>> >>> http://cr.openjdk.java.net/~zgu/8002273/webrev.00/ >> >> I'm a little unclear who is doing the checking here. Is it the case >> that a regular thread while updating its NMT records, detects that >> there is an overlap with an existing region, and infers from that >> that the other region must belong to a thread that failed to detach? >> >> This comment doesn't read clearly to me, and we don't generally >> include references to bug reports: >> >> 138 // an attached JNI thread can exit without detaching the >> thread, that results >> 139 // JVM to leak JavaThread object (JDK-8001743) >> >> >> If my understanding of the check is correct then to me a clearer >> comment would be: >> >> // Overlapping stack regions indicate that a JNI thread failed to >> // detach from the VM before exiting. This leaks the JavaThread object. >> >> Cheers, >> David >> >>> Thanks, >>> >>> -Zhengyu > From coleen.phillimore at oracle.com Fri Nov 9 12:59:25 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 09 Nov 2012 15:59:25 -0500 Subject: Code review request: JDK-8001592 NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 In-Reply-To: <509D4D49.4060208@oracle.com> References: <509A8B99.8050306@oracle.com> <509D4D49.4060208@oracle.com> Message-ID: <509D6EAD.3010601@oracle.com> The comment in memSnapshot.hpp still refers to the arena_memory record as an arena_size record. I do like arena_memory_record better because it means the memory that the Arena points to (which is allocated separately). *+ // arena size record is a special case, which we have to compare* *+ // sequence number against its associated arena record. ... **+ // record because of sorting order (by address) - NMT generates a pseudo address* *+ // for arena's size record by offsetting arena's address, that guarantees* *+ // the order of arena record and it's size record.* Other than this, it looks good. Coleen On 11/9/2012 1:36 PM, Zhengyu Gu wrote: > Updated webrev based on Karen and Coleen's comments. > > http://cr.openjdk.java.net/~zgu/8001592/webrev.01/ > > Thanks, > > -Zhengyu > > On 11/8/2012 11:19 AM, Karen Kinnear wrote: >> Zhengyu, >> >> Code looks good. Thank you for the fixes. >> >> Minor comments: >> 1. memBaseline.cpp line 119 anonymouse -> anonymous >> >> 2. Much prefer the new MallocRecordIterator::current() behavior!!! >> >> 3. MallocRecordIterator::next() >> Can you possibly clarify? Lines 194-195 say that if there is an >> associated >> arena record it has to be the previous because of sorting order? >> -- what about sorting order means it is previous? >> - and it appears that you are looking at next_rec relative to >> prev_rec. What about >> the current rec - isn't that in the middle? >> >> - and many thanks for the detailed code comments and improved >> variable names. >> >> thanks, >> Karen >> >> >> On Nov 7, 2012, at 11:26 AM, Zhengyu Gu wrote: >> >>> The assertion failure reflects that total memory that backs arenas >>> are greater than total memory chunks for backing all arenas, which >>> is obviously incorrect. >>> >>> The problem is due to Arena object, although it is declared as >>> C-heap object, but it is used as value objects and stack objects as >>> well. Value and stack objects do not have tracking records in NMT, >>> which can leave arena size records alone in NMT. Because NMT uses >>> Arena's deallocation records to cleanup size records, that means >>> those leftover size records are not get cleanup. >>> >>> The solution is to use Arena's destructor to reset arena size to 0, >>> and NMT uses this record to remove the corresponding record. >>> >>> The webrev also cleanup Memsnapshot::merge() routine, since virtual >>> memory records now are stored in separate array, malloc staging area >>> can keep only one record for each address (whoever has higher >>> sequence number win), which should reduce memory usage by NMT. >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/8001592/webrev.00/ >>> >>> Tests: >>> vm.quick.testlist on Linux 32, Windows x64, Solaris AMD64 and Sparcv9 >>> JPTR tests >>> >>> >>> Thanks, >>> >>> -Zhengyu From alejandro.murillo at oracle.com Fri Nov 9 14:49:40 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 09 Nov 2012 22:49:40 +0000 Subject: hg: hsx/hsx24/hotspot: 8003230: new hotspot build - hs24-b26 Message-ID: <20121109224946.C6FEC478BA@hg.openjdk.java.net> Changeset: 9e4a76d64d50 Author: amurillo Date: 2012-11-09 07:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9e4a76d64d50 8003230: new hotspot build - hs24-b26 Reviewed-by: jcoomes ! make/hotspot_version From alejandro.murillo at oracle.com Fri Nov 9 17:45:47 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 10 Nov 2012 01:45:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20121110014557.8B257478BD@hg.openjdk.java.net> Changeset: 49bc14aaadcc Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/49bc14aaadcc Added tag jdk8-b64 for changeset 5920f72e799c ! .hgtags Changeset: b4ee7b773144 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b4ee7b773144 Merge Changeset: 0f7290a03b24 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f7290a03b24 Added tag hs25-b09 for changeset b4ee7b773144 ! .hgtags Changeset: 3be318ecfae5 Author: amurillo Date: 2012-11-09 08:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3be318ecfae5 8003231: new hotspot build - hs25-b10 Reviewed-by: jcoomes ! make/hotspot_version From coleen.phillimore at oracle.com Sun Nov 11 19:51:26 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sun, 11 Nov 2012 22:51:26 -0500 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap Message-ID: <50A0723E.2050401@oracle.com> This change creates a ClassLoaderData object for each JSR 292 anonymous class, so that the metadata and mirror object for the anonymous class can be reclaimed when the anonymous class is no longer referenced. The java_lang_ClassLoader object for the anonymous class is the same as its host_class. Most of this change is to break the assumption that there's a 1-1 relationship between java_lang_ClassLoader Java objects and ClassLoaderData metadata objects in the VM. Also, nmethods and other things that were strong roots for java_lang_ClassLoader objects have to also be strong roots for java_lang_Class objects for anonymous classes. There were also changes to move the dependencies out of the java_lang_ClassLoader object to the ClassLoaderData type. This type is preallocated so that CMS will have card marks to track additions to the dependencies. Please check this, Stefan! Also, in this change is the addition of mirrors to the interpreter frame and a test case that shows why this is necessary. An interpreter frame can be running while it's class loader is unloaded in some special circumstances. It is easier to do this with JSR292 static MethodHandle code. Some people are looking for a platform independent way to do this, by changing code in GC. While this target-dependent interpreter code is unfortunate, the concept is simple. If the latter effort succeeds, we can remove the mirror from the interpreter frame later. A note to openjdk developers - I added this mirror to zero but not to shark. More testing is necessary. Please review the following change: Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Add mirror interpreter frame. http://cr.openjdk.java.net/~coleenp/8000662/ http://bugs.sun.com/view_bug.do?bug_id=8000662 Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. Thanks, Coleen From david.holmes at oracle.com Sun Nov 11 20:32:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Nov 2012 14:32:57 +1000 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50A0723E.2050401@oracle.com> References: <50A0723E.2050401@oracle.com> Message-ID: <50A07BF9.8030509@oracle.com> Hi Coleen, :) Can you explain the old and new relationships between these various objects please. As I understand it JSR-292 introduced this special kind of class - the anonymous class - and they differ from regular classes in important ways (mainly that they can be collected before their classloader), and pre-NPG this all "just worked". The NPG changes added the ClassLoaderData metadata objects and changed some of the associations that anonymous classes actually relied upon and as a result they stopped getting GC'd in some cases, and were prematurely GC'd in others (I hope I got that right). This changeset addresses these problems. I've been trying to follow this from the beginning and still don't have a clear understanding on what the relationships between ClassLoader, Class, "anonymous class" and ClassLoaderData objects are. So a clear picture of what relationships exist (particularly this new 1:N association) would be appreciated, and help make the code changes more understandable to me. Thanks, David On 12/11/2012 1:51 PM, Coleen Phillimore wrote: > > This change creates a ClassLoaderData object for each JSR 292 anonymous > class, so that the metadata and mirror object for the anonymous class > can be reclaimed when the anonymous class is no longer referenced. The > java_lang_ClassLoader object for the anonymous class is the same as its > host_class. Most of this change is to break the assumption that there's > a 1-1 relationship between java_lang_ClassLoader Java objects and > ClassLoaderData metadata objects in the VM. Also, nmethods and other > things that were strong roots for java_lang_ClassLoader objects have to > also be strong roots for java_lang_Class objects for anonymous classes. > > There were also changes to move the dependencies out of the > java_lang_ClassLoader object to the ClassLoaderData type. This type is > preallocated so that CMS will have card marks to track additions to the > dependencies. Please check this, Stefan! > > Also, in this change is the addition of mirrors to the interpreter frame > and a test case that shows why this is necessary. An interpreter frame > can be running while it's class loader is unloaded in some special > circumstances. It is easier to do this with JSR292 static MethodHandle > code. Some people are looking for a platform independent way to do this, > by changing code in GC. While this target-dependent interpreter code is > unfortunate, the concept is simple. If the latter effort succeeds, we > can remove the mirror from the interpreter frame later. A note to > openjdk developers - I added this mirror to zero but not to shark. More > testing is necessary. > > Please review the following change: > > Summary: Add ClassLoaderData object for each anonymous class with > metaspaces to allocate in. Add mirror interpreter frame. > > http://cr.openjdk.java.net/~coleenp/8000662/ > http://bugs.sun.com/view_bug.do?bug_id=8000662 > > Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. > > Thanks, > Coleen From christian.thalinger at oracle.com Mon Nov 12 10:51:31 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 12 Nov 2012 10:51:31 -0800 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50A0723E.2050401@oracle.com> References: <50A0723E.2050401@oracle.com> Message-ID: On Nov 11, 2012, at 7:51 PM, Coleen Phillimore wrote: > > This change creates a ClassLoaderData object for each JSR 292 anonymous class, so that the metadata and mirror object for the anonymous class can be reclaimed when the anonymous class is no longer referenced. The java_lang_ClassLoader object for the anonymous class is the same as its host_class. Most of this change is to break the assumption that there's a 1-1 relationship between java_lang_ClassLoader Java objects and ClassLoaderData metadata objects in the VM. Also, nmethods and other things that were strong roots for java_lang_ClassLoader objects have to also be strong roots for java_lang_Class objects for anonymous classes. > > There were also changes to move the dependencies out of the java_lang_ClassLoader object to the ClassLoaderData type. This type is preallocated so that CMS will have card marks to track additions to the dependencies. Please check this, Stefan! > > Also, in this change is the addition of mirrors to the interpreter frame and a test case that shows why this is necessary. An interpreter frame can be running while it's class loader is unloaded in some special circumstances. It is easier to do this with JSR292 static MethodHandle code. Some people are looking for a platform independent way to do this, by changing code in GC. While this target-dependent interpreter code is unfortunate, the concept is simple. If the latter effort succeeds, we can remove the mirror from the interpreter frame later. A note to openjdk developers - I added this mirror to zero but not to shark. More testing is necessary. We should not push this change and back it out later. Let's pick the right one before pushing. The simplest fix I have (after trying various other fixes) is putting the java mirror in a Handle when doing the Threads::gc_prologue stack walk: diff --git a/src/share/vm/runtime/frame.cpp b/src/share/vm/runtime/frame.cpp --- a/src/share/vm/runtime/frame.cpp +++ b/src/share/vm/runtime/frame.cpp @@ -1152,6 +1152,11 @@ if (is_interpreted_frame()) { // set bcx to bci to become Method* position independent during GC interpreter_frame_set_bcx(interpreter_frame_bci()); + + // Keep the class alive that holds this Method* + Thread* thread = Thread::current(); + methodHandle m(thread, interpreter_frame_method()); + Handle h(m()->constants()->pool_holder()->java_mirror()); } } Threads::gc_prologue walks are only done during full GCs but we talked in length with the GC people and Stefan Karlsson on Friday and they agreed that the fix is correct. I did a lot of 262 test suite runs with Nashorn and different GCs without a crash. The only downside is that for CMS we need to add an additional call to this walking routine in CMSCollector::checkpointRootsFinalWork: diff --git a/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp b/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp --- a/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp +++ b/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp @@ -4868,6 +4868,7 @@ if (should_unload_classes()) { CodeCache::gc_prologue(); + Threads::gc_prologue(); } assert(haveFreelistLocks(), "must have free list locks"); assert_lock_strong(bitMapLock()); @@ -4928,6 +4929,7 @@ if (should_unload_classes()) { CodeCache::gc_epilogue(); + Threads::gc_epilogue(); } JvmtiExport::gc_epilogue(); This adds a small overhead but it seems to be possible to eliminate that overhead with some refactoring in CMS (IIRC). There is also another fix from Stefan Karlsson which I'll post later. -- Chris > > Please review the following change: > > Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Add mirror interpreter frame. > > http://cr.openjdk.java.net/~coleenp/8000662/ > http://bugs.sun.com/view_bug.do?bug_id=8000662 > > Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. > > Thanks, > Coleen From mikael.vidstedt at oracle.com Mon Nov 12 19:59:20 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 12 Nov 2012 19:59:20 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC Message-ID: <50A1C598.4050904@oracle.com> All, Please review the below change. The change adds the -Wunused flag when compiling with GCC and removes a number of unused functions/dead code. In the process I found one function (same_page) which was duplicated in four different places. I merged it to a single function, renamed it to clamp_address_in_page, added some comments and refactored it to be slightly easier to understand. I also added unit tests for it. Feedback appreciated (especially on the name). http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). Thanks, Mikael From david.holmes at oracle.com Mon Nov 12 21:47:17 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Nov 2012 15:47:17 +1000 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A1C598.4050904@oracle.com> References: <50A1C598.4050904@oracle.com> Message-ID: <50A1DEE5.8090606@oracle.com> Hi Mikael, A couple of general observations as really the "owners" of each file needs to assess the changes: - sometimes functions exist for debugging/tracing and calls will be added to the code by engineers as they debug. For example MBFence in synchronizer.cpp allows you to add fences into expressions. - why was the "static" removed from a number functions. They now have global visibility rather than being restricted to their files? In globaleDefinitions.cpp: + void GlobalDefinitions::test_globals() { + intptr_t page_size = 4096; Page size may not be 4K - will the test still be valid? The comments describing clamp_address_in_page don't need to be on both the declaration and definition. Cheers, David ------ On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: > > All, > > Please review the below change. The change adds the -Wunused flag when > compiling with GCC and removes a number of unused functions/dead code. > > In the process I found one function (same_page) which was duplicated in > four different places. I merged it to a single function, renamed it to > clamp_address_in_page, added some comments and refactored it to be > slightly easier to understand. I also added unit tests for it. Feedback > appreciated (especially on the name). > > http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ > > Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). > > Thanks, > Mikael > From jesper.wilhelmsson at oracle.com Tue Nov 13 00:58:40 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 13 Nov 2012 09:58:40 +0100 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A1DEE5.8090606@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> Message-ID: <1DF1714F-744D-48D9-A74F-39E110F5346F@oracle.com> 13 nov 2012 kl. 06:47 skrev David Holmes : > Hi Mikael, > > A couple of general observations as really the "owners" of each file needs to assess the changes: > > - sometimes functions exist for debugging/tracing and calls will be added to the code by engineers as they debug. For example MBFence in synchronizer.cpp allows you to add fences into expressions. Could we encapsulate these in an ifdef or similar to make this more explicit? Maybe something like MANUAL_DEBUG? /Jesper > > - why was the "static" removed from a number functions. They now have global visibility rather than being restricted to their files? > > > In globaleDefinitions.cpp: > > + void GlobalDefinitions::test_globals() { > + intptr_t page_size = 4096; > > Page size may not be 4K - will the test still be valid? > > > The comments describing clamp_address_in_page don't need to be on both the declaration and definition. > > Cheers, > David > ------ > > On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >> >> All, >> >> Please review the below change. The change adds the -Wunused flag when >> compiling with GCC and removes a number of unused functions/dead code. >> >> In the process I found one function (same_page) which was duplicated in >> four different places. I merged it to a single function, renamed it to >> clamp_address_in_page, added some comments and refactored it to be >> slightly easier to understand. I also added unit tests for it. Feedback >> appreciated (especially on the name). >> >> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >> >> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >> >> Thanks, >> Mikael >> From coleen.phillimore at oracle.com Tue Nov 13 05:41:20 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 13 Nov 2012 08:41:20 -0500 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A1DEE5.8090606@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> Message-ID: <50A24E00.3070200@oracle.com> Hi Mikael, This is good! I have the same comments as David. For constantPool.cpp can you add #undef DBG after that code. Maybe there should be a new convention for DEBUG_ for unused code that people want to leave around for debugging. I don't recommend we add a lot of code like this, but having such an ifdef would differentiate code that was just left in unintentionally from code that we want to be left in (occasionally). Thanks, Coleen On 11/13/2012 12:47 AM, David Holmes wrote: > Hi Mikael, > > A couple of general observations as really the "owners" of each file > needs to assess the changes: > > - sometimes functions exist for debugging/tracing and calls will be > added to the code by engineers as they debug. For example MBFence in > synchronizer.cpp allows you to add fences into expressions. > > - why was the "static" removed from a number functions. They now have > global visibility rather than being restricted to their files? > > > In globaleDefinitions.cpp: > > + void GlobalDefinitions::test_globals() { > + intptr_t page_size = 4096; > > Page size may not be 4K - will the test still be valid? > > > The comments describing clamp_address_in_page don't need to be on both > the declaration and definition. > > Cheers, > David > ------ > > On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >> >> All, >> >> Please review the below change. The change adds the -Wunused flag when >> compiling with GCC and removes a number of unused functions/dead code. >> >> In the process I found one function (same_page) which was duplicated in >> four different places. I merged it to a single function, renamed it to >> clamp_address_in_page, added some comments and refactored it to be >> slightly easier to understand. I also added unit tests for it. Feedback >> appreciated (especially on the name). >> >> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >> >> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >> >> Thanks, >> Mikael >> From coleen.phillimore at oracle.com Tue Nov 13 06:20:16 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 13 Nov 2012 09:20:16 -0500 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A24E00.3070200@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> Message-ID: <50A25720.1040405@oracle.com> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: > > Hi Mikael, This is good! I have the same comments as David. > > For constantPool.cpp can you add #undef DBG after that code. > > Maybe there should be a new convention for DEBUG_ > for unused code that people want to leave around for debugging. I > don't recommend we add a lot of code like this, but having such an > ifdef would differentiate code that was just left in unintentionally > from code that we want to be left in (occasionally). Actually, I want to revise this. We had this discussion about this recently rwt metaspace debugging and favored a const static variable = false; under #ifdef DEBUG or ASSERT and the debugging code under DEBUG/ASSERT so that it doesn't bit rot. This is for the code left in intentionally. Which makes me wonder why print_cpool_bytes() is there under DEBUG_CPOOL claiming to be "temporary" when there is another printing function in that file already. Coleen > > Thanks, > Coleen > > On 11/13/2012 12:47 AM, David Holmes wrote: >> Hi Mikael, >> >> A couple of general observations as really the "owners" of each file >> needs to assess the changes: >> >> - sometimes functions exist for debugging/tracing and calls will be >> added to the code by engineers as they debug. For example MBFence in >> synchronizer.cpp allows you to add fences into expressions. >> >> - why was the "static" removed from a number functions. They now have >> global visibility rather than being restricted to their files? >> >> >> In globaleDefinitions.cpp: >> >> + void GlobalDefinitions::test_globals() { >> + intptr_t page_size = 4096; >> >> Page size may not be 4K - will the test still be valid? >> >> >> The comments describing clamp_address_in_page don't need to be on >> both the declaration and definition. >> >> Cheers, >> David >> ------ >> >> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>> >>> All, >>> >>> Please review the below change. The change adds the -Wunused flag when >>> compiling with GCC and removes a number of unused functions/dead code. >>> >>> In the process I found one function (same_page) which was duplicated in >>> four different places. I merged it to a single function, renamed it to >>> clamp_address_in_page, added some comments and refactored it to be >>> slightly easier to understand. I also added unit tests for it. Feedback >>> appreciated (especially on the name). >>> >>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>> >>> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >>> >>> Thanks, >>> Mikael >>> > From Vladimir.Kozlov at oracle.com Tue Nov 13 10:02:52 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Nov 2012 10:02:52 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A1C598.4050904@oracle.com> References: <50A1C598.4050904@oracle.com> Message-ID: <50A28B4C.7010304@oracle.com> In opto/subnode.cpp leave the beginning of commented code to explain why we don't do such optimizations. Thanks, Vladimir On 11/12/12 19:59, Mikael Vidstedt wrote: > > All, > > Please review the below change. The change adds the -Wunused flag when > compiling with GCC and removes a number of unused functions/dead code. > > In the process I found one function (same_page) which was duplicated in > four different places. I merged it to a single function, renamed it to > clamp_address_in_page, added some comments and refactored it to be > slightly easier to understand. I also added unit tests for it. Feedback > appreciated (especially on the name). > > http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ > > Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). > > Thanks, > Mikael > From vladimir.kozlov at oracle.com Wed Nov 14 16:49:46 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 15 Nov 2012 00:49:46 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20121115004951.394CC4798E@hg.openjdk.java.net> Changeset: 992c6fb64244 Author: kvn Date: 2012-10-24 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/992c6fb64244 7184394: add intrinsics to use AES instructions Summary: Use new x86 AES instructions for AESCrypt. Reviewed-by: twisti, kvn, roland Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7184394/TestAESBase.java + test/compiler/7184394/TestAESDecode.java + test/compiler/7184394/TestAESEncode.java + test/compiler/7184394/TestAESMain.java Changeset: 90ea9d355f4d Author: kvn Date: 2012-11-06 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/90ea9d355f4d 8002294: assert(VM_Version::supports_ssse3()) failed Summary: Add missing UseSSE check for AES intrinsics. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp From gnu.andrew at redhat.com Wed Nov 14 17:17:29 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 14 Nov 2012 20:17:29 -0500 (EST) Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <1953466134.907887.1352942153060.JavaMail.root@redhat.com> Message-ID: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> I hear this has been reported already, but I couldn't see anything obvious in the archives for the various HotSpot lists. The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when it exactly regressed, but a number of people have mentioned over the past week or so. The following webrev fixes the build (following GCC's advice): http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ If you've already committed something and it's in the pipes, feel free to ignore this. Otherwise, we could really do with this going in so people can build OpenJDK8 again. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From zhengyu.gu at oracle.com Wed Nov 14 19:30:33 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 15 Nov 2012 03:30:33 +0000 Subject: hg: hsx/hsx24/hotspot: 5 new changesets Message-ID: <20121115033046.633A34799B@hg.openjdk.java.net> Changeset: 588e39d3fc05 Author: zgu Date: 2012-09-11 20:53 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/588e39d3fc05 7181995: NMT ON: NMT assertion failure assert(cur_vm->is_uncommit_record() || cur_vm->is_deallocation_record Summary: Fixed virtual memory records merge and promotion logic, should be based on sequence number vs. base address order Reviewed-by: coleenp, acorn ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 45c6de60a779 Author: zgu Date: 2012-09-14 12:55 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/45c6de60a779 7198529: NPG: assert with NMT code in Thread destructor Summary: Thread stack's base address can be NULL if it is not started or exited before recording the base Reviewed-by: kvn, fparain ! src/share/vm/runtime/thread.cpp Changeset: aa65674c0e22 Author: zgu Date: 2012-09-17 10:20 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/aa65674c0e22 7190089: NMT ON: NMT failed assertion on thread's stack base address Summary: Solaris only, record stack info to NMT after stack size adjustment was made for primordial threads Reviewed-by: kvn, acorn, coleenp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 8b70e9942bd3 Author: zgu Date: 2012-09-17 16:37 -0400 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8b70e9942bd3 7188594: Print statistic collected by NMT with VM flag Summary: Print out statistics of collected NMT data if it is on at VM exits Reviewed-by: kvn, coleenp, twisti ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/services/memTracker.hpp Changeset: 490ddaa553ad Author: zgu Date: 2012-11-14 16:53 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/490ddaa553ad Merge ! src/share/vm/runtime/globals.hpp From coleen.phillimore at oracle.com Wed Nov 14 19:40:03 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 14 Nov 2012 22:40:03 -0500 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> Message-ID: <50A46413.7000609@oracle.com> On 11/14/2012 8:17 PM, Andrew Hughes wrote: > I hear this has been reported already, but I couldn't see anything > obvious in the archives for the various HotSpot lists. > > The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when > it exactly regressed, but a number of people have mentioned over the past week > or so. > > The following webrev fixes the build (following GCC's advice): > > http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ > > If you've already committed something and it's in the pipes, feel > free to ignore this. Otherwise, we could really do with this going in so people can > build OpenJDK8 again. > > Thanks, I thought someone was already going to check this in. It's reported as CR 8003259. It looks like it was also contributed by peter.levart at gmail.com. Jon's on vacation. We have reviewed this. I'll check it in now. Thanks, Coleen From david.holmes at oracle.com Wed Nov 14 20:56:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Nov 2012 14:56:21 +1000 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A46413.7000609@oracle.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> Message-ID: <50A475F5.3070003@oracle.com> IMHO Mikaels fix should be restored. David On 15/11/2012 1:40 PM, Coleen Phillimore wrote: > On 11/14/2012 8:17 PM, Andrew Hughes wrote: >> I hear this has been reported already, but I couldn't see anything >> obvious in the archives for the various HotSpot lists. >> The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when >> it exactly regressed, but a number of people have mentioned over the >> past week >> or so. >> The following webrev fixes the build (following GCC's advice): >> >> http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ >> If you've already committed something and it's in the pipes, feel >> free to ignore this. Otherwise, we could really do with this going in >> so people can >> build OpenJDK8 again. >> Thanks, > > I thought someone was already going to check this in. It's reported as > CR 8003259. > It looks like it was also contributed by peter.levart at gmail.com. > Jon's on vacation. We have reviewed this. I'll check it in now. > Thanks, > Coleen From vladimir.danushevsky at oracle.com Wed Nov 14 21:20:13 2012 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 15 Nov 2012 05:20:13 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20121115052021.237594799C@hg.openjdk.java.net> Changeset: 6cb0d32b828b Author: bpittore Date: 2012-11-07 17:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6cb0d32b828b 8001185: parsing of sun.boot.library.path in os::dll_build_name somewhat broken Summary: dll_dir can contain multiple paths, need to parse them correctly when loading agents Reviewed-by: dholmes, dlong Contributed-by: bill.pittore at oracle.com ! 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/classfile/classLoader.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: d9a84e246cce Author: cjplummer Date: 2012-11-09 09:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d9a84e246cce Merge ! src/share/vm/runtime/thread.cpp Changeset: 429994fc0754 Author: cjplummer Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/429994fc0754 Merge From mikael.vidstedt at oracle.com Wed Nov 14 23:13:09 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 14 Nov 2012 23:13:09 -0800 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A475F5.3070003@oracle.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> <50A475F5.3070003@oracle.com> Message-ID: <50A49605.9030801@oracle.com> Agreed, and it would obviously be interesting to know out why the original fix was lost. /Mikael On 2012-11-14 20:56, David Holmes wrote: > IMHO Mikaels fix should be restored. > > David > > On 15/11/2012 1:40 PM, Coleen Phillimore wrote: >> On 11/14/2012 8:17 PM, Andrew Hughes wrote: >>> I hear this has been reported already, but I couldn't see anything >>> obvious in the archives for the various HotSpot lists. >>> The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when >>> it exactly regressed, but a number of people have mentioned over the >>> past week >>> or so. >>> The following webrev fixes the build (following GCC's advice): >>> >>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ >>> If you've already committed something and it's in the pipes, feel >>> free to ignore this. Otherwise, we could really do with this going in >>> so people can >>> build OpenJDK8 again. >>> Thanks, >> >> I thought someone was already going to check this in. It's reported as >> CR 8003259. >> It looks like it was also contributed by peter.levart at gmail.com. >> Jon's on vacation. We have reviewed this. I'll check it in now. >> Thanks, >> Coleen From fweimer at redhat.com Thu Nov 15 01:26:50 2012 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 15 Nov 2012 10:26:50 +0100 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A49605.9030801@oracle.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> <50A475F5.3070003@oracle.com> <50A49605.9030801@oracle.com> Message-ID: <50A4B55A.5080203@redhat.com> On 11/15/2012 08:13 AM, Mikael Vidstedt wrote: > Agreed, and it would obviously be interesting to know out why the > original fix was lost. The using declarations were moved in this commit: changeset: 685df3c6f84b user: jmasa date: Tue Sep 18 23:35:42 2012 -0700 summary: 7045397: NPG: Add freelists to class loader arenas. This may have been due to a misunderstanding how these declarations work in this case. The effect on dependent name lookup does not propagate to templated derived classes if the base class is type-dependent. The this-> marker is more explicit, that's why I prefer it. -- Florian Weimer / Red Hat Product Security Team From david.holmes at oracle.com Thu Nov 15 02:25:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Nov 2012 20:25:10 +1000 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A4B55A.5080203@redhat.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> <50A475F5.3070003@oracle.com> <50A49605.9030801@oracle.com> <50A4B55A.5080203@redhat.com> Message-ID: <50A4C306.9080703@oracle.com> On 15/11/2012 7:26 PM, Florian Weimer wrote: > On 11/15/2012 08:13 AM, Mikael Vidstedt wrote: > >> Agreed, and it would obviously be interesting to know out why the >> original fix was lost. > > The using declarations were moved in this commit: > > changeset: 685df3c6f84b > user: jmasa > date: Tue Sep 18 23:35:42 2012 -0700 > summary: 7045397: NPG: Add freelists to class loader arenas. Yes thanks - that was covered in the original thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004737.html > This may have been due to a misunderstanding how these declarations work > in this case. The effect on dependent name lookup does not propagate to > templated derived classes if the base class is type-dependent. The > this-> marker is more explicit, that's why I prefer it. The reason I dislike it is that to me it look quite bizarre to have a series of invocations only some of which require this-> To the reader there is no obvious reason as to why it is needed. BTW there are numerous using directives in the binaryTreeDictionary.hpp file, so now we have a mixed solution which isn't good for anyone's ability to understand the code. :( Cheers, David From coleen.phillimore at oracle.com Thu Nov 15 07:23:33 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 15 Nov 2012 10:23:33 -0500 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A49605.9030801@oracle.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> <50A475F5.3070003@oracle.com> <50A49605.9030801@oracle.com> Message-ID: <50A508F5.3020901@oracle.com> On 11/15/2012 2:13 AM, Mikael Vidstedt wrote: > > Agreed, and it would obviously be interesting to know out why the > original fix was lost. Jon's freelist change was a big change, so it's not surprising this was lost. I hope my new ubuntu 12.04 system can get a later gcc compiler on it so we can find these earlier. this-> seemed like the simplest fix so that's why I checked it in. I didn't know what to use with "using" at 11pm my time. Coleen > > /Mikael > > On 2012-11-14 20:56, David Holmes wrote: >> IMHO Mikaels fix should be restored. >> >> David >> >> On 15/11/2012 1:40 PM, Coleen Phillimore wrote: >>> On 11/14/2012 8:17 PM, Andrew Hughes wrote: >>>> I hear this has been reported already, but I couldn't see anything >>>> obvious in the archives for the various HotSpot lists. >>>> The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when >>>> it exactly regressed, but a number of people have mentioned over the >>>> past week >>>> or so. >>>> The following webrev fixes the build (following GCC's advice): >>>> >>>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ >>>> If you've already committed something and it's in the pipes, feel >>>> free to ignore this. Otherwise, we could really do with this going in >>>> so people can >>>> build OpenJDK8 again. >>>> Thanks, >>> >>> I thought someone was already going to check this in. It's reported as >>> CR 8003259. >>> It looks like it was also contributed by peter.levart at gmail.com. >>> Jon's on vacation. We have reviewed this. I'll check it in now. >>> Thanks, >>> Coleen > From staffan.larsen at oracle.com Thu Nov 15 10:54:51 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 15 Nov 2012 18:54:51 +0000 Subject: hg: hsx/hsx24/hotspot: 8002078: hs_err_pid file should report full JDK version string Message-ID: <20121115185455.AF2B4479B7@hg.openjdk.java.net> Changeset: db4c2d9ffc47 Author: sla Date: 2012-11-01 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/db4c2d9ffc47 8002078: hs_err_pid file should report full JDK version string Reviewed-by: dholmes, sspitsyn, kmo ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp From coleen.phillimore at oracle.com Thu Nov 15 14:10:02 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 15 Nov 2012 17:10:02 -0500 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A508F5.3020901@oracle.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> <50A475F5.3070003@oracle.com> <50A49605.9030801@oracle.com> <50A508F5.3020901@oracle.com> Message-ID: <50A5683A.2040507@oracle.com> I just installed ubuntu 12.04 LTS on my new machine and when I get g++ I get "latest" version g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3. Why is this? Why can't I get 4.7 for ubuntu? Thanks, Coleen On 11/15/2012 10:23 AM, Coleen Phillimore wrote: > On 11/15/2012 2:13 AM, Mikael Vidstedt wrote: >> >> Agreed, and it would obviously be interesting to know out why the >> original fix was lost. > > Jon's freelist change was a big change, so it's not surprising this > was lost. I hope my new ubuntu 12.04 system can get a later gcc > compiler on it so we can find these earlier. > > this-> seemed like the simplest fix so that's why I checked it in. I > didn't know what to use with "using" at 11pm my time. > > Coleen > >> >> /Mikael >> >> On 2012-11-14 20:56, David Holmes wrote: >>> IMHO Mikaels fix should be restored. >>> >>> David >>> >>> On 15/11/2012 1:40 PM, Coleen Phillimore wrote: >>>> On 11/14/2012 8:17 PM, Andrew Hughes wrote: >>>>> I hear this has been reported already, but I couldn't see anything >>>>> obvious in the archives for the various HotSpot lists. >>>>> The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when >>>>> it exactly regressed, but a number of people have mentioned over the >>>>> past week >>>>> or so. >>>>> The following webrev fixes the build (following GCC's advice): >>>>> >>>>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ >>>>> If you've already committed something and it's in the pipes, feel >>>>> free to ignore this. Otherwise, we could really do with this going in >>>>> so people can >>>>> build OpenJDK8 again. >>>>> Thanks, >>>> >>>> I thought someone was already going to check this in. It's reported as >>>> CR 8003259. >>>> It looks like it was also contributed by peter.levart at gmail.com. >>>> Jon's on vacation. We have reviewed this. I'll check it in now. >>>> Thanks, >>>> Coleen >> > From zhengyu.gu at oracle.com Thu Nov 15 14:21:31 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 15 Nov 2012 17:21:31 -0500 Subject: Code review request: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Message-ID: <50A56AEB.9070607@oracle.com> The assertion is to check that there is not more committed region within the memory region to be released, so the check to be applied to the reserved region that is going to be released, but not whole region, when the region to be released is only a segment within the region. http://cr.openjdk.java.net/~zgu/8003487/webrev.00/ Thanks, -Zhengyu From gary.collins at oracle.com Thu Nov 15 14:26:39 2012 From: gary.collins at oracle.com (Gary Collins) Date: Thu, 15 Nov 2012 14:26:39 -0800 Subject: GCC 4.7 OpenJDK Build Failure In-Reply-To: <50A5683A.2040507@oracle.com> References: <1578976956.907982.1352942249209.JavaMail.root@redhat.com> <50A46413.7000609@oracle.com> <50A475F5.3070003@oracle.com> <50A49605.9030801@oracle.com> <50A508F5.3020901@oracle.com> <50A5683A.2040507@oracle.com> Message-ID: <0406E4BE-AFE1-41D7-BB71-825A0C8E4721@oracle.com> You need to ask for it to be installed.. 4.6 is whats default in ubuntu 12.04.. Ubuntu 12.10 will probably have 4.7 Gary On Nov 15, 2012, at 2:10 PM, Coleen Phillimore wrote: > > I just installed ubuntu 12.04 LTS on my new machine and when I get g++ I get "latest" version g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3. > Why is this? Why can't I get 4.7 for ubuntu? > Thanks, > Coleen > > On 11/15/2012 10:23 AM, Coleen Phillimore wrote: >> On 11/15/2012 2:13 AM, Mikael Vidstedt wrote: >>> >>> Agreed, and it would obviously be interesting to know out why the original fix was lost. >> >> Jon's freelist change was a big change, so it's not surprising this was lost. I hope my new ubuntu 12.04 system can get a later gcc compiler on it so we can find these earlier. >> >> this-> seemed like the simplest fix so that's why I checked it in. I didn't know what to use with "using" at 11pm my time. >> >> Coleen >> >>> >>> /Mikael >>> >>> On 2012-11-14 20:56, David Holmes wrote: >>>> IMHO Mikaels fix should be restored. >>>> >>>> David >>>> >>>> On 15/11/2012 1:40 PM, Coleen Phillimore wrote: >>>>> On 11/14/2012 8:17 PM, Andrew Hughes wrote: >>>>>> I hear this has been reported already, but I couldn't see anything >>>>>> obvious in the archives for the various HotSpot lists. >>>>>> The build of jdk8 (currently b64) fails on gcc 4.7. I'm not sure when >>>>>> it exactly regressed, but a number of people have mentioned over the >>>>>> past week >>>>>> or so. >>>>>> The following webrev fixes the build (following GCC's advice): >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/hotspot/webrev.05/ >>>>>> If you've already committed something and it's in the pipes, feel >>>>>> free to ignore this. Otherwise, we could really do with this going in >>>>>> so people can >>>>>> build OpenJDK8 again. >>>>>> Thanks, >>>>> >>>>> I thought someone was already going to check this in. It's reported as >>>>> CR 8003259. >>>>> It looks like it was also contributed by peter.levart at gmail.com. >>>>> Jon's on vacation. We have reviewed this. I'll check it in now. >>>>> Thanks, >>>>> Coleen >>> >> > From mikael.vidstedt at oracle.com Thu Nov 15 16:20:47 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 15 Nov 2012 16:20:47 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A1DEE5.8090606@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> Message-ID: <50A586DF.9090104@oracle.com> On 2012-11-12 21:47, David Holmes wrote: > Hi Mikael, > > A couple of general observations as really the "owners" of each file > needs to assess the changes: > > - sometimes functions exist for debugging/tracing and calls will be > added to the code by engineers as they debug. For example MBFence in > synchronizer.cpp allows you to add fences into expressions. For MBFence specifically, given that it is a static in synchronizer.cpp I'm going to assume it's a leftover and any future debugging/tracing should be able to do a call to OrderAccess::fence() directly instead, but in general you're absolutely right and I'm counting on the owners to point out if there are functions that are frequently used during development. Put differently - is anybody counting on the following functions, if not *they will be removed*: src/cpu/x86/vm/x86_64.ad:Address build_address(int b, int i, int s, int d) src/cpu/x86/vm/methodHandles_x86.cpp:RegisterOrConstant constant(int value) src/cpu/x86/vm/assembler_x86.cpp:int encode(XMMRegister r) src/share/vm/c1/c1_LIRGenerator.cpp:Value maxvalue(IfOp* ifop) src/share/vm/compiler/compileLog.cpp:const char* split_attrs(const char* &kind, char* buffer) src/share/vm/compiler/compilerOracle.cpp:const char * command_name(OracleCommand command) src/share/vm/gc_implementation/g1/ptrQueue.cpp:int byte_index_to_index(int ind) src/share/vm/gc_implementation/g1/ptrQueue.cpp:int index_to_byte_index(int byte_ind) src/share/vm/interpreter/interpreterRuntime.cpp:void trace_locking(Handle& h_locking_obj, bool is_locking) src/share/vm/memory/heap.cpp:size_t align_to_allocation_size(size_t size) src/share/vm/opto/connode.cpp:bool can_cause_alias(Node *n, PhaseTransform *phase) src/share/vm/opto/subnode.cpp:Node *clone_cmp( Node *cmp, Node *cmp1, Node *cmp2, PhaseGVN *gvn, BoolTest::mask test ) src/share/vm/prims/jni.cpp:methodHandle jni_resolve_interface_call(Handle recv, methodHandle method, TRAPS) src/share/vm/prims/jni.cpp:methodHandle jni_resolve_virtual_call(Handle recv, methodHandle method, TRAPS) > - why was the "static" removed from a number functions. They now have > global visibility rather than being restricted to their files? GCC knows that static functions declared in a file but not used in that same file are dead, and it emits a warning for each of them. My assumption was that the three functions for which I removed the static keyword are being used for debugging purposes, called from, say, gdb. It would be very helpful to get feedback on if that assumption is correct. Or again, put differently - is anybody using any the following functions from a debugger. If I don't get confirmation on that they'll also be removed. src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp:char* region_num_to_mbs(int length) src/share/vm/opto/block.cpp:void edge_dump(GrowableArray *edges) src/share/vm/opto/block.cpp:void trace_dump(Trace *traces[], int count) > In globaleDefinitions.cpp: > > + void GlobalDefinitions::test_globals() { > + intptr_t page_size = 4096; > > Page size may not be 4K - will the test still be valid? I'll add tests with a couple of other page sizes as well! > The comments describing clamp_address_in_page don't need to be on both > the declaration and definition. I'll keep it on the declaration only. > > Cheers, > David > ------ > > On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >> >> All, >> >> Please review the below change. The change adds the -Wunused flag when >> compiling with GCC and removes a number of unused functions/dead code. >> >> In the process I found one function (same_page) which was duplicated in >> four different places. I merged it to a single function, renamed it to >> clamp_address_in_page, added some comments and refactored it to be >> slightly easier to understand. I also added unit tests for it. Feedback >> appreciated (especially on the name). >> >> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >> >> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >> >> Thanks, >> Mikael >> From john.cuthbertson at oracle.com Thu Nov 15 16:49:55 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 16 Nov 2012 00:49:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20121116005001.3A814479C6@hg.openjdk.java.net> Changeset: 6bc207d87e5d Author: mgerdin Date: 2012-11-09 00:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6bc207d87e5d 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java Summary: Reduce the amount of calls to ChunkManager verification code Reviewed-by: jmasa, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 0400886d2613 Author: coleenp Date: 2012-11-14 22:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0400886d2613 8003259: NPG: Build with gcc 4.7.2 broken by 7045397 Summary: Qualify calls with this pointers to make gcc accept this code. Reviewed-by: coleenp, andrew Contributed-by: peter.levart at gmail.com ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: c5d4acbb943d Author: johnc Date: 2012-11-15 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c5d4acbb943d Merge From mikael.vidstedt at oracle.com Thu Nov 15 17:00:00 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 15 Nov 2012 17:00:00 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A25720.1040405@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> Message-ID: <50A59010.5040001@oracle.com> On 2012-11-13 06:20, Coleen Phillimore wrote: > On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >> >> Hi Mikael, This is good! I have the same comments as David. >> >> For constantPool.cpp can you add #undef DBG after that code. >> >> Maybe there should be a new convention for DEBUG_ >> for unused code that people want to leave around for debugging. I >> don't recommend we add a lot of code like this, but having such an >> ifdef would differentiate code that was just left in unintentionally >> from code that we want to be left in (occasionally). > > Actually, I want to revise this. We had this discussion about this > recently rwt metaspace debugging and favored a const static variable = > false; under #ifdef DEBUG or ASSERT and the debugging code under > DEBUG/ASSERT so that it doesn't bit rot. This is for the code left > in intentionally. Which makes me wonder why print_cpool_bytes() is > there under DEBUG_CPOOL claiming to be "temporary" when there is > another printing function in that file already. The reason why I moved it under DBG was because it is only ever called wrapped with a DBG(). I can play around with making it a const static = false as you outlined. The other print functions in constantPool.cpp are implementations of the virtual functions inherited from Metadata, so they are not quite as temporary as print_cpool_bytes, if that makes sense. Cheers, Mikael > > Coleen > >> >> Thanks, >> Coleen >> >> On 11/13/2012 12:47 AM, David Holmes wrote: >>> Hi Mikael, >>> >>> A couple of general observations as really the "owners" of each file >>> needs to assess the changes: >>> >>> - sometimes functions exist for debugging/tracing and calls will be >>> added to the code by engineers as they debug. For example MBFence in >>> synchronizer.cpp allows you to add fences into expressions. >>> >>> - why was the "static" removed from a number functions. They now >>> have global visibility rather than being restricted to their files? >>> >>> >>> In globaleDefinitions.cpp: >>> >>> + void GlobalDefinitions::test_globals() { >>> + intptr_t page_size = 4096; >>> >>> Page size may not be 4K - will the test still be valid? >>> >>> >>> The comments describing clamp_address_in_page don't need to be on >>> both the declaration and definition. >>> >>> Cheers, >>> David >>> ------ >>> >>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>> >>>> All, >>>> >>>> Please review the below change. The change adds the -Wunused flag when >>>> compiling with GCC and removes a number of unused functions/dead code. >>>> >>>> In the process I found one function (same_page) which was >>>> duplicated in >>>> four different places. I merged it to a single function, renamed it to >>>> clamp_address_in_page, added some comments and refactored it to be >>>> slightly easier to understand. I also added unit tests for it. >>>> Feedback >>>> appreciated (especially on the name). >>>> >>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>> >>>> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >>>> >>>> Thanks, >>>> Mikael >>>> >> > From john.r.rose at oracle.com Thu Nov 15 19:21:50 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 15 Nov 2012 19:21:50 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A586DF.9090104@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A586DF.9090104@oracle.com> Message-ID: <773A3254-6D96-4F18-9B54-056E5464E50B@oracle.com> On Nov 15, 2012, at 4:20 PM, Mikael Vidstedt wrote: > src/share/vm/opto/block.cpp:void edge_dump(GrowableArray *edges) > src/share/vm/opto/block.cpp:void trace_dump(Trace *traces[], int count) Those are from 2008, which was a very good year, but they can be retired now. Note that they are inside "#ifndef PRODUCT". There would also be almost no harm in keeping useful non-product functions, so anything that looks slightly useful for debugging should probably be kept. But these guys are specialized and simple to recreate, so I don't think they clear the bar. ? John From david.holmes at oracle.com Thu Nov 15 21:14:34 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Nov 2012 15:14:34 +1000 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A586DF.9090104@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A586DF.9090104@oracle.com> Message-ID: <50A5CBBA.7050107@oracle.com> On 16/11/2012 10:20 AM, Mikael Vidstedt wrote: > On 2012-11-12 21:47, David Holmes wrote: >> Hi Mikael, >> >> A couple of general observations as really the "owners" of each file >> needs to assess the changes: >> >> - sometimes functions exist for debugging/tracing and calls will be >> added to the code by engineers as they debug. For example MBFence in >> synchronizer.cpp allows you to add fences into expressions. > > For MBFence specifically, given that it is a static in synchronizer.cpp > I'm going to assume it's a leftover and any future debugging/tracing > should be able to do a call to OrderAccess::fence() directly instead, Not really, the helper defines a function so you can insert the barrier at arbitrary locations, including within expressions. You can't do that with OrderAccess::fence() unless you add gratuitous parentheses and use of the comma operator. So anyone wanting this will end up redefining what is presently there. That said this case is so trivial that recreating it is not an issue. > but in general you're absolutely right and I'm counting on the owners to > point out if there are functions that are frequently used during > development. > > Put differently - is anybody counting on the following functions, if not > *they will be removed*: > > src/share/vm/interpreter/interpreterRuntime.cpp:void > trace_locking(Handle& h_locking_obj, bool is_locking) I would say leave this in place but use ifndef PRODUCT around it. >> - why was the "static" removed from a number functions. They now have >> global visibility rather than being restricted to their files? > > GCC knows that static functions declared in a file but not used in that > same file are dead, and it emits a warning for each of them. My > assumption was that the three functions for which I removed the static > keyword are being used for debugging purposes, called from, say, gdb. It > would be very helpful to get feedback on if that assumption is correct. The same could be true for other methods here - they may exist to be invoked from the debugger. Unfortunately we've lost a lot of historical knowledge here. > Or again, put differently - is anybody using any the following functions > from a debugger. If I don't get confirmation on that they'll also be > removed. > > src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp:char* > region_num_to_mbs(int length) > src/share/vm/opto/block.cpp:void edge_dump(GrowableArray *edges) > src/share/vm/opto/block.cpp:void trace_dump(Trace *traces[], int count) > >> In globaleDefinitions.cpp: >> >> + void GlobalDefinitions::test_globals() { >> + intptr_t page_size = 4096; >> >> Page size may not be 4K - will the test still be valid? > > I'll add tests with a couple of other page sizes as well! Not quite what I meant. If os::vm_page_size() != 4k will this test be valid? Cheers, David ------ >> The comments describing clamp_address_in_page don't need to be on both >> the declaration and definition. > > I'll keep it on the declaration only. > >> >> Cheers, >> David >> ------ >> >> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>> >>> All, >>> >>> Please review the below change. The change adds the -Wunused flag when >>> compiling with GCC and removes a number of unused functions/dead code. >>> >>> In the process I found one function (same_page) which was duplicated in >>> four different places. I merged it to a single function, renamed it to >>> clamp_address_in_page, added some comments and refactored it to be >>> slightly easier to understand. I also added unit tests for it. Feedback >>> appreciated (especially on the name). >>> >>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>> >>> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >>> >>> Thanks, >>> Mikael >>> > From john.coomes at oracle.com Fri Nov 16 01:31:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:31:43 +0000 Subject: hg: hsx/hotspot-main: 5 new changesets Message-ID: <20121116093143.B3335479E3@hg.openjdk.java.net> Changeset: 8bbc72864a41 Author: ohrstrom Date: 2012-11-08 12:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8bbc72864a41 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! common/makefiles/JavaCompilation.gmk Changeset: 78bb27faf889 Author: tbell Date: 2012-11-12 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/78bb27faf889 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: f2ac4d0edaae Author: tbell Date: 2012-11-13 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f2ac4d0edaae 8003274: build-infra: Makefile changes needed for sjavac Summary: changes left in build-infra that are related to sjavac Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com, fredrik.ohrstrom at oracle.com ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeHelpers.gmk Changeset: b772de306dc2 Author: katleman Date: 2012-11-14 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b772de306dc2 Merge Changeset: 0e1b5886b06c Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0e1b5886b06c Added tag jdk8-b65 for changeset b772de306dc2 ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:31:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:31:47 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b65 for changeset 5132f7900a8f Message-ID: <20121116093151.2E76E479E4@hg.openjdk.java.net> Changeset: 65771ad1ca55 Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/65771ad1ca55 Added tag jdk8-b65 for changeset 5132f7900a8f ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:31:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:31:56 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b65 for changeset 5cf3c69a93d6 Message-ID: <20121116093207.107A6479E5@hg.openjdk.java.net> Changeset: e6af1ad464e3 Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e6af1ad464e3 Added tag jdk8-b65 for changeset 5cf3c69a93d6 ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:32:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:32:11 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b65 for changeset fbe54291c9d3 Message-ID: <20121116093216.35AB1479E6@hg.openjdk.java.net> Changeset: 3eb7f11cb4e0 Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/3eb7f11cb4e0 Added tag jdk8-b65 for changeset fbe54291c9d3 ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:33:20 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:33:20 +0000 Subject: hg: hsx/hotspot-main/jdk: 31 new changesets Message-ID: <20121116094004.BF9E2479E8@hg.openjdk.java.net> Changeset: bc09a1591629 Author: alanb Date: 2012-11-04 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc09a1591629 8000330: (fc) FileChannel.truncate issues when given size > file size 8002180: (fc) FileChannel.map does not throw NPE if MapMode specified as null Reviewed-by: chegar ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Truncate.java Changeset: 46b24eb85b86 Author: mullan Date: 2012-11-05 10:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/46b24eb85b86 7171570: JEP 124 Potential API Changes Reviewed-by: vinnie, xuelei ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 4770b0a49675 Author: mullan Date: 2012-11-05 10:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4770b0a49675 Merge - make/sun/jdbc/Makefile - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c Changeset: 510cb3671f14 Author: mullan Date: 2012-11-05 12:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/510cb3671f14 Merge Changeset: 519f4c9ebf8d Author: vinnie Date: 2012-11-05 20:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/519f4c9ebf8d 6383200: PBE: need new algorithm support in password based encryption Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEParameters.java + src/share/classes/com/sun/crypto/provider/PBES1Core.java + src/share/classes/com/sun/crypto/provider/PBES2Core.java + src/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java + src/share/classes/com/sun/crypto/provider/PBKDF2Core.java + src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEInvalidParamsTest.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEKeysAlgorithmNames.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEParametersTest.java + test/com/sun/crypto/provider/Cipher/PBE/PBES2Test.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Oid.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/HmacSaltLengths.java Changeset: 798292c71419 Author: ksrini Date: 2012-11-05 14:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/798292c71419 8001191: use -source 8 -target 8 when compiling the JDK Reviewed-by: chegar, dholmes, erikj, jgish ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/java/invoke/Makefile ! makefiles/Setup.gmk ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/native/java/lang/System.c ! test/ProblemList.txt Changeset: 8222e6eac651 Author: ksrini Date: 2012-11-05 15:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8222e6eac651 7050936: (pack200) Support version 52.0 class files in langtools Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/native/com/sun/java/util/jar/pack/constants.h Changeset: cb65e3315b27 Author: jiangli Date: 2012-11-05 12:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb65e3315b27 7197210: java/lang/invoke/CallSiteTest.java failing on armsflt. Summary: Reduce work load and set longer timeout for java/lang/invoke tests. Reviewed-by: kvn, twisti ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RicochetTest.java Changeset: d90714aec287 Author: lancea Date: 2012-11-06 14:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d90714aec287 8002212: adding read/writeObject to additional SerialXXX classes Reviewed-by: naoto, forax ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 157506182fa7 Author: chegar Date: 2012-11-06 21:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/157506182fa7 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently Reviewed-by: alanb, dsamersoff ! test/sun/net/www/protocol/http/StackTraceTest.java Changeset: bff9db7ca352 Author: peytoia Date: 2012-11-07 09:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bff9db7ca352 7198195: Support Unicode 6.2.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/PropList.txt ! make/tools/UnicodeData/Scripts.txt ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt ! make/tools/UnicodeData/VERSION ! src/share/classes/java/lang/Character.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/PropList.txt ! test/java/lang/Character/PropertyValueAliases.txt ! test/java/lang/Character/Scripts.txt Changeset: c9fd61d23dbe Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9fd61d23dbe Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: a1bbb8805e22 Author: weijun Date: 2012-11-07 14:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1bbb8805e22 6355584: Introduce constrained Kerberos delegation Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java + src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/PAData.java + src/share/classes/sun/security/krb5/internal/PAForUserEnc.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/Basic.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java + test/sun/security/krb5/auto/S4U2proxy.java + test/sun/security/krb5/auto/S4U2proxyGSS.java + test/sun/security/krb5/auto/S4U2self.java + test/sun/security/krb5/auto/S4U2selfAsServer.java + test/sun/security/krb5/auto/S4U2selfAsServerGSS.java + test/sun/security/krb5/auto/S4U2selfGSS.java Changeset: 59e88d3b9b17 Author: jzavgren Date: 2012-11-07 10:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/59e88d3b9b17 8001579: Cleanup warnings in security native code Reviewed-by: chegar, alanb, vinnie ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c Changeset: 9e013ce42dd7 Author: dfuchs Date: 2012-11-07 13:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9e013ce42dd7 6720349: (ch) Channels tests depending on hosts inside Sun Summary: This changeset make the nio tests start small TCP or UDP servers from within the tests, instead of relying on external services. Reviewed-by: alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/IsBound.java ! test/java/nio/channels/DatagramChannel/IsConnected.java ! test/java/nio/channels/Selector/Alias.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Basic.java ! test/java/nio/channels/SocketChannel/BufferSize.java ! test/java/nio/channels/SocketChannel/Connect.java ! test/java/nio/channels/SocketChannel/ConnectState.java ! test/java/nio/channels/SocketChannel/FinishConnect.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/Stream.java ! test/java/nio/channels/SocketChannel/VectorParams.java + test/java/nio/channels/TestServers.java ! test/java/nio/channels/TestUtil.java Changeset: 7d50ff0e2d44 Author: coffeys Date: 2012-11-07 18:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d50ff0e2d44 8002227: (tz) Support tzdata2012i Reviewed-by: peytoia, asaha ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! makefiles/GendataTimeZone.gmk Changeset: f51943263267 Author: andrew Date: 2012-11-07 16:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f51943263267 8003120: ResourceManager.getApplicationResources() does not close InputStreams Summary: Add finally blocks to close the InputStream instances Reviewed-by: lancea ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: cc325832469c Author: naoto Date: 2012-11-07 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc325832469c 8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation 8001562: Collator.getAvailableLocales() doesn't return all locales for which localized instances are available Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + test/java/util/Locale/Bug8001562.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java Changeset: 599f231cba97 Author: jfranck Date: 2012-11-07 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/599f231cba97 8001598: Augment ElementType enum for JSR 308 Reviewed-by: darcy ! src/share/classes/java/lang/annotation/ElementType.java Changeset: cdf02b372956 Author: sherman Date: 2012-11-07 20:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cdf02b372956 6282196: There should be Math.mod(number, modulo) methods Summary: added the requested methods Reviewed-by: darcy, emcmanus, alanb Contributed-by: roger.riggs at oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/DivModTests.java Changeset: 1e7dd9e05ce2 Author: mullan Date: 2012-11-08 12:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1e7dd9e05ce2 7198416: CertificateIssuerName and CertificateSubjectName are redundant Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/security/x509/certAttributes.html ! test/sun/security/pkcs11/rsa/GenKeyStore.java ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/rsa/GenKeyStore.java Changeset: 9edfa0e761b9 Author: xuelei Date: 2012-11-09 01:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9edfa0e761b9 8001569: Regression test GetPeerHost uses static port number Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java Changeset: 220d2458ce4b Author: lana Date: 2012-11-09 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/220d2458ce4b Merge Changeset: 3717bcf9d7a7 Author: dholmes Date: 2012-11-07 23:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3717bcf9d7a7 8002040: Allow Full Debug Symbols when cross-compiling Reviewed-by: dcubed, erikj, tbell ! make/common/Defs-linux.gmk Changeset: 1e79fec4a01f Author: ohrstrom Date: 2012-11-08 12:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1e79fec4a01f 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 170e8ccfbc4f Author: tbell Date: 2012-11-12 10:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/170e8ccfbc4f 8002365: build-infra: Build-infra fails on solaris 11.1 on sparc. Summary: Add '-lc' to LDFLAGS for native libraries in CompileNativeLibraries.gmk Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileNativeLibraries.gmk Changeset: 2fc142843a93 Author: tbell Date: 2012-11-12 10:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2fc142843a93 8003177: build-infra: Compare reports diff in LocaleDataMetaInfo.class Summary: Remove spurious space in the locale lists Reviewed-by: naoto, ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcLocaleDataMetaInfo.gmk Changeset: e9e8a5852690 Author: tbell Date: 2012-11-12 12:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e9e8a5852690 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/Import.gmk Changeset: 84f0439ccaab Author: tbell Date: 2012-11-13 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84f0439ccaab 8001965: build-infra: Large compare diffs between new and old on mac Summary: The wrong icon source file was used when building closed Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcIcons.gmk Changeset: 130d3a54d28b Author: katleman Date: 2012-11-14 12:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/130d3a54d28b Merge Changeset: c87df8b1f55e Author: katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c87df8b1f55e Added tag jdk8-b65 for changeset 130d3a54d28b ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:41:52 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:41:52 +0000 Subject: hg: hsx/hotspot-main/langtools: 16 new changesets Message-ID: <20121116094233.5E6FB479EA@hg.openjdk.java.net> Changeset: 2443d24d096a Author: vromero Date: 2012-11-01 13:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2443d24d096a 6949443: visitTree assertion triggered using -Xjcov on small sample program Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java + test/tools/javac/options/T6949443.java Changeset: a33770a91b00 Author: jjg Date: 2012-11-02 19:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a33770a91b00 Merge Changeset: ef3ad754f5c7 Author: jjg Date: 2012-11-03 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ef3ad754f5c7 8002146: javadoc doesn't release resources in a timely manner Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: 352d130c47c5 Author: jjg Date: 2012-11-03 21:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/352d130c47c5 8002168: Cleanup initialization of javadoc Messager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Start.java ! test/tools/javadoc/6958836/Test.java Changeset: d7d932236fee Author: mcimadamore Date: 2012-11-04 10:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d7d932236fee 7192246: Add type-checking support for default methods Summary: Add type-checking support for default methods as per Featherweight-Defender document Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java + test/tools/javac/defaultMethods/ClassReaderTest/pkg/Foo.java + test/tools/javac/defaultMethods/Neg01.java + test/tools/javac/defaultMethods/Neg01.out + test/tools/javac/defaultMethods/Neg02.java + test/tools/javac/defaultMethods/Neg02.out + test/tools/javac/defaultMethods/Neg03.java + test/tools/javac/defaultMethods/Neg03.out + test/tools/javac/defaultMethods/Neg04.java + test/tools/javac/defaultMethods/Neg04.out + test/tools/javac/defaultMethods/Neg05.java + test/tools/javac/defaultMethods/Neg05.out + test/tools/javac/defaultMethods/Neg06.java + test/tools/javac/defaultMethods/Neg06.out + test/tools/javac/defaultMethods/Neg07.java + test/tools/javac/defaultMethods/Neg07.out + test/tools/javac/defaultMethods/Neg08.java + test/tools/javac/defaultMethods/Neg08.out + test/tools/javac/defaultMethods/Neg09.java + test/tools/javac/defaultMethods/Neg09.out + test/tools/javac/defaultMethods/Neg10.java + test/tools/javac/defaultMethods/Neg10.out + test/tools/javac/defaultMethods/Neg11.java + test/tools/javac/defaultMethods/Neg11.out + test/tools/javac/defaultMethods/Neg12.java + test/tools/javac/defaultMethods/Neg12.out + test/tools/javac/defaultMethods/Neg13.java + test/tools/javac/defaultMethods/Neg13.out + test/tools/javac/defaultMethods/Neg14.java + test/tools/javac/defaultMethods/Neg14.out + test/tools/javac/defaultMethods/Neg15.java + test/tools/javac/defaultMethods/Neg15.out + test/tools/javac/defaultMethods/Neg16.java + test/tools/javac/defaultMethods/Neg16.out + test/tools/javac/defaultMethods/Pos01.java + test/tools/javac/defaultMethods/Pos02.java + test/tools/javac/defaultMethods/Pos04.java + test/tools/javac/defaultMethods/Pos05.java + test/tools/javac/defaultMethods/Pos06.java + test/tools/javac/defaultMethods/Pos07.java + test/tools/javac/defaultMethods/Pos08.java + test/tools/javac/defaultMethods/Pos10.java + test/tools/javac/defaultMethods/Pos11.java + test/tools/javac/defaultMethods/Pos12.java + test/tools/javac/defaultMethods/Pos13.java + test/tools/javac/defaultMethods/Pos14.java + test/tools/javac/defaultMethods/Pos15.java + test/tools/javac/defaultMethods/Pos16.java + test/tools/javac/defaultMethods/TestDefaultBody.java + test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java + test/tools/javac/defaultMethods/crossCompile/Clinit.java + test/tools/javac/defaultMethods/crossCompile/CrossCompile.java + test/tools/javac/defaultMethods/fd/FDTest.java + test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java + test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java + test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java + test/tools/javac/defaultMethods/fd/shapegen/Rule.java + test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java + test/tools/javac/defaultMethods/fd/shapegen/TTNode.java + test/tools/javac/defaultMethods/fd/shapegen/TTParser.java + test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/defaultMethods/separate/Separate.java + test/tools/javac/defaultMethods/separate/pkg1/A.java + test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java + test/tools/javac/diags/examples/DefaultOverridesObjectMember.java + test/tools/javac/diags/examples/OverriddenDefault.java + test/tools/javac/diags/examples/RedundantSupertype.java + test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java + test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/generics/7022054/T7022054pos1.java ! test/tools/javac/generics/7022054/T7022054pos2.java ! test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: dbc94b8363dd Author: mcimadamore Date: 2012-11-04 11:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dbc94b8363dd 8000931: Cleanup Resolve.java Summary: Unify all method resolution routines Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/resolve/tests/AmbiguityPrecedence.java Changeset: 9bce0c73583d Author: ksrini Date: 2012-10-31 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9bce0c73583d 8001112: Make -target 8 in javac generate version 52.0 classfile Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/check.sh Changeset: 9b85813d2262 Author: mcimadamore Date: 2012-11-06 14:45 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9b85813d2262 8002286: Regression: Fix for 8000931 causes a JCK test failure Summary: Wrong type used as 'site' in Resolve.resolveMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/8002286/T8002286.java + test/tools/javac/8002286/T8002286.out Changeset: 8abc56be3131 Author: jjg Date: 2012-11-06 14:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8abc56be3131 8000612: Discrepancy between resources provided in javadoc resource files and resources required by code Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! test/tools/javac/diags/CheckResourceKeys.java + test/tools/javadoc/CheckResourceKeys.java Changeset: 55a007aaf63d Author: jjg Date: 2012-11-06 17:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/55a007aaf63d 7198690: missing compiler message Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: 6dc8616cea9b Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6dc8616cea9b Merge Changeset: 19d6ba779759 Author: vromero Date: 2012-11-05 16:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/19d6ba779759 8000484: Bad error recovery when 'catch' without 'try' is found Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/incompleteStatements/T8000484.java + test/tools/javac/incompleteStatements/T8000484.out Changeset: 2986e7052952 Author: jjg Date: 2012-11-07 17:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2986e7052952 8002157: Write combo compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java Changeset: a1dc543483fc Author: jjg Date: 2012-11-07 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a1dc543483fc 8003134: CheckResourceKeys issues Reviewed-by: jjh, bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javadoc/CheckResourceKeys.java Changeset: 5f2faba89cac Author: lana Date: 2012-11-09 14:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5f2faba89cac Merge Changeset: b5d326a809a1 Author: katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b5d326a809a1 Added tag jdk8-b65 for changeset 5f2faba89cac ! .hgtags From nils.eliasson at oracle.com Fri Nov 16 05:15:30 2012 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Fri, 16 Nov 2012 13:15:30 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20121116131545.F30F447A07@hg.openjdk.java.net> Changeset: bd7a7ce2e264 Author: minqi Date: 2012-11-12 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bd7a7ce2e264 6830717: replay of compilations would help with debugging Summary: When java process crashed in compiler thread, repeat the compilation process will help finding root cause. This is done with using SA dump application class data and replay data from core dump, then use debug version of jvm to recompile the problematic java method. Reviewed-by: kvn, twisti, sspitsyn Contributed-by: yumin.qi at oracle.com + agent/doc/c2replay.html ! agent/doc/clhsdb.html ! agent/doc/index.html ! agent/make/Makefile ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp + src/share/vm/ci/ciReplay.cpp + src/share/vm/ci/ciReplay.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/vmError.cpp Changeset: bb33c6fdcf0d Author: bharadwaj Date: 2012-11-15 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bb33c6fdcf0d 8001077: remove ciMethod::will_link Summary: Removed will_link and changed all calls to is_loaded(). Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/doCall.cpp Changeset: 6b6ddf8c4329 Author: neliasso Date: 2012-11-16 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b6ddf8c4329 Merge From karen.kinnear at oracle.com Fri Nov 16 05:16:16 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 16 Nov 2012 08:16:16 -0500 Subject: Code review request: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) In-Reply-To: <50A56AEB.9070607@oracle.com> References: <50A56AEB.9070607@oracle.com> Message-ID: Code looks good. thanks, Karen On Nov 15, 2012, at 5:21 PM, Zhengyu Gu wrote: > The assertion is to check that there is not more committed region within the memory region to be released, so the check to be applied to the reserved region that is going to be released, but not whole region, when the region to be released is only a segment within the region. > > > http://cr.openjdk.java.net/~zgu/8003487/webrev.00/ > > Thanks, > > -Zhengyu From coleen.phillimore at oracle.com Fri Nov 16 05:43:33 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Nov 2012 08:43:33 -0500 Subject: Code review request: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) In-Reply-To: <50A56AEB.9070607@oracle.com> References: <50A56AEB.9070607@oracle.com> Message-ID: <50A64305.7090807@oracle.com> Looks good. thanks, Coleen On 11/15/2012 5:21 PM, Zhengyu Gu wrote: > The assertion is to check that there is not more committed region > within the memory region to be released, so the check to be applied to > the reserved region that is going to be released, but not whole > region, when the region to be released is only a segment within the > region. > > > http://cr.openjdk.java.net/~zgu/8003487/webrev.00/ > > Thanks, > > -Zhengyu From coleen.phillimore at oracle.com Fri Nov 16 09:24:37 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 16 Nov 2012 17:24:37 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20121116172501.9113447A0D@hg.openjdk.java.net> Changeset: 64812523d72e Author: sspitsyn Date: 2012-10-31 16:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/64812523d72e 7194607: VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge Summary: Use verifier_max_size instead of max_size to get code attribute max stack size. Reviewed-by: dcubed, minqi Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 8aaef2cee3b2 Author: minqi Date: 2012-11-08 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8aaef2cee3b2 Merge ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: ed8b1e39ff4f Author: zgu Date: 2012-11-09 11:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed8b1e39ff4f 8002273: NMT to report JNI memory leaks when -Xcheck:jni is on Summary: Allows NMT to report that JNI thread failed to detach from JVM before exiting, which leaks the JavaThread object when check:jni option is on. Reviewed-by: acorn, dholmes, coleenp, ctornqvi ! src/share/vm/services/memSnapshot.cpp Changeset: 4efcd79826f2 Author: zgu Date: 2012-11-09 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4efcd79826f2 Merge Changeset: fb3190e77d3c Author: zgu Date: 2012-11-09 19:24 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fb3190e77d3c 8001592: NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 Summary: Fixed NMT that miscounted arena memory when it is used as value or stack object. Reviewed-by: acorn, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.hpp Changeset: e26ce0e8b666 Author: zgu Date: 2012-11-09 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e26ce0e8b666 Merge Changeset: 8c413497f434 Author: zgu Date: 2012-11-09 22:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8c413497f434 Merge ! src/share/vm/services/memSnapshot.cpp Changeset: e4f764ddb06a Author: hseigel Date: 2012-11-12 15:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e4f764ddb06a 7122219: Passed StringTableSize value not verified Summary: Check that the values specified for -XX:StringTableSize are within a certain range. Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 070d523b96a7 Author: hseigel Date: 2012-11-12 16:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/070d523b96a7 8001471: Klass::cast() does nothing Summary: Remove function Klass::cast() and calls to it. Reviewed-by: dholmes, coleenp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/serviceUtil.hpp Changeset: 24e193d2a007 Author: coleenp Date: 2012-11-13 15:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24e193d2a007 Merge Changeset: 80e866b1d053 Author: coleenp Date: 2012-11-16 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/80e866b1d053 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp From joseph.provino at oracle.com Fri Nov 16 11:24:44 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 16 Nov 2012 14:24:44 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer Message-ID: <50A692FC.3060704@oracle.com> This is a small change to one file -- arguments.cpp -- to print an error message and exit if INCLUDE_MANAGEMENT is false. Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ thanks. joe From alejandro.murillo at oracle.com Fri Nov 16 11:46:27 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 16 Nov 2012 19:46:27 +0000 Subject: hg: hsx/hsx25/hotspot: 24 new changesets Message-ID: <20121116194720.245D347A16@hg.openjdk.java.net> Changeset: 4e3e685dbc9d Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4e3e685dbc9d Added tag jdk8-b65 for changeset 0f7290a03b24 ! .hgtags Changeset: 3be318ecfae5 Author: amurillo Date: 2012-11-09 08:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3be318ecfae5 8003231: new hotspot build - hs25-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6cb0d32b828b Author: bpittore Date: 2012-11-07 17:53 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6cb0d32b828b 8001185: parsing of sun.boot.library.path in os::dll_build_name somewhat broken Summary: dll_dir can contain multiple paths, need to parse them correctly when loading agents Reviewed-by: dholmes, dlong Contributed-by: bill.pittore at oracle.com ! 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/classfile/classLoader.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: d9a84e246cce Author: cjplummer Date: 2012-11-09 09:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d9a84e246cce Merge ! src/share/vm/runtime/thread.cpp Changeset: 429994fc0754 Author: cjplummer Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/429994fc0754 Merge Changeset: 6bc207d87e5d Author: mgerdin Date: 2012-11-09 00:38 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6bc207d87e5d 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java Summary: Reduce the amount of calls to ChunkManager verification code Reviewed-by: jmasa, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 0400886d2613 Author: coleenp Date: 2012-11-14 22:37 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0400886d2613 8003259: NPG: Build with gcc 4.7.2 broken by 7045397 Summary: Qualify calls with this pointers to make gcc accept this code. Reviewed-by: coleenp, andrew Contributed-by: peter.levart at gmail.com ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: c5d4acbb943d Author: johnc Date: 2012-11-15 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c5d4acbb943d Merge Changeset: bd7a7ce2e264 Author: minqi Date: 2012-11-12 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bd7a7ce2e264 6830717: replay of compilations would help with debugging Summary: When java process crashed in compiler thread, repeat the compilation process will help finding root cause. This is done with using SA dump application class data and replay data from core dump, then use debug version of jvm to recompile the problematic java method. Reviewed-by: kvn, twisti, sspitsyn Contributed-by: yumin.qi at oracle.com + agent/doc/c2replay.html ! agent/doc/clhsdb.html ! agent/doc/index.html ! agent/make/Makefile ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp + src/share/vm/ci/ciReplay.cpp + src/share/vm/ci/ciReplay.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/vmError.cpp Changeset: bb33c6fdcf0d Author: bharadwaj Date: 2012-11-15 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bb33c6fdcf0d 8001077: remove ciMethod::will_link Summary: Removed will_link and changed all calls to is_loaded(). Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/doCall.cpp Changeset: 6b6ddf8c4329 Author: neliasso Date: 2012-11-16 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b6ddf8c4329 Merge Changeset: 64812523d72e Author: sspitsyn Date: 2012-10-31 16:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/64812523d72e 7194607: VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge Summary: Use verifier_max_size instead of max_size to get code attribute max stack size. Reviewed-by: dcubed, minqi Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 8aaef2cee3b2 Author: minqi Date: 2012-11-08 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8aaef2cee3b2 Merge ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: ed8b1e39ff4f Author: zgu Date: 2012-11-09 11:04 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ed8b1e39ff4f 8002273: NMT to report JNI memory leaks when -Xcheck:jni is on Summary: Allows NMT to report that JNI thread failed to detach from JVM before exiting, which leaks the JavaThread object when check:jni option is on. Reviewed-by: acorn, dholmes, coleenp, ctornqvi ! src/share/vm/services/memSnapshot.cpp Changeset: 4efcd79826f2 Author: zgu Date: 2012-11-09 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4efcd79826f2 Merge Changeset: fb3190e77d3c Author: zgu Date: 2012-11-09 19:24 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fb3190e77d3c 8001592: NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 Summary: Fixed NMT that miscounted arena memory when it is used as value or stack object. Reviewed-by: acorn, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.hpp Changeset: e26ce0e8b666 Author: zgu Date: 2012-11-09 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e26ce0e8b666 Merge Changeset: 8c413497f434 Author: zgu Date: 2012-11-09 22:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8c413497f434 Merge ! src/share/vm/services/memSnapshot.cpp Changeset: e4f764ddb06a Author: hseigel Date: 2012-11-12 15:58 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e4f764ddb06a 7122219: Passed StringTableSize value not verified Summary: Check that the values specified for -XX:StringTableSize are within a certain range. Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 070d523b96a7 Author: hseigel Date: 2012-11-12 16:15 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/070d523b96a7 8001471: Klass::cast() does nothing Summary: Remove function Klass::cast() and calls to it. Reviewed-by: dholmes, coleenp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/serviceUtil.hpp Changeset: 24e193d2a007 Author: coleenp Date: 2012-11-13 15:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/24e193d2a007 Merge Changeset: 80e866b1d053 Author: coleenp Date: 2012-11-16 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/80e866b1d053 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp Changeset: cfc5309f03b7 Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cfc5309f03b7 Merge Changeset: 01684f7fee1b Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/01684f7fee1b Added tag hs25-b10 for changeset cfc5309f03b7 ! .hgtags From dmitry.samersoff at oracle.com Fri Nov 16 12:14:04 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 17 Nov 2012 00:14:04 +0400 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A692FC.3060704@oracle.com> References: <50A692FC.3060704@oracle.com> Message-ID: <50A69E8C.7010109@oracle.com> Joe, After you fix at 2788 regular hotspot start accepting do-nothing option -XX:+ManagementServer Is it intentional? -Dmitry On 2012-11-16 23:24, Joe Provino wrote: > This is a small change to one file -- arguments.cpp -- to print an error > message > and exit if INCLUDE_MANAGEMENT is false. > > Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ > > thanks. > > joe -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From joseph.provino at oracle.com Fri Nov 16 12:20:07 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 16 Nov 2012 15:20:07 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A69E8C.7010109@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> Message-ID: <50A69FF7.3060205@oracle.com> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: > Joe, > > After you fix at 2788 regular hotspot start accepting do-nothing option > > -XX:+ManagementServer > > Is it intentional? Hi Dmitry, I added the "} else if" at 2788 before the "} else if (match_option(option, "-XX:+ManagementServer", &tail)) {" that was already there. I'm not sure I understand the problem. joe > -Dmitry > > > On 2012-11-16 23:24, Joe Provino wrote: >> This is a small change to one file -- arguments.cpp -- to print an error >> message >> and exit if INCLUDE_MANAGEMENT is false. >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >> >> thanks. >> >> joe > From joseph.provino at oracle.com Fri Nov 16 12:23:54 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 16 Nov 2012 15:23:54 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A69E8C.7010109@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> Message-ID: <50A6A0DA.7020702@oracle.com> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is set to true, then there's no code generated. I think the code that's there will work but perhaps there's a better place to check for this option when INCLUDE_MANAGEMENT is false. I seem to recall there's a place were -XX: arguments are parsed But I don't see a separate method to do that. I must be looking in the wrong place. joe On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: > Joe, > > After you fix at 2788 regular hotspot start accepting do-nothing option > > -XX:+ManagementServer > > Is it intentional? > > -Dmitry > > > On 2012-11-16 23:24, Joe Provino wrote: >> This is a small change to one file -- arguments.cpp -- to print an error >> message >> and exit if INCLUDE_MANAGEMENT is false. >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >> >> thanks. >> >> joe > From coleen.phillimore at oracle.com Fri Nov 16 12:33:03 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Nov 2012 15:33:03 -0500 Subject: New HSX Committer: Harold Seigel Message-ID: <50A6A2FF.2070309@oracle.com> I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel Votes are due by Nov 30, 2012. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Coleen Phillimore [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From bill.pittore at oracle.com Fri Nov 16 12:43:52 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Fri, 16 Nov 2012 15:43:52 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A69FF7.3060205@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A69FF7.3060205@oracle.com> Message-ID: <50A6A588.8030100@oracle.com> He's saying that if you have INCLUDE_MANAGEMENT defined then you end up with an empty if statement. Harmless but ugly. I think you need to include the 'else if (match_option(... -XX:+Manage...)' line inside your #if. Watch out for braces. bill On 11/16/2012 3:20 PM, Joe Provino wrote: > > > On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >> Joe, >> >> After you fix at 2788 regular hotspot start accepting do-nothing option >> >> -XX:+ManagementServer >> >> Is it intentional? > > Hi Dmitry, I added the "} else if" at 2788 before the "} else if > (match_option(option, "-XX:+ManagementServer", &tail)) {" > that was already there. I'm not sure I understand the problem. > > joe > >> -Dmitry >> >> >> On 2012-11-16 23:24, Joe Provino wrote: >>> This is a small change to one file -- arguments.cpp -- to print an >>> error >>> message >>> and exit if INCLUDE_MANAGEMENT is false. >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>> >>> thanks. >>> >>> joe >> From zhengyu.gu at oracle.com Fri Nov 16 12:58:50 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 16 Nov 2012 15:58:50 -0500 Subject: New HSX Committer: Harold Seigel In-Reply-To: <50A6A2FF.2070309@oracle.com> References: <50A6A2FF.2070309@oracle.com> Message-ID: <50A6A90A.80802@oracle.com> Vote: yes -Zhengyu On 11/16/2012 3:33 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From karen.kinnear at oracle.com Fri Nov 16 13:09:28 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 16 Nov 2012 16:09:28 -0500 Subject: New HSX Committer: Harold Seigel In-Reply-To: <50A6A2FF.2070309@oracle.com> References: <50A6A2FF.2070309@oracle.com> Message-ID: <6BD3402D-342B-4497-A746-58F443D66EAA@oracle.com> Vote: yes thanks, Karen On Nov 16, 2012, at 3:33 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From daniel.daugherty at oracle.com Fri Nov 16 13:10:22 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 16 Nov 2012 14:10:22 -0700 Subject: New HSX Committer: Harold Seigel In-Reply-To: <50A6A2FF.2070309@oracle.com> References: <50A6A2FF.2070309@oracle.com> Message-ID: <50A6ABBE.50404@oracle.com> Vote: yes Dan On 11/16/12 1:33 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From bill.pittore at oracle.com Fri Nov 16 13:13:50 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Fri, 16 Nov 2012 16:13:50 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A6A0DA.7020702@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> Message-ID: <50A6AC8E.1050008@oracle.com> Where you had it is the right place, you just need to #if it better. The -XX: options get process by the code just after line 2788 by process_argument(). That deals with all the globals defined in globals.hpp so it's not where you can special case one flag. bill On 11/16/2012 3:23 PM, Joe Provino wrote: > Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is > set to true, then there's no code generated. > > I think the code that's there will work but perhaps there's a better > place to check for this option when > INCLUDE_MANAGEMENT is false. > > I seem to recall there's a place were -XX: arguments are parsed But I > don't see a separate method to do that. > I must be looking in the wrong place. > > joe > > On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >> Joe, >> >> After you fix at 2788 regular hotspot start accepting do-nothing option >> >> -XX:+ManagementServer >> >> Is it intentional? >> >> -Dmitry >> >> >> On 2012-11-16 23:24, Joe Provino wrote: >>> This is a small change to one file -- arguments.cpp -- to print an >>> error >>> message >>> and exit if INCLUDE_MANAGEMENT is false. >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>> >>> thanks. >>> >>> joe >> From mandy.chung at oracle.com Fri Nov 16 13:29:16 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Nov 2012 13:29:16 -0800 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A6A588.8030100@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A69FF7.3060205@oracle.com> <50A6A588.8030100@oracle.com> Message-ID: <50A6B02C.1060501@oracle.com> What about defining a new non_minimal_product flag (or whatever name) for VM flags that only present in a non minimal VM? i.e. in globals.hpp non_minimal_product(bool, ManagementServer, false, \ "Create JMX Management Server") \ This would avoid the need to add L2788-2792 for any flag that are not supported in the minimal VM (one for each). Mandy On 11/16/12 12:43 PM, BILL PITTORE wrote: > He's saying that if you have INCLUDE_MANAGEMENT defined then you end > up with an empty if statement. Harmless but ugly. I think you need to > include the 'else if (match_option(... -XX:+Manage...)' line inside > your #if. Watch out for braces. > > bill > > > > On 11/16/2012 3:20 PM, Joe Provino wrote: >> >> >> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>> Joe, >>> >>> After you fix at 2788 regular hotspot start accepting do-nothing option >>> >>> -XX:+ManagementServer >>> >>> Is it intentional? >> >> Hi Dmitry, I added the "} else if" at 2788 before the "} else if >> (match_option(option, "-XX:+ManagementServer", &tail)) {" >> that was already there. I'm not sure I understand the problem. >> >> joe >> >>> -Dmitry >>> >>> >>> On 2012-11-16 23:24, Joe Provino wrote: >>>> This is a small change to one file -- arguments.cpp -- to print an >>>> error >>>> message >>>> and exit if INCLUDE_MANAGEMENT is false. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>> >>>> thanks. >>>> >>>> joe >>> > > From vladimir.x.ivanov at oracle.com Fri Nov 16 14:33:05 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 17 Nov 2012 01:33:05 +0300 Subject: New HSX Committer: Harold Seigel In-Reply-To: <50A6ABBE.50404@oracle.com> References: <50A6A2FF.2070309@oracle.com> <50A6ABBE.50404@oracle.com> Message-ID: <50A6BF21.3060509@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 11/17/12 12:10 AM, Daniel D. Daugherty wrote: > Vote: yes > > Dan > > > On 11/16/12 1:33 PM, Coleen Phillimore wrote: >> I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX >> Committer. >> >> Harold is a member of the Hotspot runtime group. He has contributed 10 >> changesets to the HSX project and he is qualified to be committer [1]: >> >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com >> >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel >> >> Votes are due by Nov 30, 2012. >> >> Only current HSX Committers [2] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Coleen Phillimore >> >> [1]http://openjdk.java.net/projects/#project-committer >> [2]http://openjdk.java.net/census#hsx >> [3]http://openjdk.java.net/projects#committer-vote >> > From coleen.phillimore at oracle.com Fri Nov 16 13:34:32 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Nov 2012 16:34:32 -0500 Subject: CFV: New HSX Committer: Harold Seigel Message-ID: <50A6B168.60000@oracle.com> I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel Votes are due by Nov 30, 2012. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Coleen Phillimore [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote (resend with corrected title, please reply again) From alejandro.murillo at oracle.com Fri Nov 16 13:40:18 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 16 Nov 2012 21:40:18 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20121116214028.C02F047A1C@hg.openjdk.java.net> Changeset: 4e3e685dbc9d Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4e3e685dbc9d Added tag jdk8-b65 for changeset 0f7290a03b24 ! .hgtags Changeset: cfc5309f03b7 Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cfc5309f03b7 Merge Changeset: 01684f7fee1b Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/01684f7fee1b Added tag hs25-b10 for changeset cfc5309f03b7 ! .hgtags Changeset: e1d42ba865de Author: amurillo Date: 2012-11-16 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e1d42ba865de 8003541: new hotspot build - hs25-b11 Reviewed-by: jcoomes ! make/hotspot_version From coleen.phillimore at oracle.com Fri Nov 16 13:49:06 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Nov 2012 16:49:06 -0500 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A6B4D2.20104@oracle.com> Vote: yes On 11/16/2012 4:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From alejandro.murillo at oracle.com Fri Nov 16 14:03:47 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 16 Nov 2012 15:03:47 -0700 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A6B843.4020201@oracle.com> Vote: yes On 11/16/2012 2:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From joseph.provino at oracle.com Fri Nov 16 14:07:04 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 16 Nov 2012 17:07:04 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A6A588.8030100@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A69FF7.3060205@oracle.com> <50A6A588.8030100@oracle.com> Message-ID: <50A6B908.3020108@oracle.com> Okay, I see what you mean. joe On 11/16/2012 03:43 PM, BILL PITTORE wrote: > He's saying that if you have INCLUDE_MANAGEMENT defined then you end > up with an empty if statement. Harmless but ugly. I think you need to > include the 'else if (match_option(... -XX:+Manage...)' line inside > your #if. Watch out for braces. > > bill > > > > On 11/16/2012 3:20 PM, Joe Provino wrote: >> >> >> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>> Joe, >>> >>> After you fix at 2788 regular hotspot start accepting do-nothing option >>> >>> -XX:+ManagementServer >>> >>> Is it intentional? >> >> Hi Dmitry, I added the "} else if" at 2788 before the "} else if >> (match_option(option, "-XX:+ManagementServer", &tail)) {" >> that was already there. I'm not sure I understand the problem. >> >> joe >> >>> -Dmitry >>> >>> >>> On 2012-11-16 23:24, Joe Provino wrote: >>>> This is a small change to one file -- arguments.cpp -- to print an >>>> error >>>> message >>>> and exit if INCLUDE_MANAGEMENT is false. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>> >>>> thanks. >>>> >>>> joe >>> > > From joseph.provino at oracle.com Fri Nov 16 14:08:22 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Fri, 16 Nov 2012 17:08:22 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A6B02C.1060501@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A69FF7.3060205@oracle.com> <50A6A588.8030100@oracle.com> <50A6B02C.1060501@oracle.com> Message-ID: <50A6B956.1030500@oracle.com> On 11/16/2012 04:29 PM, Mandy Chung wrote: > What about defining a new non_minimal_product flag (or whatever name) > for VM flags that only present in a non minimal VM? i.e. in globals.hpp > > non_minimal_product(bool, ManagementServer, > false, \ > "Create JMX Management > Server") \ > > > > This would avoid the need to add L2788-2792 for any flag that are not > supported in the minimal VM (one for each). Mandy, that's an interesting idea. arguments.cpp is getting cluttered with conditionals and maybe that's a way to fix that. joe > > Mandy > > On 11/16/12 12:43 PM, BILL PITTORE wrote: >> He's saying that if you have INCLUDE_MANAGEMENT defined then you end >> up with an empty if statement. Harmless but ugly. I think you need to >> include the 'else if (match_option(... -XX:+Manage...)' line inside >> your #if. Watch out for braces. >> >> bill >> >> >> >> On 11/16/2012 3:20 PM, Joe Provino wrote: >>> >>> >>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>> Joe, >>>> >>>> After you fix at 2788 regular hotspot start accepting do-nothing >>>> option >>>> >>>> -XX:+ManagementServer >>>> >>>> Is it intentional? >>> >>> Hi Dmitry, I added the "} else if" at 2788 before the "} else if >>> (match_option(option, "-XX:+ManagementServer", &tail)) {" >>> that was already there. I'm not sure I understand the problem. >>> >>> joe >>> >>>> -Dmitry >>>> >>>> >>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>> error >>>>> message >>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>> >>>>> thanks. >>>>> >>>>> joe >>>> >> >> > From vladimir.x.ivanov at oracle.com Fri Nov 16 15:14:50 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 17 Nov 2012 02:14:50 +0300 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A6C8EA.6020602@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 11/17/12 12:34 AM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From Vladimir.Kozlov at oracle.com Fri Nov 16 14:38:37 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Nov 2012 14:38:37 -0800 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A6C06D.9080506@oracle.com> Vote: yes On 11/16/12 13:34, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From John.Coomes at oracle.com Fri Nov 16 16:08:05 2012 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 16 Nov 2012 16:08:05 -0800 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <20646.54629.84864.865342@oracle.com> Vote: yes -John From dean.long at oracle.com Fri Nov 16 16:29:39 2012 From: dean.long at oracle.com (Dean Long) Date: Fri, 16 Nov 2012 16:29:39 -0800 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <20646.54629.84864.865342@oracle.com> References: <50A6B168.60000@oracle.com> <20646.54629.84864.865342@oracle.com> Message-ID: <50A6DA73.5070804@oracle.com> Vote: yes dl From daniel.daugherty at oracle.com Fri Nov 16 17:50:47 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 16 Nov 2012 18:50:47 -0700 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A6ED77.2080006@oracle.com> Vote: yes Dan On 11/16/12 2:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) > From chris.plummer at oracle.com Fri Nov 16 18:29:52 2012 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 16 Nov 2012 18:29:52 -0800 Subject: hotspot-dev Digest, Vol 67, Issue 27 In-Reply-To: References: Message-ID: <50A6F6A0.5050104@oracle.com> On 11/16/12 2:15 PM, hotspot-dev-request at openjdk.java.net wrote: > Message: 8 > Date: Fri, 16 Nov 2012 17:08:22 -0500 > From: Joe Provino > Subject: Re: Review request: JDK-8003539 -- Minimal VM. VM doesn't > react to -Dcom.sun.management and -XX:+ManagementServer > To:hotspot-dev at openjdk.java.net > Message-ID:<50A6B956.1030500 at oracle.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 11/16/2012 04:29 PM, Mandy Chung wrote: >> >What about defining a new non_minimal_product flag (or whatever name) >> >for VM flags that only present in a non minimal VM? i.e. in globals.hpp >> > >> > non_minimal_product(bool, ManagementServer, >> >false, \ >> > "Create JMX Management >> >Server") \ >> > >> > >> > >> >This would avoid the need to add L2788-2792 for any flag that are not >> >supported in the minimal VM (one for each). > Mandy, that's an interesting idea. arguments.cpp is getting cluttered > with conditionals and maybe > that's a way to fix that. The problem with this solution is that the absence of this flag needs to be associated with INCLUDE_MANAGEMENT=0, not with the MinimalVM. Otherwise we'd just have #ifdef MINIMALVM all over the source rather than the more selective #if INCLUDE_XXX. Thus instead of non_minimal_product, what you need is include_management_product, or something like that. And you would need this for each INCLUDE_XXX flag that has an effect on available command line options. Whether or not that is a good idea depends on how many options and how many INCLUDE_XXX flags we are talking about. Chris > joe > >> > >> >Mandy From david.holmes at oracle.com Fri Nov 16 18:30:56 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Nov 2012 12:30:56 +1000 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A6B956.1030500@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A69FF7.3060205@oracle.com> <50A6A588.8030100@oracle.com> <50A6B02C.1060501@oracle.com> <50A6B956.1030500@oracle.com> Message-ID: <50A6F6E0.1070706@oracle.com> On 17/11/2012 8:08 AM, Joe Provino wrote: > On 11/16/2012 04:29 PM, Mandy Chung wrote: >> What about defining a new non_minimal_product flag (or whatever name) >> for VM flags that only present in a non minimal VM? i.e. in globals.hpp >> >> non_minimal_product(bool, ManagementServer, false, \ >> "Create JMX Management Server") \ >> >> >> >> This would avoid the need to add L2788-2792 for any flag that are not >> supported in the minimal VM (one for each). > > Mandy, that's an interesting idea. arguments.cpp is getting cluttered > with conditionals and maybe that's a way to fix that. Except that simply makes the flags non-existent and what we want is to trap that the user set the flag and tell them that they can't have it. Two different goals. You could also be using the UNSUPPORTED_OPTION macro. David > > joe > >> >> Mandy >> >> On 11/16/12 12:43 PM, BILL PITTORE wrote: >>> He's saying that if you have INCLUDE_MANAGEMENT defined then you end >>> up with an empty if statement. Harmless but ugly. I think you need to >>> include the 'else if (match_option(... -XX:+Manage...)' line inside >>> your #if. Watch out for braces. >>> >>> bill >>> >>> >>> >>> On 11/16/2012 3:20 PM, Joe Provino wrote: >>>> >>>> >>>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>>> Joe, >>>>> >>>>> After you fix at 2788 regular hotspot start accepting do-nothing >>>>> option >>>>> >>>>> -XX:+ManagementServer >>>>> >>>>> Is it intentional? >>>> >>>> Hi Dmitry, I added the "} else if" at 2788 before the "} else if >>>> (match_option(option, "-XX:+ManagementServer", &tail)) {" >>>> that was already there. I'm not sure I understand the problem. >>>> >>>> joe >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>>> error >>>>>> message >>>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>>> >>>>>> thanks. >>>>>> >>>>>> joe >>>>> >>> >>> >> > From david.holmes at oracle.com Fri Nov 16 21:18:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Nov 2012 15:18:47 +1000 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A71E37.80500@oracle.com> Vote: yes David On 17/11/2012 7:34 AM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From staffan.larsen at oracle.com Sun Nov 18 10:55:08 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 18 Nov 2012 19:55:08 +0100 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: Vote: yes. On 16 nov 2012, at 22:34, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From joseph.provino at oracle.com Sun Nov 18 13:31:50 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Sun, 18 Nov 2012 16:31:50 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A6AC8E.1050008@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> <50A6AC8E.1050008@oracle.com> Message-ID: <50A953C6.5080503@oracle.com> How does this look? http://cr.openjdk.java.net/~jprovino/8003539/webrev.01/ On 11/16/2012 4:13 PM, BILL PITTORE wrote: > Where you had it is the right place, you just need to #if it better. > The -XX: options get process by the code just after line 2788 by > process_argument(). That deals with all the globals defined in > globals.hpp so it's not where you can special case one flag. > > bill > > > > On 11/16/2012 3:23 PM, Joe Provino wrote: >> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is >> set to true, then there's no code generated. >> >> I think the code that's there will work but perhaps there's a better >> place to check for this option when >> INCLUDE_MANAGEMENT is false. >> >> I seem to recall there's a place were -XX: arguments are parsed But >> I don't see a separate method to do that. >> I must be looking in the wrong place. >> >> joe >> >> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>> Joe, >>> >>> After you fix at 2788 regular hotspot start accepting do-nothing option >>> >>> -XX:+ManagementServer >>> >>> Is it intentional? >>> >>> -Dmitry >>> >>> >>> On 2012-11-16 23:24, Joe Provino wrote: >>>> This is a small change to one file -- arguments.cpp -- to print an >>>> error >>>> message >>>> and exit if INCLUDE_MANAGEMENT is false. >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>> >>>> thanks. >>>> >>>> joe >>> > > From david.holmes at oracle.com Sun Nov 18 14:08:01 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Nov 2012 08:08:01 +1000 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A953C6.5080503@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> <50A6AC8E.1050008@oracle.com> <50A953C6.5080503@oracle.com> Message-ID: <50A95C41.3000207@oracle.com> Hi Joe, I think we should have utilized UNSUPPORTED_OPTION for those flags that have to be disabled and will generate a warning (eg all the GC warnings) - even if we have to augment the macro somewhat. Then we could have a second macro for the vm_exit_on_initialization case (though the distinction between a fatal error and a warning seems to be quite arbitrary :( ). Otherwise this change seems functionally correct, but the indentation appears wrong for the -Dcom.sun.management change. David On 19/11/2012 7:31 AM, Joe Provino wrote: > > How does this look? http://cr.openjdk.java.net/~jprovino/8003539/webrev.01/ > > On 11/16/2012 4:13 PM, BILL PITTORE wrote: >> Where you had it is the right place, you just need to #if it better. >> The -XX: options get process by the code just after line 2788 by >> process_argument(). That deals with all the globals defined in >> globals.hpp so it's not where you can special case one flag. >> >> bill >> >> >> >> On 11/16/2012 3:23 PM, Joe Provino wrote: >>> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is >>> set to true, then there's no code generated. >>> >>> I think the code that's there will work but perhaps there's a better >>> place to check for this option when >>> INCLUDE_MANAGEMENT is false. >>> >>> I seem to recall there's a place were -XX: arguments are parsed But I >>> don't see a separate method to do that. >>> I must be looking in the wrong place. >>> >>> joe >>> >>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>> Joe, >>>> >>>> After you fix at 2788 regular hotspot start accepting do-nothing option >>>> >>>> -XX:+ManagementServer >>>> >>>> Is it intentional? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>> error >>>>> message >>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>> >>>>> thanks. >>>>> >>>>> joe >>>> >> >> From joseph.provino at oracle.com Sun Nov 18 14:36:52 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Sun, 18 Nov 2012 17:36:52 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A95C41.3000207@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> <50A6AC8E.1050008@oracle.com> <50A953C6.5080503@oracle.com> <50A95C41.3000207@oracle.com> Message-ID: <50A96304.1050105@oracle.com> On 11/18/2012 5:08 PM, David Holmes wrote: > Hi Joe, > > I think we should have utilized UNSUPPORTED_OPTION for those flags > that have to be disabled and will generate a warning (eg all the GC > warnings) - even if we have to augment the macro somewhat. That sounds reasonable. Should I do that now or just make minimal changes? > Then we could have a second macro for the vm_exit_on_initialization > case (though the distinction between a fatal error and a warning seems > to be quite arbitrary :( ). Yeah, it's not entirely clear when we warn or exit. I do recall a discussion about how we should warn if the only impact is potentially performance and exit if something is likely to fail. Customers may have scripts that they'd like to continue to work as long as missing functionality won't prevent them from working. Maybe we should revisit this. > > Otherwise this change seems functionally correct, but the indentation > appears wrong for the -Dcom.sun.management change. Are you referring to line 2440? I looked at other calls to vm_exit_during_initialization and sometimes it's indented two spaces, other times four spaces. I agree they should all be done the same way. Is 2 spaces the standard for something like this? thanks for the review. joe > > David > > On 19/11/2012 7:31 AM, Joe Provino wrote: >> >> How does this look? >> http://cr.openjdk.java.net/~jprovino/8003539/webrev.01/ >> >> On 11/16/2012 4:13 PM, BILL PITTORE wrote: >>> Where you had it is the right place, you just need to #if it better. >>> The -XX: options get process by the code just after line 2788 by >>> process_argument(). That deals with all the globals defined in >>> globals.hpp so it's not where you can special case one flag. >>> >>> bill >>> >>> >>> >>> On 11/16/2012 3:23 PM, Joe Provino wrote: >>>> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is >>>> set to true, then there's no code generated. >>>> >>>> I think the code that's there will work but perhaps there's a better >>>> place to check for this option when >>>> INCLUDE_MANAGEMENT is false. >>>> >>>> I seem to recall there's a place were -XX: arguments are parsed But I >>>> don't see a separate method to do that. >>>> I must be looking in the wrong place. >>>> >>>> joe >>>> >>>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>>> Joe, >>>>> >>>>> After you fix at 2788 regular hotspot start accepting do-nothing >>>>> option >>>>> >>>>> -XX:+ManagementServer >>>>> >>>>> Is it intentional? >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>>> error >>>>>> message >>>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>>> >>>>>> thanks. >>>>>> >>>>>> joe >>>>> >>> >>> From david.holmes at oracle.com Sun Nov 18 15:03:54 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Nov 2012 09:03:54 +1000 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A96304.1050105@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> <50A6AC8E.1050008@oracle.com> <50A953C6.5080503@oracle.com> <50A95C41.3000207@oracle.com> <50A96304.1050105@oracle.com> Message-ID: <50A9695A.2090102@oracle.com> On 19/11/2012 8:36 AM, Joe Provino wrote: > On 11/18/2012 5:08 PM, David Holmes wrote: >> Hi Joe, >> >> I think we should have utilized UNSUPPORTED_OPTION for those flags >> that have to be disabled and will generate a warning (eg all the GC >> warnings) - even if we have to augment the macro somewhat. > > That sounds reasonable. Should I do that now or just make minimal changes? Just minimal for now. Perhaps take this up with the UseG1GC CR instead. >> Then we could have a second macro for the vm_exit_on_initialization >> case (though the distinction between a fatal error and a warning seems >> to be quite arbitrary :( ). > > Yeah, it's not entirely clear when we warn or exit. I do recall a > discussion about how we should warn if > the only impact is potentially performance and exit if something is > likely to fail. Customers may have scripts > that they'd like to continue to work as long as missing functionality > won't prevent them from working. Maybe we should revisit this. No that is the right distinction - I was just failing to make it. :) >> Otherwise this change seems functionally correct, but the indentation >> appears wrong for the -Dcom.sun.management change. > > Are you referring to line 2440? I looked at other calls to > vm_exit_during_initialization and sometimes > it's indented two spaces, other times four spaces. I agree they should > all be done the same way. Line 2439 - the call to vm_exit_... is inside the if statement so needs indenting as per line 2437. > Is 2 spaces the standard for something like this? Hotspot code indent is 2 spaces. How long lines get subsequently indented (ie 2440) does seem somewhat arbitrary. Thanks, David > thanks for the review. > > joe > >> >> David >> >> On 19/11/2012 7:31 AM, Joe Provino wrote: >>> >>> How does this look? >>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.01/ >>> >>> On 11/16/2012 4:13 PM, BILL PITTORE wrote: >>>> Where you had it is the right place, you just need to #if it better. >>>> The -XX: options get process by the code just after line 2788 by >>>> process_argument(). That deals with all the globals defined in >>>> globals.hpp so it's not where you can special case one flag. >>>> >>>> bill >>>> >>>> >>>> >>>> On 11/16/2012 3:23 PM, Joe Provino wrote: >>>>> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is >>>>> set to true, then there's no code generated. >>>>> >>>>> I think the code that's there will work but perhaps there's a better >>>>> place to check for this option when >>>>> INCLUDE_MANAGEMENT is false. >>>>> >>>>> I seem to recall there's a place were -XX: arguments are parsed But I >>>>> don't see a separate method to do that. >>>>> I must be looking in the wrong place. >>>>> >>>>> joe >>>>> >>>>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>>>> Joe, >>>>>> >>>>>> After you fix at 2788 regular hotspot start accepting do-nothing >>>>>> option >>>>>> >>>>>> -XX:+ManagementServer >>>>>> >>>>>> Is it intentional? >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>>>> error >>>>>>> message >>>>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>>>> >>>>>>> Webrev is here: >>>>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>>>> >>>>>>> thanks. >>>>>>> >>>>>>> joe >>>>>> >>>> >>>> From rickard.backman at oracle.com Sun Nov 18 22:10:58 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 19 Nov 2012 07:10:58 +0100 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: Vote: yes /R On Nov 16, 2012, at 10:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From dmitry.samersoff at oracle.com Sun Nov 18 23:28:50 2012 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 19 Nov 2012 11:28:50 +0400 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A953C6.5080503@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> <50A6AC8E.1050008@oracle.com> <50A953C6.5080503@oracle.com> Message-ID: <50A9DFB2.4040200@oracle.com> Joe, Looks good for me! -Dmitry On 2012-11-19 01:31, Joe Provino wrote: > > How does this look? > http://cr.openjdk.java.net/~jprovino/8003539/webrev.01/ > > On 11/16/2012 4:13 PM, BILL PITTORE wrote: >> Where you had it is the right place, you just need to #if it better. >> The -XX: options get process by the code just after line 2788 by >> process_argument(). That deals with all the globals defined in >> globals.hpp so it's not where you can special case one flag. >> >> bill >> >> >> >> On 11/16/2012 3:23 PM, Joe Provino wrote: >>> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is >>> set to true, then there's no code generated. >>> >>> I think the code that's there will work but perhaps there's a better >>> place to check for this option when >>> INCLUDE_MANAGEMENT is false. >>> >>> I seem to recall there's a place were -XX: arguments are parsed But >>> I don't see a separate method to do that. >>> I must be looking in the wrong place. >>> >>> joe >>> >>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>> Joe, >>>> >>>> After you fix at 2788 regular hotspot start accepting do-nothing option >>>> >>>> -XX:+ManagementServer >>>> >>>> Is it intentional? >>>> >>>> -Dmitry >>>> >>>> >>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>> error >>>>> message >>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>> >>>>> thanks. >>>>> >>>>> joe >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From bengt.rutisson at oracle.com Sun Nov 18 22:53:07 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 19 Nov 2012 07:53:07 +0100 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50A9D753.7000201@oracle.com> Vote: yes Bengt On 11/16/12 10:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From joseph.provino at oracle.com Mon Nov 19 06:17:09 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Mon, 19 Nov 2012 09:17:09 -0500 Subject: Review request: JDK-8003539 -- Minimal VM. VM doesn't react to -Dcom.sun.management and -XX:+ManagementServer In-Reply-To: <50A9695A.2090102@oracle.com> References: <50A692FC.3060704@oracle.com> <50A69E8C.7010109@oracle.com> <50A6A0DA.7020702@oracle.com> <50A6AC8E.1050008@oracle.com> <50A953C6.5080503@oracle.com> <50A95C41.3000207@oracle.com> <50A96304.1050105@oracle.com> <50A9695A.2090102@oracle.com> Message-ID: <50AA3F65.8060706@oracle.com> On 11/18/2012 06:03 PM, David Holmes wrote: > On 19/11/2012 8:36 AM, Joe Provino wrote: >> On 11/18/2012 5:08 PM, David Holmes wrote: >>> Hi Joe, >>> >>> I think we should have utilized UNSUPPORTED_OPTION for those flags >>> that have to be disabled and will generate a warning (eg all the GC >>> warnings) - even if we have to augment the macro somewhat. >> >> That sounds reasonable. Should I do that now or just make minimal >> changes? > > Just minimal for now. Perhaps take this up with the UseG1GC CR instead. > >>> Then we could have a second macro for the vm_exit_on_initialization >>> case (though the distinction between a fatal error and a warning seems >>> to be quite arbitrary :( ). >> >> Yeah, it's not entirely clear when we warn or exit. I do recall a >> discussion about how we should warn if >> the only impact is potentially performance and exit if something is >> likely to fail. Customers may have scripts >> that they'd like to continue to work as long as missing functionality >> won't prevent them from working. Maybe we should revisit this. > > No that is the right distinction - I was just failing to make it. :) > >>> Otherwise this change seems functionally correct, but the indentation >>> appears wrong for the -Dcom.sun.management change. >> >> Are you referring to line 2440? I looked at other calls to >> vm_exit_during_initialization and sometimes >> it's indented two spaces, other times four spaces. I agree they should >> all be done the same way. > > Line 2439 - the call to vm_exit_... is inside the if statement so > needs indenting as per line 2437. Okay, I fixed the indentation. joe > >> Is 2 spaces the standard for something like this? > > Hotspot code indent is 2 spaces. How long lines get subsequently > indented (ie 2440) does seem somewhat arbitrary. > > Thanks, > David > >> thanks for the review. >> >> joe >> >>> >>> David >>> >>> On 19/11/2012 7:31 AM, Joe Provino wrote: >>>> >>>> How does this look? >>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.01/ >>>> >>>> On 11/16/2012 4:13 PM, BILL PITTORE wrote: >>>>> Where you had it is the right place, you just need to #if it better. >>>>> The -XX: options get process by the code just after line 2788 by >>>>> process_argument(). That deals with all the globals defined in >>>>> globals.hpp so it's not where you can special case one flag. >>>>> >>>>> bill >>>>> >>>>> >>>>> >>>>> On 11/16/2012 3:23 PM, Joe Provino wrote: >>>>>> Dmitri, wait, I think I see what you mean. If INCLUDE_MANAGEMENT is >>>>>> set to true, then there's no code generated. >>>>>> >>>>>> I think the code that's there will work but perhaps there's a better >>>>>> place to check for this option when >>>>>> INCLUDE_MANAGEMENT is false. >>>>>> >>>>>> I seem to recall there's a place were -XX: arguments are parsed >>>>>> But I >>>>>> don't see a separate method to do that. >>>>>> I must be looking in the wrong place. >>>>>> >>>>>> joe >>>>>> >>>>>> On 11/16/2012 3:14 PM, Dmitry Samersoff wrote: >>>>>>> Joe, >>>>>>> >>>>>>> After you fix at 2788 regular hotspot start accepting do-nothing >>>>>>> option >>>>>>> >>>>>>> -XX:+ManagementServer >>>>>>> >>>>>>> Is it intentional? >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2012-11-16 23:24, Joe Provino wrote: >>>>>>>> This is a small change to one file -- arguments.cpp -- to print an >>>>>>>> error >>>>>>>> message >>>>>>>> and exit if INCLUDE_MANAGEMENT is false. >>>>>>>> >>>>>>>> Webrev is here: >>>>>>>> http://cr.openjdk.java.net/~jprovino/8003539/webrev.00/ >>>>>>>> >>>>>>>> thanks. >>>>>>>> >>>>>>>> joe >>>>>>> >>>>> >>>>> From duboscq at ssw.jku.at Mon Nov 19 07:46:59 2012 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 19 Nov 2012 16:46:59 +0100 Subject: Follow up on 8003259 Message-ID: Hello, It looks like a few more "this->" are needed to fully fix CR 8003259. This is needed to build a debug/fastdebug version with GCC 4.7.2. Regards, Gilles diff -r 01684f7fee1b src/share/vm/memory/binaryTreeDictionary.cpp --- a/src/share/vm/memory/binaryTreeDictionary.cpp ven. nov. 16 09:36:41 2012 -0800 +++ b/src/share/vm/memory/binaryTreeDictionary.cpp lun. nov. 19 16:35:30 2012 +0100 @@ -290,7 +290,7 @@ assert(chunk->list() == this, "list should be set for chunk"); assert(tail() != NULL, "The tree list is embedded in the first chunk"); // which means that the list can never be empty. - assert(!verify_chunk_in_free_list(chunk), "Double entry"); + assert(!this->verify_chunk_in_free_list(chunk), "Double entry"); assert(head() == NULL || head()->prev() == NULL, "list invariant"); assert(tail() == NULL || tail()->next() == NULL, "list invariant"); @@ -300,7 +300,7 @@ assert(!tail() || size() == tail()->size(), "Wrong sized chunk in list"); FreeList_t::increment_count(); - debug_only(increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) + debug_only(this->increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) assert(head() == NULL || head()->prev() == NULL, "list invariant"); assert(tail() == NULL || tail()->next() == NULL, "list invariant"); } @@ -314,7 +314,7 @@ assert(chunk->list() == this, "list should be set for chunk"); assert(head() != NULL, "The tree list is embedded in the first chunk"); assert(chunk != NULL, "returning NULL chunk"); - assert(!verify_chunk_in_free_list(chunk), "Double entry"); + assert(!this->verify_chunk_in_free_list(chunk), "Double entry"); assert(head() == NULL || head()->prev() == NULL, "list invariant"); assert(tail() == NULL || tail()->next() == NULL, "list invariant"); @@ -328,7 +328,7 @@ head()->link_after(chunk); assert(!head() || size() == head()->size(), "Wrong sized chunk in list"); FreeList_t::increment_count(); - debug_only(increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) + debug_only(this->increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) assert(head() == NULL || head()->prev() == NULL, "list invariant"); assert(tail() == NULL || tail()->next() == NULL, "list invariant"); } From zhengyu.gu at oracle.com Mon Nov 19 13:26:46 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 19 Nov 2012 16:26:46 -0500 Subject: Code review request (Backport): 7199092: NMT: NMT needs to deal overlapped virtual memory ranges Message-ID: <50AAA416.6040808@oracle.com> This change is already in JDK8. The purpose of this request is to review the merge conflicts during backporting to 7u12. The complete webrev: http://cr.openjdk.java.net/~zgu/7199092/webrev.backport/ The conflicts are in the two files: *src/share/vm/memory/genCollectedHeap.cpp* *src/share/vm/memory/filemap.cpp *mainly for dealing with class data sharing memory regions. Thanks, -Zhengyu From david.holmes at oracle.com Tue Nov 20 00:44:52 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Nov 2012 18:44:52 +1000 Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system In-Reply-To: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> References: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> Message-ID: <50AB4304.4060309@oracle.com> Thanks Erik, I have no further comments on this. :) You still need a second reviewer of course. Cheers, David On 20/11/2012 7:19 AM, Erik Helin wrote: > Hi David, > > first of all, sorry for my very late reply, I've had some serious > technical issues with my email account. > > This is a reply to the following email: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html > > Unfortunately, my email address has been changed and I can't therefore > reply correctly to the original email. > > I've uploaded a new, minimal webrev at: > http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ > > On 10/30/2012 6 PM, David Holmes wrote: > >> On 10/30/2012 04:29 AM, David Holmes wrote: > >>> On 30/10/2012 12:29 AM, Erik Helin wrote: > >>>> Since 'Arguments::parse' is called before 'os::init_2' in the function > >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to > false and > >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly > >>>> modified. > >>> > >>> Could we not simply adjust UseNUMAInterleaving and MinHeapDeltaBytes at > >>> the same time as setting UseNUMA to false? Or move the setting of > >>> UseNUMA to false out of os::init_2 into an earlier function - os::init > >>> perhaps? > >> > >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in os::init_2 > >> which is responsible for setting UseNUMA to false. However, I don't > >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. > > > > Ok, but in a similar style to what you have introduced, the os::init_2() > > code could simply call Arguments::adjust_gc_args() (or some such name). > > > > That said I don't think the factoring of the changes into > > adjust_parallel_gc_flags_after_os() is warranted in the current > > proposal. It isn't being called from multiple places, nor from any > > Arguments client, so there's really no need to expand the Arguments API > > this way. > > I agree, I've folded the update of the flags into the function > adjust_after_os. > > On 10/30/2012 6 PM, David Holmes wrote: > >> On 30/10/2012 12:29 AM, Erik Helin wrote: > >> I agree, I moved too much functionality into Arguments::adjust_after_os. > >> > >> I do not think that simply splitting Arguments::parse into two > >> functions, Arguments::parse and Arguments::adjust_before_os is a > >> disruptive change if Arguments::adjust_before_os ends up being called > >> directly after Arguments::parse. In fact, this change is not needed, but > >> I think it makes the code easier to understand. > > > > I don't think it is completely clear what changes can be done in parse > > versus what have to be deferred to adjust_before. So in my view this > > split does not directly aid understandability. I do understand that as a > > newcomer to the codebase this changes aids your understanding of the > code. > > > > From a pragmatic perspective such changes are highly subjective and > > they add "noise" to the reviewing process. > > I agree with you that my change did too much. If (I'm not saying that it > should) the code should be refactored, then it should be done in another > change, not the same as the one for the bugfix. > > On 10/30/2012 6 PM, David Holmes wrote: > >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: > >>>> This change also renames 'os::init' to 'os::init_before_parsing_flags' > >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done > to try > >>>> to make the relationship between the functions in 'Arguments' and the > >>>> functions in 'os' as clear as possible. > >>> > >>> On 10/30/2012 04:29 AM, David Holmes wrote: > >>> A little too verbose though I think. Maybe os::init_pre_args() and > >>> os::init_post_args() ? Though really the names are not that significant > >>> given the comments both at the call site and declaration site of the > >>> methods. > >> > >> On 30/10/2012 12:29 AM, Erik Helin wrote: > >> My idea was that the code should "speak for itself" and hopefully render > >> the comments unnecessary, since comments sometimes can become outdated > >> but code can't. > > > > I am not a fan of "code speaking for itself" if the code "talks too > > much" - that is why languages have comments. Speaking belongs in > > comments. Code should be clear without being overly verbose, yet > > succinct without being cryptic. And code can certainly become outdated > > if that code is the name of a method. If the role of the method expands > > then it is better to adapt a comment than to revise an API to rename a > > method and update all callsites! > > I think this is a very interesting discussion, and think we should continue > it "off-line", but I no longer think that it should be a part of the > discussion for this change with the new minimal webrev (see top of email). > > On 10/30/2012 6 PM, David Holmes wrote: > > If you did not do this renaming your webrev would be exceedingly short > > compared to the current webrev, and your changes would only touch on GC > > related bits of code. The renaming affects the OS API and that is > > general runtime code. So I will defer to Karen as the owner of the > > runtime code. > > I agree and I've updated the webrev accordingly, what do you think of > the new one? > > Thanks for taking your time and reviewing this change, > Erik > > On 10/30/2012 6 PM, David Holmes wrote: > > Cheers, > > David > > > > > >> > >> On 30/10/2012 12:29 AM, Erik Helin wrote: > >> > >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: > >>>> Testing: > >>>> JPRT > >>> > >>> On 10/30/2012 04:29 AM, David Holmes wrote: > >>> JPRT will barely test anything related to argument processing. > >> > >> > >> Ok, thank you for this information. Can you recommend a way to test this > >> change? > >> > >> Thanks, > >> Erik > >> > >>> David > >>> ----- > >>> > >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: > >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal -version' on a > >>>> system that does not support NUMA shows that 'UseNUMAInterleaving' and > >>>> 'MinHeapDeltaBytes' now have correct values. > >>>> > >>>> Thanks, > >>>> Erik From erik.helin at oracle.com Tue Nov 20 02:26:15 2012 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 20 Nov 2012 11:26:15 +0100 Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system In-Reply-To: <50AB4304.4060309@oracle.com> References: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> <50AB4304.4060309@oracle.com> Message-ID: <50AB5AC7.2070704@oracle.com> Thanks David! Erik On 11/20/2012 09:44 AM, David Holmes wrote: > Thanks Erik, I have no further comments on this. :) > > You still need a second reviewer of course. > > Cheers, > David > > On 20/11/2012 7:19 AM, Erik Helin wrote: >> Hi David, >> >> first of all, sorry for my very late reply, I've had some serious >> technical issues with my email account. >> >> This is a reply to the following email: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html >> >> >> Unfortunately, my email address has been changed and I can't therefore >> reply correctly to the original email. >> >> I've uploaded a new, minimal webrev at: >> http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Since 'Arguments::parse' is called before 'os::init_2' in the >> function >> >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to >> false and >> >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly >> >>>> modified. >> >>> >> >>> Could we not simply adjust UseNUMAInterleaving and >> MinHeapDeltaBytes at >> >>> the same time as setting UseNUMA to false? Or move the setting of >> >>> UseNUMA to false out of os::init_2 into an earlier function - >> os::init >> >>> perhaps? >> >> >> >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in >> os::init_2 >> >> which is responsible for setting UseNUMA to false. However, I don't >> >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. >> > >> > Ok, but in a similar style to what you have introduced, the >> os::init_2() >> > code could simply call Arguments::adjust_gc_args() (or some such >> name). >> > >> > That said I don't think the factoring of the changes into >> > adjust_parallel_gc_flags_after_os() is warranted in the current >> > proposal. It isn't being called from multiple places, nor from any >> > Arguments client, so there's really no need to expand the >> Arguments API >> > this way. >> >> I agree, I've folded the update of the flags into the function >> adjust_after_os. >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> I agree, I moved too much functionality into >> Arguments::adjust_after_os. >> >> >> >> I do not think that simply splitting Arguments::parse into two >> >> functions, Arguments::parse and Arguments::adjust_before_os is a >> >> disruptive change if Arguments::adjust_before_os ends up being >> called >> >> directly after Arguments::parse. In fact, this change is not >> needed, but >> >> I think it makes the code easier to understand. >> > >> > I don't think it is completely clear what changes can be done in >> parse >> > versus what have to be deferred to adjust_before. So in my view this >> > split does not directly aid understandability. I do understand >> that as a >> > newcomer to the codebase this changes aids your understanding of the >> code. >> > >> > From a pragmatic perspective such changes are highly subjective >> and >> > they add "noise" to the reviewing process. >> >> I agree with you that my change did too much. If (I'm not saying that it >> should) the code should be refactored, then it should be done in another >> change, not the same as the one for the bugfix. >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> This change also renames 'os::init' to >> 'os::init_before_parsing_flags' >> >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done >> to try >> >>>> to make the relationship between the functions in 'Arguments' >> and the >> >>>> functions in 'os' as clear as possible. >> >>> >> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> A little too verbose though I think. Maybe os::init_pre_args() and >> >>> os::init_post_args() ? Though really the names are not that >> significant >> >>> given the comments both at the call site and declaration site >> of the >> >>> methods. >> >> >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> My idea was that the code should "speak for itself" and >> hopefully render >> >> the comments unnecessary, since comments sometimes can become >> outdated >> >> but code can't. >> > >> > I am not a fan of "code speaking for itself" if the code "talks too >> > much" - that is why languages have comments. Speaking belongs in >> > comments. Code should be clear without being overly verbose, yet >> > succinct without being cryptic. And code can certainly become >> outdated >> > if that code is the name of a method. If the role of the method >> expands >> > then it is better to adapt a comment than to revise an API to >> rename a >> > method and update all callsites! >> >> I think this is a very interesting discussion, and think we should >> continue >> it "off-line", but I no longer think that it should be a part of the >> discussion for this change with the new minimal webrev (see top of >> email). >> >> On 10/30/2012 6 PM, David Holmes wrote: >> > If you did not do this renaming your webrev would be exceedingly >> short >> > compared to the current webrev, and your changes would only touch >> on GC >> > related bits of code. The renaming affects the OS API and that is >> > general runtime code. So I will defer to Karen as the owner of the >> > runtime code. >> >> I agree and I've updated the webrev accordingly, what do you think of >> the new one? >> >> Thanks for taking your time and reviewing this change, >> Erik >> >> On 10/30/2012 6 PM, David Holmes wrote: >> > Cheers, >> > David >> > >> > >> >> >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Testing: >> >>>> JPRT >> >>> >> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> JPRT will barely test anything related to argument processing. >> >> >> >> >> >> Ok, thank you for this information. Can you recommend a way to >> test this >> >> change? >> >> >> >> Thanks, >> >> Erik >> >> >> >>> David >> >>> ----- >> >>> >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal >> -version' on a >> >>>> system that does not support NUMA shows that >> 'UseNUMAInterleaving' and >> >>>> 'MinHeapDeltaBytes' now have correct values. >> >>>> >> >>>> Thanks, >> >>>> Erik From bengt.rutisson at oracle.com Tue Nov 20 02:32:42 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 20 Nov 2012 11:32:42 +0100 Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system In-Reply-To: <50AB4304.4060309@oracle.com> References: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> <50AB4304.4060309@oracle.com> Message-ID: <50AB5C4A.1000801@oracle.com> Erik, Looks good to me too. I can help you push this. Bengt On 2012-11-20 09:44, David Holmes wrote: > Thanks Erik, I have no further comments on this. :) > > You still need a second reviewer of course. > > Cheers, > David > > On 20/11/2012 7:19 AM, Erik Helin wrote: >> Hi David, >> >> first of all, sorry for my very late reply, I've had some serious >> technical issues with my email account. >> >> This is a reply to the following email: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html >> >> >> Unfortunately, my email address has been changed and I can't therefore >> reply correctly to the original email. >> >> I've uploaded a new, minimal webrev at: >> http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Since 'Arguments::parse' is called before 'os::init_2' in the >> function >> >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to >> false and >> >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly >> >>>> modified. >> >>> >> >>> Could we not simply adjust UseNUMAInterleaving and >> MinHeapDeltaBytes at >> >>> the same time as setting UseNUMA to false? Or move the setting of >> >>> UseNUMA to false out of os::init_2 into an earlier function - >> os::init >> >>> perhaps? >> >> >> >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in >> os::init_2 >> >> which is responsible for setting UseNUMA to false. However, I >> don't >> >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. >> > >> > Ok, but in a similar style to what you have introduced, the >> os::init_2() >> > code could simply call Arguments::adjust_gc_args() (or some such >> name). >> > >> > That said I don't think the factoring of the changes into >> > adjust_parallel_gc_flags_after_os() is warranted in the current >> > proposal. It isn't being called from multiple places, nor from any >> > Arguments client, so there's really no need to expand the >> Arguments API >> > this way. >> >> I agree, I've folded the update of the flags into the function >> adjust_after_os. >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> I agree, I moved too much functionality into >> Arguments::adjust_after_os. >> >> >> >> I do not think that simply splitting Arguments::parse into two >> >> functions, Arguments::parse and Arguments::adjust_before_os is a >> >> disruptive change if Arguments::adjust_before_os ends up being >> called >> >> directly after Arguments::parse. In fact, this change is not >> needed, but >> >> I think it makes the code easier to understand. >> > >> > I don't think it is completely clear what changes can be done in >> parse >> > versus what have to be deferred to adjust_before. So in my view >> this >> > split does not directly aid understandability. I do understand >> that as a >> > newcomer to the codebase this changes aids your understanding of >> the >> code. >> > >> > From a pragmatic perspective such changes are highly >> subjective and >> > they add "noise" to the reviewing process. >> >> I agree with you that my change did too much. If (I'm not saying that it >> should) the code should be refactored, then it should be done in another >> change, not the same as the one for the bugfix. >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> This change also renames 'os::init' to >> 'os::init_before_parsing_flags' >> >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done >> to try >> >>>> to make the relationship between the functions in 'Arguments' >> and the >> >>>> functions in 'os' as clear as possible. >> >>> >> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> A little too verbose though I think. Maybe os::init_pre_args() >> and >> >>> os::init_post_args() ? Though really the names are not that >> significant >> >>> given the comments both at the call site and declaration site >> of the >> >>> methods. >> >> >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> My idea was that the code should "speak for itself" and >> hopefully render >> >> the comments unnecessary, since comments sometimes can become >> outdated >> >> but code can't. >> > >> > I am not a fan of "code speaking for itself" if the code "talks too >> > much" - that is why languages have comments. Speaking belongs in >> > comments. Code should be clear without being overly verbose, yet >> > succinct without being cryptic. And code can certainly become >> outdated >> > if that code is the name of a method. If the role of the method >> expands >> > then it is better to adapt a comment than to revise an API to >> rename a >> > method and update all callsites! >> >> I think this is a very interesting discussion, and think we should >> continue >> it "off-line", but I no longer think that it should be a part of the >> discussion for this change with the new minimal webrev (see top of >> email). >> >> On 10/30/2012 6 PM, David Holmes wrote: >> > If you did not do this renaming your webrev would be exceedingly >> short >> > compared to the current webrev, and your changes would only >> touch on GC >> > related bits of code. The renaming affects the OS API and that is >> > general runtime code. So I will defer to Karen as the owner of the >> > runtime code. >> >> I agree and I've updated the webrev accordingly, what do you think of >> the new one? >> >> Thanks for taking your time and reviewing this change, >> Erik >> >> On 10/30/2012 6 PM, David Holmes wrote: >> > Cheers, >> > David >> > >> > >> >> >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Testing: >> >>>> JPRT >> >>> >> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> JPRT will barely test anything related to argument processing. >> >> >> >> >> >> Ok, thank you for this information. Can you recommend a way to >> test this >> >> change? >> >> >> >> Thanks, >> >> Erik >> >> >> >>> David >> >>> ----- >> >>> >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal >> -version' on a >> >>>> system that does not support NUMA shows that >> 'UseNUMAInterleaving' and >> >>>> 'MinHeapDeltaBytes' now have correct values. >> >>>> >> >>>> Thanks, >> >>>> Erik From erik.helin at oracle.com Tue Nov 20 02:50:47 2012 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 20 Nov 2012 11:50:47 +0100 Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system In-Reply-To: <50AB5C4A.1000801@oracle.com> References: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> <50AB4304.4060309@oracle.com> <50AB5C4A.1000801@oracle.com> Message-ID: <50AB6087.8090804@oracle.com> Thanks Bengt! Erik On 11/20/2012 11:32 AM, Bengt Rutisson wrote: > > Erik, > > Looks good to me too. > > I can help you push this. > > Bengt > > > > On 2012-11-20 09:44, David Holmes wrote: >> Thanks Erik, I have no further comments on this. :) >> >> You still need a second reviewer of course. >> >> Cheers, >> David >> >> On 20/11/2012 7:19 AM, Erik Helin wrote: >>> Hi David, >>> >>> first of all, sorry for my very late reply, I've had some serious >>> technical issues with my email account. >>> >>> This is a reply to the following email: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html >>> >>> >>> Unfortunately, my email address has been changed and I can't therefore >>> reply correctly to the original email. >>> >>> I've uploaded a new, minimal webrev at: >>> http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> >> On 10/30/2012 04:29 AM, David Holmes wrote: >>> >>> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> Since 'Arguments::parse' is called before 'os::init_2' in the >>> function >>> >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to >>> false and >>> >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly >>> >>>> modified. >>> >>> >>> >>> Could we not simply adjust UseNUMAInterleaving and >>> MinHeapDeltaBytes at >>> >>> the same time as setting UseNUMA to false? Or move the setting of >>> >>> UseNUMA to false out of os::init_2 into an earlier function - >>> os::init >>> >>> perhaps? >>> >> >>> >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in >>> os::init_2 >>> >> which is responsible for setting UseNUMA to false. However, I >>> don't >>> >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. >>> > >>> > Ok, but in a similar style to what you have introduced, the >>> os::init_2() >>> > code could simply call Arguments::adjust_gc_args() (or some such >>> name). >>> > >>> > That said I don't think the factoring of the changes into >>> > adjust_parallel_gc_flags_after_os() is warranted in the current >>> > proposal. It isn't being called from multiple places, nor from any >>> > Arguments client, so there's really no need to expand the >>> Arguments API >>> > this way. >>> >>> I agree, I've folded the update of the flags into the function >>> adjust_after_os. >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >> I agree, I moved too much functionality into >>> Arguments::adjust_after_os. >>> >> >>> >> I do not think that simply splitting Arguments::parse into two >>> >> functions, Arguments::parse and Arguments::adjust_before_os is a >>> >> disruptive change if Arguments::adjust_before_os ends up being >>> called >>> >> directly after Arguments::parse. In fact, this change is not >>> needed, but >>> >> I think it makes the code easier to understand. >>> > >>> > I don't think it is completely clear what changes can be done in >>> parse >>> > versus what have to be deferred to adjust_before. So in my view >>> this >>> > split does not directly aid understandability. I do understand >>> that as a >>> > newcomer to the codebase this changes aids your understanding of >>> the >>> code. >>> > >>> > From a pragmatic perspective such changes are highly >>> subjective and >>> > they add "noise" to the reviewing process. >>> >>> I agree with you that my change did too much. If (I'm not saying that it >>> should) the code should be refactored, then it should be done in another >>> change, not the same as the one for the bugfix. >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> This change also renames 'os::init' to >>> 'os::init_before_parsing_flags' >>> >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done >>> to try >>> >>>> to make the relationship between the functions in 'Arguments' >>> and the >>> >>>> functions in 'os' as clear as possible. >>> >>> >>> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >>> >>> A little too verbose though I think. Maybe os::init_pre_args() >>> and >>> >>> os::init_post_args() ? Though really the names are not that >>> significant >>> >>> given the comments both at the call site and declaration site >>> of the >>> >>> methods. >>> >> >>> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >> My idea was that the code should "speak for itself" and >>> hopefully render >>> >> the comments unnecessary, since comments sometimes can become >>> outdated >>> >> but code can't. >>> > >>> > I am not a fan of "code speaking for itself" if the code "talks too >>> > much" - that is why languages have comments. Speaking belongs in >>> > comments. Code should be clear without being overly verbose, yet >>> > succinct without being cryptic. And code can certainly become >>> outdated >>> > if that code is the name of a method. If the role of the method >>> expands >>> > then it is better to adapt a comment than to revise an API to >>> rename a >>> > method and update all callsites! >>> >>> I think this is a very interesting discussion, and think we should >>> continue >>> it "off-line", but I no longer think that it should be a part of the >>> discussion for this change with the new minimal webrev (see top of >>> email). >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> > If you did not do this renaming your webrev would be exceedingly >>> short >>> > compared to the current webrev, and your changes would only >>> touch on GC >>> > related bits of code. The renaming affects the OS API and that is >>> > general runtime code. So I will defer to Karen as the owner of the >>> > runtime code. >>> >>> I agree and I've updated the webrev accordingly, what do you think of >>> the new one? >>> >>> Thanks for taking your time and reviewing this change, >>> Erik >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> > Cheers, >>> > David >>> > >>> > >>> >> >>> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >> >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> Testing: >>> >>>> JPRT >>> >>> >>> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >>> >>> JPRT will barely test anything related to argument processing. >>> >> >>> >> >>> >> Ok, thank you for this information. Can you recommend a way to >>> test this >>> >> change? >>> >> >>> >> Thanks, >>> >> Erik >>> >> >>> >>> David >>> >>> ----- >>> >>> >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal >>> -version' on a >>> >>>> system that does not support NUMA shows that >>> 'UseNUMAInterleaving' and >>> >>>> 'MinHeapDeltaBytes' now have correct values. >>> >>>> >>> >>>> Thanks, >>> >>>> Erik > From jesper.wilhelmsson at oracle.com Tue Nov 20 05:56:03 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 20 Nov 2012 14:56:03 +0100 Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system In-Reply-To: <50AB4304.4060309@oracle.com> References: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> <50AB4304.4060309@oracle.com> Message-ID: <50AB8BF3.8040000@oracle.com> Looks good! Ship it! /Jesper On 11/20/12 9:44 AM, David Holmes wrote: > Thanks Erik, I have no further comments on this. :) > > You still need a second reviewer of course. > > Cheers, > David > > On 20/11/2012 7:19 AM, Erik Helin wrote: >> Hi David, >> >> first of all, sorry for my very late reply, I've had some serious >> technical issues with my email account. >> >> This is a reply to the following email: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html >> >> >> Unfortunately, my email address has been changed and I can't therefore >> reply correctly to the original email. >> >> I've uploaded a new, minimal webrev at: >> http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Since 'Arguments::parse' is called before 'os::init_2' in the >> function >> >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to >> false and >> >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly >> >>>> modified. >> >>> >> >>> Could we not simply adjust UseNUMAInterleaving and >> MinHeapDeltaBytes at >> >>> the same time as setting UseNUMA to false? Or move the setting of >> >>> UseNUMA to false out of os::init_2 into an earlier function - >> os::init >> >>> perhaps? >> >> >> >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in >> os::init_2 >> >> which is responsible for setting UseNUMA to false. However, I >> don't >> >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. >> > >> > Ok, but in a similar style to what you have introduced, the >> os::init_2() >> > code could simply call Arguments::adjust_gc_args() (or some such >> name). >> > >> > That said I don't think the factoring of the changes into >> > adjust_parallel_gc_flags_after_os() is warranted in the current >> > proposal. It isn't being called from multiple places, nor from any >> > Arguments client, so there's really no need to expand the >> Arguments API >> > this way. >> >> I agree, I've folded the update of the flags into the function >> adjust_after_os. >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> I agree, I moved too much functionality into >> Arguments::adjust_after_os. >> >> >> >> I do not think that simply splitting Arguments::parse into two >> >> functions, Arguments::parse and Arguments::adjust_before_os is a >> >> disruptive change if Arguments::adjust_before_os ends up being >> called >> >> directly after Arguments::parse. In fact, this change is not >> needed, but >> >> I think it makes the code easier to understand. >> > >> > I don't think it is completely clear what changes can be done in >> parse >> > versus what have to be deferred to adjust_before. So in my view >> this >> > split does not directly aid understandability. I do understand >> that as a >> > newcomer to the codebase this changes aids your understanding of >> the >> code. >> > >> > From a pragmatic perspective such changes are highly >> subjective and >> > they add "noise" to the reviewing process. >> >> I agree with you that my change did too much. If (I'm not saying that it >> should) the code should be refactored, then it should be done in another >> change, not the same as the one for the bugfix. >> >> On 10/30/2012 6 PM, David Holmes wrote: >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> This change also renames 'os::init' to >> 'os::init_before_parsing_flags' >> >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done >> to try >> >>>> to make the relationship between the functions in 'Arguments' >> and the >> >>>> functions in 'os' as clear as possible. >> >>> >> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> A little too verbose though I think. Maybe os::init_pre_args() >> and >> >>> os::init_post_args() ? Though really the names are not that >> significant >> >>> given the comments both at the call site and declaration site >> of the >> >>> methods. >> >> >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> My idea was that the code should "speak for itself" and >> hopefully render >> >> the comments unnecessary, since comments sometimes can become >> outdated >> >> but code can't. >> > >> > I am not a fan of "code speaking for itself" if the code "talks too >> > much" - that is why languages have comments. Speaking belongs in >> > comments. Code should be clear without being overly verbose, yet >> > succinct without being cryptic. And code can certainly become >> outdated >> > if that code is the name of a method. If the role of the method >> expands >> > then it is better to adapt a comment than to revise an API to >> rename a >> > method and update all callsites! >> >> I think this is a very interesting discussion, and think we should >> continue >> it "off-line", but I no longer think that it should be a part of the >> discussion for this change with the new minimal webrev (see top of >> email). >> >> On 10/30/2012 6 PM, David Holmes wrote: >> > If you did not do this renaming your webrev would be exceedingly >> short >> > compared to the current webrev, and your changes would only >> touch on GC >> > related bits of code. The renaming affects the OS API and that is >> > general runtime code. So I will defer to Karen as the owner of the >> > runtime code. >> >> I agree and I've updated the webrev accordingly, what do you think of >> the new one? >> >> Thanks for taking your time and reviewing this change, >> Erik >> >> On 10/30/2012 6 PM, David Holmes wrote: >> > Cheers, >> > David >> > >> > >> >> >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >> >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Testing: >> >>>> JPRT >> >>> >> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >> >>> JPRT will barely test anything related to argument processing. >> >> >> >> >> >> Ok, thank you for this information. Can you recommend a way to >> test this >> >> change? >> >> >> >> Thanks, >> >> Erik >> >> >> >>> David >> >>> ----- >> >>> >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >> >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal >> -version' on a >> >>>> system that does not support NUMA shows that >> 'UseNUMAInterleaving' and >> >>>> 'MinHeapDeltaBytes' now have correct values. >> >>>> >> >>>> Thanks, >> >>>> Erik From erik.helin at oracle.com Tue Nov 20 05:58:32 2012 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 20 Nov 2012 14:58:32 +0100 Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system In-Reply-To: <50AB8BF3.8040000@oracle.com> References: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> <50AB4304.4060309@oracle.com> <50AB8BF3.8040000@oracle.com> Message-ID: <50AB8C88.7070507@oracle.com> Thanks Jesper! Erik On 11/20/2012 02:56 PM, Jesper Wilhelmsson wrote: > Looks good! > Ship it! > /Jesper > > On 11/20/12 9:44 AM, David Holmes wrote: >> Thanks Erik, I have no further comments on this. :) >> >> You still need a second reviewer of course. >> >> Cheers, >> David >> >> On 20/11/2012 7:19 AM, Erik Helin wrote: >>> Hi David, >>> >>> first of all, sorry for my very late reply, I've had some serious >>> technical issues with my email account. >>> >>> This is a reply to the following email: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html >>> >>> >>> Unfortunately, my email address has been changed and I can't therefore >>> reply correctly to the original email. >>> >>> I've uploaded a new, minimal webrev at: >>> http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> >> On 10/30/2012 04:29 AM, David Holmes wrote: >>> >>> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> Since 'Arguments::parse' is called before 'os::init_2' in the >>> function >>> >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to >>> false and >>> >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly >>> >>>> modified. >>> >>> >>> >>> Could we not simply adjust UseNUMAInterleaving and >>> MinHeapDeltaBytes at >>> >>> the same time as setting UseNUMA to false? Or move the setting of >>> >>> UseNUMA to false out of os::init_2 into an earlier function - >>> os::init >>> >>> perhaps? >>> >> >>> >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in >>> os::init_2 >>> >> which is responsible for setting UseNUMA to false. However, I >>> don't >>> >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. >>> > >>> > Ok, but in a similar style to what you have introduced, the >>> os::init_2() >>> > code could simply call Arguments::adjust_gc_args() (or some such >>> name). >>> > >>> > That said I don't think the factoring of the changes into >>> > adjust_parallel_gc_flags_after_os() is warranted in the current >>> > proposal. It isn't being called from multiple places, nor from any >>> > Arguments client, so there's really no need to expand the >>> Arguments API >>> > this way. >>> >>> I agree, I've folded the update of the flags into the function >>> adjust_after_os. >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >> I agree, I moved too much functionality into >>> Arguments::adjust_after_os. >>> >> >>> >> I do not think that simply splitting Arguments::parse into two >>> >> functions, Arguments::parse and Arguments::adjust_before_os is a >>> >> disruptive change if Arguments::adjust_before_os ends up being >>> called >>> >> directly after Arguments::parse. In fact, this change is not >>> needed, but >>> >> I think it makes the code easier to understand. >>> > >>> > I don't think it is completely clear what changes can be done in >>> parse >>> > versus what have to be deferred to adjust_before. So in my view >>> this >>> > split does not directly aid understandability. I do understand >>> that as a >>> > newcomer to the codebase this changes aids your understanding of >>> the >>> code. >>> > >>> > From a pragmatic perspective such changes are highly >>> subjective and >>> > they add "noise" to the reviewing process. >>> >>> I agree with you that my change did too much. If (I'm not saying that it >>> should) the code should be refactored, then it should be done in another >>> change, not the same as the one for the bugfix. >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> This change also renames 'os::init' to >>> 'os::init_before_parsing_flags' >>> >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done >>> to try >>> >>>> to make the relationship between the functions in 'Arguments' >>> and the >>> >>>> functions in 'os' as clear as possible. >>> >>> >>> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >>> >>> A little too verbose though I think. Maybe os::init_pre_args() >>> and >>> >>> os::init_post_args() ? Though really the names are not that >>> significant >>> >>> given the comments both at the call site and declaration site >>> of the >>> >>> methods. >>> >> >>> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >> My idea was that the code should "speak for itself" and >>> hopefully render >>> >> the comments unnecessary, since comments sometimes can become >>> outdated >>> >> but code can't. >>> > >>> > I am not a fan of "code speaking for itself" if the code "talks too >>> > much" - that is why languages have comments. Speaking belongs in >>> > comments. Code should be clear without being overly verbose, yet >>> > succinct without being cryptic. And code can certainly become >>> outdated >>> > if that code is the name of a method. If the role of the method >>> expands >>> > then it is better to adapt a comment than to revise an API to >>> rename a >>> > method and update all callsites! >>> >>> I think this is a very interesting discussion, and think we should >>> continue >>> it "off-line", but I no longer think that it should be a part of the >>> discussion for this change with the new minimal webrev (see top of >>> email). >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> > If you did not do this renaming your webrev would be exceedingly >>> short >>> > compared to the current webrev, and your changes would only >>> touch on GC >>> > related bits of code. The renaming affects the OS API and that is >>> > general runtime code. So I will defer to Karen as the owner of the >>> > runtime code. >>> >>> I agree and I've updated the webrev accordingly, what do you think of >>> the new one? >>> >>> Thanks for taking your time and reviewing this change, >>> Erik >>> >>> On 10/30/2012 6 PM, David Holmes wrote: >>> > Cheers, >>> > David >>> > >>> > >>> >> >>> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >>> >> >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> Testing: >>> >>>> JPRT >>> >>> >>> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >>> >>> JPRT will barely test anything related to argument processing. >>> >> >>> >> >>> >> Ok, thank you for this information. Can you recommend a way to >>> test this >>> >> change? >>> >> >>> >> Thanks, >>> >> Erik >>> >> >>> >>> David >>> >>> ----- >>> >>> >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>> >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal >>> -version' on a >>> >>>> system that does not support NUMA shows that >>> 'UseNUMAInterleaving' and >>> >>>> 'MinHeapDeltaBytes' now have correct values. >>> >>>> >>> >>>> Thanks, >>> >>>> Erik > From krystal.mo at oracle.com Tue Nov 20 10:18:35 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 20 Nov 2012 10:18:35 -0800 (PST) Subject: New HSX Committer: Harold Seigel Message-ID: Vote: yes Regards, Kris ----- Original Message ----- From: coleen.phillimore at oracle.com To: hotspot-dev at openjdk.java.net Sent: Saturday, November 17, 2012 4:50:51 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: New HSX Committer: Harold Seigel I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel Votes are due by Nov 30, 2012. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Coleen Phillimore [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From krystal.mo at oracle.com Tue Nov 20 10:20:20 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 20 Nov 2012 10:20:20 -0800 (PST) Subject: CFV: New HSX Committer: Harold Seigel Message-ID: Vote: yes Regards, Kris ----- Original Message ----- From: coleen.phillimore at oracle.com To: hotspot-dev at openjdk.java.net Sent: Saturday, November 17, 2012 5:39:29 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: CFV: New HSX Committer: Harold Seigel I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel Votes are due by Nov 30, 2012. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Coleen Phillimore [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote (resend with corrected title, please reply again) From erik.helin at oracle.com Mon Nov 19 13:19:16 2012 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 19 Nov 2012 13:19:16 -0800 (PST) Subject: RFR (S): 7198334: UseNUMA modifies system parameters on non-NUMA system Message-ID: <43215262-5acc-4f4b-930c-a4d4f40e5fe7@default> Hi David, first of all, sorry for my very late reply, I've had some serious technical issues with my email account. This is a reply to the following email: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-October/007128.html Unfortunately, my email address has been changed and I can't therefore reply correctly to the original email. I've uploaded a new, minimal webrev at: http://cr.openjdk.java.net/~mgerdin/JDK-7198334.1/ On 10/30/2012 6 PM, David Holmes wrote: >> On 10/30/2012 04:29 AM, David Holmes wrote: >>> On 30/10/2012 12:29 AM, Erik Helin wrote: >>>> Since 'Arguments::parse' is called before 'os::init_2' in the function >>>> 'Threads::create_vm', the result was that 'UseNUMA' was set to false and >>>> 'UseNUMAInterleaving' and 'MinHeapDeltaBytes' were incorrectly >>>> modified. >>> >>> Could we not simply adjust UseNUMAInterleaving and MinHeapDeltaBytes at >>> the same time as setting UseNUMA to false? Or move the setting of >>> UseNUMA to false out of os::init_2 into an earlier function - os::init >>> perhaps? >> >> We could adjust UseNUMAInterleaving and MinHeapDeltaBytes in os::init_2 >> which is responsible for setting UseNUMA to false. However, I don't >> think that os should adjust MinHeapDeltaBytes, which is a GC flag. > > Ok, but in a similar style to what you have introduced, the os::init_2() > code could simply call Arguments::adjust_gc_args() (or some such name). > > That said I don't think the factoring of the changes into > adjust_parallel_gc_flags_after_os() is warranted in the current > proposal. It isn't being called from multiple places, nor from any > Arguments client, so there's really no need to expand the Arguments API > this way. I agree, I've folded the update of the flags into the function adjust_after_os. On 10/30/2012 6 PM, David Holmes wrote: >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> I agree, I moved too much functionality into Arguments::adjust_after_os. >> >> I do not think that simply splitting Arguments::parse into two >> functions, Arguments::parse and Arguments::adjust_before_os is a >> disruptive change if Arguments::adjust_before_os ends up being called >> directly after Arguments::parse. In fact, this change is not needed, but >> I think it makes the code easier to understand. > > I don't think it is completely clear what changes can be done in parse > versus what have to be deferred to adjust_before. So in my view this > split does not directly aid understandability. I do understand that as a > newcomer to the codebase this changes aids your understanding of the code. > > From a pragmatic perspective such changes are highly subjective and > they add "noise" to the reviewing process. I agree with you that my change did too much. If (I'm not saying that it should) the code should be refactored, then it should be done in another change, not the same as the one for the bugfix. On 10/30/2012 6 PM, David Holmes wrote: >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>>> This change also renames 'os::init' to 'os::init_before_parsing_flags' >>>> and 'os::init_2' to 'os::init_after_parsing_args'. This was done to try >>>> to make the relationship between the functions in 'Arguments' and the >>>> functions in 'os' as clear as possible. >>> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >>> A little too verbose though I think. Maybe os::init_pre_args() and >>> os::init_post_args() ? Though really the names are not that significant >>> given the comments both at the call site and declaration site of the >>> methods. >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> My idea was that the code should "speak for itself" and hopefully render >> the comments unnecessary, since comments sometimes can become outdated >> but code can't. > > I am not a fan of "code speaking for itself" if the code "talks too > much" - that is why languages have comments. Speaking belongs in > comments. Code should be clear without being overly verbose, yet > succinct without being cryptic. And code can certainly become outdated > if that code is the name of a method. If the role of the method expands > then it is better to adapt a comment than to revise an API to rename a > method and update all callsites! I think this is a very interesting discussion, and think we should continue it "off-line", but I no longer think that it should be a part of the discussion for this change with the new minimal webrev (see top of email). On 10/30/2012 6 PM, David Holmes wrote: > If you did not do this renaming your webrev would be exceedingly short > compared to the current webrev, and your changes would only touch on GC > related bits of code. The renaming affects the OS API and that is > general runtime code. So I will defer to Karen as the owner of the > runtime code. I agree and I've updated the webrev accordingly, what do you think of the new one? Thanks for taking your time and reviewing this change, Erik On 10/30/2012 6 PM, David Holmes wrote: > Cheers, > David > > >> >> On 30/10/2012 12:29 AM, Erik Helin wrote: >> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>>> Testing: >>>> JPRT >>> >>> On 10/30/2012 04:29 AM, David Holmes wrote: >>> JPRT will barely test anything related to argument processing. >> >> >> Ok, thank you for this information. Can you recommend a way to test this >> change? >> >> Thanks, >> Erik >> >>> David >>> ----- >>> >>>> On 29/10/2012 12:29 AM, Erik Helin wrote: >>>> Also, running 'java -XX:+UseNUMA -XX:+PrintFlagsFinal -version' on a >>>> system that does not support NUMA shows that 'UseNUMAInterleaving' and >>>> 'MinHeapDeltaBytes' now have correct values. >>>> >>>> Thanks, >>>> Erik From coleen.phillimore at oracle.com Tue Nov 20 14:24:41 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 20 Nov 2012 17:24:41 -0500 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Message-ID: <50AC0329.8080800@oracle.com> Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 Tested with full NSK testlist on linux 32. Studio tools group also tested this. Thanks, Coleen From coleen.phillimore at oracle.com Tue Nov 20 14:28:33 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 20 Nov 2012 17:28:33 -0500 Subject: Follow up on 8003259 In-Reply-To: References: Message-ID: <50AC0411.4090202@oracle.com> Hi, I finally have a 4.7 compiler and saw these myself. I will take care of this. thanks, Coleen On 11/19/2012 10:46 AM, Gilles Duboscq wrote: > Hello, > > It looks like a few more "this->" are needed to fully fix CR 8003259. > This is needed to build a debug/fastdebug version with GCC 4.7.2. > > Regards, > Gilles > > diff -r 01684f7fee1b src/share/vm/memory/binaryTreeDictionary.cpp > --- a/src/share/vm/memory/binaryTreeDictionary.cpp ven. nov. 16 09:36:41 > 2012 -0800 > +++ b/src/share/vm/memory/binaryTreeDictionary.cpp lun. nov. 19 16:35:30 > 2012 +0100 > @@ -290,7 +290,7 @@ > assert(chunk->list() == this, "list should be set for chunk"); > assert(tail() != NULL, "The tree list is embedded in the first chunk"); > // which means that the list can never be empty. > - assert(!verify_chunk_in_free_list(chunk), "Double entry"); > + assert(!this->verify_chunk_in_free_list(chunk), "Double entry"); > assert(head() == NULL || head()->prev() == NULL, "list invariant"); > assert(tail() == NULL || tail()->next() == NULL, "list invariant"); > > @@ -300,7 +300,7 @@ > > assert(!tail() || size() == tail()->size(), "Wrong sized chunk in list"); > FreeList_t::increment_count(); > - debug_only(increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) > + > debug_only(this->increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) > assert(head() == NULL || head()->prev() == NULL, "list invariant"); > assert(tail() == NULL || tail()->next() == NULL, "list invariant"); > } > @@ -314,7 +314,7 @@ > assert(chunk->list() == this, "list should be set for chunk"); > assert(head() != NULL, "The tree list is embedded in the first chunk"); > assert(chunk != NULL, "returning NULL chunk"); > - assert(!verify_chunk_in_free_list(chunk), "Double entry"); > + assert(!this->verify_chunk_in_free_list(chunk), "Double entry"); > assert(head() == NULL || head()->prev() == NULL, "list invariant"); > assert(tail() == NULL || tail()->next() == NULL, "list invariant"); > > @@ -328,7 +328,7 @@ > head()->link_after(chunk); > assert(!head() || size() == head()->size(), "Wrong sized chunk in list"); > FreeList_t::increment_count(); > - debug_only(increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) > + > debug_only(this->increment_returned_bytes_by(chunk->size()*sizeof(HeapWord));) > assert(head() == NULL || head()->prev() == NULL, "list invariant"); > assert(tail() == NULL || tail()->next() == NULL, "list invariant"); > } From john.cuthbertson at oracle.com Tue Nov 20 16:57:56 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 20 Nov 2012 16:57:56 -0800 Subject: RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table Message-ID: <50AC2714.2070801@oracle.com> Hi Everyone, Can I have a couple of volunteers review the changes at: http://cr.openjdk.java.net/~johnc/7194633/webrev.0 ? Background: While I was testing the fix for 719066 I ran into several assertions and guarantee failures from G1's block offset table when running through jprt. The failures were associated with using a specific version of the sparc memset to initialize the offsets array (see 7192128) which was missing from my 7190666 workspace. The changes in this webrev are the instrumenation and detailed error message changes I made to verify that G1's block offset table was not immune to the memset issue and that the failures from jprt were the same issue. These detailed error messages were invaluable when tracking the issue down. Testing: GCBasher with -UseMemsetInBOT on sparc Forcibly triggering the failures to check that the error messages made sense. jprt It is still my intent to merge G1's BOT with that of the other collectors and remove the large amount of duplicated code (which is a separate CR). When I do that, the detailed error messages will be included in the shared BOT code. Thanks, JohnC From ysr1729 at gmail.com Tue Nov 20 17:40:28 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 20 Nov 2012 17:40:28 -0800 Subject: RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table In-Reply-To: <50AC2714.2070801@oracle.com> References: <50AC2714.2070801@oracle.com> Message-ID: Looks good to me. -- ramki On Tue, Nov 20, 2012 at 4:57 PM, John Cuthbertson < john.cuthbertson at oracle.com> wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes at: > http://cr.openjdk.java.net/~**johnc/7194633/webrev.0? > > Background: > > While I was testing the fix for 719066 I ran into several assertions and > guarantee failures from G1's block offset table when running through jprt. > The failures were associated with using a specific version of the sparc > memset to initialize the offsets array (see 7192128) which was missing from > my 7190666 workspace. The changes in this webrev are the instrumenation and > detailed error message changes I made to verify that G1's block offset > table was not immune to the memset issue and that the failures from jprt > were the same issue. These detailed error messages were invaluable when > tracking the issue down. > > Testing: > GCBasher with -UseMemsetInBOT on sparc > Forcibly triggering the failures to check that the error messages made > sense. > jprt > > It is still my intent to merge G1's BOT with that of the other collectors > and remove the large amount of duplicated code (which is a separate CR). > When I do that, the detailed error messages will be included in the shared > BOT code. > > Thanks, > > JohnC > From coleen.phillimore at oracle.com Tue Nov 20 17:44:12 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 20 Nov 2012 20:44:12 -0500 Subject: Request for review 8003722: More gcc 4.7 compilation errors Message-ID: <50AC31EC.6030404@oracle.com> Summary: Add a few more this->qualifications. Reviewed-by: coleenp Contributed-by: duboscq at ssw.jku.at http://cr.openjdk.java.net/~coleenp/8003722/ Ran runThese tests with CMS gc. I want to check this into hotspot-gc since it has the other changes (hotspot-rt doesn't yet). Thanks, Coleen From david.holmes at oracle.com Tue Nov 20 18:52:40 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Nov 2012 12:52:40 +1000 Subject: Request for review 8003722: More gcc 4.7 compilation errors In-Reply-To: <50AC31EC.6030404@oracle.com> References: <50AC31EC.6030404@oracle.com> Message-ID: <50AC41F8.2080301@oracle.com> Sorry but I must protest. After the last fix we were returned to an unpleasant mixture of using directives and this-> augmentation. The fix that was lost had applied the using directive. Can we please use the using directive and just fix these once and for all. Otherwise get rid of all using directives. But lets have a consistent approach here. Thanks, David On 21/11/2012 11:44 AM, Coleen Phillimore wrote: > Summary: Add a few more this->qualifications. > Reviewed-by: coleenp > Contributed-by: duboscq at ssw.jku.at > > http://cr.openjdk.java.net/~coleenp/8003722/ > > Ran runThese tests with CMS gc. I want to check this into hotspot-gc > since it has the other changes (hotspot-rt doesn't yet). > > Thanks, > Coleen From david.holmes at oracle.com Tue Nov 20 19:26:15 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Nov 2012 13:26:15 +1000 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50AC0329.8080800@oracle.com> References: <50AC0329.8080800@oracle.com> Message-ID: <50AC49D7.9050306@oracle.com> Hi Coleen, On 21/11/2012 8:24 AM, Coleen Phillimore wrote: > Summary: Make metaspace::contains be lock free and used to see if I don't think this is 100% valid without assuming TSO. Your are growing a linked list of nodes under a lock, but allowing the existing list to be iterated without a lock. You have to ensure that a VirtualSpaceNode can't be seen in the list prior to being properly initialized - I know the code in VirtualSpaceNode::initialize makes it unlikely, but I wouldn't want to second-guess how the compiler and/or hardware might reorder things. To be safe I think you need: 980 // Allocate the meta virtual space and initialize it. 981 VirtualSpaceNode* new_entry = new VirtualSpaceNode(vs_byte_size); 982 if (!new_entry->initialize()) { 983 delete new_entry; 984 return false; 985 } else { + // ensure lock-free iteration sees fully initialized node + OrderAccess:storeStore(); 986 link_vs(new_entry, vs_word_size); 987 return true; 988 } > something is in metaspace, also compare Method* with vtbl pointer. > > open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 Do the comments in forte.cpp regarding the unsafe reference to the method not still apply? Cheers, David ----- > Tested with full NSK testlist on linux 32. Studio tools group also > tested this. > > Thanks, > Coleen From bengt.rutisson at oracle.com Wed Nov 21 00:26:00 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Nov 2012 09:26:00 +0100 Subject: RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table In-Reply-To: References: <50AC2714.2070801@oracle.com> Message-ID: <50AC9018.2040008@oracle.com> Looks good to me too. I like that you introduced the check_index() and check_offset() methods. One style question. You are using the format macros without white spaces. After grepping a bit in the hotspot source I think it is more common to have white spaces when using these. So instead of "..."SIZE_FORMAT"..", "..."UINT32_FORMAT"..." etc I think it would be more hotspot-like to use "..." SIZE_FORMAT "..." and "..." UINT32_FORMAT "...". Bengt On 2012-11-21 02:40, Srinivas Ramakrishna wrote: > Looks good to me. > > -- ramki > > On Tue, Nov 20, 2012 at 4:57 PM, John Cuthbertson < > john.cuthbertson at oracle.com> wrote: > >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes at: >> http://cr.openjdk.java.net/~**johnc/7194633/webrev.0? >> >> Background: >> >> While I was testing the fix for 719066 I ran into several assertions and >> guarantee failures from G1's block offset table when running through jprt. >> The failures were associated with using a specific version of the sparc >> memset to initialize the offsets array (see 7192128) which was missing from >> my 7190666 workspace. The changes in this webrev are the instrumenation and >> detailed error message changes I made to verify that G1's block offset >> table was not immune to the memset issue and that the failures from jprt >> were the same issue. These detailed error messages were invaluable when >> tracking the issue down. >> >> Testing: >> GCBasher with -UseMemsetInBOT on sparc >> Forcibly triggering the failures to check that the error messages made >> sense. >> jprt >> >> It is still my intent to merge G1's BOT with that of the other collectors >> and remove the large amount of duplicated code (which is a separate CR). >> When I do that, the detailed error messages will be included in the shared >> BOT code. >> >> Thanks, >> >> JohnC >> From coleen.phillimore at oracle.com Wed Nov 21 06:18:07 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Nov 2012 09:18:07 -0500 Subject: Request for review 8003722: More gcc 4.7 compilation errors In-Reply-To: <50AC41F8.2080301@oracle.com> References: <50AC31EC.6030404@oracle.com> <50AC41F8.2080301@oracle.com> Message-ID: <50ACE29F.8030601@oracle.com> On 11/20/2012 9:52 PM, David Holmes wrote: > Sorry but I must protest. After the last fix we were returned to an > unpleasant mixture of using directives and this-> augmentation. The > fix that was lost had applied the using directive. > > Can we please use the using directive and just fix these once and for > all. Okay, someone will have to contribute the "using" fix then. I don't know what to use in "using"! Please do this very soon since the VM doesn't build on gcc 4.7 (again!) Thanks, Coleen > > Otherwise get rid of all using directives. But lets have a consistent > approach here. > > Thanks, > David > > On 21/11/2012 11:44 AM, Coleen Phillimore wrote: >> Summary: Add a few more this->qualifications. >> Reviewed-by: coleenp >> Contributed-by: duboscq at ssw.jku.at >> >> http://cr.openjdk.java.net/~coleenp/8003722/ >> >> Ran runThese tests with CMS gc. I want to check this into hotspot-gc >> since it has the other changes (hotspot-rt doesn't yet). >> >> Thanks, >> Coleen From karen.kinnear at oracle.com Wed Nov 21 06:53:39 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 21 Nov 2012 09:53:39 -0500 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <6AA17D37-7789-4A2D-AE07-24DAD79ACC6D@oracle.com> Vote: yes thanks, Karen On Nov 16, 2012, at 4:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) From ysr1729 at gmail.com Wed Nov 21 08:50:55 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 21 Nov 2012 08:50:55 -0800 Subject: RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table In-Reply-To: <50AC9018.2040008@oracle.com> References: <50AC2714.2070801@oracle.com> <50AC9018.2040008@oracle.com> Message-ID: Yes, I agree. Having the white-space around the *_FORMAT macros is the standard we've generally followed, and it's good to stick to it. I have noticed (even well in the past) that G1 code has often elided the white-space, but it would be nice to keep most of the code-base consistent wrt this style (or at least new code when it touches a file). May be we could add it to the HotSpot style guide so that people are aware of it, and such consistency maintained. -- ramki On Wed, Nov 21, 2012 at 12:26 AM, Bengt Rutisson wrote: > > Looks good to me too. > > I like that you introduced the check_index() and check_offset() methods. > > One style question. You are using the format macros without white spaces. > After grepping a bit in the hotspot source I think it is more common to > have white spaces when using these. So instead of "..."SIZE_FORMAT"..", > "..."UINT32_FORMAT"..." etc I think it would be more hotspot-like to use > "..." SIZE_FORMAT "..." and "..." UINT32_FORMAT "...". > > Bengt > > > > On 2012-11-21 02:40, Srinivas Ramakrishna wrote: > >> Looks good to me. >> >> -- ramki >> >> On Tue, Nov 20, 2012 at 4:57 PM, John Cuthbertson < >> john.cuthbertson at oracle.com> wrote: >> >> Hi Everyone, >>> >>> Can I have a couple of volunteers review the changes at: >>> http://cr.openjdk.java.net/~****johnc/7194633/webrev.0 >>> >>> >? >>> >>> >>> Background: >>> >>> While I was testing the fix for 719066 I ran into several assertions and >>> guarantee failures from G1's block offset table when running through >>> jprt. >>> The failures were associated with using a specific version of the sparc >>> memset to initialize the offsets array (see 7192128) which was missing >>> from >>> my 7190666 workspace. The changes in this webrev are the instrumenation >>> and >>> detailed error message changes I made to verify that G1's block offset >>> table was not immune to the memset issue and that the failures from jprt >>> were the same issue. These detailed error messages were invaluable when >>> tracking the issue down. >>> >>> Testing: >>> GCBasher with -UseMemsetInBOT on sparc >>> Forcibly triggering the failures to check that the error messages made >>> sense. >>> jprt >>> >>> It is still my intent to merge G1's BOT with that of the other collectors >>> and remove the large amount of duplicated code (which is a separate CR). >>> When I do that, the detailed error messages will be included in the >>> shared >>> BOT code. >>> >>> Thanks, >>> >>> JohnC >>> >>> > From coleen.phillimore at oracle.com Wed Nov 21 09:13:15 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Nov 2012 12:13:15 -0500 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50AC49D7.9050306@oracle.com> References: <50AC0329.8080800@oracle.com> <50AC49D7.9050306@oracle.com> Message-ID: <50AD0BAB.2020604@oracle.com> Thanks again for the code review, David. On 11/20/2012 10:26 PM, David Holmes wrote: > Hi Coleen, > > On 21/11/2012 8:24 AM, Coleen Phillimore wrote: >> Summary: Make metaspace::contains be lock free and used to see if > > I don't think this is 100% valid without assuming TSO. Your are > growing a linked list of nodes under a lock, but allowing the existing > list to be iterated without a lock. You have to ensure that a > VirtualSpaceNode can't be seen in the list prior to being properly > initialized - I know the code in VirtualSpaceNode::initialize makes it > unlikely, but I wouldn't want to second-guess how the compiler and/or > hardware might reorder things. To be safe I think you need: > > 980 // Allocate the meta virtual space and initialize it. > 981 VirtualSpaceNode* new_entry = new VirtualSpaceNode(vs_byte_size); > 982 if (!new_entry->initialize()) { > 983 delete new_entry; > 984 return false; > 985 } else { > + // ensure lock-free iteration sees fully initialized node > + OrderAccess:storeStore(); > 986 link_vs(new_entry, vs_word_size); > 987 return true; > 988 } Thank you! I added the OrderAccess call. I feel better about the safety of walking this lock free now. > >> something is in metaspace, also compare Method* with vtbl pointer. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 > > Do the comments in forte.cpp regarding the unsafe reference to the > method not still apply? > There are better comments above this comment. The interpreter frame could be partially constructed when AsyncGetCallTrace picks it up. We no longer have to worry about GC making the Method* invalid (except for bugid 8003720 ). The second check is probably not strictly necessary since that was what it was checking, but for safety I want to leave it in. Thanks, Coleen > Cheers, > David > ----- > >> Tested with full NSK testlist on linux 32. Studio tools group also >> tested this. >> >> Thanks, >> Coleen From rkennke at redhat.com Wed Nov 21 09:31:34 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 18:31:34 +0100 Subject: RFR: Fix shark for latest Hotspot and LLVM Message-ID: <1353519094.1744.42.camel@mercury> Hi there, during the last days I worked on fixing the Shark compiler for Hotspot to get it to build and run again, with the latest Hotspot code and LLVM. Here are some details: - A lot of changes are just to make it build and the compiler happy. For example, I had to remove a lot of 'const' qualifiers because of API changes in LLVM. - Most other changes have to do with the split of the oop and metadata class hierarchies in Hotspot. - Then there have been a few changes caused by LLVM changes and improvements, most notably the LLVM intrinsics for atomic operations (memory barrier and cmpxchg) have been removed and now have a representation directly in LLVM's IR. This makes our code a little nicer. I tested this by running a number of applications, most notably Eclipse (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a bunch of other stuff. I would like to get this integrated into OpenJDK now if possible. You can find the full webrev here: http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ There are also a very minor change required in JDK: http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ In order to build it, apply the patches on hsx/hotspot-comp 's hotspot and jdk repositories respectivly. Find my build script here: http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark (Review and adjust variables to your settings, most notably you will need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) Please let me know if there are any issues or how we can get this integrated into Hotspot. Best regards, Roman From zhengyu.gu at oracle.com Wed Nov 21 09:59:28 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 21 Nov 2012 12:59:28 -0500 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <6AA17D37-7789-4A2D-AE07-24DAD79ACC6D@oracle.com> References: <50A6B168.60000@oracle.com> <6AA17D37-7789-4A2D-AE07-24DAD79ACC6D@oracle.com> Message-ID: <50AD1680.70009@oracle.com> Vote: yes -Zhengyu On 11/21/2012 9:53 AM, Karen Kinnear wrote: > Vote: yes > > thanks, > Karen > > On Nov 16, 2012, at 4:34 PM, Coleen Phillimore wrote: > >> I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX Committer. >> >> Harold is a member of the Hotspot runtime group. He has contributed 10 changesets to the HSX project and he is qualified to be committer [1]: >> >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel >> >> Votes are due by Nov 30, 2012. >> >> Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Coleen Phillimore >> >> [1]http://openjdk.java.net/projects/#project-committer >> [2]http://openjdk.java.net/census#hsx >> [3]http://openjdk.java.net/projects#committer-vote >> >> (resend with corrected title, please reply again) From christian.thalinger at oracle.com Wed Nov 21 11:43:40 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 11:43:40 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353519094.1744.42.camel@mercury> References: <1353519094.1744.42.camel@mercury> Message-ID: On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > Hi there, > > during the last days I worked on fixing the Shark compiler for Hotspot > to get it to build and run again, with the latest Hotspot code and LLVM. > Here are some details: > > - A lot of changes are just to make it build and the compiler happy. For > example, I had to remove a lot of 'const' qualifiers because of API > changes in LLVM. > - Most other changes have to do with the split of the oop and metadata > class hierarchies in Hotspot. > - Then there have been a few changes caused by LLVM changes and > improvements, most notably the LLVM intrinsics for atomic operations > (memory barrier and cmpxchg) have been removed and now have a > representation directly in LLVM's IR. This makes our code a little > nicer. > > I tested this by running a number of applications, most notably Eclipse > (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > bunch of other stuff. > > I would like to get this integrated into OpenJDK now if possible. You > can find the full webrev here: > > http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ The changes seem to touch almost only shark files so these should be fine. One question though: + develop(bool, SharkShowCompiledMethods, false, \ Isn't PrintCompilation doing that already? The shared code changes look good. I filed: 8003868: fix shark for latest HotSpot and LLVM -- Chris > > There are also a very minor change required in JDK: > > http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > and jdk repositories respectivly. Find my build script here: > > http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > > (Review and adjust variables to your settings, most notably you will > need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > > Please let me know if there are any issues or how we can get this > integrated into Hotspot. > > Best regards, > Roman > > From zhengyu.gu at oracle.com Wed Nov 21 11:55:33 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 21 Nov 2012 19:55:33 +0000 Subject: hg: hsx/hsx24/hotspot: 5 new changesets Message-ID: <20121121195544.4478847AC7@hg.openjdk.java.net> Changeset: 5e2ef189237b Author: zgu Date: 2012-11-20 14:33 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5e2ef189237b 7199092: NMT: NMT needs to deal overlapped virtual memory ranges Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map. Reviewed-by: acorn, coleenp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 4594f84fb0d3 Author: zgu Date: 2012-11-05 15:30 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4594f84fb0d3 8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region Reviewed-by: dholmes, coleenp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp Changeset: 30113730bbbd Author: zgu Date: 2012-11-09 19:24 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/30113730bbbd 8001592: NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 Summary: Fixed NMT that miscounted arena memory when it is used as value or stack object. Reviewed-by: acorn, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.hpp Changeset: 1a2f16e936e9 Author: zgu Date: 2012-11-09 11:04 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1a2f16e936e9 8002273: NMT to report JNI memory leaks when -Xcheck:jni is on Summary: Allows NMT to report that JNI thread failed to detach from JVM before exiting, which leaks the JavaThread object when check:jni option is on. Reviewed-by: acorn, dholmes, coleenp, ctornqvi ! src/share/vm/services/memSnapshot.cpp Changeset: c5ecc8839ed9 Author: zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c5ecc8839ed9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp From christian.thalinger at oracle.com Wed Nov 21 12:47:05 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 12:47:05 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> Message-ID: <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >> Hi there, >> >> during the last days I worked on fixing the Shark compiler for Hotspot >> to get it to build and run again, with the latest Hotspot code and LLVM. >> Here are some details: >> >> - A lot of changes are just to make it build and the compiler happy. For >> example, I had to remove a lot of 'const' qualifiers because of API >> changes in LLVM. >> - Most other changes have to do with the split of the oop and metadata >> class hierarchies in Hotspot. >> - Then there have been a few changes caused by LLVM changes and >> improvements, most notably the LLVM intrinsics for atomic operations >> (memory barrier and cmpxchg) have been removed and now have a >> representation directly in LLVM's IR. This makes our code a little >> nicer. >> >> I tested this by running a number of applications, most notably Eclipse >> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >> bunch of other stuff. >> >> I would like to get this integrated into OpenJDK now if possible. You >> can find the full webrev here: >> >> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > The changes seem to touch almost only shark files so these should be fine. One question though: > > + develop(bool, SharkShowCompiledMethods, false, \ > > Isn't PrintCompilation doing that already? > > The shared code changes look good. I filed: > > 8003868: fix shark for latest HotSpot and LLVM > > -- Chris > >> >> There are also a very minor change required in JDK: >> >> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >> >> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >> and jdk repositories respectivly. Find my build script here: >> >> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >> >> (Review and adjust variables to your settings, most notably you will >> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >> >> Please let me know if there are any issues or how we can get this >> integrated into Hotspot. Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, from /usr/local/include/llvm/ADT/PointerIntPair.h:17, from /usr/local/include/llvm/Use.h:28, from /usr/local/include/llvm/Value.h:17, from /usr/local/include/llvm/Argument.h:17, from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" and: In file included from /usr/local/include/llvm/Attributes.h:18, from /usr/local/include/llvm/Argument.h:18, from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope Not sure if the latter is because of the former one. Have you seen this before? -- Chris >> >> Best regards, >> Roman >> >> > From alejandro.murillo at oracle.com Wed Nov 21 12:53:48 2012 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 21 Nov 2012 13:53:48 -0700 Subject: Code review request CR 8003254: make jdk7u12 the default jprt release for hs24 In-Reply-To: <50522A7E.60803@oracle.com> References: <50522A7E.60803@oracle.com> Message-ID: <50AD3F5C.1070502@oracle.com> Can someone please review this change: make jdk7u12 the default jprt release for hs24 http://cr.openjdk.java.net/~amurillo/webrevs/8003254 8003254 : make jdk7u12 the default jprt release for hs24 thanks -- Alejandro From rkennke at redhat.com Wed Nov 21 12:54:11 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 21:54:11 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> Message-ID: <1353531251.1744.53.camel@mercury> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > > > On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > > >> Hi there, > >> > >> during the last days I worked on fixing the Shark compiler for Hotspot > >> to get it to build and run again, with the latest Hotspot code and LLVM. > >> Here are some details: > >> > >> - A lot of changes are just to make it build and the compiler happy. For > >> example, I had to remove a lot of 'const' qualifiers because of API > >> changes in LLVM. > >> - Most other changes have to do with the split of the oop and metadata > >> class hierarchies in Hotspot. > >> - Then there have been a few changes caused by LLVM changes and > >> improvements, most notably the LLVM intrinsics for atomic operations > >> (memory barrier and cmpxchg) have been removed and now have a > >> representation directly in LLVM's IR. This makes our code a little > >> nicer. > >> > >> I tested this by running a number of applications, most notably Eclipse > >> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >> bunch of other stuff. > >> > >> I would like to get this integrated into OpenJDK now if possible. You > >> can find the full webrev here: > >> > >> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > > > The changes seem to touch almost only shark files so these should be fine. One question though: > > > > + develop(bool, SharkShowCompiledMethods, false, \ > > > > Isn't PrintCompilation doing that already? > > > > The shared code changes look good. I filed: > > > > 8003868: fix shark for latest HotSpot and LLVM > > > > -- Chris > > > >> > >> There are also a very minor change required in JDK: > >> > >> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >> > >> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >> and jdk repositories respectivly. Find my build script here: > >> > >> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >> > >> (Review and adjust variables to your settings, most notably you will > >> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >> > >> Please let me know if there are any issues or how we can get this > >> integrated into Hotspot. > > Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > > In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > from /usr/local/include/llvm/Use.h:28, > from /usr/local/include/llvm/Value.h:17, > from /usr/local/include/llvm/Argument.h:17, > from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > > and: > > In file included from /usr/local/include/llvm/Attributes.h:18, > from /usr/local/include/llvm/Argument.h:18, > from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > > Not sure if the latter is because of the former one. Have you seen this before? Yes, it's caused by the former. And yes, I have seen it before. IIRC, this happens when certain cflags are not set correctly. The script jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the correct flags. In order for this to work, you need to have the full path to the llvm-config script set in the LLVM_CONFIG env variable. Were you using the build script that I provided? Roman From rkennke at redhat.com Wed Nov 21 13:01:28 2012 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 21 Nov 2012 22:01:28 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> Message-ID: <1353531688.1744.55.camel@mercury> Am Mittwoch, den 21.11.2012, 11:43 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > > Hi there, > > > > during the last days I worked on fixing the Shark compiler for Hotspot > > to get it to build and run again, with the latest Hotspot code and LLVM. > > Here are some details: > > > > - A lot of changes are just to make it build and the compiler happy. For > > example, I had to remove a lot of 'const' qualifiers because of API > > changes in LLVM. > > - Most other changes have to do with the split of the oop and metadata > > class hierarchies in Hotspot. > > - Then there have been a few changes caused by LLVM changes and > > improvements, most notably the LLVM intrinsics for atomic operations > > (memory barrier and cmpxchg) have been removed and now have a > > representation directly in LLVM's IR. This makes our code a little > > nicer. > > > > I tested this by running a number of applications, most notably Eclipse > > (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > > bunch of other stuff. > > > > I would like to get this integrated into OpenJDK now if possible. You > > can find the full webrev here: > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > The changes seem to touch almost only shark files so these should be fine. One question though: > > + develop(bool, SharkShowCompiledMethods, false, \ > > Isn't PrintCompilation doing that already? Oh yes, didn't know that one! And it's even much better. > The shared code changes look good. I filed: > > 8003868: fix shark for latest HotSpot and LLVM Thanks. I removed the above flag, and posted another webrev: http://cr.openjdk.java.net/~rkennke/shark/webrev.01/ Cheers, Roman From John.Coomes at oracle.com Wed Nov 21 14:11:23 2012 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 21 Nov 2012 14:11:23 -0800 Subject: Code review request CR 8003254: make jdk7u12 the default jprt release for hs24 In-Reply-To: <50AD3F5C.1070502@oracle.com> References: <50522A7E.60803@oracle.com> <50AD3F5C.1070502@oracle.com> Message-ID: <20653.20875.313447.159311@oracle.com> Alejandro E Murillo (alejandro.murillo at oracle.com) wrote: > > > Can someone please review this change: make jdk7u12 the default jprt > release for hs24 > http://cr.openjdk.java.net/~amurillo/webrevs/8003254 > > 8003254 : make jdk7u12 the default jprt release for hs24 Looks good to me. -John From christian.thalinger at oracle.com Wed Nov 21 14:17:01 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 14:17:01 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353531251.1744.53.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> Message-ID: On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >> >>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>> >>>> Hi there, >>>> >>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>> Here are some details: >>>> >>>> - A lot of changes are just to make it build and the compiler happy. For >>>> example, I had to remove a lot of 'const' qualifiers because of API >>>> changes in LLVM. >>>> - Most other changes have to do with the split of the oop and metadata >>>> class hierarchies in Hotspot. >>>> - Then there have been a few changes caused by LLVM changes and >>>> improvements, most notably the LLVM intrinsics for atomic operations >>>> (memory barrier and cmpxchg) have been removed and now have a >>>> representation directly in LLVM's IR. This makes our code a little >>>> nicer. >>>> >>>> I tested this by running a number of applications, most notably Eclipse >>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>> bunch of other stuff. >>>> >>>> I would like to get this integrated into OpenJDK now if possible. You >>>> can find the full webrev here: >>>> >>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>> >>> The changes seem to touch almost only shark files so these should be fine. One question though: >>> >>> + develop(bool, SharkShowCompiledMethods, false, \ >>> >>> Isn't PrintCompilation doing that already? >>> >>> The shared code changes look good. I filed: >>> >>> 8003868: fix shark for latest HotSpot and LLVM >>> >>> -- Chris >>> >>>> >>>> There are also a very minor change required in JDK: >>>> >>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>> >>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>> and jdk repositories respectivly. Find my build script here: >>>> >>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>> >>>> (Review and adjust variables to your settings, most notably you will >>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>> >>>> Please let me know if there are any issues or how we can get this >>>> integrated into Hotspot. >> >> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >> >> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >> from /usr/local/include/llvm/Use.h:28, >> from /usr/local/include/llvm/Value.h:17, >> from /usr/local/include/llvm/Argument.h:17, >> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >> >> and: >> >> In file included from /usr/local/include/llvm/Attributes.h:18, >> from /usr/local/include/llvm/Argument.h:18, >> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >> >> Not sure if the latter is because of the former one. Have you seen this before? > > Yes, it's caused by the former. And yes, I have seen it before. IIRC, > this happens when certain cflags are not set correctly. The script > jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > correct flags. In order for this to work, you need to have the full path > to the llvm-config script set in the LLVM_CONFIG env variable. Were you > using the build script that I provided? No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. Now that I have the LLVM_* variables it's even worse: /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness It's probably this guy: -Wcast-qual -- Chris > > Roman > > From christian.thalinger at oracle.com Wed Nov 21 14:22:53 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 14:22:53 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> Message-ID: <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>> >>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>> >>>>> Hi there, >>>>> >>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>> Here are some details: >>>>> >>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>> changes in LLVM. >>>>> - Most other changes have to do with the split of the oop and metadata >>>>> class hierarchies in Hotspot. >>>>> - Then there have been a few changes caused by LLVM changes and >>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>> representation directly in LLVM's IR. This makes our code a little >>>>> nicer. >>>>> >>>>> I tested this by running a number of applications, most notably Eclipse >>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>> bunch of other stuff. >>>>> >>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>> can find the full webrev here: >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>> >>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>> >>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>> >>>> Isn't PrintCompilation doing that already? >>>> >>>> The shared code changes look good. I filed: >>>> >>>> 8003868: fix shark for latest HotSpot and LLVM >>>> >>>> -- Chris >>>> >>>>> >>>>> There are also a very minor change required in JDK: >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>> >>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>> and jdk repositories respectivly. Find my build script here: >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>> >>>>> (Review and adjust variables to your settings, most notably you will >>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>> >>>>> Please let me know if there are any issues or how we can get this >>>>> integrated into Hotspot. >>> >>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>> >>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>> from /usr/local/include/llvm/Use.h:28, >>> from /usr/local/include/llvm/Value.h:17, >>> from /usr/local/include/llvm/Argument.h:17, >>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>> >>> and: >>> >>> In file included from /usr/local/include/llvm/Attributes.h:18, >>> from /usr/local/include/llvm/Argument.h:18, >>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>> >>> Not sure if the latter is because of the former one. Have you seen this before? >> >> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >> this happens when certain cflags are not set correctly. The script >> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >> correct flags. In order for this to work, you need to have the full path >> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >> using the build script that I provided? > > No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > > Now that I have the LLVM_* variables it's even worse: > > /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > > It's probably this guy: -Wcast-qual Got it: $ java -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) -- Chris > > -- Chris > >> >> Roman >> >> > From christian.thalinger at oracle.com Wed Nov 21 14:52:46 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 14:52:46 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> Message-ID: <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >> >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: >> >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>>> >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>>> >>>>>> Hi there, >>>>>> >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>>> Here are some details: >>>>>> >>>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>>> changes in LLVM. >>>>>> - Most other changes have to do with the split of the oop and metadata >>>>>> class hierarchies in Hotspot. >>>>>> - Then there have been a few changes caused by LLVM changes and >>>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>>> representation directly in LLVM's IR. This makes our code a little >>>>>> nicer. >>>>>> >>>>>> I tested this by running a number of applications, most notably Eclipse >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>>> bunch of other stuff. >>>>>> >>>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>>> can find the full webrev here: >>>>>> >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>>> >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>>> >>>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>>> >>>>> Isn't PrintCompilation doing that already? >>>>> >>>>> The shared code changes look good. I filed: >>>>> >>>>> 8003868: fix shark for latest HotSpot and LLVM >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> There are also a very minor change required in JDK: >>>>>> >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>>> >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>>> and jdk repositories respectivly. Find my build script here: >>>>>> >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>>> >>>>>> (Review and adjust variables to your settings, most notably you will >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>>> >>>>>> Please let me know if there are any issues or how we can get this >>>>>> integrated into Hotspot. >>>> >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>>> >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>>> from /usr/local/include/llvm/Use.h:28, >>>> from /usr/local/include/llvm/Value.h:17, >>>> from /usr/local/include/llvm/Argument.h:17, >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>>> >>>> and: >>>> >>>> In file included from /usr/local/include/llvm/Attributes.h:18, >>>> from /usr/local/include/llvm/Argument.h:18, >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>>> >>>> Not sure if the latter is because of the former one. Have you seen this before? >>> >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >>> this happens when certain cflags are not set correctly. The script >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >>> correct flags. In order for this to work, you need to have the full path >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >>> using the build script that I provided? >> >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. >> >> Now that I have the LLVM_* variables it's even worse: >> >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness >> >> It's probably this guy: -Wcast-qual > > Got it: > > $ java -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) I ran the compiler regression tests and Shark crashes in 5091921: cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ Directory "/export/twisti/jtreg/scratch" not found: creating Passed: compiler/5091921/Test5091921.java Passed: compiler/5091921/Test6186134.java Passed: compiler/5091921/Test6196102.java Passed: compiler/5091921/Test6357214.java Passed: compiler/5091921/Test6559156.java Passed: compiler/5091921/Test6753639.java Passed: compiler/5091921/Test6850611.java Passed: compiler/5091921/Test6890943.java Passed: compiler/5091921/Test6897150.java Passed: compiler/5091921/Test6905845.java Passed: compiler/5091921/Test6931567.java /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts You can also run all them with a simple make in test/ by setting: PRODUCT_HOME=$JAVA_HOME TESTDIRS=compiler -- Chris > > -- Chris > >> >> -- Chris >> >>> >>> Roman >>> >>> >> > From stefan.karlsson at oracle.com Thu Nov 22 06:14:34 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 22 Nov 2012 15:14:34 +0100 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated Message-ID: <50AE334A.604@oracle.com> http://cr.openjdk.java.net/~stefank/8003720/webrev/ Description from CR: In virtual calls the Method pointer in the interpreter stack frame is not kept alive by anything other than the "this" pointers to that method. If bytecodes overwrite the "this" pointer, then call a full GC, the class loader containing the Method* can be unloaded and the Method* deallocated. This is also a problem with JSR292 MethodHandle static code because the MethodHandle containing the mirror for the interpreted method Method* is not on the stack if a GC occurs. Fix proposal: The "obvious" solution to this problem would be to apply the root scanning OopClosure to the Klass::_java_mirror field of the method in the interpreted frame. However, doing this might cause us to scan the same metadata oop location more than once, which is not allowed by some of the HotSpot GCs. We currently solve similar situations by always "claiming" and start scanning from the ClassLoaderData and then proceed down into the Klasses of that class loader. For this bug we do the same. All old collections, where class unloading can occur, pass down a closure that is applied to the ClassLoaderData of the Klass of the Method in the interpreted frame. This closure does the claiming and proceeds to scan the class metadata. Note that during young collections, where we don't do class unloading, all classes are already used as strong roots and we don't have to apply this new closure in the interpreted frame. Testing: The added test was initially written by John Rose. I only ported it to JTreg and made some artistic cleanups to it. thanks, StefanK From rkennke at redhat.com Thu Nov 22 08:48:10 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 17:48:10 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> Message-ID: <1353602890.11230.13.camel@mercury> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > >> > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >> > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>> > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>> > >>>>>> Hi there, > >>>>>> > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>> Here are some details: > >>>>>> > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>> changes in LLVM. > >>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>> class hierarchies in Hotspot. > >>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>> nicer. > >>>>>> > >>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>> bunch of other stuff. > >>>>>> > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>> can find the full webrev here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>> > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>> > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>> > >>>>> Isn't PrintCompilation doing that already? > >>>>> > >>>>> The shared code changes look good. I filed: > >>>>> > >>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>> > >>>>> -- Chris > >>>>> > >>>>>> > >>>>>> There are also a very minor change required in JDK: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>> > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>> > >>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>> > >>>>>> Please let me know if there are any issues or how we can get this > >>>>>> integrated into Hotspot. > >>>> > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>> > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>> from /usr/local/include/llvm/Use.h:28, > >>>> from /usr/local/include/llvm/Value.h:17, > >>>> from /usr/local/include/llvm/Argument.h:17, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>> > >>>> and: > >>>> > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>> from /usr/local/include/llvm/Argument.h:18, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>> > >>>> Not sure if the latter is because of the former one. Have you seen this before? > >>> > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>> this happens when certain cflags are not set correctly. The script > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>> correct flags. In order for this to work, you need to have the full path > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>> using the build script that I provided? > >> > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >> > >> Now that I have the LLVM_* variables it's even worse: > >> > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >> > >> It's probably this guy: -Wcast-qual > > > > Got it: > > > > $ java -version > > java version "1.8.0-ea" > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > I ran the compiler regression tests and Shark crashes in 5091921: > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > Directory "/export/twisti/jtreg/scratch" not found: creating > Passed: compiler/5091921/Test5091921.java > Passed: compiler/5091921/Test6186134.java > Passed: compiler/5091921/Test6196102.java > Passed: compiler/5091921/Test6357214.java > Passed: compiler/5091921/Test6559156.java > Passed: compiler/5091921/Test6753639.java > Passed: compiler/5091921/Test6850611.java > Passed: compiler/5091921/Test6890943.java > Passed: compiler/5091921/Test6897150.java > Passed: compiler/5091921/Test6905845.java > Passed: compiler/5091921/Test6931567.java > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > You can also run all them with a simple make in test/ by setting: > > PRODUCT_HOME=$JAVA_HOME > TESTDIRS=compiler > This is interesting. I am not getting segfaults, but trip over assertions inside LLVM (probably the same thingy). I tried looking (and running through verifier) at the LLVM IR code, but nothing suspicious. Then I turned off optimizations in LLVM and suddenly everything passed (except for some tests that time out... probably performance tests that time out because shark is too slow?). It could be a bug in LLVM, I suspect this: http://llvm.org/bugs/show_bug.cgi?id=12470 I am not sure though. I added a -XX:SharkOptimizationLevel switch to select an optimization level at runtime. I will also check out the LLVM-3.2 RC code and see if that's any better. I will keep you posted. Roman From rkennke at redhat.com Thu Nov 22 09:47:45 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 18:47:45 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353602890.11230.13.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353602890.11230.13.camel@mercury> Message-ID: <1353606465.11230.15.camel@mercury> Am Donnerstag, den 22.11.2012, 17:48 +0100 schrieb Roman Kennke: > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > > > >> > > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > > >> > > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > > >>>> > > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > >>>>> > > >>>>>> Hi there, > > >>>>>> > > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > > >>>>>> Here are some details: > > >>>>>> > > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > > >>>>>> changes in LLVM. > > >>>>>> - Most other changes have to do with the split of the oop and metadata > > >>>>>> class hierarchies in Hotspot. > > >>>>>> - Then there have been a few changes caused by LLVM changes and > > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > > >>>>>> representation directly in LLVM's IR. This makes our code a little > > >>>>>> nicer. > > >>>>>> > > >>>>>> I tested this by running a number of applications, most notably Eclipse > > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > > >>>>>> bunch of other stuff. > > >>>>>> > > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > > >>>>>> can find the full webrev here: > > >>>>>> > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > >>>>> > > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > > >>>>> > > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > > >>>>> > > >>>>> Isn't PrintCompilation doing that already? > > >>>>> > > >>>>> The shared code changes look good. I filed: > > >>>>> > > >>>>> 8003868: fix shark for latest HotSpot and LLVM > > >>>>> > > >>>>> -- Chris > > >>>>> > > >>>>>> > > >>>>>> There are also a very minor change required in JDK: > > >>>>>> > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > >>>>>> > > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > > >>>>>> and jdk repositories respectivly. Find my build script here: > > >>>>>> > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > > >>>>>> > > >>>>>> (Review and adjust variables to your settings, most notably you will > > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > > >>>>>> > > >>>>>> Please let me know if there are any issues or how we can get this > > >>>>>> integrated into Hotspot. > > >>>> > > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > > >>>> > > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > > >>>> from /usr/local/include/llvm/Use.h:28, > > >>>> from /usr/local/include/llvm/Value.h:17, > > >>>> from /usr/local/include/llvm/Argument.h:17, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > > >>>> > > >>>> and: > > >>>> > > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > > >>>> from /usr/local/include/llvm/Argument.h:18, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > > >>>> > > >>>> Not sure if the latter is because of the former one. Have you seen this before? > > >>> > > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > > >>> this happens when certain cflags are not set correctly. The script > > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > > >>> correct flags. In order for this to work, you need to have the full path > > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > > >>> using the build script that I provided? > > >> > > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > > >> > > >> Now that I have the LLVM_* variables it's even worse: > > >> > > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > > >> > > >> It's probably this guy: -Wcast-qual > > > > > > Got it: > > > > > > $ java -version > > > java version "1.8.0-ea" > > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > > > I ran the compiler regression tests and Shark crashes in 5091921: > > > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > > Directory "/export/twisti/jtreg/scratch" not found: creating > > Passed: compiler/5091921/Test5091921.java > > Passed: compiler/5091921/Test6186134.java > > Passed: compiler/5091921/Test6196102.java > > Passed: compiler/5091921/Test6357214.java > > Passed: compiler/5091921/Test6559156.java > > Passed: compiler/5091921/Test6753639.java > > Passed: compiler/5091921/Test6850611.java > > Passed: compiler/5091921/Test6890943.java > > Passed: compiler/5091921/Test6897150.java > > Passed: compiler/5091921/Test6905845.java > > Passed: compiler/5091921/Test6931567.java > > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > > > You can also run all them with a simple make in test/ by setting: > > > > PRODUCT_HOME=$JAVA_HOME > > TESTDIRS=compiler > > > > This is interesting. I am not getting segfaults, but trip over > assertions inside LLVM (probably the same thingy). I tried looking (and > running through verifier) at the LLVM IR code, but nothing suspicious. > Then I turned off optimizations in LLVM and suddenly everything passed > (except for some tests that time out... probably performance tests that > time out because shark is too slow?). It could be a bug in LLVM, I > suspect this: > > http://llvm.org/bugs/show_bug.cgi?id=12470 > > I am not sure though. I added a -XX:SharkOptimizationLevel switch to > select an optimization level at runtime. I will also check out the > LLVM-3.2 RC code and see if that's any better. I will keep you posted. So I tried with 3.2. Good news is that only minimal changes in Shark are required to do this, and another good news is that it does indeed make the crash go away :-) Will send out the patch later tonight (needs cleanup, and I need food ;-) ). Roman From aleksey.shipilev at oracle.com Thu Nov 22 13:33:40 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 23 Nov 2012 01:33:40 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields Message-ID: <50AE9A34.4020001@oracle.com> Hi, After some internal discussions with Doug Lea, Dave Dice and others, I would like to solicit the initial feedback on the implementation of JEP-142, aka @Contended [1]: http://openjdk.java.net/jeps/142 The webrev for the initial version is here: http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ Implementation overview. Hotspot code is currently laying out the fields to optimize the memory footprint, rearranging fields freely to both satisfy alignment requirements for fields and making the less gaps possible. We leverage the same infrastructure to exempt specific fields from the packing, and pushing them outside the dense packed block at sparse offsets, naturally making up the appropriate padding. In order to demarcate the specific classes and/or fields eligible for such the padding, we use new @Contended annotation. Runtime discovery of annotations reuses the code John (?) laid out for some of JSR292-specific annotations. The behavior of this annotation is as follows: A. Marking the class as contended: @Contended public static class ContendedTest2 { private Object plainField1; private Object plainField2; private Object plainField3; private Object plainField4; } ...makes the entire field block to be padded from the both sides: (below is the output of new tracing -XX:+PrintFieldLayout) TestContended$ContendedTest2: field layout Entire class is marked contended @140 --- instance fields start --- @140 "plainField1" Ljava.lang.Object; @144 "plainField2" Ljava.lang.Object; @148 "plainField3" Ljava.lang.Object; @152 "plainField4" Ljava.lang.Object; @288 --- instance fields end --- @288 --- instance ends --- Note that we use 128 bytes, twice the cache line size on most hardware to adjust for adjacent sector prefetchers extending the false sharing collisions to two cache lines. B. Marking the field as contended: public static class ContendedTest1 { @Contended private Object contendedField1; private Object plainField1; private Object plainField2; private Object plainField3; private Object plainField4; } ...pushes the field out of dense block and effectively applies padding: TestContended$ContendedTest1: field layout @ 12 --- instance fields start --- @ 12 "plainField1" Ljava.lang.Object; @ 16 "plainField2" Ljava.lang.Object; @ 20 "plainField3" Ljava.lang.Object; @ 24 "plainField4" Ljava.lang.Object; @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) @288 --- instance fields end --- @288 --- instance ends --- C. Marking multiple fields makes each field padded: public static class ContendedTest4 { @Contended private Object contendedField1; @Contended private Object contendedField2; private Object plainField3; private Object plainField4; } ...pushes both fields with individual padding for each: TestContended$ContendedTest4: field layout @ 12 --- instance fields start --- @ 12 "plainField3" Ljava.lang.Object; @ 16 "plainField4" Ljava.lang.Object; @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) @416 --- instance fields end --- @416 --- instance ends --- *** IV. Contention groups There are cases where you want to separate the *group* of fields that are experiencing contention with everything else but not pairwise. This is the usual thing for some of the code updating two fields at once. While marking both with @Contended would be sufficient, we can optimize the memory footprint by not applying padding between them. In order to demarcate these groups, we have the parameter in the annotation describing the equivalence class for contention group. So that: public static class ContendedTest5 { @Contended("updater1") private Object contendedField1; @Contended("updater1") private Object contendedField2; @Contended("updater2") private Object contendedField3; private Object plainField5; private Object plainField6; } ...is laid out as: TestContended$ContendedTest5: field layout @ 12 --- instance fields start --- @ 12 "plainField5" Ljava.lang.Object; @ 16 "plainField6" Ljava.lang.Object; @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) @416 --- instance fields end --- @416 --- instance ends --- Note $contendedField1 and $contendedField2 are padded from everything else, but still densely packed with each other. The code is known to work at least on Linux x86-64, tested with a few microtests. The layout of fields without @Contended is not affected, so this is presumably a safe change. I will try to run more tests against this implementation with JPRT, but will appreciate the design, API, and draft implementation review meanwhile... Thanks, Aleksey. From martijnverburg at gmail.com Thu Nov 22 13:55:31 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 22 Nov 2012 21:55:31 +0000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AE9A34.4020001@oracle.com> References: <50AE9A34.4020001@oracle.com> Message-ID: Hi Aleksey, A couple of small questions/comments from an enthusiastic amateur, take with a grain of salt (inline). So this in theory takes care of the False Sharing problem without resorting to tricks, great! Note that we use 128 bytes, twice the cache line size on most hardware to adjust for adjacent sector prefetchers extending the false sharing > collisions to two cache lines. > Is this based on detecting the size of the cache line of the CPU the JVM is running on and multiplying by two? I can see architectures changing over time (bigger cache lines? Who knows). Also, wouldn't a padding of 64 bytes be fine to avoid prefetchers for a 32 byte cache line based CPU whereas 128 is overkill? *** IV. Contention groups > > There are cases where you want to separate the *group* of fields that > are experiencing contention with everything else but not pairwise. This > is the usual thing for some of the code updating two fields at once. > While marking both with @Contended would be sufficient, we can optimize > the memory footprint by not applying padding between them. In order to > demarcate these groups, we have the parameter in the annotation > describing the equivalence class for contention group. > > So that: > > public static class ContendedTest5 { > @Contended("updater1") > private Object contendedField1; > > @Contended("updater1") > private Object contendedField2; > > @Contended("updater2") > private Object contendedField3; > > private Object plainField5; > private Object plainField6; > } > > ...is laid out as: > > TestContended$ContendedTest5: field layout > @ 12 --- instance fields start --- > @ 12 "plainField5" Ljava.lang.Object; > @ 16 "plainField6" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) > @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) > @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) > @416 --- instance fields end --- > @416 --- instance ends --- > > Note $contendedField1 and $contendedField2 are padded from everything > else, but still densely packed with each other. > That's a nice addition. > The code is known to work at least on Linux x86-64, tested with a few > microtests. The layout of fields without @Contended is not affected, so > this is presumably a safe change. I will try to run more tests against > this implementation with JPRT, but will appreciate the design, API, and > draft implementation review meanwhile... > I've forwarded this to a few folks who actually know what they're talking about and have complained about false sharing for some time, hopefully they'll pop in. As an extra aside - I'm wondering if the IDE vendors could pick up on this and actually visualise for you how your class will be laid out. Would be useful when applying @Contented and making sure it's padding as you'd want it to. Cheers, Martijn From aleksey.shipilev at oracle.com Thu Nov 22 14:00:46 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 23 Nov 2012 02:00:46 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> Message-ID: <50AEA08E.90207@oracle.com> Hi Martijn, On 11/23/2012 01:55 AM, Martijn Verburg wrote: > Is this based on detecting the size of the cache line of the CPU the > JVM is running on and multiplying by two? Not yet. We use the constant 128 bytes, overridable with -XX:FieldPaddingWidth. The cache line detection is there in Hotspot, and I still need to wire this up into the patch. The really sad part is that we can not detect the presence of hardware prefetcher running without reading the MSRs, which might in the end require superuser privileges. > As an extra aside - I'm wondering if the IDE vendors could pick up > on this and actually visualise for you how your class will be laid > out. Would be useful when applying @Contented and making sure it's > padding as you'd want it to. Yup, as soon as class is loaded by the VM, it is actually pretty easy to do, see: https://github.com/shipilev/java-field-layout -Aleksey. From rkennke at redhat.com Thu Nov 22 14:00:53 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 22 Nov 2012 23:00:53 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353606465.11230.15.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353602890.11230.13.camel@mercury> <1353606465.11230.15.camel@mercury> Message-ID: <1353621653.11230.24.camel@mercury> Am Donnerstag, den 22.11.2012, 18:47 +0100 schrieb Roman Kennke: > Am Donnerstag, den 22.11.2012, 17:48 +0100 schrieb Roman Kennke: > > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > > > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > > > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > > > > > >> > > > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > > > >> > > > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > > > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > > > >>>> > > > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > > > >>>>> > > > >>>>>> Hi there, > > > >>>>>> > > > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > > > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > > > >>>>>> Here are some details: > > > >>>>>> > > > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > > > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > > > >>>>>> changes in LLVM. > > > >>>>>> - Most other changes have to do with the split of the oop and metadata > > > >>>>>> class hierarchies in Hotspot. > > > >>>>>> - Then there have been a few changes caused by LLVM changes and > > > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > > > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > > > >>>>>> representation directly in LLVM's IR. This makes our code a little > > > >>>>>> nicer. > > > >>>>>> > > > >>>>>> I tested this by running a number of applications, most notably Eclipse > > > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > > > >>>>>> bunch of other stuff. > > > >>>>>> > > > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > > > >>>>>> can find the full webrev here: > > > >>>>>> > > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > > > >>>>> > > > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > > > >>>>> > > > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > > > >>>>> > > > >>>>> Isn't PrintCompilation doing that already? > > > >>>>> > > > >>>>> The shared code changes look good. I filed: > > > >>>>> > > > >>>>> 8003868: fix shark for latest HotSpot and LLVM > > > >>>>> > > > >>>>> -- Chris > > > >>>>> > > > >>>>>> > > > >>>>>> There are also a very minor change required in JDK: > > > >>>>>> > > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > > >>>>>> > > > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > > > >>>>>> and jdk repositories respectivly. Find my build script here: > > > >>>>>> > > > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > > > >>>>>> > > > >>>>>> (Review and adjust variables to your settings, most notably you will > > > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > > > >>>>>> > > > >>>>>> Please let me know if there are any issues or how we can get this > > > >>>>>> integrated into Hotspot. > > > >>>> > > > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > > > >>>> > > > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > > > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > > > >>>> from /usr/local/include/llvm/Use.h:28, > > > >>>> from /usr/local/include/llvm/Value.h:17, > > > >>>> from /usr/local/include/llvm/Argument.h:17, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > > > >>>> > > > >>>> and: > > > >>>> > > > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > > > >>>> from /usr/local/include/llvm/Argument.h:18, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > > > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > > > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > > > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > > > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > > > >>>> > > > >>>> Not sure if the latter is because of the former one. Have you seen this before? > > > >>> > > > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > > > >>> this happens when certain cflags are not set correctly. The script > > > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > > > >>> correct flags. In order for this to work, you need to have the full path > > > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > > > >>> using the build script that I provided? > > > >> > > > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > > > >> > > > >> Now that I have the LLVM_* variables it's even worse: > > > >> > > > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > > > >> > > > >> It's probably this guy: -Wcast-qual > > > > > > > > Got it: > > > > > > > > $ java -version > > > > java version "1.8.0-ea" > > > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > > > > > I ran the compiler regression tests and Shark crashes in 5091921: > > > > > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > > > Directory "/export/twisti/jtreg/scratch" not found: creating > > > Passed: compiler/5091921/Test5091921.java > > > Passed: compiler/5091921/Test6186134.java > > > Passed: compiler/5091921/Test6196102.java > > > Passed: compiler/5091921/Test6357214.java > > > Passed: compiler/5091921/Test6559156.java > > > Passed: compiler/5091921/Test6753639.java > > > Passed: compiler/5091921/Test6850611.java > > > Passed: compiler/5091921/Test6890943.java > > > Passed: compiler/5091921/Test6897150.java > > > Passed: compiler/5091921/Test6905845.java > > > Passed: compiler/5091921/Test6931567.java > > > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > > > > > You can also run all them with a simple make in test/ by setting: > > > > > > PRODUCT_HOME=$JAVA_HOME > > > TESTDIRS=compiler > > > > > > > This is interesting. I am not getting segfaults, but trip over > > assertions inside LLVM (probably the same thingy). I tried looking (and > > running through verifier) at the LLVM IR code, but nothing suspicious. > > Then I turned off optimizations in LLVM and suddenly everything passed > > (except for some tests that time out... probably performance tests that > > time out because shark is too slow?). It could be a bug in LLVM, I > > suspect this: > > > > http://llvm.org/bugs/show_bug.cgi?id=12470 > > > > I am not sure though. I added a -XX:SharkOptimizationLevel switch to > > select an optimization level at runtime. I will also check out the > > LLVM-3.2 RC code and see if that's any better. I will keep you posted. > > So I tried with 3.2. Good news is that only minimal changes in Shark are > required to do this, and another good news is that it does indeed make > the crash go away :-) Will send out the patch later tonight (needs > cleanup, and I need food ;-) ). Ok, so here it comes: http://cr.openjdk.java.net/~rkennke/shark/webrev.02/ The changes are (basically to enable support for LLVM3.2): - Changed include for llvm/Support/IRBuilder.h > llvm/IRBuilder.h and kept the old one in an #if SHARK_LLVM_VERSION <= 31 block. - Added -XX:SharkOptimizationLevel=None|Less|Default|Aggressive option, which is passed through to LLVM. - Changed -XX:+VerifyFunctions to -XX:VerifyFunction=$PATTERN to selectively verify functions. - Changed SetCurrentDebugType -> setCurrentDebugType (and kept old one in a version-check-block like above). - Changed call to LLVM intrinsic llvm.memset.i32 to llvm.memset.p0i8.i32 (that has already been changed pre-3.2, but apparently the old one is still working, but the verifier complains about it). I ran all the tests in test/compiler and they all pass, except one that timed out (dunno) and a few that failed with exceptions due to missing JSR292 and one segfault (haven't looked yet). Cheers, Roman From david.holmes at oracle.com Thu Nov 22 16:01:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Nov 2012 10:01:42 +1000 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <50AE334A.604@oracle.com> References: <50AE334A.604@oracle.com> Message-ID: <50AEBCE6.50004@oracle.com> Hi Stefan, Not my area so a minor comment not a review :) thread.hpp 481 // GC support 482 // Apply "f->do_oop" to all root oops in "this". 483 // Apply "cf->do_code_blob" (if !NULL) to all code blobs active in frames 484 virtual void oops_do(OopClosure* f, CLDToOopClosure* cld_f, CodeBlobClosure* cf); can you add a comment that cld_f is not used/needed by Thread::oops_do Thanks, David On 23/11/2012 12:14 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8003720/webrev/ > > Description from CR: > In virtual calls the Method pointer in the interpreter stack frame is > not kept alive by anything other than the "this" pointers to that > method. If bytecodes overwrite the "this" pointer, then call a full GC, > the class loader containing the Method* can be unloaded and the Method* > deallocated. > > This is also a problem with JSR292 MethodHandle static code because the > MethodHandle containing the mirror for the interpreted method Method* is > not on the stack if a GC occurs. > > Fix proposal: > The "obvious" solution to this problem would be to apply the root > scanning OopClosure to the Klass::_java_mirror field of the method in > the interpreted frame. However, doing this might cause us to scan the > same metadata oop location more than once, which is not allowed by some > of the HotSpot GCs. We currently solve similar situations by always > "claiming" and start scanning from the ClassLoaderData and then proceed > down into the Klasses of that class loader. > > For this bug we do the same. All old collections, where class unloading > can occur, pass down a closure that is applied to the ClassLoaderData of > the Klass of the Method in the interpreted frame. This closure does the > claiming and proceeds to scan the class metadata. Note that during young > collections, where we don't do class unloading, all classes are already > used as strong roots and we don't have to apply this new closure in the > interpreted frame. > > Testing: > The added test was initially written by John Rose. I only ported it to > JTreg and made some artistic cleanups to it. > > thanks, > StefanK From alejandro.murillo at oracle.com Thu Nov 22 22:27:15 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 23 Nov 2012 06:27:15 +0000 Subject: hg: hsx/hsx24/hotspot: 8003254: make jdk7u12 the default jprt release for hs24 Message-ID: <20121123062721.90D4F47AEB@hg.openjdk.java.net> Changeset: 23cbe1ef22e0 Author: amurillo Date: 2012-11-21 12:26 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/23cbe1ef22e0 8003254: make jdk7u12 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties From stefan.karlsson at oracle.com Fri Nov 23 00:19:10 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 23 Nov 2012 09:19:10 +0100 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <50AEBCE6.50004@oracle.com> References: <50AE334A.604@oracle.com> <50AEBCE6.50004@oracle.com> Message-ID: <50AF317E.8080205@oracle.com> David, Thanks for taking a look at this. I've added a comment regarding the cld_f: // GC support // Apply "f->do_oop" to all root oops in "this". *+ // Apply "cld_f->do_cld" to CLDs that are otherwise not kept alive.* *+ // Used by JavaThread::oops_do.* // Apply "cf->do_code_blob" (if !NULL) to all code blobs active in frames *! virtual void oops_do(OopClosure* f,_CLDToOopClosure* cld_f,_CodeBlobClosure* cf);* http://cr.openjdk.java.net/~stefank/8003720/webrev.01 thanks, StefanK On 11/23/2012 01:01 AM, David Holmes wrote: > Hi Stefan, > > Not my area so a minor comment not a review :) > > thread.hpp > > 481 // GC support > 482 // Apply "f->do_oop" to all root oops in "this". > 483 // Apply "cf->do_code_blob" (if !NULL) to all code blobs active > in frames > 484 virtual void oops_do(OopClosure* f, CLDToOopClosure* cld_f, > CodeBlobClosure* cf); > > can you add a comment that cld_f is not used/needed by Thread::oops_do > > Thanks, > David > > On 23/11/2012 12:14 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8003720/webrev/ >> >> Description from CR: >> In virtual calls the Method pointer in the interpreter stack frame is >> not kept alive by anything other than the "this" pointers to that >> method. If bytecodes overwrite the "this" pointer, then call a full GC, >> the class loader containing the Method* can be unloaded and the Method* >> deallocated. >> >> This is also a problem with JSR292 MethodHandle static code because the >> MethodHandle containing the mirror for the interpreted method Method* is >> not on the stack if a GC occurs. >> >> Fix proposal: >> The "obvious" solution to this problem would be to apply the root >> scanning OopClosure to the Klass::_java_mirror field of the method in >> the interpreted frame. However, doing this might cause us to scan the >> same metadata oop location more than once, which is not allowed by some >> of the HotSpot GCs. We currently solve similar situations by always >> "claiming" and start scanning from the ClassLoaderData and then proceed >> down into the Klasses of that class loader. >> >> For this bug we do the same. All old collections, where class unloading >> can occur, pass down a closure that is applied to the ClassLoaderData of >> the Klass of the Method in the interpreted frame. This closure does the >> claiming and proceeds to scan the class metadata. Note that during young >> collections, where we don't do class unloading, all classes are already >> used as strong roots and we don't have to apply this new closure in the >> interpreted frame. >> >> Testing: >> The added test was initially written by John Rose. I only ported it to >> JTreg and made some artistic cleanups to it. >> >> thanks, >> StefanK From nils.eliasson at oracle.com Fri Nov 23 00:39:26 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 23 Nov 2012 09:39:26 +0100 Subject: RFR(S): Fix generation of malformed options for Projectcreator Message-ID: <50AF363E.9090108@oracle.com> Preferably reviewed by someone with a little nmake experience. This fixes a bug which causes visual studio to throw errors when trying to build hotspot. make/windows/projectfiles/common/Make sets up some options that is passed as a string to ProjectCreator.java. That string gets unmatched pairs of escaped quotation marks around the hotspot release version. After closer examination that happens when a number of vars and escaped quotation marks are appended together on a multi line string append. This fixes removes unnecessary (and potentially bad) quotation marks, simplifies the option creation and creates the options with escaping characters on the same line. http://cr.openjdk.java.net/~neliasso/8003934/webrev.01/ Thanks, Nils Eliasson From martijnverburg at gmail.com Fri Nov 23 02:19:34 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 23 Nov 2012 10:19:34 +0000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AEA08E.90207@oracle.com> References: <50AE9A34.4020001@oracle.com> <50AEA08E.90207@oracle.com> Message-ID: Hi Aleksey, Hi Martijn, > > On 11/23/2012 01:55 AM, Martijn Verburg wrote: > > Is this based on detecting the size of the cache line of the CPU the > > JVM is running on and multiplying by two? > > Not yet. We use the constant 128 bytes, overridable with > -XX:FieldPaddingWidth. The cache line detection is there in Hotspot, and > I still need to wire this up into the patch. The really sad part is that > we can not detect the presence of hardware prefetcher running without > reading the MSRs, which might in the end require superuser privileges. > OK, that's fair - We have a Java tool that reads MSRs and graphs lots of interesting data. It has similar supreruser requirements under Linux (and don't even get me started on having to patch in Mac Hardware kernel drivers) :-). I'll get one of our engineers to jump in if they have a brainwave on this. > As an extra aside - I'm wondering if the IDE vendors could pick up > > on this and actually visualise for you how your class will be laid > > out. Would be useful when applying @Contented and making sure it's > > padding as you'd want it to. > > Yup, as soon as class is loaded by the VM, it is actually pretty easy to > do, see: > https://github.com/shipilev/java-field-layout Awesome! I'm hoping that there's a lot of education and visualisation around this as marking fields, classes and groups as @Contended will have side effects that a day to day developer may not fully understand (like me!). Thanks again on working on this, it certainly will help with performance as numbers of cores grows. Cheers, Martijn From stefan.karlsson at oracle.com Fri Nov 23 03:54:53 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 23 Nov 2012 12:54:53 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() Message-ID: <50AF640D.1050401@oracle.com> http://cr.openjdk.java.net/~stefank/8003935/webrev Today, whenever we use Thread::current() we have to all these lines: #include "runtime/thread.hpp" #ifdef TARGET_OS_FAMILY_linux # include "thread_linux.inline.hpp" #endif #ifdef TARGET_OS_FAMILY_solaris # include "thread_solaris.inline.hpp" #endif #ifdef TARGET_OS_FAMILY_windows # include "thread_windows.inline.hpp" #endif #ifdef TARGET_OS_FAMILY_bsd # include "thread_bsd.inline.hpp" #endif This patch hides this dispatching in a new file named thread.inline.hpp. Now we only have to include thread.inline.hpp. Some background to these includes: This type of dispatching was introduced into the source files when we removed the includeDB files. We discussed whether we should use "dispatch files" or not for this kind platform dependent includes. The decision was to not create dispatch files for all types of platform at that time, but instead manually create them when we thought it was warranted. thanks, StefanK From david.holmes at oracle.com Fri Nov 23 04:22:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Nov 2012 22:22:42 +1000 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50AF640D.1050401@oracle.com> References: <50AF640D.1050401@oracle.com> Message-ID: <50AF6A92.8080401@oracle.com> Hi Stefan, I never did like these. I have to wonder though, why isn't it "runtime/thread.hpp" that all the client code #includes? And then why isn't it thread.hpp that includes the platform specific header? David On 23/11/2012 9:54 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8003935/webrev > > Today, whenever we use Thread::current() we have to all these lines: > > #include "runtime/thread.hpp" > #ifdef TARGET_OS_FAMILY_linux > # include "thread_linux.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "thread_solaris.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "thread_windows.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "thread_bsd.inline.hpp" > #endif > > This patch hides this dispatching in a new file named thread.inline.hpp. > Now we only have to include thread.inline.hpp. > > Some background to these includes: This type of dispatching was > introduced into the source files when we removed the includeDB files. We > discussed whether we should use "dispatch files" or not for this kind > platform dependent includes. The decision was to not create dispatch > files for all types of platform at that time, but instead manually > create them when we thought it was warranted. > > thanks, > StefanK > > From nils.eliasson at oracle.com Fri Nov 23 05:04:23 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 23 Nov 2012 14:04:23 +0100 Subject: RFR(S): Fix generation of malformed options for Projectcreator In-Reply-To: <50AF363E.9090108@oracle.com> References: <50AF363E.9090108@oracle.com> Message-ID: <50AF7457.1050209@oracle.com> Slight change. Moving placement of escaping tokens for a more enjoyable experience. http://cr.openjdk.java.net/~neliasso/8003934/webrev.02/ //N Nils Eliasson skrev 2012-11-23 09:39: > Preferably reviewed by someone with a little nmake experience. > > This fixes a bug which causes visual studio to throw errors when > trying to build hotspot. > > make/windows/projectfiles/common/Make sets up some options that is > passed as a string to ProjectCreator.java. That string gets unmatched > pairs of escaped quotation marks around the hotspot release version. > After closer examination that happens when a number of vars and > escaped quotation marks are appended together on a multi line string > append. > > This fixes removes unnecessary (and potentially bad) quotation marks, > simplifies the option creation and creates the options with escaping > characters on the same line. > > http://cr.openjdk.java.net/~neliasso/8003934/webrev.01/ > > Thanks, > Nils Eliasson From kirk at kodewerk.com Fri Nov 23 08:05:58 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 23 Nov 2012 17:05:58 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AE9A34.4020001@oracle.com> References: <50AE9A34.4020001@oracle.com> Message-ID: My only comment on this is how is one to know what is contended and what isn't.. and what if the programmer gets it wrong... or conditions change? My hope is that would be handled with less intervention in the code. -- Kirk On 2012-11-22, at 10:33 PM, Aleksey Shipilev wrote: > Hi, > > After some internal discussions with Doug Lea, Dave Dice and others, I > would like to solicit the initial feedback on the implementation of > JEP-142, aka @Contended [1]: > http://openjdk.java.net/jeps/142 > > The webrev for the initial version is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ > > Implementation overview. Hotspot code is currently laying out the fields > to optimize the memory footprint, rearranging fields freely to both > satisfy alignment requirements for fields and making the less gaps > possible. We leverage the same infrastructure to exempt specific fields > from the packing, and pushing them outside the dense packed block at > sparse offsets, naturally making up the appropriate padding. > > In order to demarcate the specific classes and/or fields eligible for > such the padding, we use new @Contended annotation. Runtime discovery of > annotations reuses the code John (?) laid out for some of > JSR292-specific annotations. > > The behavior of this annotation is as follows: > > A. Marking the class as contended: > > @Contended > public static class ContendedTest2 { > private Object plainField1; > private Object plainField2; > private Object plainField3; > private Object plainField4; > } > > ...makes the entire field block to be padded from the both sides: > (below is the output of new tracing -XX:+PrintFieldLayout) > > TestContended$ContendedTest2: field layout > Entire class is marked contended > @140 --- instance fields start --- > @140 "plainField1" Ljava.lang.Object; > @144 "plainField2" Ljava.lang.Object; > @148 "plainField3" Ljava.lang.Object; > @152 "plainField4" Ljava.lang.Object; > @288 --- instance fields end --- > @288 --- instance ends --- > > Note that we use 128 bytes, twice the cache line size on most hardware > to adjust for adjacent sector prefetchers extending the false sharing > collisions to two cache lines. > > B. Marking the field as contended: > > public static class ContendedTest1 { > @Contended > private Object contendedField1; > private Object plainField1; > private Object plainField2; > private Object plainField3; > private Object plainField4; > } > > ...pushes the field out of dense block and effectively applies padding: > > TestContended$ContendedTest1: field layout > @ 12 --- instance fields start --- > @ 12 "plainField1" Ljava.lang.Object; > @ 16 "plainField2" Ljava.lang.Object; > @ 20 "plainField3" Ljava.lang.Object; > @ 24 "plainField4" Ljava.lang.Object; > @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) > @288 --- instance fields end --- > @288 --- instance ends --- > > C. Marking multiple fields makes each field padded: > > public static class ContendedTest4 { > @Contended > private Object contendedField1; > > @Contended > private Object contendedField2; > > private Object plainField3; > private Object plainField4; > } > > ...pushes both fields with individual padding for each: > > TestContended$ContendedTest4: field layout > @ 12 --- instance fields start --- > @ 12 "plainField3" Ljava.lang.Object; > @ 16 "plainField4" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) > @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) > @416 --- instance fields end --- > @416 --- instance ends --- > > *** IV. Contention groups > > There are cases where you want to separate the *group* of fields that > are experiencing contention with everything else but not pairwise. This > is the usual thing for some of the code updating two fields at once. > While marking both with @Contended would be sufficient, we can optimize > the memory footprint by not applying padding between them. In order to > demarcate these groups, we have the parameter in the annotation > describing the equivalence class for contention group. > > So that: > > public static class ContendedTest5 { > @Contended("updater1") > private Object contendedField1; > > @Contended("updater1") > private Object contendedField2; > > @Contended("updater2") > private Object contendedField3; > > private Object plainField5; > private Object plainField6; > } > > ...is laid out as: > > TestContended$ContendedTest5: field layout > @ 12 --- instance fields start --- > @ 12 "plainField5" Ljava.lang.Object; > @ 16 "plainField6" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) > @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) > @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) > @416 --- instance fields end --- > @416 --- instance ends --- > > Note $contendedField1 and $contendedField2 are padded from everything > else, but still densely packed with each other. > > The code is known to work at least on Linux x86-64, tested with a few > microtests. The layout of fields without @Contended is not affected, so > this is presumably a safe change. I will try to run more tests against > this implementation with JPRT, but will appreciate the design, API, and > draft implementation review meanwhile... > > Thanks, > Aleksey. From forax at univ-mlv.fr Fri Nov 23 08:15:03 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 23 Nov 2012 17:15:03 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> Message-ID: <50AFA107.8030909@univ-mlv.fr> On 11/23/2012 05:05 PM, Kirk Pepperdine wrote: > My only comment on this is how is one to know what is contended and what isn't.. and what if the programmer gets it wrong... or conditions change? My hope is that would be handled with less intervention in the code. Do you have an idea to how to do that automatically ? > -- Kirk R?mi > On 2012-11-22, at 10:33 PM, Aleksey Shipilev wrote: > >> Hi, >> >> After some internal discussions with Doug Lea, Dave Dice and others, I >> would like to solicit the initial feedback on the implementation of >> JEP-142, aka @Contended [1]: >> http://openjdk.java.net/jeps/142 >> >> The webrev for the initial version is here: >> http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ >> >> Implementation overview. Hotspot code is currently laying out the fields >> to optimize the memory footprint, rearranging fields freely to both >> satisfy alignment requirements for fields and making the less gaps >> possible. We leverage the same infrastructure to exempt specific fields >> from the packing, and pushing them outside the dense packed block at >> sparse offsets, naturally making up the appropriate padding. >> >> In order to demarcate the specific classes and/or fields eligible for >> such the padding, we use new @Contended annotation. Runtime discovery of >> annotations reuses the code John (?) laid out for some of >> JSR292-specific annotations. >> >> The behavior of this annotation is as follows: >> >> A. Marking the class as contended: >> >> @Contended >> public static class ContendedTest2 { >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...makes the entire field block to be padded from the both sides: >> (below is the output of new tracing -XX:+PrintFieldLayout) >> >> TestContended$ContendedTest2: field layout >> Entire class is marked contended >> @140 --- instance fields start --- >> @140 "plainField1" Ljava.lang.Object; >> @144 "plainField2" Ljava.lang.Object; >> @148 "plainField3" Ljava.lang.Object; >> @152 "plainField4" Ljava.lang.Object; >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> Note that we use 128 bytes, twice the cache line size on most hardware >> to adjust for adjacent sector prefetchers extending the false sharing >> collisions to two cache lines. >> >> B. Marking the field as contended: >> >> public static class ContendedTest1 { >> @Contended >> private Object contendedField1; >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes the field out of dense block and effectively applies padding: >> >> TestContended$ContendedTest1: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField1" Ljava.lang.Object; >> @ 16 "plainField2" Ljava.lang.Object; >> @ 20 "plainField3" Ljava.lang.Object; >> @ 24 "plainField4" Ljava.lang.Object; >> @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> C. Marking multiple fields makes each field padded: >> >> public static class ContendedTest4 { >> @Contended >> private Object contendedField1; >> >> @Contended >> private Object contendedField2; >> >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes both fields with individual padding for each: >> >> TestContended$ContendedTest4: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField3" Ljava.lang.Object; >> @ 16 "plainField4" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> *** IV. Contention groups >> >> There are cases where you want to separate the *group* of fields that >> are experiencing contention with everything else but not pairwise. This >> is the usual thing for some of the code updating two fields at once. >> While marking both with @Contended would be sufficient, we can optimize >> the memory footprint by not applying padding between them. In order to >> demarcate these groups, we have the parameter in the annotation >> describing the equivalence class for contention group. >> >> So that: >> >> public static class ContendedTest5 { >> @Contended("updater1") >> private Object contendedField1; >> >> @Contended("updater1") >> private Object contendedField2; >> >> @Contended("updater2") >> private Object contendedField3; >> >> private Object plainField5; >> private Object plainField6; >> } >> >> ...is laid out as: >> >> TestContended$ContendedTest5: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField5" Ljava.lang.Object; >> @ 16 "plainField6" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) >> @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) >> @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> Note $contendedField1 and $contendedField2 are padded from everything >> else, but still densely packed with each other. >> >> The code is known to work at least on Linux x86-64, tested with a few >> microtests. The layout of fields without @Contended is not affected, so >> this is presumably a safe change. I will try to run more tests against >> this implementation with JPRT, but will appreciate the design, API, and >> draft implementation review meanwhile... >> >> Thanks, >> Aleksey. From rkennke at redhat.com Fri Nov 23 09:14:48 2012 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 23 Nov 2012 18:14:48 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> Message-ID: <1353690888.31435.3.camel@mercury> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > > > > > On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > > > >> > >> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >> > >>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>> > >>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>> > >>>>>> Hi there, > >>>>>> > >>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>> Here are some details: > >>>>>> > >>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>> changes in LLVM. > >>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>> class hierarchies in Hotspot. > >>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>> nicer. > >>>>>> > >>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>> bunch of other stuff. > >>>>>> > >>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>> can find the full webrev here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>> > >>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>> > >>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>> > >>>>> Isn't PrintCompilation doing that already? > >>>>> > >>>>> The shared code changes look good. I filed: > >>>>> > >>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>> > >>>>> -- Chris > >>>>> > >>>>>> > >>>>>> There are also a very minor change required in JDK: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>> > >>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>> > >>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>> > >>>>>> Please let me know if there are any issues or how we can get this > >>>>>> integrated into Hotspot. > >>>> > >>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>> > >>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>> from /usr/local/include/llvm/Use.h:28, > >>>> from /usr/local/include/llvm/Value.h:17, > >>>> from /usr/local/include/llvm/Argument.h:17, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>> > >>>> and: > >>>> > >>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>> from /usr/local/include/llvm/Argument.h:18, > >>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>> > >>>> Not sure if the latter is because of the former one. Have you seen this before? > >>> > >>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>> this happens when certain cflags are not set correctly. The script > >>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>> correct flags. In order for this to work, you need to have the full path > >>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>> using the build script that I provided? > >> > >> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >> > >> Now that I have the LLVM_* variables it's even worse: > >> > >> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >> > >> It's probably this guy: -Wcast-qual > > > > Got it: > > > > $ java -version > > java version "1.8.0-ea" > > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > > I ran the compiler regression tests and Shark crashes in 5091921: > > cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > Directory "/export/twisti/jtreg/scratch" not found: creating > Passed: compiler/5091921/Test5091921.java > Passed: compiler/5091921/Test6186134.java > Passed: compiler/5091921/Test6196102.java > Passed: compiler/5091921/Test6357214.java > Passed: compiler/5091921/Test6559156.java > Passed: compiler/5091921/Test6753639.java > Passed: compiler/5091921/Test6850611.java > Passed: compiler/5091921/Test6890943.java > Passed: compiler/5091921/Test6897150.java > Passed: compiler/5091921/Test6905845.java > Passed: compiler/5091921/Test6931567.java > /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > > You can also run all them with a simple make in test/ by setting: > > PRODUCT_HOME=$JAVA_HOME > TESTDIRS=compiler Alright, I found another fairly grave bug that I would like to include a fix for: apparently, a 'fence' is not enough of a memory barrier for volatile putfield/getfield (duh). Which basically broke all of j.u.c. LLVM offers atomic loads and stores, which seem to be exactly what is needed for volatile field access. However, it does not provide helper functions for those in llvm::IRBuilder so I wrote my own. This should be the final patch for now (unless you find something else). http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ Cheers, Roman From vitalyd at gmail.com Fri Nov 23 11:05:50 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 23 Nov 2012 14:05:50 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AE9A34.4020001@oracle.com> References: <50AE9A34.4020001@oracle.com> Message-ID: Aleksey, Have you considered allowing user to specify the padding amount in the @Contended constructor? The default can be picked by the VM but may be useful to allow overriding it so that someone can get the desired padding on some new architecture without upgrading the JVM. Also, how common is the adjacent line prefetcher today? On archs that don't do that, the extra 64 bytes is a waste. I think you'd really need to extract that info from the cpuid if this isn't the dominant type of prefetcher. The extra memory waste may be a bigger issue on embedded devices (although even they have quite substantial RAM these days). Thanks Sent from my phone On Nov 22, 2012 4:35 PM, "Aleksey Shipilev" wrote: > Hi, > > After some internal discussions with Doug Lea, Dave Dice and others, I > would like to solicit the initial feedback on the implementation of > JEP-142, aka @Contended [1]: > http://openjdk.java.net/jeps/142 > > The webrev for the initial version is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ > > Implementation overview. Hotspot code is currently laying out the fields > to optimize the memory footprint, rearranging fields freely to both > satisfy alignment requirements for fields and making the less gaps > possible. We leverage the same infrastructure to exempt specific fields > from the packing, and pushing them outside the dense packed block at > sparse offsets, naturally making up the appropriate padding. > > In order to demarcate the specific classes and/or fields eligible for > such the padding, we use new @Contended annotation. Runtime discovery of > annotations reuses the code John (?) laid out for some of > JSR292-specific annotations. > > The behavior of this annotation is as follows: > > A. Marking the class as contended: > > @Contended > public static class ContendedTest2 { > private Object plainField1; > private Object plainField2; > private Object plainField3; > private Object plainField4; > } > > ...makes the entire field block to be padded from the both sides: > (below is the output of new tracing -XX:+PrintFieldLayout) > > TestContended$ContendedTest2: field layout > Entire class is marked contended > @140 --- instance fields start --- > @140 "plainField1" Ljava.lang.Object; > @144 "plainField2" Ljava.lang.Object; > @148 "plainField3" Ljava.lang.Object; > @152 "plainField4" Ljava.lang.Object; > @288 --- instance fields end --- > @288 --- instance ends --- > > Note that we use 128 bytes, twice the cache line size on most hardware > to adjust for adjacent sector prefetchers extending the false sharing > collisions to two cache lines. > > B. Marking the field as contended: > > public static class ContendedTest1 { > @Contended > private Object contendedField1; > private Object plainField1; > private Object plainField2; > private Object plainField3; > private Object plainField4; > } > > ...pushes the field out of dense block and effectively applies padding: > > TestContended$ContendedTest1: field layout > @ 12 --- instance fields start --- > @ 12 "plainField1" Ljava.lang.Object; > @ 16 "plainField2" Ljava.lang.Object; > @ 20 "plainField3" Ljava.lang.Object; > @ 24 "plainField4" Ljava.lang.Object; > @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) > @288 --- instance fields end --- > @288 --- instance ends --- > > C. Marking multiple fields makes each field padded: > > public static class ContendedTest4 { > @Contended > private Object contendedField1; > > @Contended > private Object contendedField2; > > private Object plainField3; > private Object plainField4; > } > > ...pushes both fields with individual padding for each: > > TestContended$ContendedTest4: field layout > @ 12 --- instance fields start --- > @ 12 "plainField3" Ljava.lang.Object; > @ 16 "plainField4" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) > @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) > @416 --- instance fields end --- > @416 --- instance ends --- > > *** IV. Contention groups > > There are cases where you want to separate the *group* of fields that > are experiencing contention with everything else but not pairwise. This > is the usual thing for some of the code updating two fields at once. > While marking both with @Contended would be sufficient, we can optimize > the memory footprint by not applying padding between them. In order to > demarcate these groups, we have the parameter in the annotation > describing the equivalence class for contention group. > > So that: > > public static class ContendedTest5 { > @Contended("updater1") > private Object contendedField1; > > @Contended("updater1") > private Object contendedField2; > > @Contended("updater2") > private Object contendedField3; > > private Object plainField5; > private Object plainField6; > } > > ...is laid out as: > > TestContended$ContendedTest5: field layout > @ 12 --- instance fields start --- > @ 12 "plainField5" Ljava.lang.Object; > @ 16 "plainField6" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) > @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) > @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) > @416 --- instance fields end --- > @416 --- instance ends --- > > Note $contendedField1 and $contendedField2 are padded from everything > else, but still densely packed with each other. > > The code is known to work at least on Linux x86-64, tested with a few > microtests. The layout of fields without @Contended is not affected, so > this is presumably a safe change. I will try to run more tests against > this implementation with JPRT, but will appreciate the design, API, and > draft implementation review meanwhile... > > Thanks, > Aleksey. > From vitalyd at gmail.com Fri Nov 23 11:07:41 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 23 Nov 2012 14:07:41 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> Message-ID: Also, PrintFieldLayout would be nice to have in product build as well. Sent from my phone On Nov 23, 2012 2:05 PM, "Vitaly Davidovich" wrote: > Aleksey, > > Have you considered allowing user to specify the padding amount in the > @Contended constructor? The default can be picked by the VM but may be > useful to allow overriding it so that someone can get the desired padding > on some new architecture without upgrading the JVM. > > Also, how common is the adjacent line prefetcher today? On archs that > don't do that, the extra 64 bytes is a waste. I think you'd really need to > extract that info from the cpuid if this isn't the dominant type of > prefetcher. The extra memory waste may be a bigger issue on embedded > devices (although even they have quite substantial RAM these days). > > Thanks > > Sent from my phone > On Nov 22, 2012 4:35 PM, "Aleksey Shipilev" > wrote: > >> Hi, >> >> After some internal discussions with Doug Lea, Dave Dice and others, I >> would like to solicit the initial feedback on the implementation of >> JEP-142, aka @Contended [1]: >> http://openjdk.java.net/jeps/142 >> >> The webrev for the initial version is here: >> http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ >> >> Implementation overview. Hotspot code is currently laying out the fields >> to optimize the memory footprint, rearranging fields freely to both >> satisfy alignment requirements for fields and making the less gaps >> possible. We leverage the same infrastructure to exempt specific fields >> from the packing, and pushing them outside the dense packed block at >> sparse offsets, naturally making up the appropriate padding. >> >> In order to demarcate the specific classes and/or fields eligible for >> such the padding, we use new @Contended annotation. Runtime discovery of >> annotations reuses the code John (?) laid out for some of >> JSR292-specific annotations. >> >> The behavior of this annotation is as follows: >> >> A. Marking the class as contended: >> >> @Contended >> public static class ContendedTest2 { >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...makes the entire field block to be padded from the both sides: >> (below is the output of new tracing -XX:+PrintFieldLayout) >> >> TestContended$ContendedTest2: field layout >> Entire class is marked contended >> @140 --- instance fields start --- >> @140 "plainField1" Ljava.lang.Object; >> @144 "plainField2" Ljava.lang.Object; >> @148 "plainField3" Ljava.lang.Object; >> @152 "plainField4" Ljava.lang.Object; >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> Note that we use 128 bytes, twice the cache line size on most hardware >> to adjust for adjacent sector prefetchers extending the false sharing >> collisions to two cache lines. >> >> B. Marking the field as contended: >> >> public static class ContendedTest1 { >> @Contended >> private Object contendedField1; >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes the field out of dense block and effectively applies padding: >> >> TestContended$ContendedTest1: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField1" Ljava.lang.Object; >> @ 16 "plainField2" Ljava.lang.Object; >> @ 20 "plainField3" Ljava.lang.Object; >> @ 24 "plainField4" Ljava.lang.Object; >> @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> C. Marking multiple fields makes each field padded: >> >> public static class ContendedTest4 { >> @Contended >> private Object contendedField1; >> >> @Contended >> private Object contendedField2; >> >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes both fields with individual padding for each: >> >> TestContended$ContendedTest4: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField3" Ljava.lang.Object; >> @ 16 "plainField4" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> *** IV. Contention groups >> >> There are cases where you want to separate the *group* of fields that >> are experiencing contention with everything else but not pairwise. This >> is the usual thing for some of the code updating two fields at once. >> While marking both with @Contended would be sufficient, we can optimize >> the memory footprint by not applying padding between them. In order to >> demarcate these groups, we have the parameter in the annotation >> describing the equivalence class for contention group. >> >> So that: >> >> public static class ContendedTest5 { >> @Contended("updater1") >> private Object contendedField1; >> >> @Contended("updater1") >> private Object contendedField2; >> >> @Contended("updater2") >> private Object contendedField3; >> >> private Object plainField5; >> private Object plainField6; >> } >> >> ...is laid out as: >> >> TestContended$ContendedTest5: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField5" Ljava.lang.Object; >> @ 16 "plainField6" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) >> @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) >> @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> Note $contendedField1 and $contendedField2 are padded from everything >> else, but still densely packed with each other. >> >> The code is known to work at least on Linux x86-64, tested with a few >> microtests. The layout of fields without @Contended is not affected, so >> this is presumably a safe change. I will try to run more tests against >> this implementation with JPRT, but will appreciate the design, API, and >> draft implementation review meanwhile... >> >> Thanks, >> Aleksey. >> > From vitalyd at gmail.com Fri Nov 23 11:26:05 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 23 Nov 2012 14:26:05 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> Message-ID: I guess the per @Contended padding specification won't buy much given you can override the default padding via JVM arg, so scratch that part of my email. :) Sent from my phone On Nov 23, 2012 2:05 PM, "Vitaly Davidovich" wrote: > Aleksey, > > Have you considered allowing user to specify the padding amount in the > @Contended constructor? The default can be picked by the VM but may be > useful to allow overriding it so that someone can get the desired padding > on some new architecture without upgrading the JVM. > > Also, how common is the adjacent line prefetcher today? On archs that > don't do that, the extra 64 bytes is a waste. I think you'd really need to > extract that info from the cpuid if this isn't the dominant type of > prefetcher. The extra memory waste may be a bigger issue on embedded > devices (although even they have quite substantial RAM these days). > > Thanks > > Sent from my phone > On Nov 22, 2012 4:35 PM, "Aleksey Shipilev" > wrote: > >> Hi, >> >> After some internal discussions with Doug Lea, Dave Dice and others, I >> would like to solicit the initial feedback on the implementation of >> JEP-142, aka @Contended [1]: >> http://openjdk.java.net/jeps/142 >> >> The webrev for the initial version is here: >> http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ >> >> Implementation overview. Hotspot code is currently laying out the fields >> to optimize the memory footprint, rearranging fields freely to both >> satisfy alignment requirements for fields and making the less gaps >> possible. We leverage the same infrastructure to exempt specific fields >> from the packing, and pushing them outside the dense packed block at >> sparse offsets, naturally making up the appropriate padding. >> >> In order to demarcate the specific classes and/or fields eligible for >> such the padding, we use new @Contended annotation. Runtime discovery of >> annotations reuses the code John (?) laid out for some of >> JSR292-specific annotations. >> >> The behavior of this annotation is as follows: >> >> A. Marking the class as contended: >> >> @Contended >> public static class ContendedTest2 { >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...makes the entire field block to be padded from the both sides: >> (below is the output of new tracing -XX:+PrintFieldLayout) >> >> TestContended$ContendedTest2: field layout >> Entire class is marked contended >> @140 --- instance fields start --- >> @140 "plainField1" Ljava.lang.Object; >> @144 "plainField2" Ljava.lang.Object; >> @148 "plainField3" Ljava.lang.Object; >> @152 "plainField4" Ljava.lang.Object; >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> Note that we use 128 bytes, twice the cache line size on most hardware >> to adjust for adjacent sector prefetchers extending the false sharing >> collisions to two cache lines. >> >> B. Marking the field as contended: >> >> public static class ContendedTest1 { >> @Contended >> private Object contendedField1; >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes the field out of dense block and effectively applies padding: >> >> TestContended$ContendedTest1: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField1" Ljava.lang.Object; >> @ 16 "plainField2" Ljava.lang.Object; >> @ 20 "plainField3" Ljava.lang.Object; >> @ 24 "plainField4" Ljava.lang.Object; >> @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> C. Marking multiple fields makes each field padded: >> >> public static class ContendedTest4 { >> @Contended >> private Object contendedField1; >> >> @Contended >> private Object contendedField2; >> >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes both fields with individual padding for each: >> >> TestContended$ContendedTest4: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField3" Ljava.lang.Object; >> @ 16 "plainField4" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> *** IV. Contention groups >> >> There are cases where you want to separate the *group* of fields that >> are experiencing contention with everything else but not pairwise. This >> is the usual thing for some of the code updating two fields at once. >> While marking both with @Contended would be sufficient, we can optimize >> the memory footprint by not applying padding between them. In order to >> demarcate these groups, we have the parameter in the annotation >> describing the equivalence class for contention group. >> >> So that: >> >> public static class ContendedTest5 { >> @Contended("updater1") >> private Object contendedField1; >> >> @Contended("updater1") >> private Object contendedField2; >> >> @Contended("updater2") >> private Object contendedField3; >> >> private Object plainField5; >> private Object plainField6; >> } >> >> ...is laid out as: >> >> TestContended$ContendedTest5: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField5" Ljava.lang.Object; >> @ 16 "plainField6" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) >> @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) >> @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> Note $contendedField1 and $contendedField2 are padded from everything >> else, but still densely packed with each other. >> >> The code is known to work at least on Linux x86-64, tested with a few >> microtests. The layout of fields without @Contended is not affected, so >> this is presumably a safe change. I will try to run more tests against >> this implementation with JPRT, but will appreciate the design, API, and >> draft implementation review meanwhile... >> >> Thanks, >> Aleksey. >> > From dl at cs.oswego.edu Fri Nov 23 11:43:32 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 23 Nov 2012 14:43:32 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AF421C.1060408@oracle.com> References: <50AE9A34.4020001@oracle.com> <50AF233C.9040605@oracle.com> <1353660212.79869.YahooMailNeo@web132104.mail.ird.yahoo.com> <50AF421C.1060408@oracle.com> Message-ID: <50AFD1E4.10306@cs.oswego.edu> (Warning: cross-posting, so replies may bounce to one or both lists.) > However, this still has a drawback that the subclass annotation will > only affect the fields in the subclass, and not in the superclasses > (laying the superclass fields on the same offsets in the subclass is > important to get cheap polymorphism). Considering that the only usages with predictable effects will be on leaf/final classes anyway, perhaps the @Contended annotation should only have a defined effect on layout when applied to final classes (plus statics). This also seems to be the only case when a developer can have an empirical basic for using the annotation. And if there someday turns out to be some reason to lift this restriction, it would be possible to do so. -Doug From aleksey.shipilev at oracle.com Fri Nov 23 11:50:41 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 23 Nov 2012 23:50:41 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> Message-ID: <50AFD391.2070109@oracle.com> On 11/23/2012 11:05 PM, Vitaly Davidovich wrote: > Have you considered allowing user to specify the padding amount in the > @Contended constructor? The default can be picked by the VM but may be > useful to allow overriding it so that someone can get the desired > padding on some new architecture without upgrading the JVM. Even with this prototype code, the padding is controlled with -XX:FieldPaddingWidth=#, we can set the default value for that flag via CPUID (the updated patch still pending). > Also, how common is the adjacent line prefetcher today? Very common on server hardware. -Aleksey. From dl at cs.oswego.edu Fri Nov 23 12:00:29 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 23 Nov 2012 15:00:29 -0500 Subject: PackedObjects Message-ID: <50AFD5DD.2000804@cs.oswego.edu> On the occasion of subscribing to this list for the sake of exchanges about @Contended, I figure that it is also worth alerting folks who haven't heard about IBM's PackedObject proposal that they now have released some slides etc at http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 This is a VM-level approach to supporting value/struct/tuple types, that I hope catches on and turns into a JEP. Of all the ways to do this sort of thing, it strikes me as being among the few that might possibly succeed (and actually has succeeded at least to the point of a J9 implementation). -Doug From aleksey.shipilev at oracle.com Fri Nov 23 12:07:16 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 24 Nov 2012 00:07:16 +0400 Subject: [concurrency-interest] RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AFD1E4.10306@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50AF233C.9040605@oracle.com> <1353660212.79869.YahooMailNeo@web132104.mail.ird.yahoo.com> <50AF421C.1060408@oracle.com> <50AFD1E4.10306@cs.oswego.edu> Message-ID: <50AFD774.5050409@oracle.com> On 11/23/2012 11:43 PM, Doug Lea wrote: > (Warning: cross-posting, so replies may bounce to one or both lists.) > >> However, this still has a drawback that the subclass annotation will >> only affect the fields in the subclass, and not in the superclasses >> (laying the superclass fields on the same offsets in the subclass is >> important to get cheap polymorphism). > > > Considering that the only usages with predictable effects will be > on leaf/final classes anyway, perhaps the @Contended annotation > should only have a defined effect on layout when applied to final > classes (plus statics). This also seems to be the only case when a > developer can have an empirical basic for using the annotation. > And if there someday turns out to be some reason to lift this > restriction, it would be possible to do so. I don't think so. My comment was that you can't change the padding for the superclass fields, but the contended safety for the superclass fields should actually stay intact. I.e., class Base { @Contended private int mySuperImportantField; } ...should NOT be compromised with class Rogue extends Base { private int wannaKillYourPadding; } ...and it doesn't in the present version, and it sticks with the same principle: once superclass fields are laid out, you stick with that layout in all the subclasses. -Aleksey. From aleksey.shipilev at oracle.com Sat Nov 24 00:24:55 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 24 Nov 2012 12:24:55 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AE9A34.4020001@oracle.com> References: <50AE9A34.4020001@oracle.com> Message-ID: <50B08457.9010405@oracle.com> On 11/23/2012 01:33 AM, Aleksey Shipilev wrote: > Hi, > > After some internal discussions with Doug Lea, Dave Dice and others, I > would like to solicit the initial feedback on the implementation of > JEP-142, aka @Contended [1]: > http://openjdk.java.net/jeps/142 > > The webrev for the initial version is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ BTW, here's the simple microbenchmark test: four threads T1..T4 on my 2x2 i5-2520M each increments its distinct field i1..i4: static class Base { @Contended long i1; @Contended long i2; @Contended long i3; @Contended long i4; } Running with proper warmups, 10 measurement iterations for 1 second each, 10 JVM invocations per test, yields: -XX:FieldPaddingWidth=0: 7.94 +- 1.10 nsec/op -XX:FieldPaddingWidth=8: 4.92 +- 0.53 nsec/op -XX:FieldPaddingWidth=16: 4.67 +- 0.54 nsec/op -XX:FieldPaddingWidth=32: 4.67 +- 0.31 nsec/op -XX:FieldPaddingWidth=64: 3.55 +- 0.03 nsec/op -XX:FieldPaddingWidth=128: 3.54 +- 0.03 nsec/op (The time is severely bloated because of hyperthreading and other infra overheads). So that's at least two-fold difference even within single CPU package, where false sharing misses are being served by on-chip L3. It will get dramatically worse on multi-CPU hosts. "width=0" corresponds to our current behavior, i.e. dense packing. Note also the jitter is significantly better since we are not at the mercy of execution interleavings. Thanks, -Aleksey. From mikeb01 at gmail.com Sat Nov 24 00:53:24 2012 From: mikeb01 at gmail.com (Michael Barker) Date: Sat, 24 Nov 2012 08:53:24 +0000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B08457.9010405@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B08457.9010405@oracle.com> Message-ID: > -XX:FieldPaddingWidth=64: 3.55 +- 0.03 nsec/op > -XX:FieldPaddingWidth=128: 3.54 +- 0.03 nsec/op Do you have adjacent cache line prefetching supported/enabled? These numbers suggest that padding to 2 cache lines doesn't provide a significant speed up over a single cache line. If there isn't a large benefit to padding to 128 bytes, should be set as the default? From aleksey.shipilev at oracle.com Sat Nov 24 01:51:31 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 24 Nov 2012 13:51:31 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B08457.9010405@oracle.com> Message-ID: <50B098A3.8060808@oracle.com> On 11/24/2012 12:53 PM, Michael Barker wrote: >> -XX:FieldPaddingWidth=64: 3.55 +- 0.03 nsec/op >> -XX:FieldPaddingWidth=128: 3.54 +- 0.03 nsec/op > > Do you have adjacent cache line prefetching supported/enabled? These > numbers suggest that padding to 2 cache lines doesn't provide a > significant speed up over a single cache line. If there isn't a large > benefit to padding to 128 bytes, should be set as the default? On my laptop this feature is disabled, so yes, padding for single cache line already helps. On servers it's the whole different story, will do some runs on larger machines later. -Aleksey. From danhicks at ieee.org Sat Nov 24 12:38:25 2012 From: danhicks at ieee.org (Daniel Hicks) Date: Sat, 24 Nov 2012 14:38:25 -0600 Subject: Packed Objects In-Reply-To: References: Message-ID: <50B13041.8060206@ieee.org> Just as an aside, the "Classic" JVM on IBM iSeries was doing a primitive form of packed objects (only for system objects) years ago. For classes in the system classpath there was an attribute that could specify the offsets of individual fields, allowing "native" data structures to be accessed directly from Java code. On 11/24/2012 2:00 PM, hotspot-dev-request at openjdk.java.net wrote: > Send hotspot-dev mailing list submissions to > hotspot-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev > or, via email, send a message with subject or body 'help' to > hotspot-dev-request at openjdk.java.net > > You can reach the person managing the list at > hotspot-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hotspot-dev digest..." > > > Today's Topics: > > 1. PackedObjects (Doug Lea) > 2. Re: [concurrency-interest] RFR (S): JEP-142: Reduce Cache > Contention on Specified Fields (Aleksey Shipilev) > 3. Re: RFR (S): JEP-142: Reduce Cache Contention on Specified > Fields (Aleksey Shipilev) > 4. Re: RFR (S): JEP-142: Reduce Cache Contention on Specified > Fields (Michael Barker) > 5. Re: RFR (S): JEP-142: Reduce Cache Contention on Specified > Fields (Aleksey Shipilev) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 23 Nov 2012 15:00:29 -0500 > From: Doug Lea
> Subject: PackedObjects > To: hotspot-dev at openjdk.java.net > Message-ID: <50AFD5DD.2000804 at cs.oswego.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > On the occasion of subscribing to this list for the sake of > exchanges about @Contended, I figure that it is also worth > alerting folks who haven't heard about IBM's PackedObject > proposal that they now have released some slides etc at > > http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 > > This is a VM-level approach to supporting value/struct/tuple > types, that I hope catches on and turns into a JEP. Of all > the ways to do this sort of thing, it strikes me as being > among the few that might possibly succeed (and actually has > succeeded at least to the point of a J9 implementation). > > -Doug > -- Dan Hicks Experience is the name everyone gives for their mistakes. --Oscar Wilde From david.holmes at oracle.com Sun Nov 25 12:33:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Nov 2012 06:33:10 +1000 Subject: Request for review 8003722: More gcc 4.7 compilation errors In-Reply-To: <50ACE29F.8030601@oracle.com> References: <50AC31EC.6030404@oracle.com> <50AC41F8.2080301@oracle.com> <50ACE29F.8030601@oracle.com> Message-ID: <50B28086.4040006@oracle.com> Hi Coleen, Okay I withdraw my objections otherwise this will never get fixed. gcc itself says use "this->" so be it. Plus push when ready. For the record I'm hitting these kind of problems with gcc 4.6 as well. It's in build-infra repo so may be down-rev on previous hotspot changes. Thanks, David On 22/11/2012 12:18 AM, Coleen Phillimore wrote: > On 11/20/2012 9:52 PM, David Holmes wrote: >> Sorry but I must protest. After the last fix we were returned to an >> unpleasant mixture of using directives and this-> augmentation. The >> fix that was lost had applied the using directive. >> >> Can we please use the using directive and just fix these once and for >> all. > > Okay, someone will have to contribute the "using" fix then. I don't know > what to use in "using"! > > Please do this very soon since the VM doesn't build on gcc 4.7 (again!) > > Thanks, > Coleen > >> >> Otherwise get rid of all using directives. But lets have a consistent >> approach here. >> >> Thanks, >> David >> >> On 21/11/2012 11:44 AM, Coleen Phillimore wrote: >>> Summary: Add a few more this->qualifications. >>> Reviewed-by: coleenp >>> Contributed-by: duboscq at ssw.jku.at >>> >>> http://cr.openjdk.java.net/~coleenp/8003722/ >>> >>> Ran runThese tests with CMS gc. I want to check this into hotspot-gc >>> since it has the other changes (hotspot-rt doesn't yet). >>> >>> Thanks, >>> Coleen > From david.holmes at oracle.com Sun Nov 25 12:40:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Nov 2012 06:40:13 +1000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AE9A34.4020001@oracle.com> References: <50AE9A34.4020001@oracle.com> Message-ID: <50B2822D.3010603@oracle.com> Hi Aleksey, This seems good for local decisions about placement/layout, but I'm concerned about the global impact on footprint and performance. What if individually these kinds of changes yield better microbenchmark performance, but collectively they yield worse application performance? At present this is an all-or-nothing API - though after some thought I'm not sure it could be anything else. David On 23/11/2012 7:33 AM, Aleksey Shipilev wrote: > Hi, > > After some internal discussions with Doug Lea, Dave Dice and others, I > would like to solicit the initial feedback on the implementation of > JEP-142, aka @Contended [1]: > http://openjdk.java.net/jeps/142 > > The webrev for the initial version is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ > > Implementation overview. Hotspot code is currently laying out the fields > to optimize the memory footprint, rearranging fields freely to both > satisfy alignment requirements for fields and making the less gaps > possible. We leverage the same infrastructure to exempt specific fields > from the packing, and pushing them outside the dense packed block at > sparse offsets, naturally making up the appropriate padding. > > In order to demarcate the specific classes and/or fields eligible for > such the padding, we use new @Contended annotation. Runtime discovery of > annotations reuses the code John (?) laid out for some of > JSR292-specific annotations. > > The behavior of this annotation is as follows: > > A. Marking the class as contended: > > @Contended > public static class ContendedTest2 { > private Object plainField1; > private Object plainField2; > private Object plainField3; > private Object plainField4; > } > > ...makes the entire field block to be padded from the both sides: > (below is the output of new tracing -XX:+PrintFieldLayout) > > TestContended$ContendedTest2: field layout > Entire class is marked contended > @140 --- instance fields start --- > @140 "plainField1" Ljava.lang.Object; > @144 "plainField2" Ljava.lang.Object; > @148 "plainField3" Ljava.lang.Object; > @152 "plainField4" Ljava.lang.Object; > @288 --- instance fields end --- > @288 --- instance ends --- > > Note that we use 128 bytes, twice the cache line size on most hardware > to adjust for adjacent sector prefetchers extending the false sharing > collisions to two cache lines. > > B. Marking the field as contended: > > public static class ContendedTest1 { > @Contended > private Object contendedField1; > private Object plainField1; > private Object plainField2; > private Object plainField3; > private Object plainField4; > } > > ...pushes the field out of dense block and effectively applies padding: > > TestContended$ContendedTest1: field layout > @ 12 --- instance fields start --- > @ 12 "plainField1" Ljava.lang.Object; > @ 16 "plainField2" Ljava.lang.Object; > @ 20 "plainField3" Ljava.lang.Object; > @ 24 "plainField4" Ljava.lang.Object; > @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) > @288 --- instance fields end --- > @288 --- instance ends --- > > C. Marking multiple fields makes each field padded: > > public static class ContendedTest4 { > @Contended > private Object contendedField1; > > @Contended > private Object contendedField2; > > private Object plainField3; > private Object plainField4; > } > > ...pushes both fields with individual padding for each: > > TestContended$ContendedTest4: field layout > @ 12 --- instance fields start --- > @ 12 "plainField3" Ljava.lang.Object; > @ 16 "plainField4" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) > @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) > @416 --- instance fields end --- > @416 --- instance ends --- > > *** IV. Contention groups > > There are cases where you want to separate the *group* of fields that > are experiencing contention with everything else but not pairwise. This > is the usual thing for some of the code updating two fields at once. > While marking both with @Contended would be sufficient, we can optimize > the memory footprint by not applying padding between them. In order to > demarcate these groups, we have the parameter in the annotation > describing the equivalence class for contention group. > > So that: > > public static class ContendedTest5 { > @Contended("updater1") > private Object contendedField1; > > @Contended("updater1") > private Object contendedField2; > > @Contended("updater2") > private Object contendedField3; > > private Object plainField5; > private Object plainField6; > } > > ...is laid out as: > > TestContended$ContendedTest5: field layout > @ 12 --- instance fields start --- > @ 12 "plainField5" Ljava.lang.Object; > @ 16 "plainField6" Ljava.lang.Object; > @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) > @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) > @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) > @416 --- instance fields end --- > @416 --- instance ends --- > > Note $contendedField1 and $contendedField2 are padded from everything > else, but still densely packed with each other. > > The code is known to work at least on Linux x86-64, tested with a few > microtests. The layout of fields without @Contended is not affected, so > this is presumably a safe change. I will try to run more tests against > this implementation with JPRT, but will appreciate the design, API, and > draft implementation review meanwhile... > > Thanks, > Aleksey. From david.holmes at oracle.com Sun Nov 25 12:49:43 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Nov 2012 06:49:43 +1000 Subject: Request for review 8003722: More gcc 4.7 compilation errors In-Reply-To: <50B28086.4040006@oracle.com> References: <50AC31EC.6030404@oracle.com> <50AC41F8.2080301@oracle.com> <50ACE29F.8030601@oracle.com> <50B28086.4040006@oracle.com> Message-ID: <50B28467.1030807@oracle.com> On 26/11/2012 6:33 AM, David Holmes wrote: > Hi Coleen, > > Okay I withdraw my objections otherwise this will never get fixed. gcc > itself says use "this->" so be it. Plus push when ready. Please push ... David > For the record I'm hitting these kind of problems with gcc 4.6 as well. > It's in build-infra repo so may be down-rev on previous hotspot changes. > > Thanks, > David > > On 22/11/2012 12:18 AM, Coleen Phillimore wrote: >> On 11/20/2012 9:52 PM, David Holmes wrote: >>> Sorry but I must protest. After the last fix we were returned to an >>> unpleasant mixture of using directives and this-> augmentation. The >>> fix that was lost had applied the using directive. >>> >>> Can we please use the using directive and just fix these once and for >>> all. >> >> Okay, someone will have to contribute the "using" fix then. I don't know >> what to use in "using"! >> >> Please do this very soon since the VM doesn't build on gcc 4.7 (again!) >> >> Thanks, >> Coleen >> >>> >>> Otherwise get rid of all using directives. But lets have a consistent >>> approach here. >>> >>> Thanks, >>> David >>> >>> On 21/11/2012 11:44 AM, Coleen Phillimore wrote: >>>> Summary: Add a few more this->qualifications. >>>> Reviewed-by: coleenp >>>> Contributed-by: duboscq at ssw.jku.at >>>> >>>> http://cr.openjdk.java.net/~coleenp/8003722/ >>>> >>>> Ran runThese tests with CMS gc. I want to check this into hotspot-gc >>>> since it has the other changes (hotspot-rt doesn't yet). >>>> >>>> Thanks, >>>> Coleen >> From kirk at kodewerk.com Sun Nov 25 13:22:48 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sun, 25 Nov 2012 22:22:48 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B2822D.3010603@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> Message-ID: Hi David, I'm completely in agreement that there are some applications where this optimization is necessary. That said, I've more fundamental concerns with respect to this API. Traditionally the JVM has steered away from having developers hint at optimization as these optimizations have typically been ill thought out. My mantra has always been, measure, don't guess. WIthout denigrating any group of developers I would say that very very few know how to get the measures to even start to understand how to apply this "optimization". I would suggest that it would be better to leave the application of this optimization to HotSpot and the JIT compiler. I would also suggest that one could do this is the JVM were to use more of the diagnostics (MSRs) available to it to know when and how to apply this particular optimization. If this all sounds expensive... well, turning on CPU event counters is cheap but evaluating the data maybe a cycle sync... but then again maybe not. But more to the point, getting this type of profiling and optimization into HotSpot seems like a far better solution than to give developers access to how variables get laid out. Sorry Aleksey, I know you get it.. but you're not in the same class of developer as those that would be using this feature. Regards, Kirk On 2012-11-25, at 9:40 PM, David Holmes wrote: > Hi Aleksey, > > This seems good for local decisions about placement/layout, but I'm concerned about the global impact on footprint and performance. What if individually these kinds of changes yield better microbenchmark performance, but collectively they yield worse application performance? At present this is an all-or-nothing API - though after some thought I'm not sure it could be anything else. > > David > > On 23/11/2012 7:33 AM, Aleksey Shipilev wrote: >> Hi, >> >> After some internal discussions with Doug Lea, Dave Dice and others, I >> would like to solicit the initial feedback on the implementation of >> JEP-142, aka @Contended [1]: >> http://openjdk.java.net/jeps/142 >> >> The webrev for the initial version is here: >> http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ >> >> Implementation overview. Hotspot code is currently laying out the fields >> to optimize the memory footprint, rearranging fields freely to both >> satisfy alignment requirements for fields and making the less gaps >> possible. We leverage the same infrastructure to exempt specific fields >> from the packing, and pushing them outside the dense packed block at >> sparse offsets, naturally making up the appropriate padding. >> >> In order to demarcate the specific classes and/or fields eligible for >> such the padding, we use new @Contended annotation. Runtime discovery of >> annotations reuses the code John (?) laid out for some of >> JSR292-specific annotations. >> >> The behavior of this annotation is as follows: >> >> A. Marking the class as contended: >> >> @Contended >> public static class ContendedTest2 { >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...makes the entire field block to be padded from the both sides: >> (below is the output of new tracing -XX:+PrintFieldLayout) >> >> TestContended$ContendedTest2: field layout >> Entire class is marked contended >> @140 --- instance fields start --- >> @140 "plainField1" Ljava.lang.Object; >> @144 "plainField2" Ljava.lang.Object; >> @148 "plainField3" Ljava.lang.Object; >> @152 "plainField4" Ljava.lang.Object; >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> Note that we use 128 bytes, twice the cache line size on most hardware >> to adjust for adjacent sector prefetchers extending the false sharing >> collisions to two cache lines. >> >> B. Marking the field as contended: >> >> public static class ContendedTest1 { >> @Contended >> private Object contendedField1; >> private Object plainField1; >> private Object plainField2; >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes the field out of dense block and effectively applies padding: >> >> TestContended$ContendedTest1: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField1" Ljava.lang.Object; >> @ 16 "plainField2" Ljava.lang.Object; >> @ 20 "plainField3" Ljava.lang.Object; >> @ 24 "plainField4" Ljava.lang.Object; >> @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @288 --- instance fields end --- >> @288 --- instance ends --- >> >> C. Marking multiple fields makes each field padded: >> >> public static class ContendedTest4 { >> @Contended >> private Object contendedField1; >> >> @Contended >> private Object contendedField2; >> >> private Object plainField3; >> private Object plainField4; >> } >> >> ...pushes both fields with individual padding for each: >> >> TestContended$ContendedTest4: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField3" Ljava.lang.Object; >> @ 16 "plainField4" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) >> @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> *** IV. Contention groups >> >> There are cases where you want to separate the *group* of fields that >> are experiencing contention with everything else but not pairwise. This >> is the usual thing for some of the code updating two fields at once. >> While marking both with @Contended would be sufficient, we can optimize >> the memory footprint by not applying padding between them. In order to >> demarcate these groups, we have the parameter in the annotation >> describing the equivalence class for contention group. >> >> So that: >> >> public static class ContendedTest5 { >> @Contended("updater1") >> private Object contendedField1; >> >> @Contended("updater1") >> private Object contendedField2; >> >> @Contended("updater2") >> private Object contendedField3; >> >> private Object plainField5; >> private Object plainField6; >> } >> >> ...is laid out as: >> >> TestContended$ContendedTest5: field layout >> @ 12 --- instance fields start --- >> @ 12 "plainField5" Ljava.lang.Object; >> @ 16 "plainField6" Ljava.lang.Object; >> @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) >> @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) >> @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) >> @416 --- instance fields end --- >> @416 --- instance ends --- >> >> Note $contendedField1 and $contendedField2 are padded from everything >> else, but still densely packed with each other. >> >> The code is known to work at least on Linux x86-64, tested with a few >> microtests. The layout of fields without @Contended is not affected, so >> this is presumably a safe change. I will try to run more tests against >> this implementation with JPRT, but will appreciate the design, API, and >> draft implementation review meanwhile... >> >> Thanks, >> Aleksey. From dl at cs.oswego.edu Sun Nov 25 14:02:08 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 25 Nov 2012 17:02:08 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> Message-ID: <50B29560.8050908@cs.oswego.edu> On 11/25/12 16:22, Kirk Pepperdine wrote: > I'm completely in agreement that there are some applications where this > optimization is necessary. That said, I've more fundamental concerns with > respect to this API. Traditionally the JVM has steered away from having > developers hint at optimization as these optimizations have typically been > ill thought out. My mantra has always been, measure, don't guess. WIthout > denigrating any group of developers I would say that very very few know how > to get the measures to even start to understand how to apply this > "optimization". I would suggest that it would be better to leave the > application of this optimization to HotSpot and the JIT compiler. This is a common reaction, but ... As witnessed for example by C11/C++11 standards (that support better ways of obtaining alignment and padding), memory contention issues are increasingly part of core library and lower-level programming, in any language. Naively, one might hope that HW memory controllers, OSes, and/or VMs could sense problems and take evasive action, but no practical techniques for doing so are known. If JDK/Java takes the position that it is best to hope for miracles, developers who need this functionality to create libraries and frameworks will eventually choose to abandon the platform. Which might be OK if your goal is to hasten the COBOLization of Java. But most people seem to want Java to remain a broad-spectrum language, in which case, it cannot adopt policies that apply to only 99.9% of the spectrum. (BTW, stay tuned for other VM support proposals along these lines.) -Doug From david.holmes at oracle.com Sun Nov 25 14:21:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Nov 2012 08:21:47 +1000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> Message-ID: <50B299FB.3060505@oracle.com> Hi Kirk, I hear what you are saying. But I don't think expecting hotspot to be able to determine this is feasible - certainly not in the short to medium term. What you are suggesting requires dynamic adjustment to the object layout as hotspot determines that it is sub-optimal, and that level of dynamism simply isn't part of hotspot's current design. And I don't know whether state-of-the-art runtime performance measuring is at a point where you would know what data to gather, or how to analyse it, to make a decision like this. And even then that decision would be a local one. So we either do something or do nothing. This proposed API, like a number of advanced concurrency API's is certainly targeted at a very select group of expert developers (I don't even count myself in that group in this case). And even those experts are going to be hampered by local decisions (eg in a JDK core library) impacting global (application) performance. But without this we have to resort to manually padding fields to try and get the desired affects. And that makes numerous assumptions regarding normal field layout etc, that are VM dependent. So which is worse: a) providing an advanced API that the average programmer won't know how to use and could easily misuse (if silly enough to mess with things they don't understand); or b) having library/application writers introduce Java-level field padding that makes various assumptions about the underlying VM ? I think (b) is worse. Cheers, David On 26/11/2012 7:22 AM, Kirk Pepperdine wrote: > Hi David, > > I'm completely in agreement that there are some applications where this optimization is necessary. That said, I've more fundamental concerns with respect to this API. Traditionally the JVM has steered away from having developers hint at optimization as these optimizations have typically been ill thought out. My mantra has always been, measure, don't guess. WIthout denigrating any group of developers I would say that very very few know how to get the measures to even start to understand how to apply this "optimization". I would suggest that it would be better to leave the application of this optimization to HotSpot and the JIT compiler. I would also suggest that one could do this is the JVM were to use more of the diagnostics (MSRs) available to it to know when and how to apply this particular optimization. If this all sounds expensive... well, turning on CPU event counters is cheap but evaluating the data maybe a cycle sync... but then again maybe not. But more to the poin! t, getti ng this type of profiling and optimization into HotSpot seems like a far better solution than to give developers access to how variables get laid out. > > Sorry Aleksey, I know you get it.. but you're not in the same class of developer as those that would be using this feature. > > Regards, > Kirk > > On 2012-11-25, at 9:40 PM, David Holmes wrote: > >> Hi Aleksey, >> >> This seems good for local decisions about placement/layout, but I'm concerned about the global impact on footprint and performance. What if individually these kinds of changes yield better microbenchmark performance, but collectively they yield worse application performance? At present this is an all-or-nothing API - though after some thought I'm not sure it could be anything else. >> >> David >> >> On 23/11/2012 7:33 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> After some internal discussions with Doug Lea, Dave Dice and others, I >>> would like to solicit the initial feedback on the implementation of >>> JEP-142, aka @Contended [1]: >>> http://openjdk.java.net/jeps/142 >>> >>> The webrev for the initial version is here: >>> http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ >>> >>> Implementation overview. Hotspot code is currently laying out the fields >>> to optimize the memory footprint, rearranging fields freely to both >>> satisfy alignment requirements for fields and making the less gaps >>> possible. We leverage the same infrastructure to exempt specific fields >>> from the packing, and pushing them outside the dense packed block at >>> sparse offsets, naturally making up the appropriate padding. >>> >>> In order to demarcate the specific classes and/or fields eligible for >>> such the padding, we use new @Contended annotation. Runtime discovery of >>> annotations reuses the code John (?) laid out for some of >>> JSR292-specific annotations. >>> >>> The behavior of this annotation is as follows: >>> >>> A. Marking the class as contended: >>> >>> @Contended >>> public static class ContendedTest2 { >>> private Object plainField1; >>> private Object plainField2; >>> private Object plainField3; >>> private Object plainField4; >>> } >>> >>> ...makes the entire field block to be padded from the both sides: >>> (below is the output of new tracing -XX:+PrintFieldLayout) >>> >>> TestContended$ContendedTest2: field layout >>> Entire class is marked contended >>> @140 --- instance fields start --- >>> @140 "plainField1" Ljava.lang.Object; >>> @144 "plainField2" Ljava.lang.Object; >>> @148 "plainField3" Ljava.lang.Object; >>> @152 "plainField4" Ljava.lang.Object; >>> @288 --- instance fields end --- >>> @288 --- instance ends --- >>> >>> Note that we use 128 bytes, twice the cache line size on most hardware >>> to adjust for adjacent sector prefetchers extending the false sharing >>> collisions to two cache lines. >>> >>> B. Marking the field as contended: >>> >>> public static class ContendedTest1 { >>> @Contended >>> private Object contendedField1; >>> private Object plainField1; >>> private Object plainField2; >>> private Object plainField3; >>> private Object plainField4; >>> } >>> >>> ...pushes the field out of dense block and effectively applies padding: >>> >>> TestContended$ContendedTest1: field layout >>> @ 12 --- instance fields start --- >>> @ 12 "plainField1" Ljava.lang.Object; >>> @ 16 "plainField2" Ljava.lang.Object; >>> @ 20 "plainField3" Ljava.lang.Object; >>> @ 24 "plainField4" Ljava.lang.Object; >>> @156 "contendedField1" Ljava.lang.Object; (contended, group = 0) >>> @288 --- instance fields end --- >>> @288 --- instance ends --- >>> >>> C. Marking multiple fields makes each field padded: >>> >>> public static class ContendedTest4 { >>> @Contended >>> private Object contendedField1; >>> >>> @Contended >>> private Object contendedField2; >>> >>> private Object plainField3; >>> private Object plainField4; >>> } >>> >>> ...pushes both fields with individual padding for each: >>> >>> TestContended$ContendedTest4: field layout >>> @ 12 --- instance fields start --- >>> @ 12 "plainField3" Ljava.lang.Object; >>> @ 16 "plainField4" Ljava.lang.Object; >>> @148 "contendedField1" Ljava.lang.Object; (contended, group = 0) >>> @280 "contendedField2" Ljava.lang.Object; (contended, group = 0) >>> @416 --- instance fields end --- >>> @416 --- instance ends --- >>> >>> *** IV. Contention groups >>> >>> There are cases where you want to separate the *group* of fields that >>> are experiencing contention with everything else but not pairwise. This >>> is the usual thing for some of the code updating two fields at once. >>> While marking both with @Contended would be sufficient, we can optimize >>> the memory footprint by not applying padding between them. In order to >>> demarcate these groups, we have the parameter in the annotation >>> describing the equivalence class for contention group. >>> >>> So that: >>> >>> public static class ContendedTest5 { >>> @Contended("updater1") >>> private Object contendedField1; >>> >>> @Contended("updater1") >>> private Object contendedField2; >>> >>> @Contended("updater2") >>> private Object contendedField3; >>> >>> private Object plainField5; >>> private Object plainField6; >>> } >>> >>> ...is laid out as: >>> >>> TestContended$ContendedTest5: field layout >>> @ 12 --- instance fields start --- >>> @ 12 "plainField5" Ljava.lang.Object; >>> @ 16 "plainField6" Ljava.lang.Object; >>> @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) >>> @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) >>> @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) >>> @416 --- instance fields end --- >>> @416 --- instance ends --- >>> >>> Note $contendedField1 and $contendedField2 are padded from everything >>> else, but still densely packed with each other. >>> >>> The code is known to work at least on Linux x86-64, tested with a few >>> microtests. The layout of fields without @Contended is not affected, so >>> this is presumably a safe change. I will try to run more tests against >>> this implementation with JPRT, but will appreciate the design, API, and >>> draft implementation review meanwhile... >>> >>> Thanks, >>> Aleksey. > From richard.warburton at gmail.com Sun Nov 25 16:51:35 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Mon, 26 Nov 2012 00:51:35 +0000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B299FB.3060505@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> <50B299FB.3060505@oracle.com> Message-ID: > But without this we have to resort to manually padding fields to try and > get the desired affects. And that makes numerous assumptions regarding > normal field layout etc, that are VM dependent. > > So which is worse: > a) providing an advanced API that the average programmer won't know how to > use and could easily misuse (if silly enough to mess with things they don't > understand); or > b) having library/application writers introduce Java-level field padding > that makes various assumptions about the underlying VM > > ? > > I think (b) is worse. > Hey, Firstly thanks for achieving progress on JEP 142. I'm sure everyone on the community side appreciates the effort going into it. I've basically got two points to make, a: there are historical comparisons for this kind of API, b: evidence from the field about devs. One point of historical comparison to consider is System.gc(). Something that I'm sure many developers have encountered is an overly zealous usage of this function by people who don't understand the way that their GC works or an understanding of the full effects of calling this specific function have. I suppose its an open question as to whether in an ideal world this would have been removed from Java or not, but I think its something that you should consider as a point of comparison when exposing specific performance tweaking characteristics to the user. On Saturday I gave a talk to a small, but packed, room of Java Devs in London about CPU Caching performance. I talked about using MSRs to measure caching behaviour and described false sharing as a potential problem and the available solutions. (Great timing on the JEP btw!) With hindsight I should have anticipated this discussion on the list and questioned people more about whether they knew or understood the issues beforehand. My impression of the audience was the overwhelming majority of them hadn't encountered the issue before. In fact I'd say only a couple of people had really thought through this kind of issue before. The first audience question I got was what kind of company used this level of optimisation and analysis for their production code. The only people I've met who talk about false sharing and field padding are people who actually understand their CPU Caching well enough to not abuse the feature. I've met lots of people who say lots of things about Garbage Collection. A few low proportion are sensible, The London market isn't devoid of people who care about performance issues either. Some of the London Java Community's best attended talks are on performance related topics such as tuning. In conclusion Kirk is 100% correct to worry about this kind of feature and System.gc() suggests that there are Dragons to avoid, but I think so few people understand this issue enough to even realise there's a benefit to fiddling. I'm sure many other people have interacted with a wider audience than me, and I imagine they might have anecdotal evidence about abuse of this issue. Has anyone ever encountered code where a developer has padded a field in order to avoid contention issues and badly messed up in the same way that System.gc is abused? regards, Richard From weijun.wang at oracle.com Sun Nov 25 21:46:24 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 26 Nov 2012 13:46:24 +0800 Subject: Reflection.getCallerClass(n) does not skip reflection calls in constructors Message-ID: <50B30230.5000400@oracle.com> Hi I'm trying to use Reflection.getCallerClass(n) to find out who is calling a method. The method's spec says: .... Frames associated with java.lang.reflect.Method.invoke() and its implementation are completely ignored and do not count toward the number of "real" frames skipped. This is very nice but it does not mention Constructor.newInstance(). In fact, I do see the following entries if I'm creating an object thru reflection: Callee class sun.reflect.NativeConstructorAccessorImpl class sun.reflect.NativeConstructorAccessorImpl class sun.reflect.DelegatingConstructorAccessorImpl class java.lang.reflect.Constructor Caller Is there any reason why we cannot do the same for constructor instantiation? Thanks Max From stefan.karlsson at oracle.com Sun Nov 25 23:05:53 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 26 Nov 2012 08:05:53 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50AF6A92.8080401@oracle.com> References: <50AF640D.1050401@oracle.com> <50AF6A92.8080401@oracle.com> Message-ID: <50B314D1.2070409@oracle.com> On 2012-11-23 13:22, David Holmes wrote: > Hi Stefan, > > I never did like these. > > I have to wonder though, why isn't it "runtime/thread.hpp" that all > the client code #includes? Typically, you place inline functions in a inline.hpp file instead of the hpp. This helps reducing the number of unnecessary includes from spreading through out the code base. Only the users of the inline functions will include the inline.hpp file, and bring in the needed includes to implement the function. Preferably, you should only include inline.hpp files from other cpp files or other inline.hpp files. > And then why isn't it thread.hpp that includes the platform specific > header? In this specific case, there's an inline function in thread_solaris.inline.hpp that Thread::current() needs. StefanK > > David > > On 23/11/2012 9:54 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8003935/webrev >> >> Today, whenever we use Thread::current() we have to all these lines: >> >> #include "runtime/thread.hpp" >> #ifdef TARGET_OS_FAMILY_linux >> # include "thread_linux.inline.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_solaris >> # include "thread_solaris.inline.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_windows >> # include "thread_windows.inline.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_bsd >> # include "thread_bsd.inline.hpp" >> #endif >> >> This patch hides this dispatching in a new file named thread.inline.hpp. >> Now we only have to include thread.inline.hpp. >> >> Some background to these includes: This type of dispatching was >> introduced into the source files when we removed the includeDB files. We >> discussed whether we should use "dispatch files" or not for this kind >> platform dependent includes. The decision was to not create dispatch >> files for all types of platform at that time, but instead manually >> create them when we thought it was warranted. >> >> thanks, >> StefanK >> >> From david.holmes at oracle.com Sun Nov 25 23:07:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Nov 2012 17:07:42 +1000 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50B314D1.2070409@oracle.com> References: <50AF640D.1050401@oracle.com> <50AF6A92.8080401@oracle.com> <50B314D1.2070409@oracle.com> Message-ID: <50B3153E.5080903@oracle.com> Thanks for clarifying that Stefan. Looks okay to me. David On 26/11/2012 5:05 PM, Stefan Karlsson wrote: > On 2012-11-23 13:22, David Holmes wrote: >> Hi Stefan, >> >> I never did like these. >> >> I have to wonder though, why isn't it "runtime/thread.hpp" that all >> the client code #includes? > Typically, you place inline functions in a inline.hpp file instead of > the hpp. This helps reducing the number of unnecessary includes from > spreading through out the code base. Only the users of the inline > functions will include the inline.hpp file, and bring in the needed > includes to implement the function. > > Preferably, you should only include inline.hpp files from other cpp > files or other inline.hpp files. > >> And then why isn't it thread.hpp that includes the platform specific >> header? > > In this specific case, there's an inline function in > thread_solaris.inline.hpp that Thread::current() needs. > > StefanK >> >> David >> >> On 23/11/2012 9:54 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8003935/webrev >>> >>> Today, whenever we use Thread::current() we have to all these lines: >>> >>> #include "runtime/thread.hpp" >>> #ifdef TARGET_OS_FAMILY_linux >>> # include "thread_linux.inline.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_solaris >>> # include "thread_solaris.inline.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_windows >>> # include "thread_windows.inline.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_bsd >>> # include "thread_bsd.inline.hpp" >>> #endif >>> >>> This patch hides this dispatching in a new file named thread.inline.hpp. >>> Now we only have to include thread.inline.hpp. >>> >>> Some background to these includes: This type of dispatching was >>> introduced into the source files when we removed the includeDB files. We >>> discussed whether we should use "dispatch files" or not for this kind >>> platform dependent includes. The decision was to not create dispatch >>> files for all types of platform at that time, but instead manually >>> create them when we thought it was warranted. >>> >>> thanks, >>> StefanK >>> >>> > From stefan.karlsson at oracle.com Sun Nov 25 23:10:25 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 26 Nov 2012 08:10:25 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50B3153E.5080903@oracle.com> References: <50AF640D.1050401@oracle.com> <50AF6A92.8080401@oracle.com> <50B314D1.2070409@oracle.com> <50B3153E.5080903@oracle.com> Message-ID: <50B315E1.7060405@oracle.com> Thanks, David. StefanK On 2012-11-26 08:07, David Holmes wrote: > Thanks for clarifying that Stefan. Looks okay to me. > > David > > On 26/11/2012 5:05 PM, Stefan Karlsson wrote: >> On 2012-11-23 13:22, David Holmes wrote: >>> Hi Stefan, >>> >>> I never did like these. >>> >>> I have to wonder though, why isn't it "runtime/thread.hpp" that all >>> the client code #includes? >> Typically, you place inline functions in a inline.hpp file instead of >> the hpp. This helps reducing the number of unnecessary includes from >> spreading through out the code base. Only the users of the inline >> functions will include the inline.hpp file, and bring in the needed >> includes to implement the function. >> >> Preferably, you should only include inline.hpp files from other cpp >> files or other inline.hpp files. >> >>> And then why isn't it thread.hpp that includes the platform specific >>> header? >> >> In this specific case, there's an inline function in >> thread_solaris.inline.hpp that Thread::current() needs. >> >> StefanK >>> >>> David >>> >>> On 23/11/2012 9:54 PM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8003935/webrev >>>> >>>> Today, whenever we use Thread::current() we have to all these lines: >>>> >>>> #include "runtime/thread.hpp" >>>> #ifdef TARGET_OS_FAMILY_linux >>>> # include "thread_linux.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_solaris >>>> # include "thread_solaris.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_windows >>>> # include "thread_windows.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_bsd >>>> # include "thread_bsd.inline.hpp" >>>> #endif >>>> >>>> This patch hides this dispatching in a new file named >>>> thread.inline.hpp. >>>> Now we only have to include thread.inline.hpp. >>>> >>>> Some background to these includes: This type of dispatching was >>>> introduced into the source files when we removed the includeDB >>>> files. We >>>> discussed whether we should use "dispatch files" or not for this kind >>>> platform dependent includes. The decision was to not create dispatch >>>> files for all types of platform at that time, but instead manually >>>> create them when we thought it was warranted. >>>> >>>> thanks, >>>> StefanK >>>> >>>> >> From rickard.backman at oracle.com Sun Nov 25 23:48:50 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 26 Nov 2012 08:48:50 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50AF640D.1050401@oracle.com> References: <50AF640D.1050401@oracle.com> Message-ID: <37E499BE-A47B-4892-B730-66418A96BA1A@oracle.com> Stefan, nice change. Looks good. /R On Nov 23, 2012, at 12:54 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8003935/webrev > > Today, whenever we use Thread::current() we have to all these lines: > > #include "runtime/thread.hpp" > #ifdef TARGET_OS_FAMILY_linux > # include "thread_linux.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "thread_solaris.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "thread_windows.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "thread_bsd.inline.hpp" > #endif > > This patch hides this dispatching in a new file named thread.inline.hpp. Now we only have to include thread.inline.hpp. > > Some background to these includes: This type of dispatching was introduced into the source files when we removed the includeDB files. We discussed whether we should use "dispatch files" or not for this kind platform dependent includes. The decision was to not create dispatch files for all types of platform at that time, but instead manually create them when we thought it was warranted. > > thanks, > StefanK > > From stefan.karlsson at oracle.com Sun Nov 25 23:49:45 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 26 Nov 2012 08:49:45 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <37E499BE-A47B-4892-B730-66418A96BA1A@oracle.com> References: <50AF640D.1050401@oracle.com> <37E499BE-A47B-4892-B730-66418A96BA1A@oracle.com> Message-ID: <50B31F19.7020409@oracle.com> Thanks, Rickard. StefanK On 2012-11-26 08:48, Rickard B?ckman wrote: > Stefan, > > nice change. Looks good. > > /R > > On Nov 23, 2012, at 12:54 PM, Stefan Karlsson wrote: > >> http://cr.openjdk.java.net/~stefank/8003935/webrev >> >> Today, whenever we use Thread::current() we have to all these lines: >> >> #include "runtime/thread.hpp" >> #ifdef TARGET_OS_FAMILY_linux >> # include "thread_linux.inline.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_solaris >> # include "thread_solaris.inline.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_windows >> # include "thread_windows.inline.hpp" >> #endif >> #ifdef TARGET_OS_FAMILY_bsd >> # include "thread_bsd.inline.hpp" >> #endif >> >> This patch hides this dispatching in a new file named thread.inline.hpp. Now we only have to include thread.inline.hpp. >> >> Some background to these includes: This type of dispatching was introduced into the source files when we removed the includeDB files. We discussed whether we should use "dispatch files" or not for this kind platform dependent includes. The decision was to not create dispatch files for all types of platform at that time, but instead manually create them when we thought it was warranted. >> >> thanks, >> StefanK >> >> From aleksey.shipilev at oracle.com Mon Nov 26 00:55:02 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 12:55:02 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> Message-ID: <50B32E66.4000501@oracle.com> On 11/26/2012 01:22 AM, Kirk Pepperdine wrote: > My mantra has always been, measure, don't guess. ...said the guy before start guessing about the impact for this annotation :D We know exactly where this helps, and where library developers sorely need this functionality, so here we are. In a few years, having this annotation around would help us to understand if that is applicable on broader scope, and what are the preconditions to be granted while applying this optimization. Having all that on the table, we could finally rationalize the budget needed to research and bringing on the automatic field layout. Before that, it's preposterous to invest several man-years into developing the optimization now known to be needed in a handful of cases. -Aleksey. From aph at redhat.com Mon Nov 26 01:50:10 2012 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Nov 2012 09:50:10 +0000 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353690888.31435.3.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> Message-ID: <50B33B52.1060404@redhat.com> On 11/23/2012 05:14 PM, Roman Kennke wrote: > > Alright, I found another fairly grave bug that I would like to include a > fix for: apparently, a 'fence' is not enough of a memory barrier for > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > LLVM offers atomic loads and stores, which seem to be exactly what is > needed for volatile field access. However, it does not provide helper > functions for those in llvm::IRBuilder so I wrote my own. This should be > the final patch for now (unless you find something else). > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ I note that you've used llvm::SequentiallyConsistent for all the atomic accesses. This looks right to me, but if there's any doubt you could ask Doug Lea. Andrew. From kirk at kodewerk.com Mon Nov 26 01:55:53 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 26 Nov 2012 10:55:53 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B29560.8050908@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> <50B29560.8050908@cs.oswego.edu> Message-ID: <0EAD79AC-EFE6-44B5-BDFF-4E7A2CB23464@kodewerk.com> > On 11/25/12 16:22, Kirk Pepperdine wrote: > >> I'm completely in agreement that there are some applications where this >> optimization is necessary. That said, I've more fundamental concerns with >> respect to this API. Traditionally the JVM has steered away from having >> developers hint at optimization as these optimizations have typically been >> ill thought out. My mantra has always been, measure, don't guess. WIthout >> denigrating any group of developers I would say that very very few know how >> to get the measures to even start to understand how to apply this >> "optimization". I would suggest that it would be better to leave the >> application of this optimization to HotSpot and the JIT compiler. > > This is a common reaction, but ... > > As witnessed for example by C11/C++11 standards (that support > better ways of obtaining alignment and padding), memory contention > issues are increasingly part of core library and lower-level programming, > in any language. And it's a problem that naturally is just going to get worse.... > Naively, one might hope that HW memory controllers, > OSes, and/or VMs could sense problems and take evasive action, but > no practical techniques for doing so are known. If JDK/Java takes > the position that it is best to hope for miracles, developers > who need this functionality to create libraries and frameworks > will eventually choose to abandon the platform. Which might be > OK if your goal is to hasten the COBOLization of Java. But > most people seem to want Java to remain a broad-spectrum language, > in which case, it cannot adopt policies that apply to only 99.9% > of the spectrum. I think to suggest that we do nothing and rely on "magic" wasn't the message that I was trying to send. My concerns with this JEP come to me at many different levels. I might add that I tried to raise a flag w.r.t. autoboxing and as successful as it was (my editorial in JDJ remains one of the most popular to date) it was far too little and way too late. What I see here is a good idea, it helps address a problem that I believe damages performance far more than people realize. That said, I'm not sure that this is the "Java" direction. Once more, what generics has taught us that once in, these things become very very difficult to make right and impossible to remove or replace. More over, what you've taught me is that we need to be ultra-conservative when it comes to how we implement and push to production. IMHO, this annotation changes the a very fundamental assumption that developers should write code and the compilers/JIT should look after everything they can. It's also breaks another very fundamental direction where the JVM has been able to adapt to different environments and even to changing conditions with-in an environment. Correct me if I'm wrong but I feel that these annotations assumes that developers can predict deployment environments, the problems that they will encounter within those environments. While that maybe true in some cases I might also suggest that the JVM could be able to pick up on them and make the necessary adjustments. At the next level of concerns it's an optimization that very few people know how to measure for. Even so, measuring in the context of a micro-benchmark is unlikely to lead to a measure that will allow one to take reasonable corrective action that holds in macro-environments. In other words, and as I know you are well aware, there are a number of competing concerns that render these micro-optimizations invisible to the end user. This not to say that we shouldn't reach for these optimization, it's just saying that to the vast majority of applications it is very likely that the results will be an unnecessary introduction of low level (and potentially fragile) detail into the code without receiving any benefit. Where as applying these techniques using a runtime profiler will keep the low level details out of the code (reduce fragility of the optimization) and while providing meaningful benefit (as has been our experience with HotSpot/JIT). My last concern is about the general level of knowledge and the mix of these hardcore features into this blend. We don't have any durable (or even fragile) measures that are accessible to the every day developer meaning.. lets guess that we have a problem and then apply this fix.... this isn't a direction that I would subscribe to. I'd like to weave in Richard's response. Full disclosure, Richard is one of my subcontractors and we had him working on tooling that looks for these conditions by programming the event counters on Intel chips (machine specific registers). It's a piece of work that has unfortunately been pre-empted due to some higher priority items in the hopper so there is still much to be done here. What we are looking for are groups counter values that would be an indication that the software/hardware aren't cooperating as well as they should be. We believe that one of the key indicators would be a decrease in the rate at which instructions are retired. Using this plus other factors we are working to correlate drops in these key indicators (such as retirement rates) to activity in the code. From there we'd hope to be able to at worst, identify the underlying problem or at best, suggest a way to make the software cooperate better with the hardware. More over, using hardware provided counters helps cheapen the cost of detecting these problems. My work in building customized production system ready profilers has taught me that the cost of running targeted diagnostics can be accurate, quick and cheap. I believe that to do this right, one will need a combination of all of these techniques, a trigger, an analytic along with a diagnostic. To address David, as you can see I'm not suggesting we do nothing. That said, there is a third alternative that has sent. Richard responded in another post and I'd like to argument that by saying we know how to get the measurements using machine specific registers to understand when there is a low level problem. We've been looking at ways to correlate that to application behaviour and I think it's only going to be a matter of time before we'll be able to tell a developer exactly what needs to be done to reduce the problem. That said, I do recognize that it's not been fully explored and that the path isn't completely clear but.... I'd much rather say ok, at least we know a JVM based solution is impossible before forcing developers to muck up code. > > (BTW, stay tuned for other VM support proposals along these lines.) Any hints would be very much appreciated :-) Regards, Kirk From kirk at kodewerk.com Mon Nov 26 02:01:41 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 26 Nov 2012 11:01:41 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B32E66.4000501@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> <50B32E66.4000501@oracle.com> Message-ID: <20C13949-A2EA-4029-8B5D-978A2AE9AD04@kodewerk.com> I'm not arguing against the optimization, I clearly see the value. I'm just suggesting this is not a "Thinking in Java" solution, it's a "Thinking in C++" solution. Don't misunderstand, both are valid ways of thinking when done in the right context. ;-) -- Kirk On 2012-11-26, at 9:55 AM, Aleksey Shipilev wrote: > On 11/26/2012 01:22 AM, Kirk Pepperdine wrote: >> My mantra has always been, measure, don't guess. > > ...said the guy before start guessing about the impact for this > annotation :D > > We know exactly where this helps, and where library developers sorely > need this functionality, so here we are. In a few years, having this > annotation around would help us to understand if that is applicable on > broader scope, and what are the preconditions to be granted while > applying this optimization. Having all that on the table, we could > finally rationalize the budget needed to research and bringing on the > automatic field layout. Before that, it's preposterous to invest several > man-years into developing the optimization now known to be needed in a > handful of cases. > > -Aleksey. From aleksey.shipilev at oracle.com Mon Nov 26 02:09:50 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 14:09:50 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <20C13949-A2EA-4029-8B5D-978A2AE9AD04@kodewerk.com> References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> <50B32E66.4000501@oracle.com> <20C13949-A2EA-4029-8B5D-978A2AE9AD04@kodewerk.com> Message-ID: <50B33FEE.7040903@oracle.com> Well, yeah. Hardware specifics leaking into high-level application code, that's a fact of life for high-performance code, whatever language is concerned. -Aleksey. On 11/26/2012 02:01 PM, Kirk Pepperdine wrote: > I'm not arguing against the optimization, I clearly see the value. I'm just suggesting this is not a "Thinking in Java" solution, it's a "Thinking in C++" solution. Don't misunderstand, both are valid ways of thinking when done in the right context. ;-) > > -- Kirk > > On 2012-11-26, at 9:55 AM, Aleksey Shipilev wrote: > >> On 11/26/2012 01:22 AM, Kirk Pepperdine wrote: >>> My mantra has always been, measure, don't guess. >> >> ...said the guy before start guessing about the impact for this >> annotation :D >> >> We know exactly where this helps, and where library developers sorely >> need this functionality, so here we are. In a few years, having this >> annotation around would help us to understand if that is applicable on >> broader scope, and what are the preconditions to be granted while >> applying this optimization. Having all that on the table, we could >> finally rationalize the budget needed to research and bringing on the >> automatic field layout. Before that, it's preposterous to invest several >> man-years into developing the optimization now known to be needed in a >> handful of cases. >> >> -Aleksey. > From vitalyd at gmail.com Mon Nov 26 04:29:53 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Nov 2012 07:29:53 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B33FEE.7040903@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B2822D.3010603@oracle.com> <50B32E66.4000501@oracle.com> <20C13949-A2EA-4029-8B5D-978A2AE9AD04@kodewerk.com> <50B33FEE.7040903@oracle.com> Message-ID: Completely agree with this and Doug's earlier reply - java must allow low-level optimization techniques in order to stay relevant in the high perf segment. In this case, the problem (false sharing) is easy to understand (if someone's willing to learn) and the contended flag has clear semantics on what it does. If a java dev has no interest in this technique, then they simply don't care about @Contended. If a library dev decided to do this, then one hopes/expects that they've done the prerequisite investigation that warrants its use. I think expecting the JVM to do magic behind the scenes and thus leaving low level tweaks out would be a mistake. If anything, I'd welcome more ability to hint the runtime/JIT if it means more performance can be squeezed out. Vitaly Sent from my phone On Nov 26, 2012 5:11 AM, "Aleksey Shipilev" wrote: > Well, yeah. Hardware specifics leaking into high-level application code, > that's a fact of life for high-performance code, whatever language is > concerned. > > -Aleksey. > > On 11/26/2012 02:01 PM, Kirk Pepperdine wrote: > > I'm not arguing against the optimization, I clearly see the value. I'm > just suggesting this is not a "Thinking in Java" solution, it's a "Thinking > in C++" solution. Don't misunderstand, both are valid ways of thinking when > done in the right context. ;-) > > > > -- Kirk > > > > On 2012-11-26, at 9:55 AM, Aleksey Shipilev > wrote: > > > >> On 11/26/2012 01:22 AM, Kirk Pepperdine wrote: > >>> My mantra has always been, measure, don't guess. > >> > >> ...said the guy before start guessing about the impact for this > >> annotation :D > >> > >> We know exactly where this helps, and where library developers sorely > >> need this functionality, so here we are. In a few years, having this > >> annotation around would help us to understand if that is applicable on > >> broader scope, and what are the preconditions to be granted while > >> applying this optimization. Having all that on the table, we could > >> finally rationalize the budget needed to research and bringing on the > >> automatic field layout. Before that, it's preposterous to invest several > >> man-years into developing the optimization now known to be needed in a > >> handful of cases. > >> > >> -Aleksey. > > > > From rkennke at redhat.com Mon Nov 26 04:58:29 2012 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 26 Nov 2012 13:58:29 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <50B33B52.1060404@redhat.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <50B33B52.1060404@redhat.com> Message-ID: <1353934709.7814.2.camel@mercury> Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley: > On 11/23/2012 05:14 PM, Roman Kennke wrote: > > > > > Alright, I found another fairly grave bug that I would like to include a > > fix for: apparently, a 'fence' is not enough of a memory barrier for > > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > > LLVM offers atomic loads and stores, which seem to be exactly what is > > needed for volatile field access. However, it does not provide helper > > functions for those in llvm::IRBuilder so I wrote my own. This should be > > the final patch for now (unless you find something else). > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > > I note that you've used llvm::SequentiallyConsistent for all the atomic > accesses. This looks right to me, but if there's any doubt you could > ask Doug Lea. Yeah. Except for monitorenter and monitorexit, where I used Acquire and Release (which I believe is right too, at least it seems *very* sensible :-) ). The other access flags (unordered and monotonic) don't seem to have a mapping in Java, except maybe in some of the many Unsafe intrinsics, but they are not implemented in Shark (yet). Roman From aleksey.shipilev at oracle.com Mon Nov 26 05:08:17 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 17:08:17 +0400 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353934709.7814.2.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <50B33B52.1060404@redhat.com> <1353934709.7814.2.camel@mercury> Message-ID: <50B369C1.4000607@oracle.com> On 11/26/2012 04:58 PM, Roman Kennke wrote: > Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley: >> On 11/23/2012 05:14 PM, Roman Kennke wrote: >> >>> >>> Alright, I found another fairly grave bug that I would like to include a >>> fix for: apparently, a 'fence' is not enough of a memory barrier for >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. >>> LLVM offers atomic loads and stores, which seem to be exactly what is >>> needed for volatile field access. However, it does not provide helper >>> functions for those in llvm::IRBuilder so I wrote my own. This should be >>> the final patch for now (unless you find something else). >>> >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ >> >> I note that you've used llvm::SequentiallyConsistent for all the atomic >> accesses. This looks right to me, but if there's any doubt you could >> ask Doug Lea. > > Yeah. Except for monitorenter and monitorexit, where I used Acquire and > Release (which I believe is right too, at least it seems *very* > sensible :-) ). The other access flags (unordered and monotonic) don't > seem to have a mapping in Java, except maybe in some of the many Unsafe > intrinsics, but they are not implemented in Shark (yet). My 2c: making atomics SC is ok. I wonder if Shark can pass the concurrency torture tests [1]? (if you run these, make sure you do that against the latest hotspot-comp) Thanks, Aleksey [1] https://github.com/shipilev/java-concurrency-torture From coleen.phillimore at oracle.com Mon Nov 26 06:14:31 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 26 Nov 2012 09:14:31 -0500 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50AF640D.1050401@oracle.com> References: <50AF640D.1050401@oracle.com> Message-ID: <50B37947.4070401@oracle.com> This looks good to me. Thank you for explaining why this is like this again, because I still think it was the right decision. This one is warranted though because it's critical that Thread::current() be inlined. Thanks, Coleen On 11/23/2012 6:54 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8003935/webrev > > Today, whenever we use Thread::current() we have to all these lines: > > #include "runtime/thread.hpp" > #ifdef TARGET_OS_FAMILY_linux > # include "thread_linux.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "thread_solaris.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "thread_windows.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "thread_bsd.inline.hpp" > #endif > > This patch hides this dispatching in a new file named > thread.inline.hpp. Now we only have to include thread.inline.hpp. > > Some background to these includes: This type of dispatching was > introduced into the source files when we removed the includeDB files. > We discussed whether we should use "dispatch files" or not for this > kind platform dependent includes. The decision was to not create > dispatch files for all types of platform at that time, but instead > manually create them when we thought it was warranted. > > thanks, > StefanK > > From rkennke at redhat.com Mon Nov 26 06:20:22 2012 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 26 Nov 2012 15:20:22 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <50B369C1.4000607@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <50B33B52.1060404@redhat.com> <1353934709.7814.2.camel@mercury> <50B369C1.4000607@oracle.com> Message-ID: <1353939622.7814.5.camel@mercury> Am Montag, den 26.11.2012, 17:08 +0400 schrieb Aleksey Shipilev: > On 11/26/2012 04:58 PM, Roman Kennke wrote: > > Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley: > >> On 11/23/2012 05:14 PM, Roman Kennke wrote: > >> > >>> > >>> Alright, I found another fairly grave bug that I would like to include a > >>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>> needed for volatile field access. However, it does not provide helper > >>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>> the final patch for now (unless you find something else). > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >> > >> I note that you've used llvm::SequentiallyConsistent for all the atomic > >> accesses. This looks right to me, but if there's any doubt you could > >> ask Doug Lea. > > > > Yeah. Except for monitorenter and monitorexit, where I used Acquire and > > Release (which I believe is right too, at least it seems *very* > > sensible :-) ). The other access flags (unordered and monotonic) don't > > seem to have a mapping in Java, except maybe in some of the many Unsafe > > intrinsics, but they are not implemented in Shark (yet). > > My 2c: making atomics SC is ok. I wonder if Shark can pass the > concurrency torture tests [1]? (if you run these, make sure you do that > against the latest hotspot-comp) Wow, that is a great test. As far as I can tell (in a short default-options run), Shark does everything correctly (i.e. all FORBIDDEN have 0 occurances, all REQUIRED do happen, etc). Speaking of hotspot-comp, I tried to run JVMSpec with Shark and it seemed to get stuck in one of the tests (don't remember which one). Then I tried it with latest hotspot-comp and it got stuck in the same place. (No idea what it was though, need to look closer when I find some time). Regards, Roman From dl at cs.oswego.edu Mon Nov 26 06:31:13 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 26 Nov 2012 09:31:13 -0500 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353934709.7814.2.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <50B33B52.1060404@redhat.com> <1353934709.7814.2.camel@mercury> Message-ID: <50B37D31.8020406@cs.oswego.edu> On 11/26/12 07:58, Roman Kennke wrote: > Am Montag, den 26.11.2012, 09:50 +0000 schrieb Andrew Haley: >> On 11/23/2012 05:14 PM, Roman Kennke wrote: >> >>> >>> Alright, I found another fairly grave bug that I would like to include a >>> fix for: apparently, a 'fence' is not enough of a memory barrier for >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. >>> LLVM offers atomic loads and stores, which seem to be exactly what is >>> needed for volatile field access. However, it does not provide helper >>> functions for those in llvm::IRBuilder so I wrote my own. This should be >>> the final patch for now (unless you find something else). >>> >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ >> >> I note that you've used llvm::SequentiallyConsistent for all the atomic >> accesses. This looks right to me, but if there's any doubt you could >> ask Doug Lea. > > Yeah. Except for monitorenter and monitorexit, where I used Acquire and > Release (which I believe is right too, at least it seems *very* > sensible :-) ). The other access flags (unordered and monotonic) don't > seem to have a mapping in Java, except maybe in some of the many Unsafe > intrinsics, but they are not implemented in Shark (yet). > I don't much about how llvm maps modes to internals, but so long as you are using atomic updates for lock/unlock, the LLVM documentation implies that this is fine. (See http://llvm.org/docs/Atomics.html) The mappings for other intrinsics (like putOrderedX) also seem straightforward, but leaving all of them as SequentiallyConsistent for now will suffice. -Doug From coleen.phillimore at oracle.com Mon Nov 26 06:55:44 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 26 Nov 2012 09:55:44 -0500 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <50AE334A.604@oracle.com> References: <50AE334A.604@oracle.com> Message-ID: <50B382F0.2050707@oracle.com> Looks fine from the runtime code. Someone from GC will have to review the GC code. thanks, Coleen On 11/22/2012 9:14 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8003720/webrev/ > > Description from CR: > In virtual calls the Method pointer in the interpreter stack frame is > not kept alive by anything other than the "this" pointers to that > method. If bytecodes overwrite the "this" pointer, then call a full > GC, the class loader containing the Method* can be unloaded and the > Method* deallocated. > > This is also a problem with JSR292 MethodHandle static code because > the MethodHandle containing the mirror for the interpreted method > Method* is not on the stack if a GC occurs. > > Fix proposal: > The "obvious" solution to this problem would be to apply the root > scanning OopClosure to the Klass::_java_mirror field of the method in > the interpreted frame. However, doing this might cause us to scan the > same metadata oop location more than once, which is not allowed by > some of the HotSpot GCs. We currently solve similar situations by > always "claiming" and start scanning from the ClassLoaderData and then > proceed down into the Klasses of that class loader. > > For this bug we do the same. All old collections, where class > unloading can occur, pass down a closure that is applied to the > ClassLoaderData of the Klass of the Method in the interpreted frame. > This closure does the claiming and proceeds to scan the class > metadata. Note that during young collections, where we don't do class > unloading, all classes are already used as strong roots and we don't > have to apply this new closure in the interpreted frame. > > Testing: > The added test was initially written by John Rose. I only ported it to > JTreg and made some artistic cleanups to it. > > thanks, > StefanK From volker.simonis at gmail.com Mon Nov 26 07:59:19 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 26 Nov 2012 16:59:19 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50B314D1.2070409@oracle.com> References: <50AF640D.1050401@oracle.com> <50AF6A92.8080401@oracle.com> <50B314D1.2070409@oracle.com> Message-ID: On Mon, Nov 26, 2012 at 8:05 AM, Stefan Karlsson wrote: > On 2012-11-23 13:22, David Holmes wrote: >> >> Hi Stefan, >> >> I never did like these. >> >> I have to wonder though, why isn't it "runtime/thread.hpp" that all the >> client code #includes? > > Typically, you place inline functions in a inline.hpp file instead of the > hpp. This helps reducing the number of unnecessary includes from spreading > through out the code base. Only the users of the inline functions will > include the inline.hpp file, and bring in the needed includes to implement > the function. > > Preferably, you should only include inline.hpp files from other cpp files or > other inline.hpp files. > This is indeed the glory theory. However even in your change, there are still some .hpp files which include .inline.hpp files (e.g abstractInterpreter.hpp includes thread.inline.hpp). Are there any plans to further clean this up (i.e. remove inline.hpp includes from .hpp files) by either: 1a : move the methods from XXX.hpp which require implementations of inline functions from AAA.inline.hpp to XXX.cpp if they are not performance relevant (and include AAA.inline.hpp only in XXX.cpp). 1b : moving the methods from XXX.hpp which require implementations of inline functions from AAA.inline.hpp to a newly created XXX.inline.hpp if they are performance relevant (and include AAA.inline.hpp only in XXX.inline.cpp). 1c : keep the implementation of methods in XXX.hpp which don't require definitions of inline methods from ANY ".inline.hpp" (in this case it may be still necessary to include .hpp files which have been provided previously indirectly by the various ".inline.hpp" files) In general I would be in favour of such a change, but a quick search (find hotspot/src/ -name "*.hpp" | grep -v "\.inline\.hpp" | xargs grep ".inline.hpp" | awk -F ":" '{print $1;}' | sort -u | wc) reveals that there are currently 74 ".hpp" files which include other ".inline.hpp" files. So this would be a real huge change. > >> And then why isn't it thread.hpp that includes the platform specific >> header? > > > In this specific case, there's an inline function in > thread_solaris.inline.hpp that Thread::current() needs. > > StefanK > >> >> David >> >> On 23/11/2012 9:54 PM, Stefan Karlsson wrote: >>> >>> http://cr.openjdk.java.net/~stefank/8003935/webrev >>> >>> Today, whenever we use Thread::current() we have to all these lines: >>> >>> #include "runtime/thread.hpp" >>> #ifdef TARGET_OS_FAMILY_linux >>> # include "thread_linux.inline.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_solaris >>> # include "thread_solaris.inline.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_windows >>> # include "thread_windows.inline.hpp" >>> #endif >>> #ifdef TARGET_OS_FAMILY_bsd >>> # include "thread_bsd.inline.hpp" >>> #endif >>> >>> This patch hides this dispatching in a new file named thread.inline.hpp. >>> Now we only have to include thread.inline.hpp. >>> >>> Some background to these includes: This type of dispatching was >>> introduced into the source files when we removed the includeDB files. We >>> discussed whether we should use "dispatch files" or not for this kind >>> platform dependent includes. The decision was to not create dispatch >>> files for all types of platform at that time, but instead manually >>> create them when we thought it was warranted. >>> >>> thanks, >>> StefanK >>> >>> > From aleksey.shipilev at oracle.com Mon Nov 26 08:14:26 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 20:14:26 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50AE9A34.4020001@oracle.com> References: <50AE9A34.4020001@oracle.com> Message-ID: <50B39562.8070004@oracle.com> On 11/23/2012 01:33 AM, Aleksey Shipilev wrote: > Hi, > > After some internal discussions with Doug Lea, Dave Dice and others, I > would like to solicit the initial feedback on the implementation of > JEP-142, aka @Contended [1]: > http://openjdk.java.net/jeps/142 > > The webrev for the initial version is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/ To those who bothers to track the code changes, the updated webrev is here: http://shipilev.net/pub/jdk/hotspot/contended/webrev-3/ -Aleksey. From dl at cs.oswego.edu Mon Nov 26 08:22:41 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 26 Nov 2012 11:22:41 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B39562.8070004@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> Message-ID: <50B39751.1080203@cs.oswego.edu> On 11/26/12 11:14, Aleksey Shipilev wrote: > To those who bothers to track the code changes, the updated webrev is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-3/ > One small suggestion to slightly appease the nanny-state folks. How about burying the annotation one lever deeper to java.util.concurrent.atomic. This seems to impact only vmSymbols.hpp: template(java_util_concurrent_Contended_signature, "Ljava/util/concurrent/Contended;") -> Ljava/util/concurrent/atomic/Contended; -Doug From aleksey.shipilev at oracle.com Mon Nov 26 08:44:51 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 20:44:51 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B39751.1080203@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> Message-ID: <50B39C83.6010801@oracle.com> On 11/26/2012 08:22 PM, Doug Lea wrote: > One small suggestion to slightly appease the nanny-state folks. > How about burying the annotation one lever deeper to > java.util.concurrent.atomic. But the construction of @Contended has nothing to do with atomics, right? (Yes, the sanest use case is to protect atomically-updated fields.) "Nanny-state folks" would naturally presume annotating the plain field with @Contended will turn all operations on that field into atomics :) Alternatives: java.util.concurrent.hints.Contended java.util.concurrent.expert.Contended java.util.concurrent.unsafe.Contended java.util.concurrent.herebedragons.Contended :) I think the high-level annotation is already good. -Aleksey. From coleen.phillimore at oracle.com Mon Nov 26 09:34:15 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 26 Nov 2012 12:34:15 -0500 Subject: Request for review 8003722: More gcc 4.7 compilation errors In-Reply-To: <50B28467.1030807@oracle.com> References: <50AC31EC.6030404@oracle.com> <50AC41F8.2080301@oracle.com> <50ACE29F.8030601@oracle.com> <50B28086.4040006@oracle.com> <50B28467.1030807@oracle.com> Message-ID: <50B3A817.1010303@oracle.com> Ok, thanks David. Coleen On 11/25/2012 3:49 PM, David Holmes wrote: > On 26/11/2012 6:33 AM, David Holmes wrote: >> Hi Coleen, >> >> Okay I withdraw my objections otherwise this will never get fixed. gcc >> itself says use "this->" so be it. Plus push when ready. > > Please push ... > > David > >> For the record I'm hitting these kind of problems with gcc 4.6 as well. >> It's in build-infra repo so may be down-rev on previous hotspot changes. >> >> Thanks, >> David >> >> On 22/11/2012 12:18 AM, Coleen Phillimore wrote: >>> On 11/20/2012 9:52 PM, David Holmes wrote: >>>> Sorry but I must protest. After the last fix we were returned to an >>>> unpleasant mixture of using directives and this-> augmentation. The >>>> fix that was lost had applied the using directive. >>>> >>>> Can we please use the using directive and just fix these once and for >>>> all. >>> >>> Okay, someone will have to contribute the "using" fix then. I don't >>> know >>> what to use in "using"! >>> >>> Please do this very soon since the VM doesn't build on gcc 4.7 (again!) >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Otherwise get rid of all using directives. But lets have a consistent >>>> approach here. >>>> >>>> Thanks, >>>> David >>>> >>>> On 21/11/2012 11:44 AM, Coleen Phillimore wrote: >>>>> Summary: Add a few more this->qualifications. >>>>> Reviewed-by: coleenp >>>>> Contributed-by: duboscq at ssw.jku.at >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8003722/ >>>>> >>>>> Ran runThese tests with CMS gc. I want to check this into hotspot-gc >>>>> since it has the other changes (hotspot-rt doesn't yet). >>>>> >>>>> Thanks, >>>>> Coleen >>> From forax at univ-mlv.fr Mon Nov 26 09:35:48 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Nov 2012 18:35:48 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B39C83.6010801@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> Message-ID: <50B3A874.4090306@univ-mlv.fr> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: > On 11/26/2012 08:22 PM, Doug Lea wrote: >> One small suggestion to slightly appease the nanny-state folks. >> How about burying the annotation one lever deeper to >> java.util.concurrent.atomic. +1 > But the construction of @Contended has nothing to do with atomics, > right? (Yes, the sanest use case is to protect atomically-updated > fields.) I think you should re-write the javadoc to not use 'hot' (hot -> optimize -> I should use it) and talk about false sharing (with a link to the wikipedia article http://en.wikipedia.org/wiki/False_sharing). You should mention that marking @Contented a field which is not volatile is useless unless there is proper fences. And also mention that it may consume a lot of memory thus it should only be used if there is a known issue. Also, I'm not in favour of allowing to use @Contented on class, if you want all fields to be marked as @Contented, just mark them as is. Given that this annotation is here to solve a corner case, using the annotation in a class wide way in my opinion a door open to stupid usages. You don't mark a class volatile if all their fields are volatile. > "Nanny-state folks" would naturally presume annotating the > plain field with @Contended will turn all operations on that field into > atomics :) > > Alternatives: > java.util.concurrent.hints.Contended > java.util.concurrent.expert.Contended > java.util.concurrent.unsafe.Contended > java.util.concurrent.herebedragons.Contended :) > > I think the high-level annotation is already good. > > -Aleksey. R?mi From bill.pittore at oracle.com Mon Nov 26 09:45:09 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 26 Nov 2012 12:45:09 -0500 Subject: Official reviewer needed: Review request for fix for 7200297: agent code does not handle multiple dll_dir paths correctly In-Reply-To: <50AE1FEC.9030506@oracle.com> References: <50A41AEA.8050705@oracle.com> <50A4AF33.2020208@oracle.com> <50A5420A.7030502@oracle.com> <50A54734.6000608@oracle.com> <50A6A18C.1070206@oracle.com> <50AAA04A.70408@oracle.com> <50ACA54E.7020608@oracle.com> <50AD2C2A.8000401@oracle.com> <50AE1FEC.9030506@oracle.com> Message-ID: <50B3AAA5.9040401@oracle.com> Have a couple of reviews but still need official reviewer to pass muster. thanks, bill On 11/22/2012 7:51 AM, Dmitry Samersoff wrote: > Bill, > > Looks good for me. > > -Dmitry > > On 2012-11-21 23:31, BILL PITTORE wrote: >> Hi Dmitry, >> >> On 11/21/2012 4:56 AM, Dmitry Samersoff wrote: >>> Bill, >>> >>> >>> Few nits: >>> >>> 1. >>> >>> dll_build_name is exactly the same for all locations could we place it >>> to some common place? >> It looked somewhat intentional to have the agents and the hprof code be >> self-contained. I looked at using a common file but the makefile changes >> and source tree changes seemed a bit much. Hprof code is "unsupported >> demo" code and jdwp is supported agent so I went with the current scheme >> of having the code be self-contained. >>> Also file_exists is not necessary and could be >>> replaced with just ::access(buffer,R_OK) (Windows has it as well) >> I'll go with the access suggestion above, less code. >>> but if you prefer to keep it: >>> >>> strlen(filename)==0 could be a *filename == 0 >>> >>> >>> 2. We don't need else after return in all *_md.c files >>> e.g. linker_md.c:122 >> Semantically, you're correct. I think in terms of code readability I >> like the 'else' since it makes it clear to the reader that there are two >> different cases. C compiler will 'do the right thing'. >> Updated the webrev at >> http://cr.openjdk.java.net/~bpittore/7200297/webrev.03/ >> >> thanks, >> bill >>> Otherwise looks good. >>> >>> -Dmitry >>> >>> On 2012-11-20 01:10, BILL PITTORE wrote: >>>> Have gotten reviews from Serguei Spitsyn for the changes, made some >>>> improvements and need an official reviewer to check it out. >>>> >>>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.02 >>>> >>>> thanks, >>>> bill >>>> >>>> >>>> >>>> On 11/14/2012 5:27 PM, bill.pittore at oracle.com wrote: >>>>> This bug has to do with the jdwp and hprof agents not parsing the >>>>> sun.boot.library.path (dll_dir) correctly since the fix for 6819213 >>>>> went in some years ago. This bug popped up while working on a >>>>> particular platform that does not have the ability to set >>>>> LD_LIBRARY_PATH before running the VM. As documented in the bug, on >>>>> most platforms even if the sun.boot.library.path consists of multiple >>>>> paths and the jdwp or hprof code fails to load a dependent lib, the >>>>> system falls back to using LD_LIBRARY_PATH so the failure is masked. >>>>> On some other platforms, this failover doesn't exist so we get an >>>>> error when trying to load jdwp and hprof dependent libs. >>>>> >>>>> Some notes on a couple of files. >>>>> * >>>>> debugInit.c, hprof_init.c*: >>>>> Rearranged the init order so that the jvmti pointer gets initialized >>>>> before attempting to load the npt shared library. >>>>> >>>>> *linker_md.c, hprof_md.c* >>>>> Much of the platform code in hprof and jdwp is duplicated and this >>>>> change is no different. Based on the code in hotspot >>>>> os_solaris/windows.cpp it parses the boot library path and attempts to >>>>> find the library. >>>>> * >>>>> error_messages.c* >>>>> Fixed a bug in the error message code that blindly dereferenced the >>>>> npt pointer even if it wasn't set because of an error in loading. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~bpittore/7200297/webrev.00/ >>>>> >>>>> Ran the ute nsk/jdwp nsk/jvmti nsk/hprof tests, the JCK jdwp/jvmti >>>>> tests and some command line testing on windows and linux. >>>>> >>>>> thanks, >>>>> bill >>>>> >>>>> > From coleen.phillimore at oracle.com Mon Nov 26 10:00:11 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 26 Nov 2012 13:00:11 -0500 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: References: <50AF640D.1050401@oracle.com> <50AF6A92.8080401@oracle.com> <50B314D1.2070409@oracle.com> Message-ID: <50B3AE2B.9030300@oracle.com> I filed an RFE for this. Thank you for the specifics. We have a label/keyword "starter" that we've been using to give new contributors ideas for how they can get started on the JVM. I'll give this that one (even though it's a lot of code changes!) IssueJDK-8003990 - Clean up inline #includes has been successfully created. If someone wants to start on this from the community, let me know, so nobody starts on it from Oracle at the same time. Thanks, Coleen On 11/26/2012 10:59 AM, Volker Simonis wrote: > On Mon, Nov 26, 2012 at 8:05 AM, Stefan Karlsson > wrote: >> On 2012-11-23 13:22, David Holmes wrote: >>> Hi Stefan, >>> >>> I never did like these. >>> >>> I have to wonder though, why isn't it "runtime/thread.hpp" that all the >>> client code #includes? >> Typically, you place inline functions in a inline.hpp file instead of the >> hpp. This helps reducing the number of unnecessary includes from spreading >> through out the code base. Only the users of the inline functions will >> include the inline.hpp file, and bring in the needed includes to implement >> the function. >> >> Preferably, you should only include inline.hpp files from other cpp files or >> other inline.hpp files. >> > This is indeed the glory theory. However even in your change, there > are still some .hpp files which include .inline.hpp files (e.g > abstractInterpreter.hpp includes thread.inline.hpp). > > Are there any plans to further clean this up (i.e. remove inline.hpp > includes from .hpp files) by either: > > 1a : move the methods from XXX.hpp which require implementations of > inline functions from AAA.inline.hpp to XXX.cpp if they are not > performance relevant (and include AAA.inline.hpp only in XXX.cpp). > > 1b : moving the methods from XXX.hpp which require implementations of > inline functions from AAA.inline.hpp to a newly created XXX.inline.hpp > if they are performance relevant (and include AAA.inline.hpp only in > XXX.inline.cpp). > > 1c : keep the implementation of methods in XXX.hpp which don't > require definitions of inline methods from ANY ".inline.hpp" (in this > case it may be still necessary to include .hpp files which have been > provided previously indirectly by the various ".inline.hpp" files) > > In general I would be in favour of such a change, but a quick search > (find hotspot/src/ -name "*.hpp" | grep -v "\.inline\.hpp" | xargs > grep ".inline.hpp" | awk -F ":" '{print $1;}' | sort -u | wc) reveals > that there are currently 74 ".hpp" files which include other > ".inline.hpp" files. So this would be a real huge change. > >>> And then why isn't it thread.hpp that includes the platform specific >>> header? >> >> In this specific case, there's an inline function in >> thread_solaris.inline.hpp that Thread::current() needs. >> >> StefanK >> >>> David >>> >>> On 23/11/2012 9:54 PM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8003935/webrev >>>> >>>> Today, whenever we use Thread::current() we have to all these lines: >>>> >>>> #include "runtime/thread.hpp" >>>> #ifdef TARGET_OS_FAMILY_linux >>>> # include "thread_linux.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_solaris >>>> # include "thread_solaris.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_windows >>>> # include "thread_windows.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_bsd >>>> # include "thread_bsd.inline.hpp" >>>> #endif >>>> >>>> This patch hides this dispatching in a new file named thread.inline.hpp. >>>> Now we only have to include thread.inline.hpp. >>>> >>>> Some background to these includes: This type of dispatching was >>>> introduced into the source files when we removed the includeDB files. We >>>> discussed whether we should use "dispatch files" or not for this kind >>>> platform dependent includes. The decision was to not create dispatch >>>> files for all types of platform at that time, but instead manually >>>> create them when we thought it was warranted. >>>> >>>> thanks, >>>> StefanK >>>> >>>> From krystal.mo at oracle.com Mon Nov 26 10:29:56 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 27 Nov 2012 02:29:56 +0800 Subject: Fwd: Report a bug in HotSpot In-Reply-To: References: Message-ID: <50B3B524.60307@oracle.com> Hi all, Xi Yang has reported a bug in HotSpot's interpreter that it doesn't empty the FPU stack on return from JNI calls. His mail is included below. e.g. If a native function called via JNI is using MMX registers without emptying the FPU stack before returning, then after returning to Java the FPU stack will be in a bad state. The test case Xi gave is demonstrated here on JDK7u9, x86: https://gist.github.com/4148771 Running the example with -XX:+VerifyFPU shows what's going on. This test case shows the bug affecting 32-bit x86 version of HotSpot's interpreter. Not really familiar with how to file a bug on JBS yet, I'll file a bug to track this after I learn how to do it. Regards, Kris -------- Original Message -------- Subject: Fwd: Report a bug in HotSpot Date: Tue, 27 Nov 2012 02:02:59 +0800 From: Krystal Mok To: Krystal Mo ---------- Forwarded message ---------- From: Xi Yang Date: Tue, Nov 20, 2012 at 1:44 PM Subject: Report a bug in HotSpot To: Krystal Mok Hi, It looks like HotSpot does not do "emms" after backing from JNI. Here is the code to show the bug. Would you like to try the newest version? Hello.java class Hello { private static native void abc(); public static void main(String[] args) { System.out.println("I am main"); System.loadLibrary("Hello"); abc(); long a = 100; double b = (double)a; System.out.println("Double a is " + b); } } Hello.c #include #include JNIEXPORT void JNICALL Java_Hello_abc(JNIEnv *env, jclass cls) { printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); unsigned int dummy; asm volatile("movd %%mm0, %0\n":"=r"(dummy)); printf("dummy is %x\n", dummy); } gcc -m32 -shared ./Hello.c -o ./libHello.so /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello I am main I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world dummy is 0 Double a is NaN $ /opt/jdk1.7.0/bin/java -version java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) From aleksey.shipilev at oracle.com Mon Nov 26 10:40:28 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 22:40:28 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3A874.4090306@univ-mlv.fr> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> Message-ID: <50B3B79C.2050509@oracle.com> On 11/26/2012 09:35 PM, Remi Forax wrote: > On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >> On 11/26/2012 08:22 PM, Doug Lea wrote: >>> One small suggestion to slightly appease the nanny-state folks. >>> How about burying the annotation one lever deeper to >>> java.util.concurrent.atomic. > > +1 > Still fail to see the rationale about this. > I think you should re-write the javadoc to not use 'hot' (hot -> > optimize -> I should use it) and talk about false sharing (with a > link to the wikipedia article > http://en.wikipedia.org/wiki/False_sharing). Yup, will do. > You should mention that marking @Contented a field which is not > volatile is useless unless there is proper fences. Um. Actually, there is a lot of sense with marking plain fields with @Contended, especially when visibility is guaranteed elsewhere. You probably mean "marking the field @Contended does not turn it into volatile"? ...does it really worth mentioning? > And also mention that it may consume a lot of memory thus it should > only be used if there is a known issue. Yes, good idea. > Also, I'm not in favour of allowing to use @Contented on class, if > you want all fields to be marked as @Contented, just mark them as is. > Given that this annotation is here to solve a corner case, using the > annotation in a class wide way in my opinion a door open to stupid > usages. You don't mark a class volatile if all their fields are > volatile. >From the layout perspective, class-level @Contended is equivalent to all-field @Contended with the same contention group. Do you think we don't need this ask the shortcut for tuple/value/struct classes? I.e. @Contended public class ValueClass { private int field1; private int field2; private int field3; private int field4; } is the shortcut for: public class ValueClass { @Contended("theSame") private int field1; @Contended("theSame") private int field2; @Contended("theSame") private int field3; @Contended("theSame") private int field4; } That is, all the fields would be densely-packed, but will be padded as the group. Note that it is not the same as: public class ValueClass { @Contended private int field1; @Contended private int field2; @Contended private int field3; @Contended private int field4; } Maybe that is already confusing enough to drop class-level annotation? What do others feel about this? -Aleksey. From doug.simon at oracle.com Mon Nov 26 10:45:19 2012 From: doug.simon at oracle.com (Doug Simon @ Oracle) Date: Mon, 26 Nov 2012 19:45:19 +0100 Subject: Cleaning static call stubs without cleaning the corresponding calls? Message-ID: <8AC82FF7-2A65-4E03-9658-93A270D4A001@oracle.com> In the debug build of the Graal[1], I am seeing a hung VM caused by a thread spinning on an jump instruction that jumps to itself. Further investigation reveals this is the jump instruction in a static call stub. I can see that the stub is initialized properly in CompiledStaticCall::set_to_interpreted(). Then during a full GC, I see the stub is set to clean in nmethod::verify_metadata_loaders(). The strange thing is that the corresponding static (or opt_virtual) call is not reset at the same time. So, at some later point the static call goes to the stub which then starts spinning. Unless my diagnosis is flawed, I think the patch below fixes the problem. diff -r 46bec43bdfc3 src/share/vm/code/nmethod.cpp --- a/src/share/vm/code/nmethod.cpp Wed Nov 21 23:36:06 2012 +0100 +++ b/src/share/vm/code/nmethod.cpp Thu Nov 22 22:42:30 2012 +0100 @@ -1802,11 +1802,13 @@ CompiledIC* cic = CompiledIC_at(iter.reloc()); if (!cic->is_call_to_interpreted()) { static_call_addr = iter.addr(); + cic->set_to_clean(); } } else if (iter.type() == relocInfo::static_call_type) { CompiledStaticCall* csc = compiledStaticCall_at(iter.reloc()); if (!csc->is_call_to_interpreted()) { static_call_addr = iter.addr(); + csc->set_to_clean(); } } if (static_call_addr != NULL) { With this patch, I no longer see the hanging problem in Graal. The fact that this issue hasn't arisen for the debug builds of HotSpot makes me wonder if there is something else I'm missing... -Doug [1] http://openjdk.java.net/projects/graal/ From vitalyd at gmail.com Mon Nov 26 10:53:34 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Nov 2012 13:53:34 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3B79C.2050509@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: Personally, I'd leave out the class level annotation - I don't think that case happens all that often. Can always add that feature later if it turns out to be useful - it won't break compatibility. Can you also please turn field layout printing into either a product or diagnostic flag, if you didn't do that already? To reduce clutter, perhaps one can specify type name(s) for which this info should be shown - analogous to how disassembly allows this. Also, I assume heap walkers/profilers will report proper mem usage for objects with padding? One caveat here would be that if padding is applied but not somehow obvious in the tool, then the mental math of how much the object should take up vs how much it actually takes up may create some confusion. This may be more of a tool problem in that they should perhaps indicate visibly instances with @Contended fields. Sent from my phone On Nov 26, 2012 1:42 PM, "Aleksey Shipilev" wrote: > On 11/26/2012 09:35 PM, Remi Forax wrote: > > On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: > >> On 11/26/2012 08:22 PM, Doug Lea wrote: > >>> One small suggestion to slightly appease the nanny-state folks. > >>> How about burying the annotation one lever deeper to > >>> java.util.concurrent.atomic. > > > > +1 > > > > Still fail to see the rationale about this. > > > I think you should re-write the javadoc to not use 'hot' (hot -> > > optimize -> I should use it) and talk about false sharing (with a > > link to the wikipedia article > > http://en.wikipedia.org/wiki/False_sharing). > > Yup, will do. > > > You should mention that marking @Contented a field which is not > > volatile is useless unless there is proper fences. > > Um. Actually, there is a lot of sense with marking plain fields with > @Contended, especially when visibility is guaranteed elsewhere. You > probably mean "marking the field @Contended does not turn it into > volatile"? ...does it really worth mentioning? > > > And also mention that it may consume a lot of memory thus it should > > only be used if there is a known issue. > > Yes, good idea. > > > Also, I'm not in favour of allowing to use @Contented on class, if > > you want all fields to be marked as @Contented, just mark them as is. > > Given that this annotation is here to solve a corner case, using the > > annotation in a class wide way in my opinion a door open to stupid > > usages. You don't mark a class volatile if all their fields are > > volatile. > > >From the layout perspective, class-level @Contended is equivalent to > all-field @Contended with the same contention group. Do you think we > don't need this ask the shortcut for tuple/value/struct classes? > > I.e. > > @Contended > public class ValueClass { > private int field1; > private int field2; > private int field3; > private int field4; > } > > is the shortcut for: > > public class ValueClass { > @Contended("theSame") private int field1; > @Contended("theSame") private int field2; > @Contended("theSame") private int field3; > @Contended("theSame") private int field4; > } > > That is, all the fields would be densely-packed, but will be padded as > the group. Note that it is not the same as: > > public class ValueClass { > @Contended private int field1; > @Contended private int field2; > @Contended private int field3; > @Contended private int field4; > } > > Maybe that is already confusing enough to drop class-level annotation? > What do others feel about this? > > -Aleksey. > From vitalyd at gmail.com Mon Nov 26 11:03:09 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Nov 2012 14:03:09 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: Also, one useful (but more complex to implement presumably) feature would be to pad array elements. I think this case of false sharing comes up quite a bit so instead of doing manual padding, would be nice to keep java code indexer arithmetic the same but have the interpreter/JIT do the proper offsetting behind the scenes. Sent from my phone On Nov 26, 2012 1:53 PM, "Vitaly Davidovich" wrote: > Personally, I'd leave out the class level annotation - I don't think that > case happens all that often. Can always add that feature later if it turns > out to be useful - it won't break compatibility. > > Can you also please turn field layout printing into either a product or > diagnostic flag, if you didn't do that already? To reduce clutter, perhaps > one can specify type name(s) for which this info should be shown - > analogous to how disassembly allows this. > > Also, I assume heap walkers/profilers will report proper mem usage for > objects with padding? One caveat here would be that if padding is applied > but not somehow obvious in the tool, then the mental math of how much the > object should take up vs how much it actually takes up may create some > confusion. This may be more of a tool problem in that they should perhaps > indicate visibly instances with @Contended fields. > > Sent from my phone > On Nov 26, 2012 1:42 PM, "Aleksey Shipilev" > wrote: > >> On 11/26/2012 09:35 PM, Remi Forax wrote: >> > On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >> >> On 11/26/2012 08:22 PM, Doug Lea wrote: >> >>> One small suggestion to slightly appease the nanny-state folks. >> >>> How about burying the annotation one lever deeper to >> >>> java.util.concurrent.atomic. >> > >> > +1 >> > >> >> Still fail to see the rationale about this. >> >> > I think you should re-write the javadoc to not use 'hot' (hot -> >> > optimize -> I should use it) and talk about false sharing (with a >> > link to the wikipedia article >> > http://en.wikipedia.org/wiki/False_sharing). >> >> Yup, will do. >> >> > You should mention that marking @Contented a field which is not >> > volatile is useless unless there is proper fences. >> >> Um. Actually, there is a lot of sense with marking plain fields with >> @Contended, especially when visibility is guaranteed elsewhere. You >> probably mean "marking the field @Contended does not turn it into >> volatile"? ...does it really worth mentioning? >> >> > And also mention that it may consume a lot of memory thus it should >> > only be used if there is a known issue. >> >> Yes, good idea. >> >> > Also, I'm not in favour of allowing to use @Contented on class, if >> > you want all fields to be marked as @Contented, just mark them as is. >> > Given that this annotation is here to solve a corner case, using the >> > annotation in a class wide way in my opinion a door open to stupid >> > usages. You don't mark a class volatile if all their fields are >> > volatile. >> >> >From the layout perspective, class-level @Contended is equivalent to >> all-field @Contended with the same contention group. Do you think we >> don't need this ask the shortcut for tuple/value/struct classes? >> >> I.e. >> >> @Contended >> public class ValueClass { >> private int field1; >> private int field2; >> private int field3; >> private int field4; >> } >> >> is the shortcut for: >> >> public class ValueClass { >> @Contended("theSame") private int field1; >> @Contended("theSame") private int field2; >> @Contended("theSame") private int field3; >> @Contended("theSame") private int field4; >> } >> >> That is, all the fields would be densely-packed, but will be padded as >> the group. Note that it is not the same as: >> >> public class ValueClass { >> @Contended private int field1; >> @Contended private int field2; >> @Contended private int field3; >> @Contended private int field4; >> } >> >> Maybe that is already confusing enough to drop class-level annotation? >> What do others feel about this? >> >> -Aleksey. >> > From kirk at kodewerk.com Mon Nov 26 11:07:45 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 26 Nov 2012 20:07:45 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3B79C.2050509@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: This isn't really atomic, it's about concurrent so I'd vote for inclusion in the concurrent package.. given that everyone seems intent on barreling down this path without thought to my earlier email. Regards, Kirk On 2012-11-26, at 7:40 PM, Aleksey Shipilev wrote: > On 11/26/2012 09:35 PM, Remi Forax wrote: >> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >>> On 11/26/2012 08:22 PM, Doug Lea wrote: >>>> One small suggestion to slightly appease the nanny-state folks. >>>> How about burying the annotation one lever deeper to >>>> java.util.concurrent.atomic. >> >> +1 >> > > Still fail to see the rationale about this. > >> I think you should re-write the javadoc to not use 'hot' (hot -> >> optimize -> I should use it) and talk about false sharing (with a >> link to the wikipedia article >> http://en.wikipedia.org/wiki/False_sharing). > > Yup, will do. > >> You should mention that marking @Contented a field which is not >> volatile is useless unless there is proper fences. > > Um. Actually, there is a lot of sense with marking plain fields with > @Contended, especially when visibility is guaranteed elsewhere. You > probably mean "marking the field @Contended does not turn it into > volatile"? ...does it really worth mentioning? > >> And also mention that it may consume a lot of memory thus it should >> only be used if there is a known issue. > > Yes, good idea. > >> Also, I'm not in favour of allowing to use @Contented on class, if >> you want all fields to be marked as @Contented, just mark them as is. >> Given that this annotation is here to solve a corner case, using the >> annotation in a class wide way in my opinion a door open to stupid >> usages. You don't mark a class volatile if all their fields are >> volatile. > >> From the layout perspective, class-level @Contended is equivalent to > all-field @Contended with the same contention group. Do you think we > don't need this ask the shortcut for tuple/value/struct classes? > > I.e. > > @Contended > public class ValueClass { > private int field1; > private int field2; > private int field3; > private int field4; > } > > is the shortcut for: > > public class ValueClass { > @Contended("theSame") private int field1; > @Contended("theSame") private int field2; > @Contended("theSame") private int field3; > @Contended("theSame") private int field4; > } > > That is, all the fields would be densely-packed, but will be padded as > the group. Note that it is not the same as: > > public class ValueClass { > @Contended private int field1; > @Contended private int field2; > @Contended private int field3; > @Contended private int field4; > } > > Maybe that is already confusing enough to drop class-level annotation? > What do others feel about this? > > -Aleksey. From martijnverburg at gmail.com Mon Nov 26 11:07:58 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 26 Nov 2012 19:07:58 +0000 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3B79C.2050509@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: Hi Aleksey, On 26 November 2012 18:40, Aleksey Shipilev wrote: > On 11/26/2012 09:35 PM, Remi Forax wrote: > > On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: > >> On 11/26/2012 08:22 PM, Doug Lea wrote: > >>> One small suggestion to slightly appease the nanny-state folks. > >>> How about burying the annotation one lever deeper to > >>> java.util.concurrent.atomic. > > > > +1 > > > > Still fail to see the rationale about this. I think (as others have posted) that this is one of the rare cases where a Java developer is deliberately encouraged to bypass the runtime environment's heuristics. This is not common behaviour. Similar functionality has traditionally been hidden as deeply as possible to try and protect people from themselves (like having access to pointers via Unsafe). It's interesting to note that Unsafe is pretty much only used by extremely expert library authors (such as Cliff Click and Doug Lea). I think this @Contended annotation is in that same category despite how personally excited about it. The more I've thought about this, the more I realise that this is a feature that if broadly advertised and adopted could lead a lot of developers shooting themselves in the foot. Cheers, Martijn From dl at cs.oswego.edu Mon Nov 26 11:08:12 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 26 Nov 2012 14:08:12 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3B79C.2050509@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: <50B3BE1C.2040207@cs.oswego.edu> On 11/26/12 13:40, Aleksey Shipilev wrote: > On 11/26/2012 09:35 PM, Remi Forax wrote: >> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >>> On 11/26/2012 08:22 PM, Doug Lea wrote: >>>> One small suggestion to slightly appease the nanny-state folks. >>>> How about burying the annotation one lever deeper to >>>> java.util.concurrent.atomic. >> >> +1 >> > > Still fail to see the rationale about this. All things considered, I'm back to agreeing with you -- Just j.u.c.Contended > >> I think you should re-write the javadoc ... The Contended.java file and its javadoc in Aleksey's webrev is just a placeholder to get things moving. We expect to solicit reviews in the usual way (mainly on concurrency-interest list) for a version that will make it into JDK8. > > I.e. > > @Contended > public class ValueClass { > private int field1; > private int field2; > private int field3; > private int field4; > } > > is the shortcut for: > > public class ValueClass { > @Contended("theSame") private int field1; > @Contended("theSame") private int field2; > @Contended("theSame") private int field3; > @Contended("theSame") private int field4; > } > > That is, all the fields would be densely-packed, but will be padded as > the group. Note that it is not the same as: > > public class ValueClass { > @Contended private int field1; > @Contended private int field2; > @Contended private int field3; > @Contended private int field4; > } > > Maybe that is already confusing enough to drop class-level annotation? > What do others feel about this? I think that the most common and most-recommended case will be class-level, so it should be kept. We can work on the usage advice in the javadocs. -Doug From aleksey.shipilev at oracle.com Mon Nov 26 11:13:29 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 26 Nov 2012 23:13:29 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: <50B3BF59.2040506@oracle.com> On 11/26/2012 11:07 PM, Martijn Verburg wrote: > It's interesting to note that Unsafe is pretty much only used by > extremely expert library authors (such as Cliff Click and Doug Lea). I > think this @Contended annotation is in that same category despite how > personally excited about it. Oh yes. Count me in to heavy Unsafe user :) I'm not opposing against moving out from the root j.u.c package, I'm opposing from burying that annotation in some random unrelated place, which is j.u.c.atomic in my POV. -Aleksey. From kirk at kodewerk.com Mon Nov 26 11:18:51 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 26 Nov 2012 20:18:51 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3BE1C.2040207@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> Message-ID: <448B1ACA-9E81-4824-B329-C6436DF0BE1A@kodewerk.com> Actually, sun.misc.Contended right beside sun.misc.Unsafe doesn't sound like such a bad idea. -- Kirk On 2012-11-26, at 8:08 PM, Doug Lea
wrote: > On 11/26/12 13:40, Aleksey Shipilev wrote: >> On 11/26/2012 09:35 PM, Remi Forax wrote: >>> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >>>> On 11/26/2012 08:22 PM, Doug Lea wrote: >>>>> One small suggestion to slightly appease the nanny-state folks. >>>>> How about burying the annotation one lever deeper to >>>>> java.util.concurrent.atomic. >>> >>> +1 >>> >> >> Still fail to see the rationale about this. > > All things considered, I'm back to agreeing with you -- > Just j.u.c.Contended > >> >>> I think you should re-write the javadoc ... > > The Contended.java file and its javadoc in Aleksey's webrev is just a > placeholder to get things moving. We expect to solicit > reviews in the usual way (mainly on concurrency-interest list) > for a version that will make it into JDK8. > >> >> I.e. >> >> @Contended >> public class ValueClass { >> private int field1; >> private int field2; >> private int field3; >> private int field4; >> } >> >> is the shortcut for: >> >> public class ValueClass { >> @Contended("theSame") private int field1; >> @Contended("theSame") private int field2; >> @Contended("theSame") private int field3; >> @Contended("theSame") private int field4; >> } >> >> That is, all the fields would be densely-packed, but will be padded as >> the group. Note that it is not the same as: >> >> public class ValueClass { >> @Contended private int field1; >> @Contended private int field2; >> @Contended private int field3; >> @Contended private int field4; >> } >> >> Maybe that is already confusing enough to drop class-level annotation? >> What do others feel about this? > > I think that the most common and most-recommended case will be class-level, > so it should be kept. We can work on the usage advice in the javadocs. > > -Doug > > From vitalyd at gmail.com Mon Nov 26 11:43:58 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 26 Nov 2012 14:43:58 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <448B1ACA-9E81-4824-B329-C6436DF0BE1A@kodewerk.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> <448B1ACA-9E81-4824-B329-C6436DF0BE1A@kodewerk.com> Message-ID: I don't see what burying this in sun.misc really accomplishes. Look at Unsafe - it's still widely used except have to jump through reflection hoops. Also, sun.misc is apparently going away in java 9. I also don't understand the reasoning behind trying to "prevent people from shooting themselves in the foot" - we should consider java developers as responsible adults. Nobody is forcing anyone to use this annotation. Otherwise, we should throw out GC tuning knobs, JIT tuning knobs, weak/soft/phantom refs, finalizers, thread locals, direct byte buffers, etc. This entire "java devs are too immature/dumb/irresponsible/etc" sentiment is ridiculous, IMHO. By the way, if you think only Doug/Cliff Click/etc are using Unsafe, then don't tell Cassandra/Hbase developers :). Cassandra goes as far as using pluggable C heap allocators (accessed via Unsafe behind the scenes) to allocate off-heap memory - this is in addition to using unsafe comparators for byte arrays, and other "tricks". That's the price of admission when trying to squeeze perf ... Sent from my phone On Nov 26, 2012 2:19 PM, "Kirk Pepperdine" wrote: > Actually, sun.misc.Contended right beside sun.misc.Unsafe doesn't sound > like such a bad idea. > > -- Kirk > > On 2012-11-26, at 8:08 PM, Doug Lea
wrote: > > > On 11/26/12 13:40, Aleksey Shipilev wrote: > >> On 11/26/2012 09:35 PM, Remi Forax wrote: > >>> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: > >>>> On 11/26/2012 08:22 PM, Doug Lea wrote: > >>>>> One small suggestion to slightly appease the nanny-state folks. > >>>>> How about burying the annotation one lever deeper to > >>>>> java.util.concurrent.atomic. > >>> > >>> +1 > >>> > >> > >> Still fail to see the rationale about this. > > > > All things considered, I'm back to agreeing with you -- > > Just j.u.c.Contended > > > >> > >>> I think you should re-write the javadoc ... > > > > The Contended.java file and its javadoc in Aleksey's webrev is just a > > placeholder to get things moving. We expect to solicit > > reviews in the usual way (mainly on concurrency-interest list) > > for a version that will make it into JDK8. > > > >> > >> I.e. > >> > >> @Contended > >> public class ValueClass { > >> private int field1; > >> private int field2; > >> private int field3; > >> private int field4; > >> } > >> > >> is the shortcut for: > >> > >> public class ValueClass { > >> @Contended("theSame") private int field1; > >> @Contended("theSame") private int field2; > >> @Contended("theSame") private int field3; > >> @Contended("theSame") private int field4; > >> } > >> > >> That is, all the fields would be densely-packed, but will be padded as > >> the group. Note that it is not the same as: > >> > >> public class ValueClass { > >> @Contended private int field1; > >> @Contended private int field2; > >> @Contended private int field3; > >> @Contended private int field4; > >> } > >> > >> Maybe that is already confusing enough to drop class-level annotation? > >> What do others feel about this? > > > > I think that the most common and most-recommended case will be > class-level, > > so it should be kept. We can work on the usage advice in the javadocs. > > > > -Doug > > > > > > From christian.thalinger at oracle.com Mon Nov 26 11:55:34 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 26 Nov 2012 11:55:34 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353690888.31435.3.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> Message-ID: <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: >> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: >> >>> >>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: >>> >>>> >>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: >>>> >>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>>>>> >>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>>>>> Here are some details: >>>>>>>> >>>>>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>>>>> changes in LLVM. >>>>>>>> - Most other changes have to do with the split of the oop and metadata >>>>>>>> class hierarchies in Hotspot. >>>>>>>> - Then there have been a few changes caused by LLVM changes and >>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>>>>> representation directly in LLVM's IR. This makes our code a little >>>>>>>> nicer. >>>>>>>> >>>>>>>> I tested this by running a number of applications, most notably Eclipse >>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>>>>> bunch of other stuff. >>>>>>>> >>>>>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>>>>> can find the full webrev here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>>>>> >>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>>>>> >>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>>>>> >>>>>>> Isn't PrintCompilation doing that already? >>>>>>> >>>>>>> The shared code changes look good. I filed: >>>>>>> >>>>>>> 8003868: fix shark for latest HotSpot and LLVM >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> There are also a very minor change required in JDK: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>>>>> >>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>>>>> and jdk repositories respectivly. Find my build script here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>>>>> >>>>>>>> (Review and adjust variables to your settings, most notably you will >>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>>>>> >>>>>>>> Please let me know if there are any issues or how we can get this >>>>>>>> integrated into Hotspot. >>>>>> >>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>>>>> >>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>>>>> from /usr/local/include/llvm/Use.h:28, >>>>>> from /usr/local/include/llvm/Value.h:17, >>>>>> from /usr/local/include/llvm/Argument.h:17, >>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>>>>> >>>>>> and: >>>>>> >>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, >>>>>> from /usr/local/include/llvm/Argument.h:18, >>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>>>>> >>>>>> Not sure if the latter is because of the former one. Have you seen this before? >>>>> >>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >>>>> this happens when certain cflags are not set correctly. The script >>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >>>>> correct flags. In order for this to work, you need to have the full path >>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >>>>> using the build script that I provided? >>>> >>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. >>>> >>>> Now that I have the LLVM_* variables it's even worse: >>>> >>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness >>>> >>>> It's probably this guy: -Wcast-qual >>> >>> Got it: >>> >>> $ java -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) >> >> I ran the compiler regression tests and Shark crashes in 5091921: >> >> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ >> Directory "/export/twisti/jtreg/scratch" not found: creating >> Passed: compiler/5091921/Test5091921.java >> Passed: compiler/5091921/Test6186134.java >> Passed: compiler/5091921/Test6196102.java >> Passed: compiler/5091921/Test6357214.java >> Passed: compiler/5091921/Test6559156.java >> Passed: compiler/5091921/Test6753639.java >> Passed: compiler/5091921/Test6850611.java >> Passed: compiler/5091921/Test6890943.java >> Passed: compiler/5091921/Test6897150.java >> Passed: compiler/5091921/Test6905845.java >> Passed: compiler/5091921/Test6931567.java >> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts >> >> You can also run all them with a simple make in test/ by setting: >> >> PRODUCT_HOME=$JAVA_HOME >> TESTDIRS=compiler > > Alright, I found another fairly grave bug that I would like to include a > fix for: apparently, a 'fence' is not enough of a memory barrier for > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > LLVM offers atomic loads and stores, which seem to be exactly what is > needed for volatile field access. However, it does not provide helper > functions for those in llvm::IRBuilder so I wrote my own. This should be > the final patch for now (unless you find something else). > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ Hmm. Maybe I did something wrong but I've already rebuilt twice: $ java -Xcomp -version Value type size is target-dependent. Ask TLI. UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' Aborted (core dumped) -- Chris > > Cheers, > Roman > > From christian.thalinger at oracle.com Mon Nov 26 15:06:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 26 Nov 2012 15:06:09 -0800 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <50AF317E.8080205@oracle.com> References: <50AE334A.604@oracle.com> <50AEBCE6.50004@oracle.com> <50AF317E.8080205@oracle.com> Message-ID: <0A82D1E8-2EEC-44D8-BCE1-7BFF70915E4A@oracle.com> On Nov 23, 2012, at 12:19 AM, Stefan Karlsson wrote: > David, > > Thanks for taking a look at this. > > I've added a comment regarding the cld_f: > > // GC support > // Apply "f->do_oop" to all root oops in "this". > *+ // Apply "cld_f->do_cld" to CLDs that are otherwise not kept alive.* > *+ // Used by JavaThread::oops_do.* > // Apply "cf->do_code_blob" (if !NULL) to all code blobs active in frames > *! virtual void oops_do(OopClosure* f,_CLDToOopClosure* cld_f,_CodeBlobClosure* cf);* > > http://cr.openjdk.java.net/~stefank/8003720/webrev.01 test/runtime/8003720/Asmator.java: Two comments here: 1. The copyright header is missing 2. The ASM import should be updated as soon the new ASM package has hit our repositories (I track the 292 files with 8001885) Otherwise this looks good. -- Chris > > thanks, > StefanK > > On 11/23/2012 01:01 AM, David Holmes wrote: >> Hi Stefan, >> >> Not my area so a minor comment not a review :) >> >> thread.hpp >> >> 481 // GC support >> 482 // Apply "f->do_oop" to all root oops in "this". >> 483 // Apply "cf->do_code_blob" (if !NULL) to all code blobs active in frames >> 484 virtual void oops_do(OopClosure* f, CLDToOopClosure* cld_f, CodeBlobClosure* cf); >> >> can you add a comment that cld_f is not used/needed by Thread::oops_do >> >> Thanks, >> David >> >> On 23/11/2012 12:14 AM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8003720/webrev/ >>> >>> Description from CR: >>> In virtual calls the Method pointer in the interpreter stack frame is >>> not kept alive by anything other than the "this" pointers to that >>> method. If bytecodes overwrite the "this" pointer, then call a full GC, >>> the class loader containing the Method* can be unloaded and the Method* >>> deallocated. >>> >>> This is also a problem with JSR292 MethodHandle static code because the >>> MethodHandle containing the mirror for the interpreted method Method* is >>> not on the stack if a GC occurs. >>> >>> Fix proposal: >>> The "obvious" solution to this problem would be to apply the root >>> scanning OopClosure to the Klass::_java_mirror field of the method in >>> the interpreted frame. However, doing this might cause us to scan the >>> same metadata oop location more than once, which is not allowed by some >>> of the HotSpot GCs. We currently solve similar situations by always >>> "claiming" and start scanning from the ClassLoaderData and then proceed >>> down into the Klasses of that class loader. >>> >>> For this bug we do the same. All old collections, where class unloading >>> can occur, pass down a closure that is applied to the ClassLoaderData of >>> the Klass of the Method in the interpreted frame. This closure does the >>> claiming and proceeds to scan the class metadata. Note that during young >>> collections, where we don't do class unloading, all classes are already >>> used as strong roots and we don't have to apply this new closure in the >>> interpreted frame. >>> >>> Testing: >>> The added test was initially written by John Rose. I only ported it to >>> JTreg and made some artistic cleanups to it. >>> >>> thanks, >>> StefanK > From rkennke at redhat.com Mon Nov 26 15:18:50 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 27 Nov 2012 00:18:50 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> Message-ID: <1353971930.20183.3.camel@mercury> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > > > Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >> > >>> > >>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>> > >>>> > >>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>> > >>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>> > >>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>> > >>>>>>>> Hi there, > >>>>>>>> > >>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>> Here are some details: > >>>>>>>> > >>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>> changes in LLVM. > >>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>> class hierarchies in Hotspot. > >>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>> nicer. > >>>>>>>> > >>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>> bunch of other stuff. > >>>>>>>> > >>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>> can find the full webrev here: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>> > >>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>> > >>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>> > >>>>>>> Isn't PrintCompilation doing that already? > >>>>>>> > >>>>>>> The shared code changes look good. I filed: > >>>>>>> > >>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>> > >>>>>>> -- Chris > >>>>>>> > >>>>>>>> > >>>>>>>> There are also a very minor change required in JDK: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>> > >>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>> > >>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>> > >>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>> integrated into Hotspot. > >>>>>> > >>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>> > >>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>> > >>>>>> and: > >>>>>> > >>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>> > >>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>> > >>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>> this happens when certain cflags are not set correctly. The script > >>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>> correct flags. In order for this to work, you need to have the full path > >>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>> using the build script that I provided? > >>>> > >>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>> > >>>> Now that I have the LLVM_* variables it's even worse: > >>>> > >>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>> > >>>> It's probably this guy: -Wcast-qual > >>> > >>> Got it: > >>> > >>> $ java -version > >>> java version "1.8.0-ea" > >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >> > >> I ran the compiler regression tests and Shark crashes in 5091921: > >> > >> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >> Directory "/export/twisti/jtreg/scratch" not found: creating > >> Passed: compiler/5091921/Test5091921.java > >> Passed: compiler/5091921/Test6186134.java > >> Passed: compiler/5091921/Test6196102.java > >> Passed: compiler/5091921/Test6357214.java > >> Passed: compiler/5091921/Test6559156.java > >> Passed: compiler/5091921/Test6753639.java > >> Passed: compiler/5091921/Test6850611.java > >> Passed: compiler/5091921/Test6890943.java > >> Passed: compiler/5091921/Test6897150.java > >> Passed: compiler/5091921/Test6905845.java > >> Passed: compiler/5091921/Test6931567.java > >> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >> > >> You can also run all them with a simple make in test/ by setting: > >> > >> PRODUCT_HOME=$JAVA_HOME > >> TESTDIRS=compiler > > > > Alright, I found another fairly grave bug that I would like to include a > > fix for: apparently, a 'fence' is not enough of a memory barrier for > > volatile putfield/getfield (duh). Which basically broke all of j.u.c. > > LLVM offers atomic loads and stores, which seem to be exactly what is > > needed for volatile field access. However, it does not provide helper > > functions for those in llvm::IRBuilder so I wrote my own. This should be > > the final patch for now (unless you find something else). > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > > Hmm. Maybe I did something wrong but I've already rebuilt twice: > > $ java -Xcomp -version > Value type size is target-dependent. Ask TLI. > UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > Stack dump: > 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > Aborted (core dumped) Arg! The last couple of changes I did only with LLVM3.2, where the problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with atomic load/store :-( I re-introduced the CreateMemoryBarrier call and use that for SHARK_LLVM_VERSION <= 31. http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ Hope that works better :-) Roman From christian.thalinger at oracle.com Mon Nov 26 15:43:16 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 26 Nov 2012 15:43:16 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353971930.20183.3.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> Message-ID: On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: >> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: >> >>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: >>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: >>>>>> >>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>>>>>>> >>>>>>>>>> Hi there, >>>>>>>>>> >>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>>>>>>> Here are some details: >>>>>>>>>> >>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>>>>>>> changes in LLVM. >>>>>>>>>> - Most other changes have to do with the split of the oop and metadata >>>>>>>>>> class hierarchies in Hotspot. >>>>>>>>>> - Then there have been a few changes caused by LLVM changes and >>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>>>>>>> representation directly in LLVM's IR. This makes our code a little >>>>>>>>>> nicer. >>>>>>>>>> >>>>>>>>>> I tested this by running a number of applications, most notably Eclipse >>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>>>>>>> bunch of other stuff. >>>>>>>>>> >>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>>>>>>> can find the full webrev here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>>>>>>> >>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>>>>>>> >>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>>>>>>> >>>>>>>>> Isn't PrintCompilation doing that already? >>>>>>>>> >>>>>>>>> The shared code changes look good. I filed: >>>>>>>>> >>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM >>>>>>>>> >>>>>>>>> -- Chris >>>>>>>>> >>>>>>>>>> >>>>>>>>>> There are also a very minor change required in JDK: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>>>>>>> >>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>>>>>>> and jdk repositories respectivly. Find my build script here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>>>>>>> >>>>>>>>>> (Review and adjust variables to your settings, most notably you will >>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>>>>>>> >>>>>>>>>> Please let me know if there are any issues or how we can get this >>>>>>>>>> integrated into Hotspot. >>>>>>>> >>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>>>>>>> >>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>>>>>>> from /usr/local/include/llvm/Use.h:28, >>>>>>>> from /usr/local/include/llvm/Value.h:17, >>>>>>>> from /usr/local/include/llvm/Argument.h:17, >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>>>>>>> >>>>>>>> and: >>>>>>>> >>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, >>>>>>>> from /usr/local/include/llvm/Argument.h:18, >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>>>>>>> >>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? >>>>>>> >>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >>>>>>> this happens when certain cflags are not set correctly. The script >>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >>>>>>> correct flags. In order for this to work, you need to have the full path >>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >>>>>>> using the build script that I provided? >>>>>> >>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. >>>>>> >>>>>> Now that I have the LLVM_* variables it's even worse: >>>>>> >>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness >>>>>> >>>>>> It's probably this guy: -Wcast-qual >>>>> >>>>> Got it: >>>>> >>>>> $ java -version >>>>> java version "1.8.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) >>>> >>>> I ran the compiler regression tests and Shark crashes in 5091921: >>>> >>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ >>>> Directory "/export/twisti/jtreg/scratch" not found: creating >>>> Passed: compiler/5091921/Test5091921.java >>>> Passed: compiler/5091921/Test6186134.java >>>> Passed: compiler/5091921/Test6196102.java >>>> Passed: compiler/5091921/Test6357214.java >>>> Passed: compiler/5091921/Test6559156.java >>>> Passed: compiler/5091921/Test6753639.java >>>> Passed: compiler/5091921/Test6850611.java >>>> Passed: compiler/5091921/Test6890943.java >>>> Passed: compiler/5091921/Test6897150.java >>>> Passed: compiler/5091921/Test6905845.java >>>> Passed: compiler/5091921/Test6931567.java >>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts >>>> >>>> You can also run all them with a simple make in test/ by setting: >>>> >>>> PRODUCT_HOME=$JAVA_HOME >>>> TESTDIRS=compiler >>> >>> Alright, I found another fairly grave bug that I would like to include a >>> fix for: apparently, a 'fence' is not enough of a memory barrier for >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. >>> LLVM offers atomic loads and stores, which seem to be exactly what is >>> needed for volatile field access. However, it does not provide helper >>> functions for those in llvm::IRBuilder so I wrote my own. This should be >>> the final patch for now (unless you find something else). >>> >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ >> >> Hmm. Maybe I did something wrong but I've already rebuilt twice: >> >> $ java -Xcomp -version >> Value type size is target-dependent. Ask TLI. >> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! >> Stack dump: >> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' >> Aborted (core dumped) > > Arg! The last couple of changes I did only with LLVM3.2, where the > problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > use that for SHARK_LLVM_VERSION <= 31. > > http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > > Hope that works better :-) I'm so sorry but... /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' -- Chris > > Roman > > From John.Coomes at oracle.com Mon Nov 26 16:10:57 2012 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 26 Nov 2012 16:10:57 -0800 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <50AF317E.8080205@oracle.com> References: <50AE334A.604@oracle.com> <50AEBCE6.50004@oracle.com> <50AF317E.8080205@oracle.com> Message-ID: <20660.1297.322575.970503@oracle.com> Stefan Karlsson (stefan.karlsson at oracle.com) wrote: > David, > > Thanks for taking a look at this. > > I've added a comment regarding the cld_f: > > // GC support > // Apply "f->do_oop" to all root oops in "this". > *+ // Apply "cld_f->do_cld" to CLDs that are otherwise not kept alive.* > *+ // Used by JavaThread::oops_do.* > // Apply "cf->do_code_blob" (if !NULL) to all code blobs active in frames > *! virtual void oops_do(OopClosure* f,_CLDToOopClosure* cld_f,_CodeBlobClosure* cf);* > > http://cr.openjdk.java.net/~stefank/8003720/webrev.01 iterator.hpp: ------------ I don't see any uses of this constructor: 150 CLDToOopClosure(OopClosure* oop_closure, KlassClosure* klass_closure, bool must_claim_cld = true) : 151 _oop_closure(oop_closure), 152 _default_klass_closure(NULL), // Ignored 153 _klass_closure(klass_closure), 154 _must_claim_cld(must_claim_cld) {} If it's unused, then you can eliminate the _default_klass_closure / _klass_closure distinction. frame.cpp: -------- A typo in the comment: 916 // closure that knows have to keep klasses alive given a ClassLoaderData. ^^^^ Otherwise, looks good. -John > On 11/23/2012 01:01 AM, David Holmes wrote: > > Hi Stefan, > > > > Not my area so a minor comment not a review :) > > > > thread.hpp > > > > 481 // GC support > > 482 // Apply "f->do_oop" to all root oops in "this". > > 483 // Apply "cf->do_code_blob" (if !NULL) to all code blobs active > > in frames > > 484 virtual void oops_do(OopClosure* f, CLDToOopClosure* cld_f, > > CodeBlobClosure* cf); > > > > can you add a comment that cld_f is not used/needed by Thread::oops_do > > > > Thanks, > > David > > > > On 23/11/2012 12:14 AM, Stefan Karlsson wrote: > >> http://cr.openjdk.java.net/~stefank/8003720/webrev/ > >> > >> Description from CR: > >> In virtual calls the Method pointer in the interpreter stack frame is > >> not kept alive by anything other than the "this" pointers to that > >> method. If bytecodes overwrite the "this" pointer, then call a full GC, > >> the class loader containing the Method* can be unloaded and the Method* > >> deallocated. > >> > >> This is also a problem with JSR292 MethodHandle static code because the > >> MethodHandle containing the mirror for the interpreted method Method* is > >> not on the stack if a GC occurs. > >> > >> Fix proposal: > >> The "obvious" solution to this problem would be to apply the root > >> scanning OopClosure to the Klass::_java_mirror field of the method in > >> the interpreted frame. However, doing this might cause us to scan the > >> same metadata oop location more than once, which is not allowed by some > >> of the HotSpot GCs. We currently solve similar situations by always > >> "claiming" and start scanning from the ClassLoaderData and then proceed > >> down into the Klasses of that class loader. > >> > >> For this bug we do the same. All old collections, where class unloading > >> can occur, pass down a closure that is applied to the ClassLoaderData of > >> the Klass of the Method in the interpreted frame. This closure does the > >> claiming and proceeds to scan the class metadata. Note that during young > >> collections, where we don't do class unloading, all classes are already > >> used as strong roots and we don't have to apply this new closure in the > >> interpreted frame. > >> > >> Testing: > >> The added test was initially written by John Rose. I only ported it to > >> JTreg and made some artistic cleanups to it. > >> > >> thanks, > >> StefanK > From dl at cs.oswego.edu Mon Nov 26 16:20:09 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 26 Nov 2012 19:20:09 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3BE1C.2040207@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> Message-ID: <50B40739.10709@cs.oswego.edu> On 11/26/12 14:08, Doug Lea wrote: >> >>> I think you should re-write the javadoc ... > > The Contended.java file and its javadoc in Aleksey's webrev is just a > placeholder to get things moving. We expect to solicit > reviews in the usual way (mainly on concurrency-interest list) > for a version that will make it into JDK8. The initial javadoc is pasted below; updates will appear in jsr166 CVS viewable at: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Contended.java?view=log /** * An annotation expressing that objects and/or their fields are * expected to encounter memory contention, generally in the form of * "false sharing". This annotation serves as a hint that such objects * and fields should reside in locations isolated from those of other * objects or fields. The effects of this annotation will nearly * always add space overhead to programs. Its use is warranted only * when the performance impact of this time/space tradeoff is * intrinsically worthwhile; for example, in concurrent contexts in * which each instance of the annotated object is often accessed by a * different thread. * *

A {@code @Contended} field annotation may optionally include a * contention group tag. All fields with the same tag are considered * as a group with respect to isolation from other groups. A default * annotation without a tag indicates contention with all other * fields, including other {@code @Contended} ones. *

When the annotation is used at the class level, all unannotated * fields of the object are considered to be in the same default * group, separate from any fields that carry their own (possibly * tagged) {@code @Contended} annotations. * *

Sample Usages. (Forthcoming.) * * @since 1.8 */ From rkennke at redhat.com Mon Nov 26 16:44:17 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 27 Nov 2012 01:44:17 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> Message-ID: <1353977057.20183.8.camel@mercury> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > > > Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >> > >>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>> > >>>>> > >>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>> > >>>>>> > >>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>> > >>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>> > >>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>> > >>>>>>>>>> Hi there, > >>>>>>>>>> > >>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>> Here are some details: > >>>>>>>>>> > >>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>> changes in LLVM. > >>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>> nicer. > >>>>>>>>>> > >>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>> bunch of other stuff. > >>>>>>>>>> > >>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>> can find the full webrev here: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>> > >>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>> > >>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>> > >>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>> > >>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>> > >>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>> > >>>>>>>>> -- Chris > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>> > >>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>> > >>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>> > >>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>> integrated into Hotspot. > >>>>>>>> > >>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>> > >>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>> > >>>>>>>> and: > >>>>>>>> > >>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>> > >>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>> > >>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>> using the build script that I provided? > >>>>>> > >>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>> > >>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>> > >>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>> > >>>>>> It's probably this guy: -Wcast-qual > >>>>> > >>>>> Got it: > >>>>> > >>>>> $ java -version > >>>>> java version "1.8.0-ea" > >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>> > >>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>> > >>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>> Passed: compiler/5091921/Test5091921.java > >>>> Passed: compiler/5091921/Test6186134.java > >>>> Passed: compiler/5091921/Test6196102.java > >>>> Passed: compiler/5091921/Test6357214.java > >>>> Passed: compiler/5091921/Test6559156.java > >>>> Passed: compiler/5091921/Test6753639.java > >>>> Passed: compiler/5091921/Test6850611.java > >>>> Passed: compiler/5091921/Test6890943.java > >>>> Passed: compiler/5091921/Test6897150.java > >>>> Passed: compiler/5091921/Test6905845.java > >>>> Passed: compiler/5091921/Test6931567.java > >>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>> > >>>> You can also run all them with a simple make in test/ by setting: > >>>> > >>>> PRODUCT_HOME=$JAVA_HOME > >>>> TESTDIRS=compiler > >>> > >>> Alright, I found another fairly grave bug that I would like to include a > >>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>> needed for volatile field access. However, it does not provide helper > >>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>> the final patch for now (unless you find something else). > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >> > >> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >> > >> $ java -Xcomp -version > >> Value type size is target-dependent. Ask TLI. > >> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >> Stack dump: > >> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >> Aborted (core dumped) > > > > Arg! The last couple of changes I did only with LLVM3.2, where the > > problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > > atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > > use that for SHARK_LLVM_VERSION <= 31. > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > > > > Hope that works better :-) > > I'm so sorry but... > > /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and llvm3.1, but apparently not (maybe I shouldn't work after 1am). This (hopefully final final) patch re-instates the missing memory_barrier() method: http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ Sorry for the messy back-and-forth. Roman From christian.thalinger at oracle.com Mon Nov 26 17:14:36 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 26 Nov 2012 17:14:36 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1353977057.20183.8.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> Message-ID: On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: >> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: >> >>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: >>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: >>>> >>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: >>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: >>>>>> >>>>>>> >>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: >>>>>>> >>>>>>>> >>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: >>>>>>>> >>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi there, >>>>>>>>>>>> >>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>>>>>>>>> Here are some details: >>>>>>>>>>>> >>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>>>>>>>>> changes in LLVM. >>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata >>>>>>>>>>>> class hierarchies in Hotspot. >>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and >>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little >>>>>>>>>>>> nicer. >>>>>>>>>>>> >>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse >>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>>>>>>>>> bunch of other stuff. >>>>>>>>>>>> >>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>>>>>>>>> can find the full webrev here: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>>>>>>>>> >>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>>>>>>>>> >>>>>>>>>>> Isn't PrintCompilation doing that already? >>>>>>>>>>> >>>>>>>>>>> The shared code changes look good. I filed: >>>>>>>>>>> >>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM >>>>>>>>>>> >>>>>>>>>>> -- Chris >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There are also a very minor change required in JDK: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>>>>>>>>> >>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>>>>>>>>> >>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will >>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>>>>>>>>> >>>>>>>>>>>> Please let me know if there are any issues or how we can get this >>>>>>>>>>>> integrated into Hotspot. >>>>>>>>>> >>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>>>>>>>>> >>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>>>>>>>>> from /usr/local/include/llvm/Use.h:28, >>>>>>>>>> from /usr/local/include/llvm/Value.h:17, >>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>>>>>>>>> >>>>>>>>>> and: >>>>>>>>>> >>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, >>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>>>>>>>>> >>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? >>>>>>>>> >>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >>>>>>>>> this happens when certain cflags are not set correctly. The script >>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >>>>>>>>> correct flags. In order for this to work, you need to have the full path >>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >>>>>>>>> using the build script that I provided? >>>>>>>> >>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. >>>>>>>> >>>>>>>> Now that I have the LLVM_* variables it's even worse: >>>>>>>> >>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness >>>>>>>> >>>>>>>> It's probably this guy: -Wcast-qual >>>>>>> >>>>>>> Got it: >>>>>>> >>>>>>> $ java -version >>>>>>> java version "1.8.0-ea" >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) >>>>>> >>>>>> I ran the compiler regression tests and Shark crashes in 5091921: >>>>>> >>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ >>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating >>>>>> Passed: compiler/5091921/Test5091921.java >>>>>> Passed: compiler/5091921/Test6186134.java >>>>>> Passed: compiler/5091921/Test6196102.java >>>>>> Passed: compiler/5091921/Test6357214.java >>>>>> Passed: compiler/5091921/Test6559156.java >>>>>> Passed: compiler/5091921/Test6753639.java >>>>>> Passed: compiler/5091921/Test6850611.java >>>>>> Passed: compiler/5091921/Test6890943.java >>>>>> Passed: compiler/5091921/Test6897150.java >>>>>> Passed: compiler/5091921/Test6905845.java >>>>>> Passed: compiler/5091921/Test6931567.java >>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts >>>>>> >>>>>> You can also run all them with a simple make in test/ by setting: >>>>>> >>>>>> PRODUCT_HOME=$JAVA_HOME >>>>>> TESTDIRS=compiler >>>>> >>>>> Alright, I found another fairly grave bug that I would like to include a >>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for >>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. >>>>> LLVM offers atomic loads and stores, which seem to be exactly what is >>>>> needed for volatile field access. However, it does not provide helper >>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be >>>>> the final patch for now (unless you find something else). >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ >>>> >>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: >>>> >>>> $ java -Xcomp -version >>>> Value type size is target-dependent. Ask TLI. >>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! >>>> Stack dump: >>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' >>>> Aborted (core dumped) >>> >>> Arg! The last couple of changes I did only with LLVM3.2, where the >>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with >>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and >>> use that for SHARK_LLVM_VERSION <= 31. >>> >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ >>> >>> Hope that works better :-) >> >> I'm so sorry but... >> >> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > > Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > (hopefully final final) patch re-instates the missing memory_barrier() > method: > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > > Sorry for the messy back-and-forth. Again, so sorry: $ java -Xcomp -version LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! Send a new patch tomorrow after some sleep ;-) -- Chris > > Roman > From david.holmes at oracle.com Mon Nov 26 18:38:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Nov 2012 12:38:26 +1000 Subject: Official reviewer needed: Review request for fix for 7200297: agent code does not handle multiple dll_dir paths correctly In-Reply-To: <50B3AAA5.9040401@oracle.com> References: <50A41AEA.8050705@oracle.com> <50A4AF33.2020208@oracle.com> <50A5420A.7030502@oracle.com> <50A54734.6000608@oracle.com> <50A6A18C.1070206@oracle.com> <50AAA04A.70408@oracle.com> <50ACA54E.7020608@oracle.com> <50AD2C2A.8000401@oracle.com> <50AE1FEC.9030506@oracle.com> <50B3AAA5.9040401@oracle.com> Message-ID: <50B427A2.8050809@oracle.com> Hi Bill, A few minor comments, some of which you've touched on with Dmitry. David ------ share/back/debugInit.c 40 #include "sys.h" Shouldn't that be ? --- src/share/back/transport.c * Note: Java property sun.boot.library.path contains a single directory. + * Note: Above incorrect since 6819213 fixed. Dll_dir is the first entry + * and -Dsun.boot.library.path entries are appended. Better to just change the original comment than to keep it and say it isn't true. --- src/solaris/back/linker_md.c 113 return; Adding the return is superfluous. Arguably the whole method should be a chained if-else with no returns. Stylistically you have now mixed styles: either use a return, or use an else, but not both. --- src/solaris/demo/jvmti/hprof/hprof_md.c 426 return; Same comment as for linker_md.c And why didn't you move *holder = '\0'; in this version? Ditto src/windows/demo/jvmti/hprof/hprof_md.c --- src/windows/back/linker_md.c 123 return; Ditto previous comments. --- On 27/11/2012 3:45 AM, BILL PITTORE wrote: > Have a couple of reviews but still need official reviewer to pass muster. > > thanks, > bill > > > > On 11/22/2012 7:51 AM, Dmitry Samersoff wrote: >> Bill, >> >> Looks good for me. >> >> -Dmitry >> >> On 2012-11-21 23:31, BILL PITTORE wrote: >>> Hi Dmitry, >>> >>> On 11/21/2012 4:56 AM, Dmitry Samersoff wrote: >>>> Bill, >>>> >>>> >>>> Few nits: >>>> >>>> 1. >>>> >>>> dll_build_name is exactly the same for all locations could we place it >>>> to some common place? >>> It looked somewhat intentional to have the agents and the hprof code be >>> self-contained. I looked at using a common file but the makefile changes >>> and source tree changes seemed a bit much. Hprof code is "unsupported >>> demo" code and jdwp is supported agent so I went with the current scheme >>> of having the code be self-contained. >>>> Also file_exists is not necessary and could be >>>> replaced with just ::access(buffer,R_OK) (Windows has it as well) >>> I'll go with the access suggestion above, less code. >>>> but if you prefer to keep it: >>>> >>>> strlen(filename)==0 could be a *filename == 0 >>>> >>>> >>>> 2. We don't need else after return in all *_md.c files >>>> e.g. linker_md.c:122 >>> Semantically, you're correct. I think in terms of code readability I >>> like the 'else' since it makes it clear to the reader that there are two >>> different cases. C compiler will 'do the right thing'. >>> Updated the webrev at >>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.03/ >>> >>> thanks, >>> bill >>>> Otherwise looks good. >>>> >>>> -Dmitry >>>> >>>> On 2012-11-20 01:10, BILL PITTORE wrote: >>>>> Have gotten reviews from Serguei Spitsyn for the changes, made some >>>>> improvements and need an official reviewer to check it out. >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.02 >>>>> >>>>> thanks, >>>>> bill >>>>> >>>>> >>>>> >>>>> On 11/14/2012 5:27 PM, bill.pittore at oracle.com wrote: >>>>>> This bug has to do with the jdwp and hprof agents not parsing the >>>>>> sun.boot.library.path (dll_dir) correctly since the fix for 6819213 >>>>>> went in some years ago. This bug popped up while working on a >>>>>> particular platform that does not have the ability to set >>>>>> LD_LIBRARY_PATH before running the VM. As documented in the bug, on >>>>>> most platforms even if the sun.boot.library.path consists of multiple >>>>>> paths and the jdwp or hprof code fails to load a dependent lib, the >>>>>> system falls back to using LD_LIBRARY_PATH so the failure is masked. >>>>>> On some other platforms, this failover doesn't exist so we get an >>>>>> error when trying to load jdwp and hprof dependent libs. >>>>>> >>>>>> Some notes on a couple of files. >>>>>> * >>>>>> debugInit.c, hprof_init.c*: >>>>>> Rearranged the init order so that the jvmti pointer gets initialized >>>>>> before attempting to load the npt shared library. >>>>>> >>>>>> *linker_md.c, hprof_md.c* >>>>>> Much of the platform code in hprof and jdwp is duplicated and this >>>>>> change is no different. Based on the code in hotspot >>>>>> os_solaris/windows.cpp it parses the boot library path and >>>>>> attempts to >>>>>> find the library. >>>>>> * >>>>>> error_messages.c* >>>>>> Fixed a bug in the error message code that blindly dereferenced the >>>>>> npt pointer even if it wasn't set because of an error in loading. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~bpittore/7200297/webrev.00/ >>>>>> >>>>>> Ran the ute nsk/jdwp nsk/jvmti nsk/hprof tests, the JCK jdwp/jvmti >>>>>> tests and some command line testing on windows and linux. >>>>>> >>>>>> thanks, >>>>>> bill >>>>>> >>>>>> >> > > From david.holmes at oracle.com Mon Nov 26 19:57:31 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Nov 2012 13:57:31 +1000 Subject: Fwd: Report a bug in HotSpot In-Reply-To: <50B3B524.60307@oracle.com> References: <50B3B524.60307@oracle.com> Message-ID: <50B43A2B.4070202@oracle.com> Hi Kris, I think historically hotspot assumes/requires JNI code to be well behaved about these things. There have been some well known issues with FPU state in the past. I'm not that familiar with MMX so can't say whether it is reasonable for the VM to know when it has to do this kind of cleanup. David On 27/11/2012 4:29 AM, Krystal Mo wrote: > Hi all, > > Xi Yang has reported a bug in HotSpot's interpreter that it doesn't > empty the FPU stack on return from JNI calls. His mail is included below. > > e.g. If a native function called via JNI is using MMX registers without > emptying the FPU stack before returning, then after returning to Java > the FPU stack will be in a bad state. > > The test case Xi gave is demonstrated here on JDK7u9, x86: > https://gist.github.com/4148771 > Running the example with -XX:+VerifyFPU shows what's going on. > > This test case shows the bug affecting 32-bit x86 version of HotSpot's > interpreter. > > Not really familiar with how to file a bug on JBS yet, I'll file a bug > to track this after I learn how to do it. > > Regards, > Kris > > > -------- Original Message -------- > Subject: Fwd: Report a bug in HotSpot > Date: Tue, 27 Nov 2012 02:02:59 +0800 > From: Krystal Mok > To: Krystal Mo > > > > ---------- Forwarded message ---------- > From: Xi Yang > Date: Tue, Nov 20, 2012 at 1:44 PM > Subject: Report a bug in HotSpot > To: Krystal Mok > > > Hi, > > It looks like HotSpot does not do "emms" after backing from JNI. Here > is the code to show the bug. Would you like to try the newest version? > > > Hello.java > class Hello { > private static native void abc(); > public static void main(String[] args) { > System.out.println("I am main"); > System.loadLibrary("Hello"); > abc(); > long a = 100; > double b = (double)a; > System.out.println("Double a is " + b); > } > } > > Hello.c > #include > #include > > JNIEXPORT void JNICALL > Java_Hello_abc(JNIEnv *env, jclass cls) > { > printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); > unsigned int dummy; > asm volatile("movd %%mm0, %0\n":"=r"(dummy)); > printf("dummy is %x\n", dummy); > } > > > gcc -m32 -shared ./Hello.c -o ./libHello.so > > > /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello > I am main > I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world > dummy is 0 > Double a is NaN > > > $ /opt/jdk1.7.0/bin/java -version > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) > Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) > > > From kirk at kodewerk.com Mon Nov 26 22:33:29 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 27 Nov 2012 07:33:29 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> <448B1ACA-9E81-4824-B329-C6436DF0BE1A@kodewerk.com> Message-ID: <604EDA6F-68AA-4D64-B483-64B9891EB46B@kodewerk.com> Hi Vitaly, My comment about unsafe was a bit tongue in cheek. If this is to be done, than it seems the sensible package would be j.u.c. As for mothering developers, this isn't about mothering developers, it's about moving forward in a way that fits with Java's way of doing thing. I still stand by my previous email that this"optimization" is unsfe (hence the pun). I'll start with some questions... how would a developer know when to apply this annotation. Or conversely, once applied, how would a developer know if the padding now was de-optimizing the run time? I'm sure that there are some (micro???) benchmarks (have they been published so we can look at them?) some where in Oracle that demonstrates which means this has been a very interesting and useful experiment. It has demonstrated that there is some value in somehow adapting code to deal with conditions that are specific to a particular runtime configuration. That said, Java has been about making difficult things reachable to average developers. HotSpot has been about adapting code to particular run time conditions. Thus I would argue that this annotation runs counter to both purposes. From a business perspective I'd be thrilled to have this annotation appear in the JDK. I've built tooling that nicely detects conditions when padding out a cache line would solve some degenerate condition such as false sharing. I'd be thrilled because the tooling is completely safe to run in a production environment and this annotation will create a very nice market for it. I which is exactly where it would need to run to properly detect the need or impact of the "optimization". t would replace all of the business I lost when CMS started to collected perm space by default. Ok, that was another tongue in cheek also because I did speak to Tony about all the field work I was doing just getting people to set two values to true. My point here is that if I have been able to develop this type of tooling it suggests that it is possible (in fact I'd argue some what easier) to develop it for the JVM. This way we would convert a difficult to understand, potentially fragile optimization into one that becomes adaptive to the runtime conditions that it finds it's self in. This is not full profiling in the traditional sense of profiling. It's targeted and it's cheap. So before dropping an annotation into the JDK that will be with us forever, I would suggest that we explore ways having the runtime detect and adapt. Regards, Kirk On 2012-11-26, at 8:43 PM, Vitaly Davidovich wrote: > I don't see what burying this in sun.misc really accomplishes. Look at Unsafe - it's still widely used except have to jump through reflection hoops. Also, sun.misc is apparently going away in java 9. > > I also don't understand the reasoning behind trying to "prevent people from shooting themselves in the foot" - we should consider java developers as responsible adults. Nobody is forcing anyone to use this annotation. Otherwise, we should throw out GC tuning knobs, JIT tuning knobs, weak/soft/phantom refs, finalizers, thread locals, direct byte buffers, etc. This entire "java devs are too immature/dumb/irresponsible/etc" sentiment is ridiculous, IMHO. > > By the way, if you think only Doug/Cliff Click/etc are using Unsafe, then don't tell Cassandra/Hbase developers :). Cassandra goes as far as using pluggable C heap allocators (accessed via Unsafe behind the scenes) to allocate off-heap memory - this is in addition to using unsafe comparators for byte arrays, and other "tricks". That's the price of admission when trying to squeeze perf ... > > Sent from my phone > > On Nov 26, 2012 2:19 PM, "Kirk Pepperdine" wrote: > Actually, sun.misc.Contended right beside sun.misc.Unsafe doesn't sound like such a bad idea. > > -- Kirk > > On 2012-11-26, at 8:08 PM, Doug Lea

wrote: > > > On 11/26/12 13:40, Aleksey Shipilev wrote: > >> On 11/26/2012 09:35 PM, Remi Forax wrote: > >>> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: > >>>> On 11/26/2012 08:22 PM, Doug Lea wrote: > >>>>> One small suggestion to slightly appease the nanny-state folks. > >>>>> How about burying the annotation one lever deeper to > >>>>> java.util.concurrent.atomic. > >>> > >>> +1 > >>> > >> > >> Still fail to see the rationale about this. > > > > All things considered, I'm back to agreeing with you -- > > Just j.u.c.Contended > > > >> > >>> I think you should re-write the javadoc ... > > > > The Contended.java file and its javadoc in Aleksey's webrev is just a > > placeholder to get things moving. We expect to solicit > > reviews in the usual way (mainly on concurrency-interest list) > > for a version that will make it into JDK8. > > > >> > >> I.e. > >> > >> @Contended > >> public class ValueClass { > >> private int field1; > >> private int field2; > >> private int field3; > >> private int field4; > >> } > >> > >> is the shortcut for: > >> > >> public class ValueClass { > >> @Contended("theSame") private int field1; > >> @Contended("theSame") private int field2; > >> @Contended("theSame") private int field3; > >> @Contended("theSame") private int field4; > >> } > >> > >> That is, all the fields would be densely-packed, but will be padded as > >> the group. Note that it is not the same as: > >> > >> public class ValueClass { > >> @Contended private int field1; > >> @Contended private int field2; > >> @Contended private int field3; > >> @Contended private int field4; > >> } > >> > >> Maybe that is already confusing enough to drop class-level annotation? > >> What do others feel about this? > > > > I think that the most common and most-recommended case will be class-level, > > so it should be kept. We can work on the usage advice in the javadocs. > > > > -Doug > > > > > From forax at univ-mlv.fr Tue Nov 27 00:57:07 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Nov 2012 09:57:07 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <604EDA6F-68AA-4D64-B483-64B9891EB46B@kodewerk.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> <448B1ACA-9E81-4824-B329-C6436DF0BE1A@kodewerk.com> <604EDA6F-68AA-4D64-B483-64B9891EB46B@kodewerk.com> Message-ID: <50B48063.9060707@univ-mlv.fr> On 11/27/2012 07:33 AM, Kirk Pepperdine wrote: > Hi Vitaly, > > My comment about unsafe was a bit tongue in cheek. If this is to be done, than it seems the sensible package would be j.u.c. As for mothering developers, this isn't about mothering developers, it's about moving forward in a way that fits with Java's way of doing thing. I still stand by my previous email that this"optimization" is unsfe (hence the pun). I'll start with some questions... how would a developer know when to apply this annotation. Or conversely, once applied, how would a developer know if the padding now was de-optimizing the run time? > > I'm sure that there are some (micro???) benchmarks (have they been published so we can look at them?) some where in Oracle that demonstrates which means this has been a very interesting and useful experiment. It has demonstrated that there is some value in somehow adapting code to deal with conditions that are specific to a particular runtime configuration. That said, Java has been about making difficult things reachable to average developers. HotSpot has been about adapting code to particular run time conditions. Thus I would argue that this annotation runs counter to both purposes. > > From a business perspective I'd be thrilled to have this annotation appear in the JDK. I've built tooling that nicely detects conditions when padding out a cache line would solve some degenerate condition such as false sharing. I'd be thrilled because the tooling is completely safe to run in a production environment and this annotation will create a very nice market for it. I which is exactly where it would need to run to properly detect the need or impact of the "optimization". t would replace all of the business I lost when CMS started to collected perm space by default. Ok, that was another tongue in cheek also because I did speak to Tony about all the field work I was doing just getting people to set two values to true. My point here is that if I have been able to develop this type of tooling it suggests that it is possible (in fact I'd argue some what easier) to develop it for the JVM. This way we would convert a difficult to understand, potentially fragile optimization into one that becomes adaptive to the runtime conditions that it finds it's self in. This is not full profiling in the traditional sense of profiling. It's targeted and it's cheap. > > So before dropping an annotation into the JDK that will be with us forever, I would suggest that we explore ways having the runtime detect and adapt. Does your tooling works with G1 ? > > Regards, > Kirk cheers, R?mi > > > > On 2012-11-26, at 8:43 PM, Vitaly Davidovich wrote: > >> I don't see what burying this in sun.misc really accomplishes. Look at Unsafe - it's still widely used except have to jump through reflection hoops. Also, sun.misc is apparently going away in java 9. >> >> I also don't understand the reasoning behind trying to "prevent people from shooting themselves in the foot" - we should consider java developers as responsible adults. Nobody is forcing anyone to use this annotation. Otherwise, we should throw out GC tuning knobs, JIT tuning knobs, weak/soft/phantom refs, finalizers, thread locals, direct byte buffers, etc. This entire "java devs are too immature/dumb/irresponsible/etc" sentiment is ridiculous, IMHO. >> >> By the way, if you think only Doug/Cliff Click/etc are using Unsafe, then don't tell Cassandra/Hbase developers :). Cassandra goes as far as using pluggable C heap allocators (accessed via Unsafe behind the scenes) to allocate off-heap memory - this is in addition to using unsafe comparators for byte arrays, and other "tricks". That's the price of admission when trying to squeeze perf ... >> >> Sent from my phone >> >> On Nov 26, 2012 2:19 PM, "Kirk Pepperdine" wrote: >> Actually, sun.misc.Contended right beside sun.misc.Unsafe doesn't sound like such a bad idea. >> >> -- Kirk >> >> On 2012-11-26, at 8:08 PM, Doug Lea
wrote: >> >>> On 11/26/12 13:40, Aleksey Shipilev wrote: >>>> On 11/26/2012 09:35 PM, Remi Forax wrote: >>>>> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >>>>>> On 11/26/2012 08:22 PM, Doug Lea wrote: >>>>>>> One small suggestion to slightly appease the nanny-state folks. >>>>>>> How about burying the annotation one lever deeper to >>>>>>> java.util.concurrent.atomic. >>>>> +1 >>>>> >>>> Still fail to see the rationale about this. >>> All things considered, I'm back to agreeing with you -- >>> Just j.u.c.Contended >>> >>>>> I think you should re-write the javadoc ... >>> The Contended.java file and its javadoc in Aleksey's webrev is just a >>> placeholder to get things moving. We expect to solicit >>> reviews in the usual way (mainly on concurrency-interest list) >>> for a version that will make it into JDK8. >>> >>>> I.e. >>>> >>>> @Contended >>>> public class ValueClass { >>>> private int field1; >>>> private int field2; >>>> private int field3; >>>> private int field4; >>>> } >>>> >>>> is the shortcut for: >>>> >>>> public class ValueClass { >>>> @Contended("theSame") private int field1; >>>> @Contended("theSame") private int field2; >>>> @Contended("theSame") private int field3; >>>> @Contended("theSame") private int field4; >>>> } >>>> >>>> That is, all the fields would be densely-packed, but will be padded as >>>> the group. Note that it is not the same as: >>>> >>>> public class ValueClass { >>>> @Contended private int field1; >>>> @Contended private int field2; >>>> @Contended private int field3; >>>> @Contended private int field4; >>>> } >>>> >>>> Maybe that is already confusing enough to drop class-level annotation? >>>> What do others feel about this? >>> I think that the most common and most-recommended case will be class-level, >>> so it should be kept. We can work on the usage advice in the javadocs. >>> >>> -Doug >>> >>> From forax at univ-mlv.fr Tue Nov 27 01:07:33 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Nov 2012 10:07:33 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B3B79C.2050509@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: <50B482D5.9020108@univ-mlv.fr> On 11/26/2012 07:40 PM, Aleksey Shipilev wrote: > On 11/26/2012 09:35 PM, Remi Forax wrote: >> On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: >>> On 11/26/2012 08:22 PM, Doug Lea wrote: >>>> One small suggestion to slightly appease the nanny-state folks. >>>> How about burying the annotation one lever deeper to >>>> java.util.concurrent.atomic. >> +1 >> > Still fail to see the rationale about this. A lot of people already uses classes from j.u.c, j.u.c.atomic is more exotic. Given that @Contented is exotic too ... R?mi From stefan.karlsson at oracle.com Tue Nov 27 01:10:23 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Nov 2012 10:10:23 +0100 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <20660.1297.322575.970503@oracle.com> References: <50AE334A.604@oracle.com> <50AEBCE6.50004@oracle.com> <50AF317E.8080205@oracle.com> <20660.1297.322575.970503@oracle.com> Message-ID: <50B4837F.5080107@oracle.com> On 11/27/2012 01:10 AM, John Coomes wrote: > Stefan Karlsson (stefan.karlsson at oracle.com) wrote: >> David, >> >> Thanks for taking a look at this. >> >> I've added a comment regarding the cld_f: >> >> // GC support >> // Apply "f->do_oop" to all root oops in "this". >> *+ // Apply "cld_f->do_cld" to CLDs that are otherwise not kept alive.* >> *+ // Used by JavaThread::oops_do.* >> // Apply "cf->do_code_blob" (if !NULL) to all code blobs active in frames >> *! virtual void oops_do(OopClosure* f,_CLDToOopClosure* cld_f,_CodeBlobClosure* cf);* >> >> http://cr.openjdk.java.net/~stefank/8003720/webrev.01 > iterator.hpp: > ------------ > > I don't see any uses of this constructor: > > 150 CLDToOopClosure(OopClosure* oop_closure, KlassClosure* klass_closure, bool must_claim_cld = true) : > 151 _oop_closure(oop_closure), > 152 _default_klass_closure(NULL), // Ignored > 153 _klass_closure(klass_closure), > 154 _must_claim_cld(must_claim_cld) {} > > If it's unused, then you can eliminate the _default_klass_closure / > _klass_closure distinction. Good catch. I'll remove the distinction. > > frame.cpp: > -------- > > A typo in the comment: > > 916 // closure that knows have to keep klasses alive given a ClassLoaderData. > ^^^^ Fixed. > > Otherwise, looks good. Thanks for the review. StefanK > > -John > >> On 11/23/2012 01:01 AM, David Holmes wrote: >>> Hi Stefan, >>> >>> Not my area so a minor comment not a review :) >>> >>> thread.hpp >>> >>> 481 // GC support >>> 482 // Apply "f->do_oop" to all root oops in "this". >>> 483 // Apply "cf->do_code_blob" (if !NULL) to all code blobs active >>> in frames >>> 484 virtual void oops_do(OopClosure* f, CLDToOopClosure* cld_f, >>> CodeBlobClosure* cf); >>> >>> can you add a comment that cld_f is not used/needed by Thread::oops_do >>> >>> Thanks, >>> David >>> >>> On 23/11/2012 12:14 AM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8003720/webrev/ >>>> >>>> Description from CR: >>>> In virtual calls the Method pointer in the interpreter stack frame is >>>> not kept alive by anything other than the "this" pointers to that >>>> method. If bytecodes overwrite the "this" pointer, then call a full GC, >>>> the class loader containing the Method* can be unloaded and the Method* >>>> deallocated. >>>> >>>> This is also a problem with JSR292 MethodHandle static code because the >>>> MethodHandle containing the mirror for the interpreted method Method* is >>>> not on the stack if a GC occurs. >>>> >>>> Fix proposal: >>>> The "obvious" solution to this problem would be to apply the root >>>> scanning OopClosure to the Klass::_java_mirror field of the method in >>>> the interpreted frame. However, doing this might cause us to scan the >>>> same metadata oop location more than once, which is not allowed by some >>>> of the HotSpot GCs. We currently solve similar situations by always >>>> "claiming" and start scanning from the ClassLoaderData and then proceed >>>> down into the Klasses of that class loader. >>>> >>>> For this bug we do the same. All old collections, where class unloading >>>> can occur, pass down a closure that is applied to the ClassLoaderData of >>>> the Klass of the Method in the interpreted frame. This closure does the >>>> claiming and proceeds to scan the class metadata. Note that during young >>>> collections, where we don't do class unloading, all classes are already >>>> used as strong roots and we don't have to apply this new closure in the >>>> interpreted frame. >>>> >>>> Testing: >>>> The added test was initially written by John Rose. I only ported it to >>>> JTreg and made some artistic cleanups to it. >>>> >>>> thanks, >>>> StefanK From stefan.karlsson at oracle.com Tue Nov 27 01:12:03 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Nov 2012 10:12:03 +0100 Subject: Review request (M): 8003720: NPG: Method in interpreter stack frame can be deallocated In-Reply-To: <50B382F0.2050707@oracle.com> References: <50AE334A.604@oracle.com> <50B382F0.2050707@oracle.com> Message-ID: <50B483E3.3050301@oracle.com> On 11/26/2012 03:55 PM, Coleen Phillimore wrote: > Looks fine from the runtime code. Thanks. > Someone from GC will have to review the GC code. John Coomes has now reviewed this, so I'm going to push this. thanks, StefanK > thanks, > Coleen > > On 11/22/2012 9:14 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8003720/webrev/ >> >> Description from CR: >> In virtual calls the Method pointer in the interpreter stack frame is >> not kept alive by anything other than the "this" pointers to that >> method. If bytecodes overwrite the "this" pointer, then call a full >> GC, the class loader containing the Method* can be unloaded and the >> Method* deallocated. >> >> This is also a problem with JSR292 MethodHandle static code because >> the MethodHandle containing the mirror for the interpreted method >> Method* is not on the stack if a GC occurs. >> >> Fix proposal: >> The "obvious" solution to this problem would be to apply the root >> scanning OopClosure to the Klass::_java_mirror field of the method in >> the interpreted frame. However, doing this might cause us to scan the >> same metadata oop location more than once, which is not allowed by >> some of the HotSpot GCs. We currently solve similar situations by >> always "claiming" and start scanning from the ClassLoaderData and >> then proceed down into the Klasses of that class loader. >> >> For this bug we do the same. All old collections, where class >> unloading can occur, pass down a closure that is applied to the >> ClassLoaderData of the Klass of the Method in the interpreted frame. >> This closure does the claiming and proceeds to scan the class >> metadata. Note that during young collections, where we don't do class >> unloading, all classes are already used as strong roots and we don't >> have to apply this new closure in the interpreted frame. >> >> Testing: >> The added test was initially written by John Rose. I only ported it >> to JTreg and made some artistic cleanups to it. >> >> thanks, >> StefanK > From forax at univ-mlv.fr Tue Nov 27 01:12:14 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Nov 2012 10:12:14 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> Message-ID: <50B483EE.7080406@univ-mlv.fr> On 11/26/2012 08:03 PM, Vitaly Davidovich wrote: > > Also, one useful (but more complex to implement presumably) feature > would be to pad array elements. I think this case of false sharing > comes up quite a bit so instead of doing manual padding, would be nice > to keep java code indexer arithmetic the same but have the > interpreter/JIT do the proper offsetting behind the scenes. > > Sent from my phone > There is an ongoing effort to try to add value type to Java. @Contented on a field of a value type will do exactly what you want. R?mi > On Nov 26, 2012 1:53 PM, "Vitaly Davidovich" > wrote: > > Personally, I'd leave out the class level annotation - I don't > think that case happens all that often. Can always add that > feature later if it turns out to be useful - it won't break > compatibility. > > Can you also please turn field layout printing into either a > product or diagnostic flag, if you didn't do that already? To > reduce clutter, perhaps one can specify type name(s) for which > this info should be shown - analogous to how disassembly allows this. > > Also, I assume heap walkers/profilers will report proper mem usage > for objects with padding? One caveat here would be that if padding > is applied but not somehow obvious in the tool, then the mental > math of how much the object should take up vs how much it actually > takes up may create some confusion. This may be more of a tool > problem in that they should perhaps indicate visibly instances > with @Contended fields. > > Sent from my phone > > On Nov 26, 2012 1:42 PM, "Aleksey Shipilev" > > > wrote: > > On 11/26/2012 09:35 PM, Remi Forax wrote: > > On 11/26/2012 05:44 PM, Aleksey Shipilev wrote: > >> On 11/26/2012 08:22 PM, Doug Lea wrote: > >>> One small suggestion to slightly appease the nanny-state > folks. > >>> How about burying the annotation one lever deeper to > >>> java.util.concurrent.atomic. > > > > +1 > > > > Still fail to see the rationale about this. > > > I think you should re-write the javadoc to not use 'hot' (hot -> > > optimize -> I should use it) and talk about false sharing > (with a > > link to the wikipedia article > > http://en.wikipedia.org/wiki/False_sharing). > > Yup, will do. > > > You should mention that marking @Contented a field which is not > > volatile is useless unless there is proper fences. > > Um. Actually, there is a lot of sense with marking plain > fields with > @Contended, especially when visibility is guaranteed > elsewhere. You > probably mean "marking the field @Contended does not turn it into > volatile"? ...does it really worth mentioning? > > > And also mention that it may consume a lot of memory thus it > should > > only be used if there is a known issue. > > Yes, good idea. > > > Also, I'm not in favour of allowing to use @Contented on > class, if > > you want all fields to be marked as @Contented, just mark > them as is. > > Given that this annotation is here to solve a corner case, > using the > > annotation in a class wide way in my opinion a door open to > stupid > > usages. You don't mark a class volatile if all their fields are > > volatile. > > >From the layout perspective, class-level @Contended is > equivalent to > all-field @Contended with the same contention group. Do you > think we > don't need this ask the shortcut for tuple/value/struct classes? > > I.e. > > @Contended > public class ValueClass { > private int field1; > private int field2; > private int field3; > private int field4; > } > > is the shortcut for: > > public class ValueClass { > @Contended("theSame") private int field1; > @Contended("theSame") private int field2; > @Contended("theSame") private int field3; > @Contended("theSame") private int field4; > } > > That is, all the fields would be densely-packed, but will be > padded as > the group. Note that it is not the same as: > > public class ValueClass { > @Contended private int field1; > @Contended private int field2; > @Contended private int field3; > @Contended private int field4; > } > > Maybe that is already confusing enough to drop class-level > annotation? > What do others feel about this? > > -Aleksey. > From forax at univ-mlv.fr Tue Nov 27 01:17:37 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Nov 2012 10:17:37 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B40739.10709@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> <50B40739.10709@cs.oswego.edu> Message-ID: <50B48531.5050606@univ-mlv.fr> On 11/27/2012 01:20 AM, Doug Lea wrote: > On 11/26/12 14:08, Doug Lea wrote: > >>> >>>> I think you should re-write the javadoc ... >> >> The Contended.java file and its javadoc in Aleksey's webrev is just a >> placeholder to get things moving. We expect to solicit >> reviews in the usual way (mainly on concurrency-interest list) >> for a version that will make it into JDK8. Ok, cool. Could you add that @Contented doesn't imply volatile and that the space overhead can be really big ? cheers, R?mi > > The initial javadoc is pasted below; > updates will appear in jsr166 CVS viewable at: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Contended.java?view=log > > > /** > * An annotation expressing that objects and/or their fields are > * expected to encounter memory contention, generally in the form of > * "false sharing". This annotation serves as a hint that such objects > * and fields should reside in locations isolated from those of other > * objects or fields. The effects of this annotation will nearly > * always add space overhead to programs. Its use is warranted only > * when the performance impact of this time/space tradeoff is > * intrinsically worthwhile; for example, in concurrent contexts in > * which each instance of the annotated object is often accessed by a > * different thread. > * > *

A {@code @Contended} field annotation may optionally include a > * contention group tag. All fields with the same tag are considered > * as a group with respect to isolation from other groups. A default > * annotation without a tag indicates contention with all other > * fields, including other {@code @Contended} ones. > > *

When the annotation is used at the class level, all unannotated > * fields of the object are considered to be in the same default > * group, separate from any fields that carry their own (possibly > * tagged) {@code @Contended} annotations. > * > *

Sample Usages. (Forthcoming.) > * > * @since 1.8 > */ From kirk at kodewerk.com Tue Nov 27 01:27:42 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 27 Nov 2012 10:27:42 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B48531.5050606@univ-mlv.fr> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> <50B40739.10709@cs.oswego.edu> <50B48531.5050606@univ-mlv.fr> Message-ID: <1ABD0404-8D84-4C7D-B6B6-C553D40E1E06@kodewerk.com> and that marking contented fields that aren't contented is potentially counter productive????? And maybe some hints as to how to determine if fields are contented in a run time environment? -- Kirk On 2012-11-27, at 10:17 AM, Remi Forax wrote: > On 11/27/2012 01:20 AM, Doug Lea wrote: >> On 11/26/12 14:08, Doug Lea wrote: >> >>>> >>>>> I think you should re-write the javadoc ... >>> >>> The Contended.java file and its javadoc in Aleksey's webrev is just a >>> placeholder to get things moving. We expect to solicit >>> reviews in the usual way (mainly on concurrency-interest list) >>> for a version that will make it into JDK8. > > Ok, cool. > Could you add that @Contented doesn't imply volatile and that the space overhead can be really big ? > > cheers, > R?mi > >> >> The initial javadoc is pasted below; >> updates will appear in jsr166 CVS viewable at: >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Contended.java?view=log >> >> /** >> * An annotation expressing that objects and/or their fields are >> * expected to encounter memory contention, generally in the form of >> * "false sharing". This annotation serves as a hint that such objects >> * and fields should reside in locations isolated from those of other >> * objects or fields. The effects of this annotation will nearly >> * always add space overhead to programs. Its use is warranted only >> * when the performance impact of this time/space tradeoff is >> * intrinsically worthwhile; for example, in concurrent contexts in >> * which each instance of the annotated object is often accessed by a >> * different thread. >> * >> *

A {@code @Contended} field annotation may optionally include a >> * contention group tag. All fields with the same tag are considered >> * as a group with respect to isolation from other groups. A default >> * annotation without a tag indicates contention with all other >> * fields, including other {@code @Contended} ones. >> >> *

When the annotation is used at the class level, all unannotated >> * fields of the object are considered to be in the same default >> * group, separate from any fields that carry their own (possibly >> * tagged) {@code @Contended} annotations. >> * >> *

Sample Usages. (Forthcoming.) >> * >> * @since 1.8 >> */ > From kirk at kodewerk.com Tue Nov 27 01:35:41 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 27 Nov 2012 10:35:41 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B48063.9060707@univ-mlv.fr> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B3BE1C.2040207@cs.oswego.edu> <448B1ACA-9E81-4824-B329-C6436DF0BE1A@kodewerk.com> <604EDA6F-68AA-4D64-B483-64B9891EB46B@kodewerk.com> <50B48063.9060707@univ-mlv.fr> Message-ID: <6FF8D51F-4223-49C3-96EC-ABFB523DC528@kodewerk.com> On 2012-11-27, at 9:57 AM, Remi Forax wrote: > On 11/27/2012 07:33 AM, Kirk Pepperdine wrote: >> Hi Vitaly, >> >> My comment about unsafe was a bit tongue in cheek. If this is to be done, than it seems the sensible package would be j.u.c. As for mothering developers, this isn't about mothering developers, it's about moving forward in a way that fits with Java's way of doing thing. I still stand by my previous email that this"optimization" is unsfe (hence the pun). I'll start with some questions... how would a developer know when to apply this annotation. Or conversely, once applied, how would a developer know if the padding now was de-optimizing the run time? >> >> I'm sure that there are some (micro???) benchmarks (have they been published so we can look at them?) some where in Oracle that demonstrates which means this has been a very interesting and useful experiment. It has demonstrated that there is some value in somehow adapting code to deal with conditions that are specific to a particular runtime configuration. That said, Java has been about making difficult things reachable to average developers. HotSpot has been about adapting code to particular run time conditions. Thus I would argue that this annotation runs counter to both purposes. >> >> From a business perspective I'd be thrilled to have this annotation appear in the JDK. I've built tooling that nicely detects conditions when padding out a cache line would solve some degenerate condition such as false sharing. I'd be thrilled because the tooling is completely safe to run in a production environment and this annotation will create a very nice market for it. I which is exactly where it would need to run to properly detect the need or impact of the "optimization". t would replace all of the business I lost when CMS started to collected perm space by default. Ok, that was another tongue in cheek also because I did speak to Tony about all the field work I was doing just getting people to set two values to true. My point here is that if I have been able to develop this type of tooling it suggests that it is possible (in fact I'd argue some what easier) to develop it for the JVM. This way we would convert a difficult to understand, potentially fragile optimization into one that becomes adaptive to the runtime conditions that it finds it's self in. This is not full profiling in the traditional sense of profiling. It's targeted and it's cheap. >> >> So before dropping an annotation into the JDK that will be with us forever, I would suggest that we explore ways having the runtime detect and adapt. > > Does your tooling works with G1 ? It's hardware specific.. Linux only (so we can stick to pure Java) and it's only been tested on a limited number of Intel chips. As interesting as it is, we've unfortunately had to pull resources from that project in order to feed other efforts which means it's sitting for the moment waiting for attention. Regards, Kirk From dl at cs.oswego.edu Tue Nov 27 03:35:05 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 27 Nov 2012 06:35:05 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B482D5.9020108@univ-mlv.fr> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B482D5.9020108@univ-mlv.fr> Message-ID: <50B4A569.8000707@cs.oswego.edu> On 11/27/12 04:07, Remi Forax wrote: > A lot of people already uses classes from j.u.c, j.u.c.atomic is more exotic. > Given that @Contented is exotic too ... > And, as someone else noted, sun.misc (where Unsafe lives) is even more exotic, and has the audience of low-level/core developers that this targets. Placing it there would get us past all the concerns (that I honestly think are wrong) about sending the wrong message or precluding miraculous automation. So, how about we just live with it as follows: (I updated some of the javadoc wording but removed placeholder section on sample usages to added only (if ever) only after gaining more experience.) package sun.misc; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; /** * An annotation expressing that objects and/or their fields are * expected to encounter memory contention, generally in the form of * "false sharing". This annotation serves as a hint that such objects * and fields should reside in locations isolated from those of other * objects or fields. Susceptibility to memory contention is a * property of the intended usages of objects and fields, not their * types or qualifiers. The effects of this annotation will nearly * always add significant space overhead to objects. The use of * {@code @Contended} is warranted only when the performance impact of * this time/space tradeoff is intrinsically worthwhile; for example, * in concurrent contexts in which each instance of the annotated * object is often accessed by a different thread. * *

A {@code @Contended} field annotation may optionally include a * contention group tag. All fields with the same tag are considered * as a group with respect to isolation from other groups. A default * annotation without a tag indicates contention with all other * fields, including other {@code @Contended} ones. *

When the annotation is used at the class level, all unannotated * fields of the object are considered to be in the same default * group, separate from any fields that carry their own (possibly * tagged) {@code @Contended} annotations. * * @since 1.8 */ @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE}) public @interface Contended { /** * The (optional) contention group tag. */ String value() default ""; } From karen.kinnear at oracle.com Tue Nov 27 05:01:13 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 27 Nov 2012 08:01:13 -0500 Subject: Report a bug in HotSpot In-Reply-To: <50B43A2B.4070202@oracle.com> References: <50B3B524.60307@oracle.com> <50B43A2B.4070202@oracle.com> Message-ID: <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> Hi Kris, I would concur. And there is also an explicit intention to not slow down JNI transitions by having the JVM do extra work. The model is to have the JNI code restore a good state. Looks like we already have a flag that lets you know that you need to fix the jni code, so no need to add another way to do that. thanks, Karen On Nov 26, 2012, at 10:57 PM, David Holmes wrote: > Hi Kris, > > I think historically hotspot assumes/requires JNI code to be well behaved about these things. There have been some well known issues with FPU state in the past. I'm not that familiar with MMX so can't say whether it is reasonable for the VM to know when it has to do this kind of cleanup. > > David > > On 27/11/2012 4:29 AM, Krystal Mo wrote: >> Hi all, >> >> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't >> empty the FPU stack on return from JNI calls. His mail is included below. >> >> e.g. If a native function called via JNI is using MMX registers without >> emptying the FPU stack before returning, then after returning to Java >> the FPU stack will be in a bad state. >> >> The test case Xi gave is demonstrated here on JDK7u9, x86: >> https://gist.github.com/4148771 >> Running the example with -XX:+VerifyFPU shows what's going on. >> >> This test case shows the bug affecting 32-bit x86 version of HotSpot's >> interpreter. >> >> Not really familiar with how to file a bug on JBS yet, I'll file a bug >> to track this after I learn how to do it. >> >> Regards, >> Kris >> >> >> -------- Original Message -------- >> Subject: Fwd: Report a bug in HotSpot >> Date: Tue, 27 Nov 2012 02:02:59 +0800 >> From: Krystal Mok >> To: Krystal Mo >> >> >> >> ---------- Forwarded message ---------- >> From: Xi Yang >> Date: Tue, Nov 20, 2012 at 1:44 PM >> Subject: Report a bug in HotSpot >> To: Krystal Mok >> >> >> Hi, >> >> It looks like HotSpot does not do "emms" after backing from JNI. Here >> is the code to show the bug. Would you like to try the newest version? >> >> >> Hello.java >> class Hello { >> private static native void abc(); >> public static void main(String[] args) { >> System.out.println("I am main"); >> System.loadLibrary("Hello"); >> abc(); >> long a = 100; >> double b = (double)a; >> System.out.println("Double a is " + b); >> } >> } >> >> Hello.c >> #include >> #include >> >> JNIEXPORT void JNICALL >> Java_Hello_abc(JNIEnv *env, jclass cls) >> { >> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); >> unsigned int dummy; >> asm volatile("movd %%mm0, %0\n":"=r"(dummy)); >> printf("dummy is %x\n", dummy); >> } >> >> >> gcc -m32 -shared ./Hello.c -o ./libHello.so >> >> >> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello >> I am main >> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world >> dummy is 0 >> Double a is NaN >> >> >> $ /opt/jdk1.7.0/bin/java -version >> java version "1.7.0-ea" >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) >> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) >> >> >> From stefan.karlsson at oracle.com Tue Nov 27 05:13:28 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Nov 2012 14:13:28 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: References: <50AF640D.1050401@oracle.com> <50AF6A92.8080401@oracle.com> <50B314D1.2070409@oracle.com> Message-ID: <50B4BC78.1010105@oracle.com> On 11/26/2012 04:59 PM, Volker Simonis wrote: > On Mon, Nov 26, 2012 at 8:05 AM, Stefan Karlsson > wrote: >> On 2012-11-23 13:22, David Holmes wrote: >>> Hi Stefan, >>> >>> I never did like these. >>> >>> I have to wonder though, why isn't it "runtime/thread.hpp" that all the >>> client code #includes? >> Typically, you place inline functions in a inline.hpp file instead of the >> hpp. This helps reducing the number of unnecessary includes from spreading >> through out the code base. Only the users of the inline functions will >> include the inline.hpp file, and bring in the needed includes to implement >> the function. >> >> Preferably, you should only include inline.hpp files from other cpp files or >> other inline.hpp files. >> > This is indeed the glory theory. However even in your change, there > are still some .hpp files which include .inline.hpp files (e.g > abstractInterpreter.hpp includes thread.inline.hpp). The reason for this RFE was to remove the platform dependent includes, not to fix the includes of .inline.hpp files from .hpp files. However, I actually tried to remove all included of thread.inline.hpp from .hpp files, but I didn't proceed when I realized I had to change the includes for the ResourceMark. It would have been a too big change for this small RFE. > > Are there any plans to further clean this up (i.e. remove inline.hpp > includes from .hpp files) by either: Coleen created JDK-8003990 for that. thanks, StefanK > > 1a : move the methods from XXX.hpp which require implementations of > inline functions from AAA.inline.hpp to XXX.cpp if they are not > performance relevant (and include AAA.inline.hpp only in XXX.cpp). > > 1b : moving the methods from XXX.hpp which require implementations of > inline functions from AAA.inline.hpp to a newly created XXX.inline.hpp > if they are performance relevant (and include AAA.inline.hpp only in > XXX.inline.cpp). > > 1c : keep the implementation of methods in XXX.hpp which don't > require definitions of inline methods from ANY ".inline.hpp" (in this > case it may be still necessary to include .hpp files which have been > provided previously indirectly by the various ".inline.hpp" files) > > In general I would be in favour of such a change, but a quick search > (find hotspot/src/ -name "*.hpp" | grep -v "\.inline\.hpp" | xargs > grep ".inline.hpp" | awk -F ":" '{print $1;}' | sort -u | wc) reveals > that there are currently 74 ".hpp" files which include other > ".inline.hpp" files. So this would be a real huge change. > >>> And then why isn't it thread.hpp that includes the platform specific >>> header? >> >> In this specific case, there's an inline function in >> thread_solaris.inline.hpp that Thread::current() needs. >> >> StefanK >> >>> David >>> >>> On 23/11/2012 9:54 PM, Stefan Karlsson wrote: >>>> http://cr.openjdk.java.net/~stefank/8003935/webrev >>>> >>>> Today, whenever we use Thread::current() we have to all these lines: >>>> >>>> #include "runtime/thread.hpp" >>>> #ifdef TARGET_OS_FAMILY_linux >>>> # include "thread_linux.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_solaris >>>> # include "thread_solaris.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_windows >>>> # include "thread_windows.inline.hpp" >>>> #endif >>>> #ifdef TARGET_OS_FAMILY_bsd >>>> # include "thread_bsd.inline.hpp" >>>> #endif >>>> >>>> This patch hides this dispatching in a new file named thread.inline.hpp. >>>> Now we only have to include thread.inline.hpp. >>>> >>>> Some background to these includes: This type of dispatching was >>>> introduced into the source files when we removed the includeDB files. We >>>> discussed whether we should use "dispatch files" or not for this kind >>>> platform dependent includes. The decision was to not create dispatch >>>> files for all types of platform at that time, but instead manually >>>> create them when we thought it was warranted. >>>> >>>> thanks, >>>> StefanK >>>> >>>> From stefan.karlsson at oracle.com Tue Nov 27 05:20:13 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Nov 2012 14:20:13 +0100 Subject: Review request: 8003935: Simplify the needed includes for using Thread::current() In-Reply-To: <50AF640D.1050401@oracle.com> References: <50AF640D.1050401@oracle.com> Message-ID: <50B4BE0D.9000000@oracle.com> Thanks David, Rickard and Coleen for the reviews. StefanK On 11/23/2012 12:54 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8003935/webrev > > Today, whenever we use Thread::current() we have to all these lines: > > #include "runtime/thread.hpp" > #ifdef TARGET_OS_FAMILY_linux > # include "thread_linux.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_solaris > # include "thread_solaris.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_windows > # include "thread_windows.inline.hpp" > #endif > #ifdef TARGET_OS_FAMILY_bsd > # include "thread_bsd.inline.hpp" > #endif > > This patch hides this dispatching in a new file named > thread.inline.hpp. Now we only have to include thread.inline.hpp. > > Some background to these includes: This type of dispatching was > introduced into the source files when we removed the includeDB files. > We discussed whether we should use "dispatch files" or not for this > kind platform dependent includes. The decision was to not create > dispatch files for all types of platform at that time, but instead > manually create them when we thought it was warranted. > > thanks, > StefanK > > From jesper.wilhelmsson at oracle.com Tue Nov 27 05:52:32 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 27 Nov 2012 14:52:32 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B4A569.8000707@cs.oswego.edu> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu> Message-ID: <50B4C5A0.7050507@oracle.com> Looks good to me. Even though I would prefer not to add more stuff in sun.misc, but if that makes people happy I don't have a strong opinion. There are others that know language design better than me. What I do have an opinion about is garbage collection, and I have a potential future work question. Annotated fields and classes will be padded and require more memory. What would be the optimal behavior in an out of memory situation? Should the GC try to remove the padding to keep OOME away, or should we just accept that these objects are now larger and we are out of memory. Also, the current design adds twice the size of a normal cache line, one potential improvement could be to make sure that allocation and GC are aware of these padded fields and always place them at the start of a cache line and only pads as much as needed to fill the rest of the cache line. I'm not suggesting that this should be done now, it's quite a lot of work to get that working actually, but for future thoughts. Maybe something for a PhD student to look at ;-) /Jesper On 27/11/12 12:35 PM, Doug Lea wrote: > On 11/27/12 04:07, Remi Forax wrote: > >> A lot of people already uses classes from j.u.c, j.u.c.atomic is more >> exotic. >> Given that @Contented is exotic too ... >> > > And, as someone else noted, sun.misc (where Unsafe lives) is even > more exotic, and has the audience of low-level/core developers > that this targets. Placing it there would get us past all the > concerns (that I honestly think are wrong) about sending the > wrong message or precluding miraculous automation. So, how > about we just live with it as follows: > > (I updated some of the javadoc wording but removed placeholder > section on sample usages to added only (if ever) only after > gaining more experience.) > > > package sun.misc; > > import java.lang.annotation.ElementType; > import java.lang.annotation.Retention; > import java.lang.annotation.RetentionPolicy; > import java.lang.annotation.Target; > > /** > * An annotation expressing that objects and/or their fields are > * expected to encounter memory contention, generally in the form of > * "false sharing". This annotation serves as a hint that such objects > * and fields should reside in locations isolated from those of other > * objects or fields. Susceptibility to memory contention is a > * property of the intended usages of objects and fields, not their > * types or qualifiers. The effects of this annotation will nearly > * always add significant space overhead to objects. The use of > * {@code @Contended} is warranted only when the performance impact of > * this time/space tradeoff is intrinsically worthwhile; for example, > * in concurrent contexts in which each instance of the annotated > * object is often accessed by a different thread. > * > *

A {@code @Contended} field annotation may optionally include a > * contention group tag. All fields with the same tag are considered > * as a group with respect to isolation from other groups. A default > * annotation without a tag indicates contention with all other > * fields, including other {@code @Contended} ones. > > *

When the annotation is used at the class level, all unannotated > * fields of the object are considered to be in the same default > * group, separate from any fields that carry their own (possibly > * tagged) {@code @Contended} annotations. > * > * @since 1.8 > */ > @Retention(RetentionPolicy.RUNTIME) > @Target({ElementType.FIELD, ElementType.TYPE}) > public @interface Contended { > /** > * The (optional) contention group tag. > */ > String value() default ""; > } > > > > From aleksey.shipilev at oracle.com Tue Nov 27 05:59:14 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Nov 2012 17:59:14 +0400 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B4C5A0.7050507@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu> <50B4C5A0.7050507@oracle.com> Message-ID: <50B4C732.4040400@oracle.com> On 11/27/2012 05:52 PM, Jesper Wilhelmsson wrote: > Annotated fields and classes will be padded and require more memory. > What would be the optimal behavior in an out of memory situation? Should > the GC try to remove the padding to keep OOME away, or should we just > accept that these objects are now larger and we are out of memory. No can do. That means repackaging the field in existing classes forced by GC; this is impossible unless JEP-159 is here. > Also, the current design adds twice the size of a normal cache line, one > potential improvement could be to make sure that allocation and GC are > aware of these padded fields and always place them at the start of a > cache line and only pads as much as needed to fill the rest of the cache > line. Yes, that was the inclination we are considering. We are padding in both directions because we miss the GC interop at this point. This can be added non-disruptively after the fact. -Aleksey. From david.r.chase at oracle.com Tue Nov 27 06:17:18 2012 From: david.r.chase at oracle.com (David Chase) Date: Tue, 27 Nov 2012 09:17:18 -0500 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <50B4C5A0.7050507@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu> <50B4C5A0.7050507@oracle.com> Message-ID: <3553E29C-3BCD-4944-893E-DA810378A456@oracle.com> On 2012-11-27, at 8:52 AM, Jesper Wilhelmsson wrote: > What I do have an opinion about is garbage collection, and I have a potential future work question. > > Annotated fields and classes will be padded and require more memory. What would be the optimal behavior in an out of memory situation? Should the GC try to remove the padding to keep OOME away, or should we just accept that these objects are now larger and we are out of memory. I think it might be useful to play with the feature for a little while to get some feel for how much of a heap can be "contended" before we worry too much about this. My off-the-cuff reaction is that if it is not in the cache, then it is not really contended, and how big is the cache compared to main memory? Imagine a gigabyte heap and a megabyte cache -- that's only one part in 1000. We might want to measure first. David From jesper.wilhelmsson at oracle.com Tue Nov 27 06:31:45 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 27 Nov 2012 15:31:45 +0100 Subject: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields In-Reply-To: <3553E29C-3BCD-4944-893E-DA810378A456@oracle.com> References: <50AE9A34.4020001@oracle.com> <50B39562.8070004@oracle.com> <50B39751.1080203@cs.oswego.edu> <50B39C83.6010801@oracle.com> <50B3A874.4090306@univ-mlv.fr> <50B3B79C.2050509@oracle.com> <50B482D5.9020108@univ-mlv.fr> <50B4A569.8000707@cs.oswego.edu> <50B4C5A0.7050507@oracle.com> <3553E29C-3BCD-4944-893E-DA810378A456@oracle.com> Message-ID: <50B4CED1.90801@oracle.com> On 27/11/12 3:17 PM, David Chase wrote: > On 2012-11-27, at 8:52 AM, Jesper Wilhelmsson wrote: >> What I do have an opinion about is garbage collection, and I have a potential future work question. >> >> Annotated fields and classes will be padded and require more memory. What would be the optimal behavior in an out of memory situation? Should the GC try to remove the padding to keep OOME away, or should we just accept that these objects are now larger and we are out of memory. > I think it might be useful to play with the feature for a little while to get some feel for how much of a heap can be "contended" before we worry too much about this. My off-the-cuff reaction is that if it is not in the cache, then it is not really contended, and how big is the cache compared to main memory? Imagine a gigabyte heap and a megabyte cache -- that's only one part in 1000. We might want to measure first. You are absolutely right. It was just a random thought. This would be more of a saftey catch for people who sprinkle their code with annotations without knowing what they are doing. OOMEs probably won't be their biggest concern though. And I'm actually fine with allowing for the trigger happy developer to shoot his or her foot :-) /Jesper From coleen.phillimore at oracle.com Tue Nov 27 06:53:49 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 27 Nov 2012 09:53:49 -0500 Subject: Report a bug in HotSpot In-Reply-To: <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> References: <50B3B524.60307@oracle.com> <50B43A2B.4070202@oracle.com> <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> Message-ID: <50B4D3FD.4050406@oracle.com> We have this flag for this problem: product(bool, AlwaysRestoreFPU, false, \ "Restore the FPU control word after every JNI call (expensive)") \ \ Coleen On 11/27/2012 08:01 AM, Karen Kinnear wrote: > Hi Kris, > > I would concur. And there is also an explicit intention to not slow down JNI transitions by having the JVM do extra work. The > model is to have the JNI code restore a good state. > > Looks like we already have a flag that lets you know that you need to fix the jni code, so no need to add another way to do that. > > thanks, > Karen > > On Nov 26, 2012, at 10:57 PM, David Holmes wrote: > >> Hi Kris, >> >> I think historically hotspot assumes/requires JNI code to be well behaved about these things. There have been some well known issues with FPU state in the past. I'm not that familiar with MMX so can't say whether it is reasonable for the VM to know when it has to do this kind of cleanup. >> >> David >> >> On 27/11/2012 4:29 AM, Krystal Mo wrote: >>> Hi all, >>> >>> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't >>> empty the FPU stack on return from JNI calls. His mail is included below. >>> >>> e.g. If a native function called via JNI is using MMX registers without >>> emptying the FPU stack before returning, then after returning to Java >>> the FPU stack will be in a bad state. >>> >>> The test case Xi gave is demonstrated here on JDK7u9, x86: >>> https://gist.github.com/4148771 >>> Running the example with -XX:+VerifyFPU shows what's going on. >>> >>> This test case shows the bug affecting 32-bit x86 version of HotSpot's >>> interpreter. >>> >>> Not really familiar with how to file a bug on JBS yet, I'll file a bug >>> to track this after I learn how to do it. >>> >>> Regards, >>> Kris >>> >>> >>> -------- Original Message -------- >>> Subject: Fwd: Report a bug in HotSpot >>> Date: Tue, 27 Nov 2012 02:02:59 +0800 >>> From: Krystal Mok >>> To: Krystal Mo >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Xi Yang >>> Date: Tue, Nov 20, 2012 at 1:44 PM >>> Subject: Report a bug in HotSpot >>> To: Krystal Mok >>> >>> >>> Hi, >>> >>> It looks like HotSpot does not do "emms" after backing from JNI. Here >>> is the code to show the bug. Would you like to try the newest version? >>> >>> >>> Hello.java >>> class Hello { >>> private static native void abc(); >>> public static void main(String[] args) { >>> System.out.println("I am main"); >>> System.loadLibrary("Hello"); >>> abc(); >>> long a = 100; >>> double b = (double)a; >>> System.out.println("Double a is " + b); >>> } >>> } >>> >>> Hello.c >>> #include >>> #include >>> >>> JNIEXPORT void JNICALL >>> Java_Hello_abc(JNIEnv *env, jclass cls) >>> { >>> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); >>> unsigned int dummy; >>> asm volatile("movd %%mm0, %0\n":"=r"(dummy)); >>> printf("dummy is %x\n", dummy); >>> } >>> >>> >>> gcc -m32 -shared ./Hello.c -o ./libHello.so >>> >>> >>> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello >>> I am main >>> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world >>> dummy is 0 >>> Double a is NaN >>> >>> >>> $ /opt/jdk1.7.0/bin/java -version >>> java version "1.7.0-ea" >>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) >>> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) >>> >>> >>> From krystal.mo at oracle.com Tue Nov 27 06:59:08 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 27 Nov 2012 22:59:08 +0800 Subject: Report a bug in HotSpot In-Reply-To: <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> References: <50B3B524.60307@oracle.com> <50B43A2B.4070202@oracle.com> <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> Message-ID: <50B4D53C.3090900@oracle.com> Hi David and Karen, Thanks for the reply. I don't have a strong opinion on whether this should be viewed as a "bug" and fixed, just forwarding concerns from Xi Yang. Perhaps Xi would like to explain his rationales for having such concerns in the first place. There's a follow up on the test case: Xi provided a modified test case that would affect amd64 as well: class Hello { private static native void abc(); public static void main(String[] args) { System.out.println("I am main"); System.loadLibrary("hello"); abc(); long a = 100; double b = (double)a; double c = 3.14; System.out.println("Double a%c is " + a%c); } } Even though HotSpot's interpreter doesn't use the FPU stack itself, the "drem" bytecode instruction is implemented with a call to SharedRuntime::drem(double,double), which uses the FPU and thus affected by dirty FPU stack: Dump of assembler code for function _ZN13SharedRuntime4dremEdd: 0x00007ffff6e8d790 <+0>: push %rbp 0x00007ffff6e8d791 <+1>: mov %rsp,%rbp 0x00007ffff6e8d794 <+4>: sub $0x10,%rsp 0x00007ffff6e8d798 <+8>: movsd %xmm0,-0x10(%rbp) 0x00007ffff6e8d79d <+13>: fldl -0x10(%rbp) 0x00007ffff6e8d7a0 <+16>: movsd %xmm1,-0x10(%rbp) 0x00007ffff6e8d7a5 <+21>: fldl -0x10(%rbp) 0x00007ffff6e8d7a8 <+24>: fld %st(1) 0x00007ffff6e8d7aa <+26>: fld %st(1) 0x00007ffff6e8d7ac <+28>: fxch %st(1) 0x00007ffff6e8d7ae <+30>: fprem 0x00007ffff6e8d7b0 <+32>: fnstsw %ax 0x00007ffff6e8d7b2 <+34>: test $0x4,%ah 0x00007ffff6e8d7b5 <+37>: jne 0x7ffff6e8d7ae 0x00007ffff6e8d7b7 <+39>: fstp %st(1) 0x00007ffff6e8d7b9 <+41>: fstpl -0x8(%rbp) 0x00007ffff6e8d7bc <+44>: movsd -0x8(%rbp),%xmm0 0x00007ffff6e8d7c1 <+49>: ucomisd %xmm0,%xmm0 0x00007ffff6e8d7c5 <+53>: jp 0x7ffff6e8d7d0 0x00007ffff6e8d7c7 <+55>: jne 0x7ffff6e8d7d0 0x00007ffff6e8d7c9 <+57>: fstp %st(0) 0x00007ffff6e8d7cb <+59>: fstp %st(0) 0x00007ffff6e8d7cd <+61>: leaveq 0x00007ffff6e8d7ce <+62>: retq 0x00007ffff6e8d7cf <+63>: nop 0x00007ffff6e8d7d0 <+64>: fstpl -0x10(%rbp) 0x00007ffff6e8d7d3 <+67>: movsd -0x10(%rbp),%xmm1 0x00007ffff6e8d7d8 <+72>: fstpl -0x10(%rbp) 0x00007ffff6e8d7db <+75>: movsd -0x10(%rbp),%xmm0 0x00007ffff6e8d7e0 <+80>: callq 0x7ffff6857fa8 0x00007ffff6e8d7e5 <+85>: leaveq 0x00007ffff6e8d7e6 <+86>: retq (disassembly from JDK7u9 on Ubuntu 12.04, amd64) I had a partial fix to this problem in x86: diff -r fb2d98043048 src/cpu/x86/vm/sharedRuntime_x86_32.cpp --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp Fri Sep 14 15:00:02 2012 -0700 +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp Tue Nov 27 20:59:44 2012 +0800 @@ -2054,10 +2054,15 @@ // no exception, we're almost done - // check that only result value is on FPU stack - __ verify_FPU(ret_type == T_FLOAT || ret_type == T_DOUBLE ? 1 : 0, "native_wrapper normal exit"); - - // Fixup floating pointer results so that result looks like a return from a compiled method + // Check that only result value is on FPU stack for floating point return type, + // Empty the FPU stack otherwise, just in case it was left dirty by the native call. + if (ret_type == T_FLOAT || ret_type == T_DOUBLE) { + __ verify_FPU(1, "native_wrapper normal exit"); + } else { + __ empty_FPU_stack(); + } + + // Fixup floating point results so that result looks like a return from a compiled method if (ret_type == T_FLOAT) { if (UseSSE >= 1) { // Pop st0 and store as float and reload into xmm register diff -r fb2d98043048 src/cpu/x86/vm/templateInterpreter_x86_32.cpp --- a/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Fri Sep 14 15:00:02 2012 -0700 +++ b/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Tue Nov 27 20:59:44 2012 +0800 @@ -1119,6 +1119,10 @@ __ bind(L); } __ push(ltos); + + // Clear FPU stack here, just in case the native call left it dirty. + // It's safe since the potential result is saved already. + __ empty_FPU_stack(); // change thread state __ get_thread(thread); (diff against tip of hsx/hsx23.6) This patch empties the FPU stack upon return from the native call, in both the native entry for the interpter and the native wrapper for compiled code. It's straightforward to do in the interpreter native entry case, because the FPU stack is supposed to be empty at that point anyway; it's not so straightforward for the native wrapper case, because there's potential return value left in st(0). I could pop st(0) to the stack, empty the FPU stack, and then restore the return value to st(0), but I haven't done so in this patch yet, since it'd be weird to return a floating point result with a dirty FPU stack anyway. Regards, Kris On 11/27/2012 09:01 PM, Karen Kinnear wrote: > Hi Kris, > > I would concur. And there is also an explicit intention to not slow down JNI transitions by having the JVM do extra work. The > model is to have the JNI code restore a good state. > > Looks like we already have a flag that lets you know that you need to fix the jni code, so no need to add another way to do that. > > thanks, > Karen > > On Nov 26, 2012, at 10:57 PM, David Holmes wrote: > >> Hi Kris, >> >> I think historically hotspot assumes/requires JNI code to be well behaved about these things. There have been some well known issues with FPU state in the past. I'm not that familiar with MMX so can't say whether it is reasonable for the VM to know when it has to do this kind of cleanup. >> >> David >> >> On 27/11/2012 4:29 AM, Krystal Mo wrote: >>> Hi all, >>> >>> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't >>> empty the FPU stack on return from JNI calls. His mail is included below. >>> >>> e.g. If a native function called via JNI is using MMX registers without >>> emptying the FPU stack before returning, then after returning to Java >>> the FPU stack will be in a bad state. >>> >>> The test case Xi gave is demonstrated here on JDK7u9, x86: >>> https://gist.github.com/4148771 >>> Running the example with -XX:+VerifyFPU shows what's going on. >>> >>> This test case shows the bug affecting 32-bit x86 version of HotSpot's >>> interpreter. >>> >>> Not really familiar with how to file a bug on JBS yet, I'll file a bug >>> to track this after I learn how to do it. >>> >>> Regards, >>> Kris >>> >>> >>> -------- Original Message -------- >>> Subject: Fwd: Report a bug in HotSpot >>> Date: Tue, 27 Nov 2012 02:02:59 +0800 >>> From: Krystal Mok >>> To: Krystal Mo >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Xi Yang >>> Date: Tue, Nov 20, 2012 at 1:44 PM >>> Subject: Report a bug in HotSpot >>> To: Krystal Mok >>> >>> >>> Hi, >>> >>> It looks like HotSpot does not do "emms" after backing from JNI. Here >>> is the code to show the bug. Would you like to try the newest version? >>> >>> >>> Hello.java >>> class Hello { >>> private static native void abc(); >>> public static void main(String[] args) { >>> System.out.println("I am main"); >>> System.loadLibrary("Hello"); >>> abc(); >>> long a = 100; >>> double b = (double)a; >>> System.out.println("Double a is " + b); >>> } >>> } >>> >>> Hello.c >>> #include >>> #include >>> >>> JNIEXPORT void JNICALL >>> Java_Hello_abc(JNIEnv *env, jclass cls) >>> { >>> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); >>> unsigned int dummy; >>> asm volatile("movd %%mm0, %0\n":"=r"(dummy)); >>> printf("dummy is %x\n", dummy); >>> } >>> >>> >>> gcc -m32 -shared ./Hello.c -o ./libHello.so >>> >>> >>> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello >>> I am main >>> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world >>> dummy is 0 >>> Double a is NaN >>> >>> >>> $ /opt/jdk1.7.0/bin/java -version >>> java version "1.7.0-ea" >>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) >>> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) >>> >>> >>> From frederic.parain at oracle.com Tue Nov 27 07:04:25 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 27 Nov 2012 16:04:25 +0100 Subject: CFV: New HSX Committer: Harold Seigel In-Reply-To: <50A6B168.60000@oracle.com> References: <50A6B168.60000@oracle.com> Message-ID: <50B4D679.7060805@oracle.com> Vote: yes Fred On 11/16/12 10:34 PM, Coleen Phillimore wrote: > I hereby nominate Harold Seigel (OpenJDK user name: hseigel) to HSX > Committer. > > Harold is a member of the Hotspot runtime group. He has contributed 10 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=harold.seigel at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=hseigel > > Votes are due by Nov 30, 2012. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Coleen Phillimore > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > > (resend with corrected title, please reply again) -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From krystal.mo at oracle.com Tue Nov 27 07:20:59 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 27 Nov 2012 23:20:59 +0800 Subject: Report a bug in HotSpot In-Reply-To: <50B4D3FD.4050406@oracle.com> References: <50B3B524.60307@oracle.com> <50B43A2B.4070202@oracle.com> <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> <50B4D3FD.4050406@oracle.com> Message-ID: <50B4DA5B.5060603@oracle.com> Hi Coleen, Thank you for the reply. Yes, I know that flag, but it doesn't fix the problem demonstrated in the first test case. Running that test case with this flag will still show "Double a is NaN" on 32-bit JDK7u9 on Ubuntu 12.04. It's not about the FPU control word. Regards, Kris On 2012/11/27 22:53, Coleen Phillimore wrote: > > We have this flag for this problem: > > product(bool, AlwaysRestoreFPU, > false, \ > "Restore the FPU control word after every JNI call > (expensive)") \ > \ > > Coleen > > On 11/27/2012 08:01 AM, Karen Kinnear wrote: >> Hi Kris, >> >> I would concur. And there is also an explicit intention to not slow >> down JNI transitions by having the JVM do extra work. The >> model is to have the JNI code restore a good state. >> >> Looks like we already have a flag that lets you know that you need to >> fix the jni code, so no need to add another way to do that. >> >> thanks, >> Karen >> >> On Nov 26, 2012, at 10:57 PM, David Holmes wrote: >> >>> Hi Kris, >>> >>> I think historically hotspot assumes/requires JNI code to be well >>> behaved about these things. There have been some well known issues >>> with FPU state in the past. I'm not that familiar with MMX so can't >>> say whether it is reasonable for the VM to know when it has to do >>> this kind of cleanup. >>> >>> David >>> >>> On 27/11/2012 4:29 AM, Krystal Mo wrote: >>>> Hi all, >>>> >>>> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't >>>> empty the FPU stack on return from JNI calls. His mail is included >>>> below. >>>> >>>> e.g. If a native function called via JNI is using MMX registers >>>> without >>>> emptying the FPU stack before returning, then after returning to Java >>>> the FPU stack will be in a bad state. >>>> >>>> The test case Xi gave is demonstrated here on JDK7u9, x86: >>>> https://gist.github.com/4148771 >>>> Running the example with -XX:+VerifyFPU shows what's going on. >>>> >>>> This test case shows the bug affecting 32-bit x86 version of HotSpot's >>>> interpreter. >>>> >>>> Not really familiar with how to file a bug on JBS yet, I'll file a bug >>>> to track this after I learn how to do it. >>>> >>>> Regards, >>>> Kris >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Fwd: Report a bug in HotSpot >>>> Date: Tue, 27 Nov 2012 02:02:59 +0800 >>>> From: Krystal Mok >>>> To: Krystal Mo >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Xi Yang >>>> Date: Tue, Nov 20, 2012 at 1:44 PM >>>> Subject: Report a bug in HotSpot >>>> To: Krystal Mok >>>> >>>> >>>> Hi, >>>> >>>> It looks like HotSpot does not do "emms" after backing from JNI. Here >>>> is the code to show the bug. Would you like to try the newest version? >>>> >>>> >>>> Hello.java >>>> class Hello { >>>> private static native void abc(); >>>> public static void main(String[] args) { >>>> System.out.println("I am main"); >>>> System.loadLibrary("Hello"); >>>> abc(); >>>> long a = 100; >>>> double b = (double)a; >>>> System.out.println("Double a is " + b); >>>> } >>>> } >>>> >>>> Hello.c >>>> #include >>>> #include >>>> >>>> JNIEXPORT void JNICALL >>>> Java_Hello_abc(JNIEnv *env, jclass cls) >>>> { >>>> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); >>>> unsigned int dummy; >>>> asm volatile("movd %%mm0, %0\n":"=r"(dummy)); >>>> printf("dummy is %x\n", dummy); >>>> } >>>> >>>> >>>> gcc -m32 -shared ./Hello.c -o ./libHello.so >>>> >>>> >>>> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello >>>> I am main >>>> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world >>>> dummy is 0 >>>> Double a is NaN >>>> >>>> >>>> $ /opt/jdk1.7.0/bin/java -version >>>> java version "1.7.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) >>>> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) >>>> >>>> >>>> > From bill.pittore at oracle.com Tue Nov 27 07:49:09 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Tue, 27 Nov 2012 10:49:09 -0500 Subject: Official reviewer needed: Review request for fix for 7200297: agent code does not handle multiple dll_dir paths correctly In-Reply-To: <50B427A2.8050809@oracle.com> References: <50A41AEA.8050705@oracle.com> <50A4AF33.2020208@oracle.com> <50A5420A.7030502@oracle.com> <50A54734.6000608@oracle.com> <50A6A18C.1070206@oracle.com> <50AAA04A.70408@oracle.com> <50ACA54E.7020608@oracle.com> <50AD2C2A.8000401@oracle.com> <50AE1FEC.9030506@oracle.com> <50B3AAA5.9040401@oracle.com> <50B427A2.8050809@oracle.com> Message-ID: <50B4E0F5.5070702@oracle.com> Thanks David for the review. On 11/26/2012 9:38 PM, David Holmes wrote: > Hi Bill, > > A few minor comments, some of which you've touched on with Dmitry. > > David > ------ > > > share/back/debugInit.c > > 40 #include "sys.h" > > Shouldn't that be ? > No, it's really "sys.h" -> jdk/src/share/back/export/sys.h: > --- > > src/share/back/transport.c > > * Note: Java property sun.boot.library.path contains a single > directory. > + * Note: Above incorrect since 6819213 fixed. Dll_dir is the > first entry > + * and -Dsun.boot.library.path entries are appended. > > Better to just change the original comment than to keep it and say it > isn't true. > Fixed. > --- > > src/solaris/back/linker_md.c > > 113 return; > > Adding the return is superfluous. Arguably the whole method should be > a chained if-else with no returns. Stylistically you have now mixed > styles: either use a return, or use an else, but not both. > Removed the return. > --- > > src/solaris/demo/jvmti/hprof/hprof_md.c > > 426 return; > > Same comment as for linker_md.c > > And why didn't you move *holder = '\0'; in this version? Fixed both issues. > > Ditto src/windows/demo/jvmti/hprof/hprof_md.c Fixed. > > --- > > src/windows/back/linker_md.c > > 123 return; > > Ditto previous comments. > Fixed. Updated webrev http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ Running nsk tests. bill > --- > > > On 27/11/2012 3:45 AM, BILL PITTORE wrote: >> Have a couple of reviews but still need official reviewer to pass >> muster. >> >> thanks, >> bill >> >> >> >> On 11/22/2012 7:51 AM, Dmitry Samersoff wrote: >>> Bill, >>> >>> Looks good for me. >>> >>> -Dmitry >>> >>> On 2012-11-21 23:31, BILL PITTORE wrote: >>>> Hi Dmitry, >>>> >>>> On 11/21/2012 4:56 AM, Dmitry Samersoff wrote: >>>>> Bill, >>>>> >>>>> >>>>> Few nits: >>>>> >>>>> 1. >>>>> >>>>> dll_build_name is exactly the same for all locations could we >>>>> place it >>>>> to some common place? >>>> It looked somewhat intentional to have the agents and the hprof >>>> code be >>>> self-contained. I looked at using a common file but the makefile >>>> changes >>>> and source tree changes seemed a bit much. Hprof code is "unsupported >>>> demo" code and jdwp is supported agent so I went with the current >>>> scheme >>>> of having the code be self-contained. >>>>> Also file_exists is not necessary and could be >>>>> replaced with just ::access(buffer,R_OK) (Windows has it as well) >>>> I'll go with the access suggestion above, less code. >>>>> but if you prefer to keep it: >>>>> >>>>> strlen(filename)==0 could be a *filename == 0 >>>>> >>>>> >>>>> 2. We don't need else after return in all *_md.c files >>>>> e.g. linker_md.c:122 >>>> Semantically, you're correct. I think in terms of code readability I >>>> like the 'else' since it makes it clear to the reader that there >>>> are two >>>> different cases. C compiler will 'do the right thing'. >>>> Updated the webrev at >>>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.03/ >>>> >>>> thanks, >>>> bill >>>>> Otherwise looks good. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2012-11-20 01:10, BILL PITTORE wrote: >>>>>> Have gotten reviews from Serguei Spitsyn for the changes, made some >>>>>> improvements and need an official reviewer to check it out. >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.02 >>>>>> >>>>>> thanks, >>>>>> bill >>>>>> >>>>>> >>>>>> >>>>>> On 11/14/2012 5:27 PM, bill.pittore at oracle.com wrote: >>>>>>> This bug has to do with the jdwp and hprof agents not parsing the >>>>>>> sun.boot.library.path (dll_dir) correctly since the fix for 6819213 >>>>>>> went in some years ago. This bug popped up while working on a >>>>>>> particular platform that does not have the ability to set >>>>>>> LD_LIBRARY_PATH before running the VM. As documented in the bug, on >>>>>>> most platforms even if the sun.boot.library.path consists of >>>>>>> multiple >>>>>>> paths and the jdwp or hprof code fails to load a dependent lib, the >>>>>>> system falls back to using LD_LIBRARY_PATH so the failure is >>>>>>> masked. >>>>>>> On some other platforms, this failover doesn't exist so we get an >>>>>>> error when trying to load jdwp and hprof dependent libs. >>>>>>> >>>>>>> Some notes on a couple of files. >>>>>>> * >>>>>>> debugInit.c, hprof_init.c*: >>>>>>> Rearranged the init order so that the jvmti pointer gets >>>>>>> initialized >>>>>>> before attempting to load the npt shared library. >>>>>>> >>>>>>> *linker_md.c, hprof_md.c* >>>>>>> Much of the platform code in hprof and jdwp is duplicated and this >>>>>>> change is no different. Based on the code in hotspot >>>>>>> os_solaris/windows.cpp it parses the boot library path and >>>>>>> attempts to >>>>>>> find the library. >>>>>>> * >>>>>>> error_messages.c* >>>>>>> Fixed a bug in the error message code that blindly dereferenced the >>>>>>> npt pointer even if it wasn't set because of an error in loading. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~bpittore/7200297/webrev.00/ >>>>>>> >>>>>>> Ran the ute nsk/jdwp nsk/jvmti nsk/hprof tests, the JCK jdwp/jvmti >>>>>>> tests and some command line testing on windows and linux. >>>>>>> >>>>>>> thanks, >>>>>>> bill >>>>>>> >>>>>>> >>> >> >> From rkennke at redhat.com Tue Nov 27 09:24:26 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 27 Nov 2012 18:24:26 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> Message-ID: <1354037066.29268.10.camel@mercury> Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: > On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > > > Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > >> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > >> > >>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >>>> > >>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>>>> > >>>>>>> > >>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>>>> > >>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>>>> > >>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi there, > >>>>>>>>>>>> > >>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>>>> Here are some details: > >>>>>>>>>>>> > >>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>>>> changes in LLVM. > >>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>>>> nicer. > >>>>>>>>>>>> > >>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>>>> bunch of other stuff. > >>>>>>>>>>>> > >>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>>>> can find the full webrev here: > >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>>>> > >>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>>>> > >>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>>>> > >>>>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>>>> > >>>>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>>>> > >>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>>>> > >>>>>>>>>>> -- Chris > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>>>> > >>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>>>> > >>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>>>> > >>>>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>>>> integrated into Hotspot. > >>>>>>>>>> > >>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>>>> > >>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>>>> > >>>>>>>>>> and: > >>>>>>>>>> > >>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>>>> > >>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>>>> > >>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>>>> using the build script that I provided? > >>>>>>>> > >>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>>>> > >>>>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>>>> > >>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>>>> > >>>>>>>> It's probably this guy: -Wcast-qual > >>>>>>> > >>>>>>> Got it: > >>>>>>> > >>>>>>> $ java -version > >>>>>>> java version "1.8.0-ea" > >>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>>>> > >>>>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>>>> > >>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>>>> Passed: compiler/5091921/Test5091921.java > >>>>>> Passed: compiler/5091921/Test6186134.java > >>>>>> Passed: compiler/5091921/Test6196102.java > >>>>>> Passed: compiler/5091921/Test6357214.java > >>>>>> Passed: compiler/5091921/Test6559156.java > >>>>>> Passed: compiler/5091921/Test6753639.java > >>>>>> Passed: compiler/5091921/Test6850611.java > >>>>>> Passed: compiler/5091921/Test6890943.java > >>>>>> Passed: compiler/5091921/Test6897150.java > >>>>>> Passed: compiler/5091921/Test6905845.java > >>>>>> Passed: compiler/5091921/Test6931567.java > >>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>>>> > >>>>>> You can also run all them with a simple make in test/ by setting: > >>>>>> > >>>>>> PRODUCT_HOME=$JAVA_HOME > >>>>>> TESTDIRS=compiler > >>>>> > >>>>> Alright, I found another fairly grave bug that I would like to include a > >>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>>>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>>>> needed for volatile field access. However, it does not provide helper > >>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>>>> the final patch for now (unless you find something else). > >>>>> > >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >>>> > >>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >>>> > >>>> $ java -Xcomp -version > >>>> Value type size is target-dependent. Ask TLI. > >>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >>>> Stack dump: > >>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >>>> Aborted (core dumped) > >>> > >>> Arg! The last couple of changes I did only with LLVM3.2, where the > >>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > >>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > >>> use that for SHARK_LLVM_VERSION <= 31. > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > >>> > >>> Hope that works better :-) > >> > >> I'm so sorry but... > >> > >> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > > > > Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > > llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > > (hopefully final final) patch re-instates the missing memory_barrier() > > method: > > > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > > > > Sorry for the messy back-and-forth. > > Again, so sorry: > > $ java -Xcomp -version > LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! > > Send a new patch tomorrow after some sleep ;-) Yeah, apparently 'replaced by' means that the old thing (the intrinsics) are indeed gone ;-) The problem is that the correct way to implement it (atomic load/store) doesn't work, the 'old way' (the memory_barrier() intrinsic call) doesn't work either, I also tried CreateAtomicRMW() which is probably not 100% correct, but would have done the job, but that doesn't work either (it throws the same error as the atomic load/store ...). The problem seems to only appear on 64bit volatile access. I don't know a really good solution that doesn't require jumping through big hoops, and I don't feel like working around LLVM bugs like this, especially since LLVM 3.2 (which should be released real soon now) works just fine. If you have a suggestion, please let me know, otherwise I suggest the following patch, which gets rid of all the LLVM31 blocks again and creates atomic load/store instructions (and requires LLVM 3.2 which can be found here http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ Roman From aleksey.shipilev at oracle.com Tue Nov 27 09:57:41 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 27 Nov 2012 21:57:41 +0400 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 Message-ID: <50B4FF15.6090304@oracle.com> Hi, This is the daizy-fresh thread for reviewing the actual changes to support the JEP-142 in HotSpot. Please address API issues about @Contended to concurrency-interest list, Doug had started the thread here: http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010208.html We are not discussing the design, API and all the general stuff here, only the reference implementation. I would like to have someone extra knowledgeable in HotSpot codebase to see whether I do anything stupid there. The webrev for the change is here: http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ Notable differences against latest version: - a little denser packing in some corner cases - support @Contended for static fields - moved @Contended to sun.misc (go and nag at c-i@ about this) - bugfixes Testing: - hotspot/test/runtime/8003985/Test8003985 on Linux x86_64 - jprt, specjvm98 quick run - jprt full cycle is underway, looking good Thanks, Aleksey. From christian.thalinger at oracle.com Tue Nov 27 10:59:47 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 27 Nov 2012 10:59:47 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1354037066.29268.10.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> <1354037066.29268.10.camel@mercury> Message-ID: <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> On Nov 27, 2012, at 9:24 AM, Roman Kennke wrote: > Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: >> On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: >> >>> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: >>>> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: >>>> >>>>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: >>>>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: >>>>>> >>>>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: >>>>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: >>>>>>>>>> >>>>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>>>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi there, >>>>>>>>>>>>>> >>>>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>>>>>>>>>>> Here are some details: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>>>>>>>>>>> changes in LLVM. >>>>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata >>>>>>>>>>>>>> class hierarchies in Hotspot. >>>>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and >>>>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little >>>>>>>>>>>>>> nicer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse >>>>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>>>>>>>>>>> bunch of other stuff. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>>>>>>>>>>> can find the full webrev here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>>>>>>>>>>> >>>>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>>>>>>>>>>> >>>>>>>>>>>>> Isn't PrintCompilation doing that already? >>>>>>>>>>>>> >>>>>>>>>>>>> The shared code changes look good. I filed: >>>>>>>>>>>>> >>>>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM >>>>>>>>>>>>> >>>>>>>>>>>>> -- Chris >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are also a very minor change required in JDK: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>>>>>>>>>>> >>>>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will >>>>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please let me know if there are any issues or how we can get this >>>>>>>>>>>>>> integrated into Hotspot. >>>>>>>>>>>> >>>>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>>>>>>>>>>> >>>>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>>>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>>>>>>>>>>> from /usr/local/include/llvm/Use.h:28, >>>>>>>>>>>> from /usr/local/include/llvm/Value.h:17, >>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>>>>>>>>>>> >>>>>>>>>>>> and: >>>>>>>>>>>> >>>>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, >>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>>>>>>>>>>> >>>>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? >>>>>>>>>>> >>>>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >>>>>>>>>>> this happens when certain cflags are not set correctly. The script >>>>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >>>>>>>>>>> correct flags. In order for this to work, you need to have the full path >>>>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >>>>>>>>>>> using the build script that I provided? >>>>>>>>>> >>>>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. >>>>>>>>>> >>>>>>>>>> Now that I have the LLVM_* variables it's even worse: >>>>>>>>>> >>>>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness >>>>>>>>>> >>>>>>>>>> It's probably this guy: -Wcast-qual >>>>>>>>> >>>>>>>>> Got it: >>>>>>>>> >>>>>>>>> $ java -version >>>>>>>>> java version "1.8.0-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) >>>>>>>> >>>>>>>> I ran the compiler regression tests and Shark crashes in 5091921: >>>>>>>> >>>>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ >>>>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating >>>>>>>> Passed: compiler/5091921/Test5091921.java >>>>>>>> Passed: compiler/5091921/Test6186134.java >>>>>>>> Passed: compiler/5091921/Test6196102.java >>>>>>>> Passed: compiler/5091921/Test6357214.java >>>>>>>> Passed: compiler/5091921/Test6559156.java >>>>>>>> Passed: compiler/5091921/Test6753639.java >>>>>>>> Passed: compiler/5091921/Test6850611.java >>>>>>>> Passed: compiler/5091921/Test6890943.java >>>>>>>> Passed: compiler/5091921/Test6897150.java >>>>>>>> Passed: compiler/5091921/Test6905845.java >>>>>>>> Passed: compiler/5091921/Test6931567.java >>>>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts >>>>>>>> >>>>>>>> You can also run all them with a simple make in test/ by setting: >>>>>>>> >>>>>>>> PRODUCT_HOME=$JAVA_HOME >>>>>>>> TESTDIRS=compiler >>>>>>> >>>>>>> Alright, I found another fairly grave bug that I would like to include a >>>>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for >>>>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. >>>>>>> LLVM offers atomic loads and stores, which seem to be exactly what is >>>>>>> needed for volatile field access. However, it does not provide helper >>>>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be >>>>>>> the final patch for now (unless you find something else). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ >>>>>> >>>>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: >>>>>> >>>>>> $ java -Xcomp -version >>>>>> Value type size is target-dependent. Ask TLI. >>>>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! >>>>>> Stack dump: >>>>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' >>>>>> Aborted (core dumped) >>>>> >>>>> Arg! The last couple of changes I did only with LLVM3.2, where the >>>>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with >>>>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and >>>>> use that for SHARK_LLVM_VERSION <= 31. >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ >>>>> >>>>> Hope that works better :-) >>>> >>>> I'm so sorry but... >>>> >>>> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' >>> >>> Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and >>> llvm3.1, but apparently not (maybe I shouldn't work after 1am). This >>> (hopefully final final) patch re-instates the missing memory_barrier() >>> method: >>> >>> >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ >>> >>> Sorry for the messy back-and-forth. >> >> Again, so sorry: >> >> $ java -Xcomp -version >> LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! >> >> Send a new patch tomorrow after some sleep ;-) > > Yeah, apparently 'replaced by' means that the old thing (the intrinsics) > are indeed gone ;-) > > The problem is that the correct way to implement it (atomic load/store) > doesn't work, the 'old way' (the memory_barrier() intrinsic call) > doesn't work either, I also tried CreateAtomicRMW() which is probably > not 100% correct, but would have done the job, but that doesn't work > either (it throws the same error as the atomic load/store ...). The > problem seems to only appear on 64bit volatile access. > > I don't know a really good solution that doesn't require jumping through > big hoops, and I don't feel like working around LLVM bugs like this, > especially since LLVM 3.2 (which should be released real soon now) works > just fine. If you have a suggestion, please let me know, otherwise I > suggest the following patch, which gets rid of all the LLVM31 blocks > again and creates atomic load/store instructions (and requires LLVM 3.2 > which can be found here > http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). > > http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ That's a reasonable thing to do given the tentative release date of December 16th. While running the compiler regression tests I got a couple of failures. You might want to address them with separate bugs. -- Chris -------------------------------------------------- TEST: compiler/6539464/Test.java JDK under test: (/export/twisti/build/8003868/build/jdk-linux) java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, mixed mode) ACTION: build -- Passed. Build successful REASON: Named class compiled on demand TIME: 1.988 seconds messages: command: build Test reason: Named class compiled on demand elapsed time (seconds): 1.988 ACTION: compile -- Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 1.986 seconds messages: command: compile /home/cthaling/8003868/test/compiler/6539464/Test.java reason: .class file out of date or does not exist elapsed time (seconds): 1.986 STDOUT: STDERR: ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.InternalError: Math.log produces inconsistent results: 9.752490228984199 != 9.7524902289842 REASON: User specified action: run main/othervm -Xcomp -XX:CompileOnly=Test.main Test TIME: 0.121 seconds messages: command: main -Xcomp -XX:CompileOnly=Test.mainTest reason: User specified action: run main/othervm -Xcomp -XX:CompileOnly=Test.main Test elapsed time (seconds): 0.121 STDOUT: STDERR: java.lang.InternalError: Math.log produces inconsistent results: 9.752490228984199 != 9.7524902289842 at Test.main(Test.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:722) JavaTest Message: Test threw exception: java.lang.InternalError: Math.log produces inconsistent results: 9.752490228984199 != 9.7524902289842 JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.InternalError: Math.log produces inconsistent results: 9.752490228984199 != 9.7524902289842 TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.InternalError: Math.log produces inconsistent results: 9.752490228984199 != 9.7524902289842 -------------------------------------------------- -------------------------------------------------- TEST: compiler/6796786/Test6796786.java JDK under test: (/export/twisti/build/8003868/build/jdk-linux) java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, mixed mode) ACTION: build -- Passed. Build successful REASON: Named class compiled on demand TIME: 2.212 seconds messages: command: build Test6796786 reason: Named class compiled on demand elapsed time (seconds): 2.212 ACTION: compile -- Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 2.209 seconds messages: command: compile /home/cthaling/8003868/test/compiler/6796786/Test6796786.java reason: .class file out of date or does not exist elapsed time (seconds): 2.209 STDOUT: STDERR: ACTION: main -- Failed. Unexpected exit from test [exit code: 1] REASON: User specified action: run main/othervm -Xbatch Test6796786 TIME: 0.638 seconds messages: command: main -XbatchTest6796786 reason: User specified action: run main/othervm -Xbatch Test6796786 elapsed time (seconds): 0.638 STDOUT: STDERR: LLVM ERROR: Cannot select: 0x2ab78c065100: f32,ch = AtomicLoad 0x2ab78c64dad0:1, 0x2ab78c069c40 [ORD=26732] [ID=49] 0x2ab78c069c40: i64 = add 0x2ab78c64dad0, 0x2ab78c64d9d0 [ORD=26730] [ID=48] 0x2ab78c64dad0: i64,ch = load 0x2ab78c061710:1, 0x2ab78c0649f0, 0x2ab78c64dcd0 [ORD=26729] [ID=47] 0x2ab78c0649f0: i64 = add 0x2ab78c069b40, 0x2ab78c0ef4b0 [ORD=26727] [ID=40] 0x2ab78c069b40: i64,ch = CopyFromReg 0x2ab75c0be7a0, 0x2ab78c061110 [ORD=26721] [ID=29] 0x2ab78c061110: i64 = Register %vreg31 [ORD=26721] [ID=2] 0x2ab78c0ef4b0: i64 = Constant<48> [ORD=26727] [ID=6] 0x2ab78c64dcd0: i64 = undef [ORD=26723] [ID=4] 0x2ab78c64d9d0: i64 = Constant<204> [ORD=26730] [ID=7] In function: Test6796786::main TEST RESULT: Failed. Unexpected exit from test [exit code: 1] -------------------------------------------------- -------------------------------------------------- TEST: compiler/6932496/Test6932496.java JDK under test: (/export/twisti/build/8003868/build/jdk-linux) java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, mixed mode) ACTION: compile -- Passed. Compilation successful REASON: User specified action: run compile -source 1.5 -target 1.5 -XDjsrlimit=0 Test6932496.java TIME: 2.022 seconds messages: command: compile -source 1.5 -target 1.5 -XDjsrlimit=0 /home/cthaling/8003868/test/compiler/6932496/Test6932496.java reason: User specified action: run compile -source 1.5 -target 1.5 -XDjsrlimit=0 Test6932496.java elapsed time (seconds): 2.022 STDOUT: STDERR: warning: [options] bootstrap class path not set in conjunction with -source 1.5 1 warning ACTION: build -- Passed. All files up to date REASON: Named class compiled on demand TIME: 0.002 seconds messages: command: build Test6932496 reason: Named class compiled on demand elapsed time (seconds): 0.002 ACTION: main -- Failed. Unexpected exit from test [exit code: 134] REASON: User specified action: run main/othervm -Xcomp -XX:CompileOnly=Test6932496.m Test6932496 TIME: 0.673 seconds messages: command: main -Xcomp -XX:CompileOnly=Test6932496.mTest6932496 reason: User specified action: run main/othervm -Xcomp -XX:CompileOnly=Test6932496.m Test6932496 elapsed time (seconds): 0.673 STDOUT: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_zero.cpp:254), pid=6346, tid=47237501929232 # fatal error: caught unhandled signal 7 # # JRE version: Java(TM) SE Runtime Environment (8.0-b65) (build 1.8.0-ea-b65) # Java VM: OpenJDK 64-Bit Shark VM (25.0-b11-internal compiled mode linux-amd64 ) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /export/twisti/build/8003868/build/linux-x86_64/testoutput/JTwork/scratch/hs_err_pid6346.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # STDERR: TEST RESULT: Failed. Unexpected exit from test [exit code: 134] -------------------------------------------------- From john.cuthbertson at oracle.com Tue Nov 27 11:15:31 2012 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 27 Nov 2012 11:15:31 -0800 Subject: RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table In-Reply-To: <50AC9018.2040008@oracle.com> References: <50AC2714.2070801@oracle.com> <50AC9018.2040008@oracle.com> Message-ID: <50B51153.1050704@oracle.com> Hi Ramki, Bengt, Thanks for the reviews. I've changed the added messages to include whitespace around the format macros. Regards, JohnC On 11/21/12 00:26, Bengt Rutisson wrote: > > Looks good to me too. > > I like that you introduced the check_index() and check_offset() methods. > > One style question. You are using the format macros without white > spaces. After grepping a bit in the hotspot source I think it is more > common to have white spaces when using these. So instead of > "..."SIZE_FORMAT"..", "..."UINT32_FORMAT"..." etc I think it would be > more hotspot-like to use "..." SIZE_FORMAT "..." and "..." > UINT32_FORMAT "...". > > Bengt > > > On 2012-11-21 02:40, Srinivas Ramakrishna wrote: >> Looks good to me. >> >> -- ramki >> >> On Tue, Nov 20, 2012 at 4:57 PM, John Cuthbertson < >> john.cuthbertson at oracle.com> wrote: >> >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review the changes at: >>> http://cr.openjdk.java.net/~**johnc/7194633/webrev.0? >>> >>> >>> Background: >>> >>> While I was testing the fix for 719066 I ran into several assertions >>> and >>> guarantee failures from G1's block offset table when running through >>> jprt. >>> The failures were associated with using a specific version of the sparc >>> memset to initialize the offsets array (see 7192128) which was >>> missing from >>> my 7190666 workspace. The changes in this webrev are the >>> instrumenation and >>> detailed error message changes I made to verify that G1's block offset >>> table was not immune to the memset issue and that the failures from >>> jprt >>> were the same issue. These detailed error messages were invaluable when >>> tracking the issue down. >>> >>> Testing: >>> GCBasher with -UseMemsetInBOT on sparc >>> Forcibly triggering the failures to check that the error messages made >>> sense. >>> jprt >>> >>> It is still my intent to merge G1's BOT with that of the other >>> collectors >>> and remove the large amount of duplicated code (which is a separate >>> CR). >>> When I do that, the detailed error messages will be included in the >>> shared >>> BOT code. >>> >>> Thanks, >>> >>> JohnC >>> > From serguei.spitsyn at oracle.com Tue Nov 27 14:45:14 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 27 Nov 2012 14:45:14 -0800 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50AD0BAB.2020604@oracle.com> References: <50AC0329.8080800@oracle.com> <50AC49D7.9050306@oracle.com> <50AD0BAB.2020604@oracle.com> Message-ID: <50B5427A.2080307@oracle.com> If you still need it, the fix looks good. Also, the Solaris studio guys are pretty happy with this fix. :) Thanks, Serguei On 11/21/12 9:13 AM, Coleen Phillimore wrote: > > Thanks again for the code review, David. > > On 11/20/2012 10:26 PM, David Holmes wrote: >> Hi Coleen, >> >> On 21/11/2012 8:24 AM, Coleen Phillimore wrote: >>> Summary: Make metaspace::contains be lock free and used to see if >> >> I don't think this is 100% valid without assuming TSO. Your are >> growing a linked list of nodes under a lock, but allowing the >> existing list to be iterated without a lock. You have to ensure that >> a VirtualSpaceNode can't be seen in the list prior to being properly >> initialized - I know the code in VirtualSpaceNode::initialize makes >> it unlikely, but I wouldn't want to second-guess how the compiler >> and/or hardware might reorder things. To be safe I think you need: >> >> 980 // Allocate the meta virtual space and initialize it. >> 981 VirtualSpaceNode* new_entry = new VirtualSpaceNode(vs_byte_size); >> 982 if (!new_entry->initialize()) { >> 983 delete new_entry; >> 984 return false; >> 985 } else { >> + // ensure lock-free iteration sees fully initialized node >> + OrderAccess:storeStore(); >> 986 link_vs(new_entry, vs_word_size); >> 987 return true; >> 988 } > > Thank you! I added the OrderAccess call. I feel better about the > safety of walking this lock free now. >> >>> something is in metaspace, also compare Method* with vtbl pointer. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 >> >> Do the comments in forte.cpp regarding the unsafe reference to the >> method not still apply? >> > > There are better comments above this comment. The interpreter frame > could be partially constructed when AsyncGetCallTrace picks it up. > We no longer have to worry about GC making the Method* invalid (except > for bugid 8003720 ). > The second check is probably not strictly necessary since that was > what it was checking, but for safety I want to leave it in. > > Thanks, > Coleen >> Cheers, >> David >> ----- >> >>> Tested with full NSK testlist on linux 32. Studio tools group also >>> tested this. >>> >>> Thanks, >>> Coleen > From hiyangxi at gmail.com Tue Nov 27 15:28:36 2012 From: hiyangxi at gmail.com (Xi Yang) Date: Wed, 28 Nov 2012 10:28:36 +1100 Subject: Report a bug in HotSpot In-Reply-To: <50B4D53C.3090900@oracle.com> References: <50B3B524.60307@oracle.com> <50B43A2B.4070202@oracle.com> <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> <50B4D53C.3090900@oracle.com> Message-ID: Hi all, Thanks Kris for forwarding the problem here. On 28 November 2012 01:59, Krystal Mo wrote: > Hi David and Karen, > > Thanks for the reply. I don't have a strong opinion on whether this should > be viewed as a "bug" and fixed, just forwarding concerns from Xi Yang. It is hard to say this is bug. However, I think it is worth to look at this problem because: 1) x86 ABI does not define this very clearly. 2) When this problem is happened (bad guy touches MMx register in native code, which causes x87 operations in Java world leading to wrong results), Java keeps silent. So programmer is hard to notice something wrong in the code. It is very easy to fix the problem or provide a option to allow the user to fix the problem, insert "emms" instructions after back from native to Java world. Well, there is no problem to say that the problem is from native code and native code should preserve x87 state when using MMx instructions, and then just ignore this. No problem, 100% fine. Here is the description of "EMMS" instruction I copied from intel arch manual: "Sets the values of all the tags in the x87 FPU tag word to empty (all 1s). This opera- tion marks the x87 FPU data registers (which are aliased to the MMX technology registers) as available for use by x87 FPU floating-point instructions. (See Figure 8-7 in the Intel? 64 and IA-32 Architectures Software Developer?s Manual, Volume 1, for the format of the x87 FPU tag word.) All other MMX instructions (other than the EMMS instruction) set all the tags in x87 FPU tag word to valid (all 0s). The EMMS instruction must be used to clear the MMX technology state at the end of all MMX technology procedures or subroutines and before calling other procedures or subroutines that may execute x87 floating-point instructions. If a floating-point instruction loads one of the registers in the x87 FPU data register stack before the x87 FPU tag word has been reset by the EMMS instruction, an x87 floating-point register stack overflow can occur that will result in an x87 floating-point exception or incorrect result. EMMS operation is the same in non-64-bit modes and 64-bit mode." Regards. > > Perhaps Xi would like to explain his rationales for having such concerns in > the first place. > > There's a follow up on the test case: Xi provided a modified test case that > would affect amd64 as well: > > > class Hello { > private static native void abc(); > public static void main(String[] args) { > System.out.println("I am main"); > System.loadLibrary("hello"); > abc(); > long a = 100; > double b = (double)a; > double c = 3.14; > System.out.println("Double a%c is " + a%c); > } > } > > Even though HotSpot's interpreter doesn't use the FPU stack itself, the > "drem" bytecode instruction is implemented with a call to > SharedRuntime::drem(double,double), which uses the FPU and thus affected by > dirty FPU stack: > > Dump of assembler code for function _ZN13SharedRuntime4dremEdd: > 0x00007ffff6e8d790 <+0>: push %rbp > 0x00007ffff6e8d791 <+1>: mov %rsp,%rbp > 0x00007ffff6e8d794 <+4>: sub $0x10,%rsp > 0x00007ffff6e8d798 <+8>: movsd %xmm0,-0x10(%rbp) > 0x00007ffff6e8d79d <+13>: fldl -0x10(%rbp) > 0x00007ffff6e8d7a0 <+16>: movsd %xmm1,-0x10(%rbp) > 0x00007ffff6e8d7a5 <+21>: fldl -0x10(%rbp) > 0x00007ffff6e8d7a8 <+24>: fld %st(1) > 0x00007ffff6e8d7aa <+26>: fld %st(1) > 0x00007ffff6e8d7ac <+28>: fxch %st(1) > 0x00007ffff6e8d7ae <+30>: fprem > 0x00007ffff6e8d7b0 <+32>: fnstsw %ax > 0x00007ffff6e8d7b2 <+34>: test $0x4,%ah > 0x00007ffff6e8d7b5 <+37>: jne 0x7ffff6e8d7ae > > 0x00007ffff6e8d7b7 <+39>: fstp %st(1) > 0x00007ffff6e8d7b9 <+41>: fstpl -0x8(%rbp) > 0x00007ffff6e8d7bc <+44>: movsd -0x8(%rbp),%xmm0 > 0x00007ffff6e8d7c1 <+49>: ucomisd %xmm0,%xmm0 > 0x00007ffff6e8d7c5 <+53>: jp 0x7ffff6e8d7d0 > > 0x00007ffff6e8d7c7 <+55>: jne 0x7ffff6e8d7d0 > > 0x00007ffff6e8d7c9 <+57>: fstp %st(0) > 0x00007ffff6e8d7cb <+59>: fstp %st(0) > 0x00007ffff6e8d7cd <+61>: leaveq > 0x00007ffff6e8d7ce <+62>: retq > 0x00007ffff6e8d7cf <+63>: nop > 0x00007ffff6e8d7d0 <+64>: fstpl -0x10(%rbp) > 0x00007ffff6e8d7d3 <+67>: movsd -0x10(%rbp),%xmm1 > 0x00007ffff6e8d7d8 <+72>: fstpl -0x10(%rbp) > 0x00007ffff6e8d7db <+75>: movsd -0x10(%rbp),%xmm0 > 0x00007ffff6e8d7e0 <+80>: callq 0x7ffff6857fa8 > 0x00007ffff6e8d7e5 <+85>: leaveq > 0x00007ffff6e8d7e6 <+86>: retq > > (disassembly from JDK7u9 on Ubuntu 12.04, amd64) > > I had a partial fix to this problem in x86: > > diff -r fb2d98043048 src/cpu/x86/vm/sharedRuntime_x86_32.cpp > --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp Fri Sep 14 15:00:02 2012 > -0700 > +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp Tue Nov 27 20:59:44 2012 > +0800 > @@ -2054,10 +2054,15 @@ > > // no exception, we're almost done > > - // check that only result value is on FPU stack > - __ verify_FPU(ret_type == T_FLOAT || ret_type == T_DOUBLE ? 1 : 0, > "native_wrapper normal exit"); > - > - // Fixup floating pointer results so that result looks like a return from > a compiled method > + // Check that only result value is on FPU stack for floating point return > type, > + // Empty the FPU stack otherwise, just in case it was left dirty by the > native call. > + if (ret_type == T_FLOAT || ret_type == T_DOUBLE) { > + __ verify_FPU(1, "native_wrapper normal exit"); > + } else { > + __ empty_FPU_stack(); > + } > + > + // Fixup floating point results so that result looks like a return from a > compiled method > if (ret_type == T_FLOAT) { > if (UseSSE >= 1) { > // Pop st0 and store as float and reload into xmm register > diff -r fb2d98043048 src/cpu/x86/vm/templateInterpreter_x86_32.cpp > --- a/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Fri Sep 14 15:00:02 > 2012 -0700 > +++ b/src/cpu/x86/vm/templateInterpreter_x86_32.cpp Tue Nov 27 20:59:44 > 2012 +0800 > @@ -1119,6 +1119,10 @@ > __ bind(L); > } > __ push(ltos); > + > + // Clear FPU stack here, just in case the native call left it dirty. > + // It's safe since the potential result is saved already. > + __ empty_FPU_stack(); > > // change thread state > __ get_thread(thread); > > (diff against tip of hsx/hsx23.6) > > This patch empties the FPU stack upon return from the native call, in both > the native entry for the interpter and the native wrapper for compiled code. > It's straightforward to do in the interpreter native entry case, because the > FPU stack is supposed to be empty at that point anyway; > it's not so straightforward for the native wrapper case, because there's > potential return value left in st(0). I could pop st(0) to the stack, empty > the FPU stack, and then restore the return value to st(0), but I haven't > done so in this patch yet, since it'd be weird to return a floating point > result with a dirty FPU stack anyway. > > Regards, > Kris > > > On 11/27/2012 09:01 PM, Karen Kinnear wrote: >> >> Hi Kris, >> >> I would concur. And there is also an explicit intention to not slow down >> JNI transitions by having the JVM do extra work. The >> model is to have the JNI code restore a good state. >> >> Looks like we already have a flag that lets you know that you need to fix >> the jni code, so no need to add another way to do that. >> >> thanks, >> Karen >> >> On Nov 26, 2012, at 10:57 PM, David Holmes wrote: >> >>> Hi Kris, >>> >>> I think historically hotspot assumes/requires JNI code to be well behaved >>> about these things. There have been some well known issues with FPU state in >>> the past. I'm not that familiar with MMX so can't say whether it is >>> reasonable for the VM to know when it has to do this kind of cleanup. >>> >>> David >>> >>> On 27/11/2012 4:29 AM, Krystal Mo wrote: >>>> >>>> Hi all, >>>> >>>> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't >>>> empty the FPU stack on return from JNI calls. His mail is included >>>> below. >>>> >>>> e.g. If a native function called via JNI is using MMX registers without >>>> emptying the FPU stack before returning, then after returning to Java >>>> the FPU stack will be in a bad state. >>>> >>>> The test case Xi gave is demonstrated here on JDK7u9, x86: >>>> https://gist.github.com/4148771 >>>> Running the example with -XX:+VerifyFPU shows what's going on. >>>> >>>> This test case shows the bug affecting 32-bit x86 version of HotSpot's >>>> interpreter. >>>> >>>> Not really familiar with how to file a bug on JBS yet, I'll file a bug >>>> to track this after I learn how to do it. >>>> >>>> Regards, >>>> Kris >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Fwd: Report a bug in HotSpot >>>> Date: Tue, 27 Nov 2012 02:02:59 +0800 >>>> From: Krystal Mok >>>> To: Krystal Mo >>>> >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Xi Yang >>>> Date: Tue, Nov 20, 2012 at 1:44 PM >>>> Subject: Report a bug in HotSpot >>>> To: Krystal Mok >>>> >>>> >>>> Hi, >>>> >>>> It looks like HotSpot does not do "emms" after backing from JNI. Here >>>> is the code to show the bug. Would you like to try the newest version? >>>> >>>> >>>> Hello.java >>>> class Hello { >>>> private static native void abc(); >>>> public static void main(String[] args) { >>>> System.out.println("I am main"); >>>> System.loadLibrary("Hello"); >>>> abc(); >>>> long a = 100; >>>> double b = (double)a; >>>> System.out.println("Double a is " + b); >>>> } >>>> } >>>> >>>> Hello.c >>>> #include >>>> #include >>>> >>>> JNIEXPORT void JNICALL >>>> Java_Hello_abc(JNIEnv *env, jclass cls) >>>> { >>>> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); >>>> unsigned int dummy; >>>> asm volatile("movd %%mm0, %0\n":"=r"(dummy)); >>>> printf("dummy is %x\n", dummy); >>>> } >>>> >>>> >>>> gcc -m32 -shared ./Hello.c -o ./libHello.so >>>> >>>> >>>> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello >>>> I am main >>>> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world >>>> dummy is 0 >>>> Double a is NaN >>>> >>>> >>>> $ /opt/jdk1.7.0/bin/java -version >>>> java version "1.7.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) >>>> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) >>>> >>>> >>>> > From christian.thalinger at oracle.com Tue Nov 27 16:13:21 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 27 Nov 2012 16:13:21 -0800 Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF4B7FF18@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF4B7FF18@DEWDFECCR03.wdf.sap.corp> Message-ID: <22088E6D-15CA-44FB-BBDB-822057B1A3DE@oracle.com> Quick question: Do you have a non-empty implementation for CodeBuffer::flush_bundle on IA64? -- Chris On Nov 8, 2012, at 12:25 AM, "Lindenmaier, Goetz" wrote: > Hi Morris, > > > > I had a look at your change. As you know we maintain a port for IA64. > > We basically use all the IA64 specific code, although some of the defines > > are obviously superfluous. > > The changes are not that essential that removing them would cause us > > huge problems, but nevertheless we would prefer if most of them stay > > in the code to reduce our deviation from your code. > > > > In more detail: > > > > Code to remove > > ============= > > > > We do not use the agent on ia64, so we don't care about > > agent/src/os/linux/LinuxDebuggerLocal.c > > agent/src/os/linux/libproc.h > > agent/src/os/win32/windbg/sawindbg.cpp > > > > We don?t need the code here: > > src/os/bsd/vm/os_bsd.cpp > > > > Here we removed the #define ourselves: > > src/share/vm/interpreter/bytecodeInterpreter.cpp > > src/share/vm/runtime/sharedRuntime.cpp > > src/share/vm/runtime/synchronizer.cpp > > > > Further you can remove > > src/share/vm/runtime/vframeArray.cpp > > > > We can easily work around need_register_stack_bang(), and as it's rather platform > > dependent, just remove it in > > src/share/vm/opto/compile.hpp > > src/share/vm/opto/output.cpp > > > > > > Code to keep > > =========== > > > > This is basic platform support, so keep it please: > > src/share/vm/runtime/vm_version.cpp > > src/share/vm/utilities/macros.hpp > > > > Keep this: > > src/share/vm/prims/forte.cpp > > > > Don't care: > > src/share/vm/runtime/os.cpp > > We extended the code at this place to cover more cases, see below. > > Therefore we don't care about the fix in openJDK. > > Note that our code is also used on AMD64: > > > > // Looks like all platforms except IA64 can use the same function to check > > // if C stack is walkable beyond current frame. The check for fp() is not > > // necessary on Sparc, but it's harmless. > > bool os::is_first_C_frame(frame* fr) { > > #if defined(IA64) && !defined(_WIN32) > > // On IA64 we have to check if the callers bsp is still valid > > // (i.e. within the register stack bounds). > > // Notice: this only works for threads created by the VM and only if > > // we walk the current stack!!! If we want to be able to walk > > // arbitrary other threads, we'll have to somehow store the thread > > // object in the frame. > > Thread *thread = Thread::current(); > > if ((address)fr->fp() <= thread->register_stack_base() HPUX_ONLY(+ 0x0) LINUX_ONLY(+ 0x50)) { > > // This check is a little hacky, because on Linux the frist C > > // frame's ('start_thread') register stack frame starts at > > // "register_stack_base + 0x48" while on HPUX, the first C frame's > > // ('__pthread_bound_body') register stack frame seems to really > > // start at "register_stack_base". > > return true; > > } else { > > return false; > > } > > // On Windows AMD64 link() does not work as there's no back link on the stack. > > #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) > > return true; > > #else > > // Load up sp, fp, sender sp and sender fp, check for reasonable values. > > // Check usp first, because if that's bad the other accessors may fault > > // on some architectures. Ditto ufp second, etc. > > uintptr_t fp_align_mask = (uintptr_t)(sizeof(address)-1); > > > > > > The extension of the frame_slots in > > src/share/vm/opto/output.cpp > > is only needed for the _zap_dead_*_locals stubs. But better keep it. > > > > We use most of the code in os_linux.cpp as is, please keep it. > > src/os/linux/vm/os_linux.cpp > > > > There are two patches where you could improve the code: > > > > You could use IA64_ONLY(* 2) here: > > > > @@ -1174,12 +1170,7 @@ > > // for initial thread if its stack size exceeds 6M. Cap it at 2M, > > // in case other parts in glibc still assumes 2M max stack size. > > // FIXME: alt signal stack is gone, maybe we can relax this constraint? > > -#ifndef IA64 > > if (stack_size > 2 * K * K) stack_size = 2 * K * K; > > -#else > > - // Problem still exists RH7.2 (IA64 anyway) but 2MB is a little small > > - if (stack_size > 4 * K * K) stack_size = 4 * K * K; > > -#endif > > > > // Try to figure out where the stack base (top) is. This is harder. > > // > > > > You can apply this patch, instead I implemented the two functions empty > > in the platform file. > > > > @@ -4385,16 +4373,12 @@ > > if (is_NPTL()) { > > return pthread_cond_timedwait(_cond, _mutex, _abstime); > > } else { > > -#ifndef IA64 > > // 6292965: LinuxThreads pthread_cond_timedwait() resets FPU control > > // word back to default 64bit precision if condvar is signaled. Java > > // wants 53bit precision. Save and restore current value. > > int fpu = get_fpu_control_word(); > > -#endif // IA64 > > int status = pthread_cond_timedwait(_cond, _mutex, _abstime); > > -#ifndef IA64 > > set_fpu_control_word(fpu); > > -#endif // IA64 > > return status; > > } > > } > > > > We use all of the #defines/#ifdefs here: > > src/os/windows/vm/os_windows.cpp > > But we changed the IA64 specific code a lot. > > > > It's unclear whether this change is needed: > > src/share/vm/oops/oop.inline.hpp > > but to avoid a regression we would like to keep it. Maybe it > > would be better to protect the change by > > #if defined(IA64) && defined(_WIN32) > > as it's done at other shared code locations. > > > > Best regards, > > Goetz > > > > > > > > > > > > > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Montag, 5. November 2012 11:25 > To: Morris Meyer > Cc: Lindenmaier, Goetz > Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code > > > > Hi Morris, > > > > we had a long weekend last week because last Thursday was public > > holiday in Germany, but my colleague Goetz is currently looking at the > > change and will come back to you. > > > > Thank you and best regards, > > Volker > > > > On Fri, Nov 2, 2012 at 10:42 PM, Morris Meyer > wrote: > >> Volker, > >> > >> Have you had a chance to review my changes for this bug? > >> > >> Thanks in advance, > >> > >> --morris From daniel.daugherty at oracle.com Tue Nov 27 18:34:18 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Nov 2012 19:34:18 -0700 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50AC0329.8080800@oracle.com> References: <50AC0329.8080800@oracle.com> Message-ID: <50B5782A.7020507@oracle.com> On 11/20/12 3:24 PM, Coleen Phillimore wrote: > Summary: Make metaspace::contains be lock free and used to see if > something is in metaspace, also compare Method* with vtbl pointer. > > open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 > > Tested with full NSK testlist on linux 32. Studio tools group also > tested this. > > Thanks, > Coleen Thumbs up! And a very nice catch by David H in VirtualSpaceList::grow_vs(). Dan src/share/vm/gc_interface/collectedHeap.hpp src/share/vm/gc_interface/collectedHeap.inline.hpp Moving CollectedHeap::is_valid_method() to Method::is_valid_method() makes sense since methods aren't in the heap anymore. src/share/vm/memory/allocation.cpp No comments. src/share/vm/memory/metaspace.hpp Was: bool contains(const void *ptr) const; and is now: static bool contains(const void *ptr); So why was the trailing "const" dropped? src/share/vm/memory/metaspace.cpp No comments except I don't see the changes that David Holmes requested so I'm going to guess that you didn't refresh the webrev in place. I'm OK if you didn't. src/share/vm/oops/method.hpp No comments. src/share/vm/oops/method.cpp line 1820: if (this == NULL) { If "this" is NULL, then how did this non-static is_valid_method() function get called? Or is my brain confusing Java "this" versus C++ "this"? lines 1825-1828: vtable pointer matching? The skeptic in me wonders how portable such a construct is across various C++ compilers. line 1952: guarantee(md == NULL || line 1953: md->is_metadata(), "should be in permspace"); Not part of your change, but this mention of "permspace" caught my eye. I'm not caught on all the post-PGR terms, but is this the right word to use? The guarantee() on line 1950 says "should be metadata"... src/cpu/sparc/vm/frame_sparc.cpp line 651: if (!m->is_valid_method()) return false; In the post-PGR world, if this call to frame::is_interpreted_frame_valid() returns true, then the check on line 220 in forte.cpp is not necessary. src/cpu/x86/vm/frame_x86.cpp line 537: if (!m->is_valid_method()) return false; In the post-PGR world, if this call to frame::is_interpreted_frame_valid() returns true, then the check on line 220 in forte.cpp is not necessary. src/share/vm/prims/forte.cpp line 220: if (!method->is_valid_method()) return false; Methods can no longer move in the post-PGR world, right? If that's the case, then this check isn't needed since the frame was validated on line 199. However, the extra paranoia doesn't hurt. From david.holmes at oracle.com Tue Nov 27 18:43:22 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Nov 2012 12:43:22 +1000 Subject: Official reviewer needed: Review request for fix for 7200297: agent code does not handle multiple dll_dir paths correctly In-Reply-To: <50B4E0F5.5070702@oracle.com> References: <50A41AEA.8050705@oracle.com> <50A4AF33.2020208@oracle.com> <50A5420A.7030502@oracle.com> <50A54734.6000608@oracle.com> <50A6A18C.1070206@oracle.com> <50AAA04A.70408@oracle.com> <50ACA54E.7020608@oracle.com> <50AD2C2A.8000401@oracle.com> <50AE1FEC.9030506@oracle.com> <50B3AAA5.9040401@oracle.com> <50B427A2.8050809@oracle.com> <50B4E0F5.5070702@oracle.com> Message-ID: <50B57A4A.5040305@oracle.com> Thanks Bill - Reviewed. David On 28/11/2012 1:49 AM, BILL PITTORE wrote: > Thanks David for the review. > > > On 11/26/2012 9:38 PM, David Holmes wrote: >> Hi Bill, >> >> A few minor comments, some of which you've touched on with Dmitry. >> >> David >> ------ >> >> >> share/back/debugInit.c >> >> 40 #include "sys.h" >> >> Shouldn't that be ? >> > No, it's really "sys.h" -> jdk/src/share/back/export/sys.h: >> --- >> >> src/share/back/transport.c >> >> * Note: Java property sun.boot.library.path contains a single directory. >> + * Note: Above incorrect since 6819213 fixed. Dll_dir is the first entry >> + * and -Dsun.boot.library.path entries are appended. >> >> Better to just change the original comment than to keep it and say it >> isn't true. >> > Fixed. >> --- >> >> src/solaris/back/linker_md.c >> >> 113 return; >> >> Adding the return is superfluous. Arguably the whole method should be >> a chained if-else with no returns. Stylistically you have now mixed >> styles: either use a return, or use an else, but not both. >> > Removed the return. >> --- >> >> src/solaris/demo/jvmti/hprof/hprof_md.c >> >> 426 return; >> >> Same comment as for linker_md.c >> >> And why didn't you move *holder = '\0'; in this version? > Fixed both issues. >> >> Ditto src/windows/demo/jvmti/hprof/hprof_md.c > Fixed. >> >> --- >> >> src/windows/back/linker_md.c >> >> 123 return; >> >> Ditto previous comments. >> > Fixed. > > Updated webrev http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ > Running nsk tests. > > bill > >> --- >> >> >> On 27/11/2012 3:45 AM, BILL PITTORE wrote: >>> Have a couple of reviews but still need official reviewer to pass >>> muster. >>> >>> thanks, >>> bill >>> >>> >>> >>> On 11/22/2012 7:51 AM, Dmitry Samersoff wrote: >>>> Bill, >>>> >>>> Looks good for me. >>>> >>>> -Dmitry >>>> >>>> On 2012-11-21 23:31, BILL PITTORE wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 11/21/2012 4:56 AM, Dmitry Samersoff wrote: >>>>>> Bill, >>>>>> >>>>>> >>>>>> Few nits: >>>>>> >>>>>> 1. >>>>>> >>>>>> dll_build_name is exactly the same for all locations could we >>>>>> place it >>>>>> to some common place? >>>>> It looked somewhat intentional to have the agents and the hprof >>>>> code be >>>>> self-contained. I looked at using a common file but the makefile >>>>> changes >>>>> and source tree changes seemed a bit much. Hprof code is "unsupported >>>>> demo" code and jdwp is supported agent so I went with the current >>>>> scheme >>>>> of having the code be self-contained. >>>>>> Also file_exists is not necessary and could be >>>>>> replaced with just ::access(buffer,R_OK) (Windows has it as well) >>>>> I'll go with the access suggestion above, less code. >>>>>> but if you prefer to keep it: >>>>>> >>>>>> strlen(filename)==0 could be a *filename == 0 >>>>>> >>>>>> >>>>>> 2. We don't need else after return in all *_md.c files >>>>>> e.g. linker_md.c:122 >>>>> Semantically, you're correct. I think in terms of code readability I >>>>> like the 'else' since it makes it clear to the reader that there >>>>> are two >>>>> different cases. C compiler will 'do the right thing'. >>>>> Updated the webrev at >>>>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.03/ >>>>> >>>>> thanks, >>>>> bill >>>>>> Otherwise looks good. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2012-11-20 01:10, BILL PITTORE wrote: >>>>>>> Have gotten reviews from Serguei Spitsyn for the changes, made some >>>>>>> improvements and need an official reviewer to check it out. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/7200297/webrev.02 >>>>>>> >>>>>>> thanks, >>>>>>> bill >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/14/2012 5:27 PM, bill.pittore at oracle.com wrote: >>>>>>>> This bug has to do with the jdwp and hprof agents not parsing the >>>>>>>> sun.boot.library.path (dll_dir) correctly since the fix for 6819213 >>>>>>>> went in some years ago. This bug popped up while working on a >>>>>>>> particular platform that does not have the ability to set >>>>>>>> LD_LIBRARY_PATH before running the VM. As documented in the bug, on >>>>>>>> most platforms even if the sun.boot.library.path consists of >>>>>>>> multiple >>>>>>>> paths and the jdwp or hprof code fails to load a dependent lib, the >>>>>>>> system falls back to using LD_LIBRARY_PATH so the failure is >>>>>>>> masked. >>>>>>>> On some other platforms, this failover doesn't exist so we get an >>>>>>>> error when trying to load jdwp and hprof dependent libs. >>>>>>>> >>>>>>>> Some notes on a couple of files. >>>>>>>> * >>>>>>>> debugInit.c, hprof_init.c*: >>>>>>>> Rearranged the init order so that the jvmti pointer gets >>>>>>>> initialized >>>>>>>> before attempting to load the npt shared library. >>>>>>>> >>>>>>>> *linker_md.c, hprof_md.c* >>>>>>>> Much of the platform code in hprof and jdwp is duplicated and this >>>>>>>> change is no different. Based on the code in hotspot >>>>>>>> os_solaris/windows.cpp it parses the boot library path and >>>>>>>> attempts to >>>>>>>> find the library. >>>>>>>> * >>>>>>>> error_messages.c* >>>>>>>> Fixed a bug in the error message code that blindly dereferenced the >>>>>>>> npt pointer even if it wasn't set because of an error in loading. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~bpittore/7200297/webrev.00/ >>>>>>>> >>>>>>>> Ran the ute nsk/jdwp nsk/jvmti nsk/hprof tests, the JCK jdwp/jvmti >>>>>>>> tests and some command line testing on windows and linux. >>>>>>>> >>>>>>>> thanks, >>>>>>>> bill >>>>>>>> >>>>>>>> >>>> >>> >>> > > From david.holmes at oracle.com Tue Nov 27 19:06:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Nov 2012 13:06:29 +1000 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50B5782A.7020507@oracle.com> References: <50AC0329.8080800@oracle.com> <50B5782A.7020507@oracle.com> Message-ID: <50B57FB5.6020506@oracle.com> On 28/11/2012 12:34 PM, Daniel D. Daugherty wrote: > src/share/vm/oops/method.cpp > line 1820: if (this == NULL) { > If "this" is NULL, then how did this non-static is_valid_method() > function get called? Or is my brain confusing Java "this" versus > C++ "this"? ooh ooh! I know this one :) I've had the same reaction a few times myself. So in C++ a non-virtual method invocation: o->is_valid_method() is actually a call: is_valid_method(o); Hence you can execute the method and examine o (the this pointer) to see if it is NULL, inside the method. We actually have an is_null() method that does that instead of doing the check at the call site. David ----- > lines 1825-1828: vtable pointer matching? The skeptic in me wonders > how portable such a construct is across various C++ compilers. > > line 1952: guarantee(md == NULL || > line 1953: md->is_metadata(), "should be in permspace"); > Not part of your change, but this mention of "permspace" > caught my eye. I'm not caught on all the post-PGR terms, > but is this the right word to use? The guarantee() on line > 1950 says "should be metadata"... > > src/cpu/sparc/vm/frame_sparc.cpp > line 651: if (!m->is_valid_method()) return false; > In the post-PGR world, if this call to > frame::is_interpreted_frame_valid() returns true, then the > check on line 220 in forte.cpp is not necessary. > > src/cpu/x86/vm/frame_x86.cpp > line 537: if (!m->is_valid_method()) return false; > In the post-PGR world, if this call to > frame::is_interpreted_frame_valid() returns true, then the > check on line 220 in forte.cpp is not necessary. > > src/share/vm/prims/forte.cpp > line 220: if (!method->is_valid_method()) return false; > Methods can no longer move in the post-PGR world, right? > If that's the case, then this check isn't needed since > the frame was validated on line 199. However, the extra > paranoia doesn't hurt. From hiyangxi at gmail.com Tue Nov 27 20:13:09 2012 From: hiyangxi at gmail.com (Xi Yang) Date: Wed, 28 Nov 2012 15:13:09 +1100 Subject: Report a bug in HotSpot In-Reply-To: <50B4DA5B.5060603@oracle.com> References: <50B3B524.60307@oracle.com> <50B43A2B.4070202@oracle.com> <296A5C5B-6696-43C6-8C6A-10FD32A63D64@oracle.com> <50B4D3FD.4050406@oracle.com> <50B4DA5B.5060603@oracle.com> Message-ID: On 28 November 2012 02:20, Krystal Mo wrote: > Hi Coleen, > > Thank you for the reply. > > Yes, I know that flag, but it doesn't fix the problem demonstrated in the > first test case. > Running that test case with this flag will still show "Double a is NaN" on > 32-bit JDK7u9 on Ubuntu 12.04. It's not about the FPU control word. Right, the problem is "x87 tag word". Regards. > > Regards, > Kris > > > On 2012/11/27 22:53, Coleen Phillimore wrote: >> >> >> We have this flag for this problem: >> >> product(bool, AlwaysRestoreFPU, false, >> \ >> "Restore the FPU control word after every JNI call (expensive)") >> \ >> \ >> >> Coleen >> >> On 11/27/2012 08:01 AM, Karen Kinnear wrote: >>> >>> Hi Kris, >>> >>> I would concur. And there is also an explicit intention to not slow down >>> JNI transitions by having the JVM do extra work. The >>> model is to have the JNI code restore a good state. >>> >>> Looks like we already have a flag that lets you know that you need to fix >>> the jni code, so no need to add another way to do that. >>> >>> thanks, >>> Karen >>> >>> On Nov 26, 2012, at 10:57 PM, David Holmes wrote: >>> >>>> Hi Kris, >>>> >>>> I think historically hotspot assumes/requires JNI code to be well >>>> behaved about these things. There have been some well known issues with FPU >>>> state in the past. I'm not that familiar with MMX so can't say whether it is >>>> reasonable for the VM to know when it has to do this kind of cleanup. >>>> >>>> David >>>> >>>> On 27/11/2012 4:29 AM, Krystal Mo wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Xi Yang has reported a bug in HotSpot's interpreter that it doesn't >>>>> empty the FPU stack on return from JNI calls. His mail is included >>>>> below. >>>>> >>>>> e.g. If a native function called via JNI is using MMX registers without >>>>> emptying the FPU stack before returning, then after returning to Java >>>>> the FPU stack will be in a bad state. >>>>> >>>>> The test case Xi gave is demonstrated here on JDK7u9, x86: >>>>> https://gist.github.com/4148771 >>>>> Running the example with -XX:+VerifyFPU shows what's going on. >>>>> >>>>> This test case shows the bug affecting 32-bit x86 version of HotSpot's >>>>> interpreter. >>>>> >>>>> Not really familiar with how to file a bug on JBS yet, I'll file a bug >>>>> to track this after I learn how to do it. >>>>> >>>>> Regards, >>>>> Kris >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Fwd: Report a bug in HotSpot >>>>> Date: Tue, 27 Nov 2012 02:02:59 +0800 >>>>> From: Krystal Mok >>>>> To: Krystal Mo >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Xi Yang >>>>> Date: Tue, Nov 20, 2012 at 1:44 PM >>>>> Subject: Report a bug in HotSpot >>>>> To: Krystal Mok >>>>> >>>>> >>>>> Hi, >>>>> >>>>> It looks like HotSpot does not do "emms" after backing from JNI. Here >>>>> is the code to show the bug. Would you like to try the newest version? >>>>> >>>>> >>>>> Hello.java >>>>> class Hello { >>>>> private static native void abc(); >>>>> public static void main(String[] args) { >>>>> System.out.println("I am main"); >>>>> System.loadLibrary("Hello"); >>>>> abc(); >>>>> long a = 100; >>>>> double b = (double)a; >>>>> System.out.println("Double a is " + b); >>>>> } >>>>> } >>>>> >>>>> Hello.c >>>>> #include >>>>> #include >>>>> >>>>> JNIEXPORT void JNICALL >>>>> Java_Hello_abc(JNIEnv *env, jclass cls) >>>>> { >>>>> printf("I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world\n"); >>>>> unsigned int dummy; >>>>> asm volatile("movd %%mm0, %0\n":"=r"(dummy)); >>>>> printf("dummy is %x\n", dummy); >>>>> } >>>>> >>>>> >>>>> gcc -m32 -shared ./Hello.c -o ./libHello.so >>>>> >>>>> >>>>> /opt/jdk1.7.0/bin/java -Djava.library.path=. Hello >>>>> I am main >>>>> I mmmmmmmmmmmmmmmmmmmmmmmmm java Helo world >>>>> dummy is 0 >>>>> Double a is NaN >>>>> >>>>> >>>>> $ /opt/jdk1.7.0/bin/java -version >>>>> java version "1.7.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.7.0-ea-b93) >>>>> Java HotSpot(TM) Server VM (build 18.0-b04, mixed mode) >>>>> >>>>> >>>>> >> > From david.holmes at oracle.com Tue Nov 27 23:45:19 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 28 Nov 2012 07:45:19 +0000 Subject: hg: hsx/hsx24/hotspot: 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Message-ID: <20121128074525.B1B7E47B68@hg.openjdk.java.net> Changeset: e5977d045076 Author: dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e5977d045076 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp From goetz.lindenmaier at sap.com Wed Nov 28 00:06:33 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 28 Nov 2012 09:06:33 +0100 Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code In-Reply-To: <22088E6D-15CA-44FB-BBDB-822057B1A3DE@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF4B7FF18@DEWDFECCR03.wdf.sap.corp> <22088E6D-15CA-44FB-BBDB-822057B1A3DE@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6C397D5@DEWDFECCR03.wdf.sap.corp> Hi Chris, Yes! And it's used a lot, especially in the generated assembler. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Mittwoch, 28. November 2012 01:13 To: Lindenmaier, Goetz Cc: Morris Meyer; hotspot-dev at openjdk.java.net Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code Quick question: Do you have a non-empty implementation for CodeBuffer::flush_bundle on IA64? -- Chris On Nov 8, 2012, at 12:25 AM, "Lindenmaier, Goetz" wrote: > Hi Morris, > > > > I had a look at your change. As you know we maintain a port for IA64. > > We basically use all the IA64 specific code, although some of the defines > > are obviously superfluous. > > The changes are not that essential that removing them would cause us > > huge problems, but nevertheless we would prefer if most of them stay > > in the code to reduce our deviation from your code. > > > > In more detail: > > > > Code to remove > > ============= > > > > We do not use the agent on ia64, so we don't care about > > agent/src/os/linux/LinuxDebuggerLocal.c > > agent/src/os/linux/libproc.h > > agent/src/os/win32/windbg/sawindbg.cpp > > > > We don't need the code here: > > src/os/bsd/vm/os_bsd.cpp > > > > Here we removed the #define ourselves: > > src/share/vm/interpreter/bytecodeInterpreter.cpp > > src/share/vm/runtime/sharedRuntime.cpp > > src/share/vm/runtime/synchronizer.cpp > > > > Further you can remove > > src/share/vm/runtime/vframeArray.cpp > > > > We can easily work around need_register_stack_bang(), and as it's rather platform > > dependent, just remove it in > > src/share/vm/opto/compile.hpp > > src/share/vm/opto/output.cpp > > > > > > Code to keep > > =========== > > > > This is basic platform support, so keep it please: > > src/share/vm/runtime/vm_version.cpp > > src/share/vm/utilities/macros.hpp > > > > Keep this: > > src/share/vm/prims/forte.cpp > > > > Don't care: > > src/share/vm/runtime/os.cpp > > We extended the code at this place to cover more cases, see below. > > Therefore we don't care about the fix in openJDK. > > Note that our code is also used on AMD64: > > > > // Looks like all platforms except IA64 can use the same function to check > > // if C stack is walkable beyond current frame. The check for fp() is not > > // necessary on Sparc, but it's harmless. > > bool os::is_first_C_frame(frame* fr) { > > #if defined(IA64) && !defined(_WIN32) > > // On IA64 we have to check if the callers bsp is still valid > > // (i.e. within the register stack bounds). > > // Notice: this only works for threads created by the VM and only if > > // we walk the current stack!!! If we want to be able to walk > > // arbitrary other threads, we'll have to somehow store the thread > > // object in the frame. > > Thread *thread = Thread::current(); > > if ((address)fr->fp() <= thread->register_stack_base() HPUX_ONLY(+ 0x0) LINUX_ONLY(+ 0x50)) { > > // This check is a little hacky, because on Linux the frist C > > // frame's ('start_thread') register stack frame starts at > > // "register_stack_base + 0x48" while on HPUX, the first C frame's > > // ('__pthread_bound_body') register stack frame seems to really > > // start at "register_stack_base". > > return true; > > } else { > > return false; > > } > > // On Windows AMD64 link() does not work as there's no back link on the stack. > > #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) > > return true; > > #else > > // Load up sp, fp, sender sp and sender fp, check for reasonable values. > > // Check usp first, because if that's bad the other accessors may fault > > // on some architectures. Ditto ufp second, etc. > > uintptr_t fp_align_mask = (uintptr_t)(sizeof(address)-1); > > > > > > The extension of the frame_slots in > > src/share/vm/opto/output.cpp > > is only needed for the _zap_dead_*_locals stubs. But better keep it. > > > > We use most of the code in os_linux.cpp as is, please keep it. > > src/os/linux/vm/os_linux.cpp > > > > There are two patches where you could improve the code: > > > > You could use IA64_ONLY(* 2) here: > > > > @@ -1174,12 +1170,7 @@ > > // for initial thread if its stack size exceeds 6M. Cap it at 2M, > > // in case other parts in glibc still assumes 2M max stack size. > > // FIXME: alt signal stack is gone, maybe we can relax this constraint? > > -#ifndef IA64 > > if (stack_size > 2 * K * K) stack_size = 2 * K * K; > > -#else > > - // Problem still exists RH7.2 (IA64 anyway) but 2MB is a little small > > - if (stack_size > 4 * K * K) stack_size = 4 * K * K; > > -#endif > > > > // Try to figure out where the stack base (top) is. This is harder. > > // > > > > You can apply this patch, instead I implemented the two functions empty > > in the platform file. > > > > @@ -4385,16 +4373,12 @@ > > if (is_NPTL()) { > > return pthread_cond_timedwait(_cond, _mutex, _abstime); > > } else { > > -#ifndef IA64 > > // 6292965: LinuxThreads pthread_cond_timedwait() resets FPU control > > // word back to default 64bit precision if condvar is signaled. Java > > // wants 53bit precision. Save and restore current value. > > int fpu = get_fpu_control_word(); > > -#endif // IA64 > > int status = pthread_cond_timedwait(_cond, _mutex, _abstime); > > -#ifndef IA64 > > set_fpu_control_word(fpu); > > -#endif // IA64 > > return status; > > } > > } > > > > We use all of the #defines/#ifdefs here: > > src/os/windows/vm/os_windows.cpp > > But we changed the IA64 specific code a lot. > > > > It's unclear whether this change is needed: > > src/share/vm/oops/oop.inline.hpp > > but to avoid a regression we would like to keep it. Maybe it > > would be better to protect the change by > > #if defined(IA64) && defined(_WIN32) > > as it's done at other shared code locations. > > > > Best regards, > > Goetz > > > > > > > > > > > > > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Montag, 5. November 2012 11:25 > To: Morris Meyer > Cc: Lindenmaier, Goetz > Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code > > > > Hi Morris, > > > > we had a long weekend last week because last Thursday was public > > holiday in Germany, but my colleague Goetz is currently looking at the > > change and will come back to you. > > > > Thank you and best regards, > > Volker > > > > On Fri, Nov 2, 2012 at 10:42 PM, Morris Meyer > wrote: > >> Volker, > >> > >> Have you had a chance to review my changes for this bug? > >> > >> Thanks in advance, > >> > >> --morris From bengt.rutisson at oracle.com Wed Nov 28 01:21:15 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 28 Nov 2012 10:21:15 +0100 Subject: RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table In-Reply-To: <50B51153.1050704@oracle.com> References: <50AC2714.2070801@oracle.com> <50AC9018.2040008@oracle.com> <50B51153.1050704@oracle.com> Message-ID: <50B5D78B.9050507@oracle.com> Ship it! Bengt On 2012-11-27 20:15, John Cuthbertson wrote: > Hi Ramki, Bengt, > > Thanks for the reviews. I've changed the added messages to include > whitespace around the format macros. > > Regards, > > JohnC > > On 11/21/12 00:26, Bengt Rutisson wrote: >> >> Looks good to me too. >> >> I like that you introduced the check_index() and check_offset() methods. >> >> One style question. You are using the format macros without white >> spaces. After grepping a bit in the hotspot source I think it is more >> common to have white spaces when using these. So instead of >> "..."SIZE_FORMAT"..", "..."UINT32_FORMAT"..." etc I think it would be >> more hotspot-like to use "..." SIZE_FORMAT "..." and "..." >> UINT32_FORMAT "...". >> >> Bengt >> >> >> On 2012-11-21 02:40, Srinivas Ramakrishna wrote: >>> Looks good to me. >>> >>> -- ramki >>> >>> On Tue, Nov 20, 2012 at 4:57 PM, John Cuthbertson < >>> john.cuthbertson at oracle.com> wrote: >>> >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers review the changes at: >>>> http://cr.openjdk.java.net/~**johnc/7194633/webrev.0? >>>> >>>> >>>> Background: >>>> >>>> While I was testing the fix for 719066 I ran into several >>>> assertions and >>>> guarantee failures from G1's block offset table when running >>>> through jprt. >>>> The failures were associated with using a specific version of the >>>> sparc >>>> memset to initialize the offsets array (see 7192128) which was >>>> missing from >>>> my 7190666 workspace. The changes in this webrev are the >>>> instrumenation and >>>> detailed error message changes I made to verify that G1's block offset >>>> table was not immune to the memset issue and that the failures from >>>> jprt >>>> were the same issue. These detailed error messages were invaluable >>>> when >>>> tracking the issue down. >>>> >>>> Testing: >>>> GCBasher with -UseMemsetInBOT on sparc >>>> Forcibly triggering the failures to check that the error messages made >>>> sense. >>>> jprt >>>> >>>> It is still my intent to merge G1's BOT with that of the other >>>> collectors >>>> and remove the large amount of duplicated code (which is a separate >>>> CR). >>>> When I do that, the detailed error messages will be included in the >>>> shared >>>> BOT code. >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >> > From coleen.phillimore at oracle.com Wed Nov 28 07:27:57 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 28 Nov 2012 10:27:57 -0500 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50B5427A.2080307@oracle.com> References: <50AC0329.8080800@oracle.com> <50AC49D7.9050306@oracle.com> <50AD0BAB.2020604@oracle.com> <50B5427A.2080307@oracle.com> Message-ID: <50B62D7D.2070108@oracle.com> Thank you Serguei! I was waiting for another review. I'm glad they are happy with this. Coleen On 11/27/2012 5:45 PM, serguei.spitsyn at oracle.com wrote: > If you still need it, the fix looks good. > Also, the Solaris studio guys are pretty happy with this fix. :) > > Thanks, > Serguei > > On 11/21/12 9:13 AM, Coleen Phillimore wrote: >> >> Thanks again for the code review, David. >> >> On 11/20/2012 10:26 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 21/11/2012 8:24 AM, Coleen Phillimore wrote: >>>> Summary: Make metaspace::contains be lock free and used to see if >>> >>> I don't think this is 100% valid without assuming TSO. Your are >>> growing a linked list of nodes under a lock, but allowing the >>> existing list to be iterated without a lock. You have to ensure that >>> a VirtualSpaceNode can't be seen in the list prior to being properly >>> initialized - I know the code in VirtualSpaceNode::initialize makes >>> it unlikely, but I wouldn't want to second-guess how the compiler >>> and/or hardware might reorder things. To be safe I think you need: >>> >>> 980 // Allocate the meta virtual space and initialize it. >>> 981 VirtualSpaceNode* new_entry = new >>> VirtualSpaceNode(vs_byte_size); >>> 982 if (!new_entry->initialize()) { >>> 983 delete new_entry; >>> 984 return false; >>> 985 } else { >>> + // ensure lock-free iteration sees fully initialized node >>> + OrderAccess:storeStore(); >>> 986 link_vs(new_entry, vs_word_size); >>> 987 return true; >>> 988 } >> >> Thank you! I added the OrderAccess call. I feel better about the >> safety of walking this lock free now. >>> >>>> something is in metaspace, also compare Method* with vtbl pointer. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ >>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 >>> >>> Do the comments in forte.cpp regarding the unsafe reference to the >>> method not still apply? >>> >> >> There are better comments above this comment. The interpreter frame >> could be partially constructed when AsyncGetCallTrace picks it up. >> We no longer have to worry about GC making the Method* invalid >> (except for bugid 8003720 >> ). The second check >> is probably not strictly necessary since that was what it was >> checking, but for safety I want to leave it in. >> >> Thanks, >> Coleen >>> Cheers, >>> David >>> ----- >>> >>>> Tested with full NSK testlist on linux 32. Studio tools group also >>>> tested this. >>>> >>>> Thanks, >>>> Coleen >> > From coleen.phillimore at oracle.com Wed Nov 28 09:02:45 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 28 Nov 2012 12:02:45 -0500 Subject: Request for review 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call In-Reply-To: <50B5782A.7020507@oracle.com> References: <50AC0329.8080800@oracle.com> <50B5782A.7020507@oracle.com> Message-ID: <50B643B5.9090909@oracle.com> Thank you for doing this review, Dan. In response to one of your comments below, I made a change to globalDefinitions.hpp to add dereference_vptr() to get the vptr for an object, so that the assumption in a couple of places is in a file that can refactor for compiler differences if they exist. http://cr.openjdk.java.net/~coleenp/8003635_2/ On 11/27/2012 9:34 PM, Daniel D. Daugherty wrote: > On 11/20/12 3:24 PM, Coleen Phillimore wrote: >> Summary: Make metaspace::contains be lock free and used to see if >> something is in metaspace, also compare Method* with vtbl pointer. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003635/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8003635 >> >> Tested with full NSK testlist on linux 32. Studio tools group also >> tested this. >> >> Thanks, >> Coleen > > Thumbs up! And a very nice catch by David H in > VirtualSpaceList::grow_vs(). > > Dan > > > src/share/vm/gc_interface/collectedHeap.hpp > src/share/vm/gc_interface/collectedHeap.inline.hpp > Moving CollectedHeap::is_valid_method() to Method::is_valid_method() > makes sense since methods aren't in the heap anymore. > > src/share/vm/memory/allocation.cpp > No comments. > > src/share/vm/memory/metaspace.hpp > Was: > bool contains(const void *ptr) const; > > and is now: > > static bool contains(const void *ptr); > > So why was the trailing "const" dropped? > "const" applies to the "this" pointer and making it static means there isn't a "this" pointer. > src/share/vm/memory/metaspace.cpp > No comments except I don't see the changes that David Holmes > requested so I'm going to guess that you didn't refresh the > webrev in place. I'm OK if you didn't. I haven't replaced the webrev. > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/oops/method.cpp > line 1820: if (this == NULL) { > If "this" is NULL, then how did this non-static is_valid_method() > function get called? Or is my brain confusing Java "this" versus > C++ "this"? David answered this "this" question. > > lines 1825-1828: vtable pointer matching? The skeptic in me wonders > how portable such a construct is across various C++ compilers. > It's not portable except every C++ compiler puts the main vtbl pointer as the first word in a class. I'll add a comment though. This assumption is also made in universe.cpp for CDS vtbl pointer patching. I just added a deference_vptr in globalDefinitions.hpp with a comment about it's portability. Will post another webrev. > line 1952: guarantee(md == NULL || > line 1953: md->is_metadata(), "should be in permspace"); > Not part of your change, but this mention of "permspace" > caught my eye. I'm not caught on all the post-PGR terms, > but is this the right word to use? The guarantee() on line > 1950 says "should be metadata"... I think we have a lot of these left over. > > src/cpu/sparc/vm/frame_sparc.cpp > line 651: if (!m->is_valid_method()) return false; > In the post-PGR world, if this call to > frame::is_interpreted_frame_valid() returns true, then the > check on line 220 in forte.cpp is not necessary. Yes, I realized this but was afraid to change it. I'm still wary of changing more since I wasn't able to test this properly myself. > > src/cpu/x86/vm/frame_x86.cpp > line 537: if (!m->is_valid_method()) return false; > In the post-PGR world, if this call to > frame::is_interpreted_frame_valid() returns true, then the > check on line 220 in forte.cpp is not necessary. > > src/share/vm/prims/forte.cpp > line 220: if (!method->is_valid_method()) return false; > Methods can no longer move in the post-PGR world, right? > If that's the case, then this check isn't needed since > the frame was validated on line 199. However, the extra > paranoia doesn't hurt. I completely agree. The extra paranoia doesn't really hurt anything here. Thanks! Coleen From christian.thalinger at oracle.com Wed Nov 28 10:11:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 28 Nov 2012 10:11:43 -0800 Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6C397D5@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF4B7FF18@DEWDFECCR03.wdf.sap.corp> <22088E6D-15CA-44FB-BBDB-822057B1A3DE@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6C397D5@DEWDFECCR03.wdf.sap.corp> Message-ID: <5BD70388-B6FA-4398-852E-A32D818E1AF5@oracle.com> That's what I expected. I just double checked. -- Chris On Nov 28, 2012, at 12:06 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > > Yes! > And it's used a lot, especially in the generated assembler. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Mittwoch, 28. November 2012 01:13 > To: Lindenmaier, Goetz > Cc: Morris Meyer; hotspot-dev at openjdk.java.net > Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code > > Quick question: Do you have a non-empty implementation for CodeBuffer::flush_bundle on IA64? > > -- Chris > > On Nov 8, 2012, at 12:25 AM, "Lindenmaier, Goetz" wrote: > >> Hi Morris, >> >> >> >> I had a look at your change. As you know we maintain a port for IA64. >> >> We basically use all the IA64 specific code, although some of the defines >> >> are obviously superfluous. >> >> The changes are not that essential that removing them would cause us >> >> huge problems, but nevertheless we would prefer if most of them stay >> >> in the code to reduce our deviation from your code. >> >> >> >> In more detail: >> >> >> >> Code to remove >> >> ============= >> >> >> >> We do not use the agent on ia64, so we don't care about >> >> agent/src/os/linux/LinuxDebuggerLocal.c >> >> agent/src/os/linux/libproc.h >> >> agent/src/os/win32/windbg/sawindbg.cpp >> >> >> >> We don't need the code here: >> >> src/os/bsd/vm/os_bsd.cpp >> >> >> >> Here we removed the #define ourselves: >> >> src/share/vm/interpreter/bytecodeInterpreter.cpp >> >> src/share/vm/runtime/sharedRuntime.cpp >> >> src/share/vm/runtime/synchronizer.cpp >> >> >> >> Further you can remove >> >> src/share/vm/runtime/vframeArray.cpp >> >> >> >> We can easily work around need_register_stack_bang(), and as it's rather platform >> >> dependent, just remove it in >> >> src/share/vm/opto/compile.hpp >> >> src/share/vm/opto/output.cpp >> >> >> >> >> >> Code to keep >> >> =========== >> >> >> >> This is basic platform support, so keep it please: >> >> src/share/vm/runtime/vm_version.cpp >> >> src/share/vm/utilities/macros.hpp >> >> >> >> Keep this: >> >> src/share/vm/prims/forte.cpp >> >> >> >> Don't care: >> >> src/share/vm/runtime/os.cpp >> >> We extended the code at this place to cover more cases, see below. >> >> Therefore we don't care about the fix in openJDK. >> >> Note that our code is also used on AMD64: >> >> >> >> // Looks like all platforms except IA64 can use the same function to check >> >> // if C stack is walkable beyond current frame. The check for fp() is not >> >> // necessary on Sparc, but it's harmless. >> >> bool os::is_first_C_frame(frame* fr) { >> >> #if defined(IA64) && !defined(_WIN32) >> >> // On IA64 we have to check if the callers bsp is still valid >> >> // (i.e. within the register stack bounds). >> >> // Notice: this only works for threads created by the VM and only if >> >> // we walk the current stack!!! If we want to be able to walk >> >> // arbitrary other threads, we'll have to somehow store the thread >> >> // object in the frame. >> >> Thread *thread = Thread::current(); >> >> if ((address)fr->fp() <= thread->register_stack_base() HPUX_ONLY(+ 0x0) LINUX_ONLY(+ 0x50)) { >> >> // This check is a little hacky, because on Linux the frist C >> >> // frame's ('start_thread') register stack frame starts at >> >> // "register_stack_base + 0x48" while on HPUX, the first C frame's >> >> // ('__pthread_bound_body') register stack frame seems to really >> >> // start at "register_stack_base". >> >> return true; >> >> } else { >> >> return false; >> >> } >> >> // On Windows AMD64 link() does not work as there's no back link on the stack. >> >> #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) >> >> return true; >> >> #else >> >> // Load up sp, fp, sender sp and sender fp, check for reasonable values. >> >> // Check usp first, because if that's bad the other accessors may fault >> >> // on some architectures. Ditto ufp second, etc. >> >> uintptr_t fp_align_mask = (uintptr_t)(sizeof(address)-1); >> >> >> >> >> >> The extension of the frame_slots in >> >> src/share/vm/opto/output.cpp >> >> is only needed for the _zap_dead_*_locals stubs. But better keep it. >> >> >> >> We use most of the code in os_linux.cpp as is, please keep it. >> >> src/os/linux/vm/os_linux.cpp >> >> >> >> There are two patches where you could improve the code: >> >> >> >> You could use IA64_ONLY(* 2) here: >> >> >> >> @@ -1174,12 +1170,7 @@ >> >> // for initial thread if its stack size exceeds 6M. Cap it at 2M, >> >> // in case other parts in glibc still assumes 2M max stack size. >> >> // FIXME: alt signal stack is gone, maybe we can relax this constraint? >> >> -#ifndef IA64 >> >> if (stack_size > 2 * K * K) stack_size = 2 * K * K; >> >> -#else >> >> - // Problem still exists RH7.2 (IA64 anyway) but 2MB is a little small >> >> - if (stack_size > 4 * K * K) stack_size = 4 * K * K; >> >> -#endif >> >> >> >> // Try to figure out where the stack base (top) is. This is harder. >> >> // >> >> >> >> You can apply this patch, instead I implemented the two functions empty >> >> in the platform file. >> >> >> >> @@ -4385,16 +4373,12 @@ >> >> if (is_NPTL()) { >> >> return pthread_cond_timedwait(_cond, _mutex, _abstime); >> >> } else { >> >> -#ifndef IA64 >> >> // 6292965: LinuxThreads pthread_cond_timedwait() resets FPU control >> >> // word back to default 64bit precision if condvar is signaled. Java >> >> // wants 53bit precision. Save and restore current value. >> >> int fpu = get_fpu_control_word(); >> >> -#endif // IA64 >> >> int status = pthread_cond_timedwait(_cond, _mutex, _abstime); >> >> -#ifndef IA64 >> >> set_fpu_control_word(fpu); >> >> -#endif // IA64 >> >> return status; >> >> } >> >> } >> >> >> >> We use all of the #defines/#ifdefs here: >> >> src/os/windows/vm/os_windows.cpp >> >> But we changed the IA64 specific code a lot. >> >> >> >> It's unclear whether this change is needed: >> >> src/share/vm/oops/oop.inline.hpp >> >> but to avoid a regression we would like to keep it. Maybe it >> >> would be better to protect the change by >> >> #if defined(IA64) && defined(_WIN32) >> >> as it's done at other shared code locations. >> >> >> >> Best regards, >> >> Goetz >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Volker Simonis [mailto:volker.simonis at gmail.com] >> Sent: Montag, 5. November 2012 11:25 >> To: Morris Meyer >> Cc: Lindenmaier, Goetz >> Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code >> >> >> >> Hi Morris, >> >> >> >> we had a long weekend last week because last Thursday was public >> >> holiday in Germany, but my colleague Goetz is currently looking at the >> >> change and will come back to you. >> >> >> >> Thank you and best regards, >> >> Volker >> >> >> >> On Fri, Nov 2, 2012 at 10:42 PM, Morris Meyer > wrote: >> >>> Volker, >> >> >>> Have you had a chance to review my changes for this bug? >> >> >>> Thanks in advance, >> >> >>> --morris > From zhengyu.gu at oracle.com Wed Nov 28 12:12:22 2012 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Wed, 28 Nov 2012 20:12:22 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20121128201230.1503E47B9A@hg.openjdk.java.net> Changeset: 2c3dca6e1d65 Author: nloodin Date: 2012-09-21 10:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2c3dca6e1d65 7200092: Make NMT a bit friendlier to work with Reviewed-by: kvn, ysr, azeemj ! src/share/vm/services/memTracker.cpp Changeset: 1ba2ed1c07df Author: zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1ba2ed1c07df 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp From coleen.phillimore at oracle.com Wed Nov 28 16:43:01 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 28 Nov 2012 19:43:01 -0500 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50A07BF9.8030509@oracle.com> References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> Message-ID: <50B6AF95.8070607@oracle.com> Please review updated changes to fix the nashorn OOMs from using jsr 292 anonymous classes. The changes to fix bug 8003720 NPG: Method in interpreter stack frame can be deallocated have been removed from this changeset in favor of the change that Stefan checked in on Monday. Note - there is no target-specific code in this change now. Other changes since last webrev are several cleanups from internal discussions. open webrev at http://cr.openjdk.java.net/~coleenp/8000662_3/ bug link at http://bugs.sun.com/view_bug.do?bug_id=8000662_3 Retesting with NSK vm tests. I'll try to describe things better below in reply to David's questions. On 11/11/2012 11:32 PM, David Holmes wrote: > Hi Coleen, > > :) > > Can you explain the old and new relationships between these various > objects please. As I understand it JSR-292 introduced this special > kind of class - the anonymous class - and they differ from regular > classes in important ways (mainly that they can be collected before > their classloader), and pre-NPG this all "just worked". The NPG > changes added the ClassLoaderData metadata objects and changed some of > the associations that anonymous classes actually relied upon and as a > result they stopped getting GC'd in some cases, and were prematurely > GC'd in others (I hope I got that right). This changeset addresses > these problems. This is correct. I don't think I could have written this better. Yes, in the old Permgen world, when the MethodHandles that contained the mirror to the anonymous class was unreferenced, the klass and all the metadata associated with it would be collected. Now with ClassLoaderData objects, collection of metadata is tied to these objects. The initial naive implementation just added the anonymous classes to the host_klass's ClassLoaderData object, which before b63 (I think) was the boot class loader. So the anonymous classes were never collected. This changeset gives each anonymous class it's own ClassLoaderData object and uses it's java_mirror to determine whether the anonymous class is still live and whether the ClassLoaderData object can be unloaded. We have been doing some tuning to determine how large the metaspace should be for these special cases. That is ongoing. > > I've been trying to follow this from the beginning and still don't > have a clear understanding on what the relationships between > ClassLoader, Class, "anonymous class" and ClassLoaderData objects are. > So a clear picture of what relationships exist (particularly this new > 1:N association) would be appreciated, and help make the code changes > more understandable to me. I can't draw pictures without a whiteboard! But you may have several CLD objects that correspond to one class_loader oop. Each CLD object points to the class_loader, but the class_loader only points to the primary CLD object. The additional CLD objects are for anonymous classes, which are kept live by their mirrors, not the class_loader. That's the source of many of the changes in this changeset. Thanks, Coleen > > Thanks, > David > > On 12/11/2012 1:51 PM, Coleen Phillimore wrote: >> >> This change creates a ClassLoaderData object for each JSR 292 anonymous >> class, so that the metadata and mirror object for the anonymous class >> can be reclaimed when the anonymous class is no longer referenced. The >> java_lang_ClassLoader object for the anonymous class is the same as its >> host_class. Most of this change is to break the assumption that there's >> a 1-1 relationship between java_lang_ClassLoader Java objects and >> ClassLoaderData metadata objects in the VM. Also, nmethods and other >> things that were strong roots for java_lang_ClassLoader objects have to >> also be strong roots for java_lang_Class objects for anonymous classes. >> >> There were also changes to move the dependencies out of the >> java_lang_ClassLoader object to the ClassLoaderData type. This type is >> preallocated so that CMS will have card marks to track additions to the >> dependencies. Please check this, Stefan! >> >> Also, in this change is the addition of mirrors to the interpreter frame >> and a test case that shows why this is necessary. An interpreter frame >> can be running while it's class loader is unloaded in some special >> circumstances. It is easier to do this with JSR292 static MethodHandle >> code. Some people are looking for a platform independent way to do this, >> by changing code in GC. While this target-dependent interpreter code is >> unfortunate, the concept is simple. If the latter effort succeeds, we >> can remove the mirror from the interpreter frame later. A note to >> openjdk developers - I added this mirror to zero but not to shark. More >> testing is necessary. >> >> Please review the following change: >> >> Summary: Add ClassLoaderData object for each anonymous class with >> metaspaces to allocate in. Add mirror interpreter frame. >> >> http://cr.openjdk.java.net/~coleenp/8000662/ >> http://bugs.sun.com/view_bug.do?bug_id=8000662 >> >> Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. >> >> Thanks, >> Coleen From christian.thalinger at oracle.com Wed Nov 28 17:15:14 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 28 Nov 2012 17:15:14 -0800 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50B6AF95.8070607@oracle.com> References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> <50B6AF95.8070607@oracle.com> Message-ID: On Nov 28, 2012, at 4:43 PM, Coleen Phillimore wrote: > > Please review updated changes to fix the nashorn OOMs from using jsr 292 anonymous classes. The changes to fix bug 8003720 NPG: Method in interpreter stack frame can be deallocated have been removed from this changeset in favor of the change that Stefan checked in on Monday. Note - there is no target-specific code in this change now. > > Other changes since last webrev are several cleanups from internal discussions. > > open webrev at http://cr.openjdk.java.net/~coleenp/8000662_3/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8000662_3 > > Retesting with NSK vm tests. I'll try to describe things better below in reply to David's questions. src/share/vm/prims/unsafe.cpp: + // this point. The mirror any any instances of this class have to keep Typo. Otherwise this looks good. Thanks for fixing it. -- Chris > > On 11/11/2012 11:32 PM, David Holmes wrote: >> Hi Coleen, >> >> :) >> >> Can you explain the old and new relationships between these various objects please. As I understand it JSR-292 introduced this special kind of class - the anonymous class - and they differ from regular classes in important ways (mainly that they can be collected before their classloader), and pre-NPG this all "just worked". The NPG changes added the ClassLoaderData metadata objects and changed some of the associations that anonymous classes actually relied upon and as a result they stopped getting GC'd in some cases, and were prematurely GC'd in others (I hope I got that right). This changeset addresses these problems. > > This is correct. I don't think I could have written this better. Yes, in the old Permgen world, when the MethodHandles that contained the mirror to the anonymous class was unreferenced, the klass and all the metadata associated with it would be collected. Now with ClassLoaderData objects, collection of metadata is tied to these objects. The initial naive implementation just added the anonymous classes to the host_klass's ClassLoaderData object, which before b63 (I think) was the boot class loader. So the anonymous classes were never collected. > > This changeset gives each anonymous class it's own ClassLoaderData object and uses it's java_mirror to determine whether the anonymous class is still live and whether the ClassLoaderData object can be unloaded. > > We have been doing some tuning to determine how large the metaspace should be for these special cases. That is ongoing. > >> >> I've been trying to follow this from the beginning and still don't have a clear understanding on what the relationships between ClassLoader, Class, "anonymous class" and ClassLoaderData objects are. So a clear picture of what relationships exist (particularly this new 1:N association) would be appreciated, and help make the code changes more understandable to me. > > I can't draw pictures without a whiteboard! But you may have several CLD objects that correspond to one class_loader oop. Each CLD object points to the class_loader, but the class_loader only points to the primary CLD object. The additional CLD objects are for anonymous classes, which are kept live by their mirrors, not the class_loader. That's the source of many of the changes in this changeset. > > Thanks, > Coleen > >> >> Thanks, >> David >> >> On 12/11/2012 1:51 PM, Coleen Phillimore wrote: >>> >>> This change creates a ClassLoaderData object for each JSR 292 anonymous >>> class, so that the metadata and mirror object for the anonymous class >>> can be reclaimed when the anonymous class is no longer referenced. The >>> java_lang_ClassLoader object for the anonymous class is the same as its >>> host_class. Most of this change is to break the assumption that there's >>> a 1-1 relationship between java_lang_ClassLoader Java objects and >>> ClassLoaderData metadata objects in the VM. Also, nmethods and other >>> things that were strong roots for java_lang_ClassLoader objects have to >>> also be strong roots for java_lang_Class objects for anonymous classes. >>> >>> There were also changes to move the dependencies out of the >>> java_lang_ClassLoader object to the ClassLoaderData type. This type is >>> preallocated so that CMS will have card marks to track additions to the >>> dependencies. Please check this, Stefan! >>> >>> Also, in this change is the addition of mirrors to the interpreter frame >>> and a test case that shows why this is necessary. An interpreter frame >>> can be running while it's class loader is unloaded in some special >>> circumstances. It is easier to do this with JSR292 static MethodHandle >>> code. Some people are looking for a platform independent way to do this, >>> by changing code in GC. While this target-dependent interpreter code is >>> unfortunate, the concept is simple. If the latter effort succeeds, we >>> can remove the mirror from the interpreter frame later. A note to >>> openjdk developers - I added this mirror to zero but not to shark. More >>> testing is necessary. >>> >>> Please review the following change: >>> >>> Summary: Add ClassLoaderData object for each anonymous class with >>> metaspaces to allocate in. Add mirror interpreter frame. >>> >>> http://cr.openjdk.java.net/~coleenp/8000662/ >>> http://bugs.sun.com/view_bug.do?bug_id=8000662 >>> >>> Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. >>> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Wed Nov 28 17:34:49 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 28 Nov 2012 20:34:49 -0500 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> <50B6AF95.8070607@oracle.com> Message-ID: <50B6BBB9.20107@oracle.com> Chris, Thank you for the quick review! I fixed the typo. Coleen On 11/28/2012 8:15 PM, Christian Thalinger wrote: > On Nov 28, 2012, at 4:43 PM, Coleen Phillimore wrote: > >> Please review updated changes to fix the nashorn OOMs from using jsr 292 anonymous classes. The changes to fix bug 8003720 NPG: Method in interpreter stack frame can be deallocated have been removed from this changeset in favor of the change that Stefan checked in on Monday. Note - there is no target-specific code in this change now. >> >> Other changes since last webrev are several cleanups from internal discussions. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8000662_3/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8000662_3 >> >> Retesting with NSK vm tests. I'll try to describe things better below in reply to David's questions. > src/share/vm/prims/unsafe.cpp: > > + // this point. The mirror any any instances of this class have to keep > > Typo. > > Otherwise this looks good. Thanks for fixing it. > > -- Chris > >> On 11/11/2012 11:32 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> :) >>> >>> Can you explain the old and new relationships between these various objects please. As I understand it JSR-292 introduced this special kind of class - the anonymous class - and they differ from regular classes in important ways (mainly that they can be collected before their classloader), and pre-NPG this all "just worked". The NPG changes added the ClassLoaderData metadata objects and changed some of the associations that anonymous classes actually relied upon and as a result they stopped getting GC'd in some cases, and were prematurely GC'd in others (I hope I got that right). This changeset addresses these problems. >> This is correct. I don't think I could have written this better. Yes, in the old Permgen world, when the MethodHandles that contained the mirror to the anonymous class was unreferenced, the klass and all the metadata associated with it would be collected. Now with ClassLoaderData objects, collection of metadata is tied to these objects. The initial naive implementation just added the anonymous classes to the host_klass's ClassLoaderData object, which before b63 (I think) was the boot class loader. So the anonymous classes were never collected. >> >> This changeset gives each anonymous class it's own ClassLoaderData object and uses it's java_mirror to determine whether the anonymous class is still live and whether the ClassLoaderData object can be unloaded. >> >> We have been doing some tuning to determine how large the metaspace should be for these special cases. That is ongoing. >> >>> I've been trying to follow this from the beginning and still don't have a clear understanding on what the relationships between ClassLoader, Class, "anonymous class" and ClassLoaderData objects are. So a clear picture of what relationships exist (particularly this new 1:N association) would be appreciated, and help make the code changes more understandable to me. >> I can't draw pictures without a whiteboard! But you may have several CLD objects that correspond to one class_loader oop. Each CLD object points to the class_loader, but the class_loader only points to the primary CLD object. The additional CLD objects are for anonymous classes, which are kept live by their mirrors, not the class_loader. That's the source of many of the changes in this changeset. >> >> Thanks, >> Coleen >> >>> Thanks, >>> David >>> >>> On 12/11/2012 1:51 PM, Coleen Phillimore wrote: >>>> This change creates a ClassLoaderData object for each JSR 292 anonymous >>>> class, so that the metadata and mirror object for the anonymous class >>>> can be reclaimed when the anonymous class is no longer referenced. The >>>> java_lang_ClassLoader object for the anonymous class is the same as its >>>> host_class. Most of this change is to break the assumption that there's >>>> a 1-1 relationship between java_lang_ClassLoader Java objects and >>>> ClassLoaderData metadata objects in the VM. Also, nmethods and other >>>> things that were strong roots for java_lang_ClassLoader objects have to >>>> also be strong roots for java_lang_Class objects for anonymous classes. >>>> >>>> There were also changes to move the dependencies out of the >>>> java_lang_ClassLoader object to the ClassLoaderData type. This type is >>>> preallocated so that CMS will have card marks to track additions to the >>>> dependencies. Please check this, Stefan! >>>> >>>> Also, in this change is the addition of mirrors to the interpreter frame >>>> and a test case that shows why this is necessary. An interpreter frame >>>> can be running while it's class loader is unloaded in some special >>>> circumstances. It is easier to do this with JSR292 static MethodHandle >>>> code. Some people are looking for a platform independent way to do this, >>>> by changing code in GC. While this target-dependent interpreter code is >>>> unfortunate, the concept is simple. If the latter effort succeeds, we >>>> can remove the mirror from the interpreter frame later. A note to >>>> openjdk developers - I added this mirror to zero but not to shark. More >>>> testing is necessary. >>>> >>>> Please review the following change: >>>> >>>> Summary: Add ClassLoaderData object for each anonymous class with >>>> metaspaces to allocate in. Add mirror interpreter frame. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8000662/ >>>> http://bugs.sun.com/view_bug.do?bug_id=8000662 >>>> >>>> Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. >>>> >>>> Thanks, >>>> Coleen From aleksey.shipilev at oracle.com Thu Nov 29 02:52:04 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Nov 2012 14:52:04 +0400 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B4FF15.6090304@oracle.com> References: <50B4FF15.6090304@oracle.com> Message-ID: <50B73E54.8020800@oracle.com> Anyone? Thanks, Aleksey. On 11/27/2012 09:57 PM, Aleksey Shipilev wrote: > Hi, > > This is the daizy-fresh thread for reviewing the actual changes to > support the JEP-142 in HotSpot. Please address API issues about > @Contended to concurrency-interest list, Doug had started the thread here: > > http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010208.html > > We are not discussing the design, API and all the general stuff here, > only the reference implementation. I would like to have someone extra > knowledgeable in HotSpot codebase to see whether I do anything stupid there. > > The webrev for the change is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ > > Notable differences against latest version: > - a little denser packing in some corner cases > - support @Contended for static fields > - moved @Contended to sun.misc (go and nag at c-i@ about this) > - bugfixes > > Testing: > - hotspot/test/runtime/8003985/Test8003985 on Linux x86_64 > - jprt, specjvm98 quick run > - jprt full cycle is underway, looking good > > Thanks, > Aleksey. > From goetz.lindenmaier at sap.com Thu Nov 29 03:16:18 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 29 Nov 2012 12:16:18 +0100 Subject: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code In-Reply-To: <50B6604A.70102@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF4B7FF18@DEWDFECCR03.wdf.sap.corp> <50B6604A.70102@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6D1B4C3@DEWDFECCR03.wdf.sap.corp> Hi Morris, I applied the patch I got from you wherever useful to our code. Wherever we changed in places your patch mentions, I included our changes. You find the result here: http://cr.openjdk.java.net/~goetz/webrevs/6518907-sap/ Best regards, Goetz. From: Morris Meyer [mailto:morris.meyer at oracle.com] Sent: Mittwoch, 28. November 2012 20:05 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR (small) 6518907: purge IA64 platform-specific ifdefs in source code On 11/8/12 3:25 AM, Lindenmaier, Goetz wrote: We use all of the #defines/#ifdefs here: src/os/windows/vm/os_windows.cpp But we changed the IA64 specific code a lot. Would you like to harmonize those changes to os_windows.cpp at this time? --mm From stefan.karlsson at oracle.com Thu Nov 29 04:12:55 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 29 Nov 2012 13:12:55 +0100 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50B6AF95.8070607@oracle.com> References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> <50B6AF95.8070607@oracle.com> Message-ID: <50B75147.70805@oracle.com> Hi Coleen, I took a closer look at the ClassLoaderData::anonymous_class_loader_data: I'm wondering if we have a potential bug in that code. Here's a some pseudo code for that: cld = new ClassLoaderData(loader) put_on_cld_list(cld) // GC can now find it init_dependencies // GC can occur at this line cld->set_keep_alive(true) // We mark that this CLD should be considered live by the GC I think the set_keep_alive call should be done before init_dependencies are set up. Otherwise this CLD might be prematurely unloaded. Some minor comments: http://cr.openjdk.java.net/~coleenp/8000662_3/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.patch Unrelated whitespace change. http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/classLoaderData.cpp.udiff.html is_alive isn't used anymore: + void ClassLoaderData::unload(BoolObjectClosure* is_alive) { I think we are using the wrong abstraction when we are looking at the claimed bits here. I'll revisit this code after this has been pushed. - if (data->class_loader() == NULL || is_alive->do_object_b(data->class_loader())) { - assert(data->claimed(), "class loader data must have been claimed"); + if (data->claimed() || data->keep_alive()) { + assert(data->class_loader() == NULL || is_alive->do_object_b(data->class_loader()), "class loader data must be live"); http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/classLoaderData.hpp.patch Unnecessary change: bool is_unloading() const { - assert(!(is_the_null_class_loader_data() && _unloading), "The null class loader can never be unloaded"); + assert(!(this == the_null_class_loader_data() && _unloading), "The null class loader can never be unloaded"); return _unloading; } http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/systemDictionary.cpp.patch I don't know if this is needed or not. I thought we would have registered some sort of object in the resolved_references to keep the mirror alive. But I guess that's not the case. (*appendix_result) = Handle(THREAD, appendix); + // the target is stored in the cpCache and if a reference to this + // MethodName is dropped we need a way to make sure the + // class_loader containing this method is kept alive. + ClassLoaderData* this_key = InstanceKlass::cast(accessing_klass())->class_loader_data(); + this_key->record_dependency(m->method_holder(), CHECK_NULL); // Can throw OOM return methodHandle(THREAD, m); } StefanK On 11/29/2012 01:43 AM, Coleen Phillimore wrote: > > Please review updated changes to fix the nashorn OOMs from using jsr > 292 anonymous classes. The changes to fix bug 8003720 NPG: Method in > interpreter stack frame can be deallocated > have been removed > from this changeset in favor of the change that Stefan checked in on > Monday. Note - there is no target-specific code in this change now. > > Other changes since last webrev are several cleanups from internal > discussions. > > open webrev at http://cr.openjdk.java.net/~coleenp/8000662_3/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=8000662_3 > > Retesting with NSK vm tests. I'll try to describe things better > below in reply to David's questions. > > On 11/11/2012 11:32 PM, David Holmes wrote: >> Hi Coleen, >> >> :) >> >> Can you explain the old and new relationships between these various >> objects please. As I understand it JSR-292 introduced this special >> kind of class - the anonymous class - and they differ from regular >> classes in important ways (mainly that they can be collected before >> their classloader), and pre-NPG this all "just worked". The NPG >> changes added the ClassLoaderData metadata objects and changed some >> of the associations that anonymous classes actually relied upon and >> as a result they stopped getting GC'd in some cases, and were >> prematurely GC'd in others (I hope I got that right). This changeset >> addresses these problems. > > This is correct. I don't think I could have written this better. Yes, > in the old Permgen world, when the MethodHandles that contained the > mirror to the anonymous class was unreferenced, the klass and all the > metadata associated with it would be collected. Now with > ClassLoaderData objects, collection of metadata is tied to these > objects. The initial naive implementation just added the anonymous > classes to the host_klass's ClassLoaderData object, which before b63 > (I think) was the boot class loader. So the anonymous classes were > never collected. > > This changeset gives each anonymous class it's own ClassLoaderData > object and uses it's java_mirror to determine whether the anonymous > class is still live and whether the ClassLoaderData object can be > unloaded. > > We have been doing some tuning to determine how large the metaspace > should be for these special cases. That is ongoing. > >> >> I've been trying to follow this from the beginning and still don't >> have a clear understanding on what the relationships between >> ClassLoader, Class, "anonymous class" and ClassLoaderData objects >> are. So a clear picture of what relationships exist (particularly >> this new 1:N association) would be appreciated, and help make the >> code changes more understandable to me. > > I can't draw pictures without a whiteboard! But you may have several > CLD objects that correspond to one class_loader oop. Each CLD object > points to the class_loader, but the class_loader only points to the > primary CLD object. The additional CLD objects are for anonymous > classes, which are kept live by their mirrors, not the class_loader. > That's the source of many of the changes in this changeset. > > Thanks, > Coleen > >> >> Thanks, >> David >> >> On 12/11/2012 1:51 PM, Coleen Phillimore wrote: >>> >>> This change creates a ClassLoaderData object for each JSR 292 anonymous >>> class, so that the metadata and mirror object for the anonymous class >>> can be reclaimed when the anonymous class is no longer referenced. The >>> java_lang_ClassLoader object for the anonymous class is the same as its >>> host_class. Most of this change is to break the assumption that there's >>> a 1-1 relationship between java_lang_ClassLoader Java objects and >>> ClassLoaderData metadata objects in the VM. Also, nmethods and other >>> things that were strong roots for java_lang_ClassLoader objects have to >>> also be strong roots for java_lang_Class objects for anonymous classes. >>> >>> There were also changes to move the dependencies out of the >>> java_lang_ClassLoader object to the ClassLoaderData type. This type is >>> preallocated so that CMS will have card marks to track additions to the >>> dependencies. Please check this, Stefan! >>> >>> Also, in this change is the addition of mirrors to the interpreter >>> frame >>> and a test case that shows why this is necessary. An interpreter frame >>> can be running while it's class loader is unloaded in some special >>> circumstances. It is easier to do this with JSR292 static MethodHandle >>> code. Some people are looking for a platform independent way to do >>> this, >>> by changing code in GC. While this target-dependent interpreter code is >>> unfortunate, the concept is simple. If the latter effort succeeds, we >>> can remove the mirror from the interpreter frame later. A note to >>> openjdk developers - I added this mirror to zero but not to shark. More >>> testing is necessary. >>> >>> Please review the following change: >>> >>> Summary: Add ClassLoaderData object for each anonymous class with >>> metaspaces to allocate in. Add mirror interpreter frame. >>> >>> http://cr.openjdk.java.net/~coleenp/8000662/ >>> http://bugs.sun.com/view_bug.do?bug_id=8000662 >>> >>> Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. >>> >>> Thanks, >>> Coleen > From rkennke at redhat.com Thu Nov 29 06:26:19 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 29 Nov 2012 15:26:19 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> <1354037066.29268.10.camel@mercury> <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> Message-ID: <1354199179.2203.34.camel@mercury> Am Dienstag, den 27.11.2012, 10:59 -0800 schrieb Christian Thalinger: > On Nov 27, 2012, at 9:24 AM, Roman Kennke wrote: > > > Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: > >> On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > >> > >>> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > >>>> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > >>>> > >>>>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >>>>>> > >>>>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>>>>>> > >>>>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi there, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>>>>>> Here are some details: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>>>>>> changes in LLVM. > >>>>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>>>>>> nicer. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>>>>>> bunch of other stuff. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>>>>>> can find the full webrev here: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>>>>>> > >>>>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>>>>>> > >>>>>>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>>>>>> > >>>>>>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>>>>>> > >>>>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- Chris > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>>>>>> integrated into Hotspot. > >>>>>>>>>>>> > >>>>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>>>>>> > >>>>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>>>>>> > >>>>>>>>>>>> and: > >>>>>>>>>>>> > >>>>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>>>>>> > >>>>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>>>>>> > >>>>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>>>>>> using the build script that I provided? > >>>>>>>>>> > >>>>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>>>>>> > >>>>>>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>>>>>> > >>>>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>>>>>> > >>>>>>>>>> It's probably this guy: -Wcast-qual > >>>>>>>>> > >>>>>>>>> Got it: > >>>>>>>>> > >>>>>>>>> $ java -version > >>>>>>>>> java version "1.8.0-ea" > >>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>>>>>> > >>>>>>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>>>>>> > >>>>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>>>>>> Passed: compiler/5091921/Test5091921.java > >>>>>>>> Passed: compiler/5091921/Test6186134.java > >>>>>>>> Passed: compiler/5091921/Test6196102.java > >>>>>>>> Passed: compiler/5091921/Test6357214.java > >>>>>>>> Passed: compiler/5091921/Test6559156.java > >>>>>>>> Passed: compiler/5091921/Test6753639.java > >>>>>>>> Passed: compiler/5091921/Test6850611.java > >>>>>>>> Passed: compiler/5091921/Test6890943.java > >>>>>>>> Passed: compiler/5091921/Test6897150.java > >>>>>>>> Passed: compiler/5091921/Test6905845.java > >>>>>>>> Passed: compiler/5091921/Test6931567.java > >>>>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>>>>>> > >>>>>>>> You can also run all them with a simple make in test/ by setting: > >>>>>>>> > >>>>>>>> PRODUCT_HOME=$JAVA_HOME > >>>>>>>> TESTDIRS=compiler > >>>>>>> > >>>>>>> Alright, I found another fairly grave bug that I would like to include a > >>>>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>>>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>>>>>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>>>>>> needed for volatile field access. However, it does not provide helper > >>>>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>>>>>> the final patch for now (unless you find something else). > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >>>>>> > >>>>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >>>>>> > >>>>>> $ java -Xcomp -version > >>>>>> Value type size is target-dependent. Ask TLI. > >>>>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >>>>>> Stack dump: > >>>>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >>>>>> Aborted (core dumped) > >>>>> > >>>>> Arg! The last couple of changes I did only with LLVM3.2, where the > >>>>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > >>>>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > >>>>> use that for SHARK_LLVM_VERSION <= 31. > >>>>> > >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > >>>>> > >>>>> Hope that works better :-) > >>>> > >>>> I'm so sorry but... > >>>> > >>>> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > >>> > >>> Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > >>> llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > >>> (hopefully final final) patch re-instates the missing memory_barrier() > >>> method: > >>> > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > >>> > >>> Sorry for the messy back-and-forth. > >> > >> Again, so sorry: > >> > >> $ java -Xcomp -version > >> LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! > >> > >> Send a new patch tomorrow after some sleep ;-) > > > > Yeah, apparently 'replaced by' means that the old thing (the intrinsics) > > are indeed gone ;-) > > > > The problem is that the correct way to implement it (atomic load/store) > > doesn't work, the 'old way' (the memory_barrier() intrinsic call) > > doesn't work either, I also tried CreateAtomicRMW() which is probably > > not 100% correct, but would have done the job, but that doesn't work > > either (it throws the same error as the atomic load/store ...). The > > problem seems to only appear on 64bit volatile access. > > > > I don't know a really good solution that doesn't require jumping through > > big hoops, and I don't feel like working around LLVM bugs like this, > > especially since LLVM 3.2 (which should be released real soon now) works > > just fine. If you have a suggestion, please let me know, otherwise I > > suggest the following patch, which gets rid of all the LLVM31 blocks > > again and creates atomic load/store instructions (and requires LLVM 3.2 > > which can be found here > > http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ > > That's a reasonable thing to do given the tentative release date of December 16th. While running the compiler regression tests I got a couple of failures. You might want to address them with separate bugs. Hi Twisti, I see that you committed the patch, thanks a lot for this! However, there is still the small jdk patch missing: http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ Can I push this myself or do you want to do it? Cheers, Roman From coleen.phillimore at oracle.com Thu Nov 29 09:24:37 2012 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 29 Nov 2012 17:24:37 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20121129172500.3FE4E47BDD@hg.openjdk.java.net> Changeset: 49cbd3e25ba9 Author: zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/49cbd3e25ba9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp Changeset: 3ed6de6e139b Author: coleenp Date: 2012-11-20 20:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3ed6de6e139b Merge Changeset: 73e64867adb7 Author: mikael Date: 2012-11-21 09:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/73e64867adb7 8003690: Example code in JVMTI GetStackTrace documentation is broken Summary: Fixed to minor errors in example code Reviewed-by: sspitsyn, dholmes ! src/share/vm/prims/jvmti.xml Changeset: 6b881a6b0665 Author: dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6b881a6b0665 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp Changeset: ca1be5fbe6ff Author: dholmes Date: 2012-11-21 21:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca1be5fbe6ff Merge Changeset: 7c15faa95ce7 Author: mikael Date: 2012-11-27 07:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c15faa95ce7 8003879: Duplicate definitions in vmStructs Summary: Removed duplicate entries Reviewed-by: dholmes, sspitsyn ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: bbc14465e7db Author: zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bbc14465e7db 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp Changeset: 5de2a5bd519e Author: zgu Date: 2012-11-28 06:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5de2a5bd519e Merge Changeset: fe81517cfb77 Author: hseigel Date: 2012-11-28 08:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fe81517cfb77 6924920: Class Data Sharing limit on the java version string can create failures Summary: Truncate the java version string and add a hash value if it is too long. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/filemap.cpp Changeset: b51dc8df86e5 Author: coleenp Date: 2012-11-28 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b51dc8df86e5 Merge Changeset: 59c790074993 Author: coleenp Date: 2012-11-28 17:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/59c790074993 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. Reviewed-by: dholmes, sspitsyn, dcubed, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/utilities/globalDefinitions.hpp From gary.collins at oracle.com Thu Nov 29 09:37:12 2012 From: gary.collins at oracle.com (Gary Collins) Date: Thu, 29 Nov 2012 09:37:12 -0800 Subject: RFR: JDK-8004114 build environment change In-Reply-To: <2F920579-D7B5-4187-878E-4E057604B8B2@oracle.com> References: <4FAD3712.6040600@oracle.com> <2F920579-D7B5-4187-878E-4E057604B8B2@oracle.com> Message-ID: A small tweak to our JPRT settings: This change is slated for hsx24 repo. http://cr.openjdk.java.net/~collins/JDK-8004114/webrev-00/ Thanks Gary From coleen.phillimore at oracle.com Thu Nov 29 09:38:39 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 29 Nov 2012 12:38:39 -0500 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50B75147.70805@oracle.com> References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> <50B6AF95.8070607@oracle.com> <50B75147.70805@oracle.com> Message-ID: <50B79D9F.2080802@oracle.com> Thanks again for the code review, Stefan. On 11/29/2012 07:12 AM, Stefan Karlsson wrote: > Hi Coleen, > > I took a closer look at the ClassLoaderData::anonymous_class_loader_data: > > I'm wondering if we have a potential bug in that code. Here's a some > pseudo code for that: > cld = new ClassLoaderData(loader) > put_on_cld_list(cld) // GC can now find it > init_dependencies // GC can occur at this line > cld->set_keep_alive(true) // We mark that this CLD should be > considered live by the GC > > I think the set_keep_alive call should be done before > init_dependencies are set up. Otherwise this CLD might be prematurely > unloaded. > Yes, that was a bug. I moved keep_alive setting into ClassLoaderDataGraph::add. > > Some minor comments: > > http://cr.openjdk.java.net/~coleenp/8000662_3/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.patch > > > Unrelated whitespace change. > Reverted file. > > http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/classLoaderData.cpp.udiff.html > > > is_alive isn't used anymore: > + void ClassLoaderData::unload(BoolObjectClosure* is_alive) { You're right. > > I think we are using the wrong abstraction when we are looking at the > claimed bits here. I'll revisit this code after this has been pushed. > - if (data->class_loader() == NULL || > is_alive->do_object_b(data->class_loader())) { > - assert(data->claimed(), "class loader data must have been > claimed"); > + if (data->claimed() || data->keep_alive()) { > + assert(data->class_loader() == NULL || > is_alive->do_object_b(data->class_loader()), "class loader data must > be live"); Okay, I rewrote this in terms of is_alive closure rather than checking the "claimed" bit. It's asserted to be equivalent to the claimed bit except you might change the meaning of claimed for GC someday. bool ClassLoaderData::is_alive(BoolObjectClosure* is_alive_closure) const { bool alive = is_anonymous() ? is_alive_closure->do_object_b(_klasses->java_mirror()) : class_loader() == NULL || is_alive_closure->do_object_b(class_loader()); assert(!alive || claimed(), "must be claimed"); return alive; } And ClassLoaderDataGraph::do_unloading() does: while (data != NULL) { if (data->keep_alive() || data->is_alive(is_alive_closure)) { ... continue ... > > http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/classLoaderData.hpp.patch > > > Unnecessary change: > > bool is_unloading() const { > - assert(!(is_the_null_class_loader_data() && _unloading), "The > null class loader can never be unloaded"); > + assert(!(this == the_null_class_loader_data() && _unloading), > "The null class loader can never be unloaded"); > return _unloading; > } Fixed. > > > http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/systemDictionary.cpp.patch > > > I don't know if this is needed or not. I thought we would have > registered some sort of object in the resolved_references to keep the > mirror alive. But I guess that's not the case. > > (*appendix_result) = Handle(THREAD, appendix); > + // the target is stored in the cpCache and if a reference to this > + // MethodName is dropped we need a way to make sure the > + // class_loader containing this method is kept alive. > + ClassLoaderData* this_key = > InstanceKlass::cast(accessing_klass())->class_loader_data(); > + this_key->record_dependency(m->method_holder(), CHECK_NULL); // > Can throw OOM > return methodHandle(THREAD, m); > } This would be nice if it's true. I don't really have a way of proving it though and JSR 292 keeps changing so it might not stay true. I'll add a FIXME comment to this though. Coleen > > StefanK > > On 11/29/2012 01:43 AM, Coleen Phillimore wrote: >> >> Please review updated changes to fix the nashorn OOMs from using jsr >> 292 anonymous classes. The changes to fix bug 8003720 NPG: Method >> in interpreter stack frame can be deallocated >> have been removed >> from this changeset in favor of the change that Stefan checked in on >> Monday. Note - there is no target-specific code in this change now. >> >> Other changes since last webrev are several cleanups from internal >> discussions. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8000662_3/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=8000662_3 >> >> Retesting with NSK vm tests. I'll try to describe things better >> below in reply to David's questions. >> >> On 11/11/2012 11:32 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> :) >>> >>> Can you explain the old and new relationships between these various >>> objects please. As I understand it JSR-292 introduced this special >>> kind of class - the anonymous class - and they differ from regular >>> classes in important ways (mainly that they can be collected before >>> their classloader), and pre-NPG this all "just worked". The NPG >>> changes added the ClassLoaderData metadata objects and changed some >>> of the associations that anonymous classes actually relied upon and >>> as a result they stopped getting GC'd in some cases, and were >>> prematurely GC'd in others (I hope I got that right). This changeset >>> addresses these problems. >> >> This is correct. I don't think I could have written this better. >> Yes, in the old Permgen world, when the MethodHandles that contained >> the mirror to the anonymous class was unreferenced, the klass and all >> the metadata associated with it would be collected. Now with >> ClassLoaderData objects, collection of metadata is tied to these >> objects. The initial naive implementation just added the anonymous >> classes to the host_klass's ClassLoaderData object, which before b63 >> (I think) was the boot class loader. So the anonymous classes were >> never collected. >> >> This changeset gives each anonymous class it's own ClassLoaderData >> object and uses it's java_mirror to determine whether the anonymous >> class is still live and whether the ClassLoaderData object can be >> unloaded. >> >> We have been doing some tuning to determine how large the metaspace >> should be for these special cases. That is ongoing. >> >>> >>> I've been trying to follow this from the beginning and still don't >>> have a clear understanding on what the relationships between >>> ClassLoader, Class, "anonymous class" and ClassLoaderData objects >>> are. So a clear picture of what relationships exist (particularly >>> this new 1:N association) would be appreciated, and help make the >>> code changes more understandable to me. >> >> I can't draw pictures without a whiteboard! But you may have several >> CLD objects that correspond to one class_loader oop. Each CLD object >> points to the class_loader, but the class_loader only points to the >> primary CLD object. The additional CLD objects are for anonymous >> classes, which are kept live by their mirrors, not the class_loader. >> That's the source of many of the changes in this changeset. >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>> On 12/11/2012 1:51 PM, Coleen Phillimore wrote: >>>> >>>> This change creates a ClassLoaderData object for each JSR 292 >>>> anonymous >>>> class, so that the metadata and mirror object for the anonymous class >>>> can be reclaimed when the anonymous class is no longer referenced. The >>>> java_lang_ClassLoader object for the anonymous class is the same as >>>> its >>>> host_class. Most of this change is to break the assumption that >>>> there's >>>> a 1-1 relationship between java_lang_ClassLoader Java objects and >>>> ClassLoaderData metadata objects in the VM. Also, nmethods and other >>>> things that were strong roots for java_lang_ClassLoader objects >>>> have to >>>> also be strong roots for java_lang_Class objects for anonymous >>>> classes. >>>> >>>> There were also changes to move the dependencies out of the >>>> java_lang_ClassLoader object to the ClassLoaderData type. This type is >>>> preallocated so that CMS will have card marks to track additions to >>>> the >>>> dependencies. Please check this, Stefan! >>>> >>>> Also, in this change is the addition of mirrors to the interpreter >>>> frame >>>> and a test case that shows why this is necessary. An interpreter frame >>>> can be running while it's class loader is unloaded in some special >>>> circumstances. It is easier to do this with JSR292 static MethodHandle >>>> code. Some people are looking for a platform independent way to do >>>> this, >>>> by changing code in GC. While this target-dependent interpreter >>>> code is >>>> unfortunate, the concept is simple. If the latter effort succeeds, we >>>> can remove the mirror from the interpreter frame later. A note to >>>> openjdk developers - I added this mirror to zero but not to shark. >>>> More >>>> testing is necessary. >>>> >>>> Please review the following change: >>>> >>>> Summary: Add ClassLoaderData object for each anonymous class with >>>> metaspaces to allocate in. Add mirror interpreter frame. >>>> >>>> http://cr.openjdk.java.net/~coleenp/8000662/ >>>> http://bugs.sun.com/view_bug.do?bug_id=8000662 >>>> >>>> Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. >>>> >>>> Thanks, >>>> Coleen >> > From stefan.karlsson at oracle.com Thu Nov 29 09:56:02 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 29 Nov 2012 18:56:02 +0100 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50B79D9F.2080802@oracle.com> References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> <50B6AF95.8070607@oracle.com> <50B75147.70805@oracle.com> <50B79D9F.2080802@oracle.com> Message-ID: On 29 nov 2012, at 18:38, Coleen Phillimore wrote: > > Thanks again for the code review, Stefan. > > On 11/29/2012 07:12 AM, Stefan Karlsson wrote: >> Hi Coleen, >> >> I took a closer look at the ClassLoaderData::anonymous_class_loader_data: >> >> I'm wondering if we have a potential bug in that code. Here's a some pseudo code for that: >> cld = new ClassLoaderData(loader) >> put_on_cld_list(cld) // GC can now find it >> init_dependencies // GC can occur at this line >> cld->set_keep_alive(true) // We mark that this CLD should be considered live by the GC >> >> I think the set_keep_alive call should be done before init_dependencies are set up. Otherwise this CLD might be prematurely unloaded. > > Yes, that was a bug. I moved keep_alive setting into ClassLoaderDataGraph::add. > >> >> Some minor comments: >> >> http://cr.openjdk.java.net/~coleenp/8000662_3/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.patch >> >> Unrelated whitespace change. > > Reverted file. > >> >> http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/classLoaderData.cpp.udiff.html >> >> is_alive isn't used anymore: >> + void ClassLoaderData::unload(BoolObjectClosure* is_alive) { > > You're right. > >> >> I think we are using the wrong abstraction when we are looking at the claimed bits here. I'll revisit this code after this has been pushed. >> - if (data->class_loader() == NULL || is_alive->do_object_b(data->class_loader())) { >> - assert(data->claimed(), "class loader data must have been claimed"); >> + if (data->claimed() || data->keep_alive()) { >> + assert(data->class_loader() == NULL || is_alive->do_object_b(data->class_loader()), "class loader data must be live"); > > Okay, I rewrote this in terms of is_alive closure rather than checking the "claimed" bit. It's asserted to be equivalent to the claimed bit except you might change the meaning of claimed for GC someday. > > bool ClassLoaderData::is_alive(BoolObjectClosure* is_alive_closure) const { > bool alive = > is_anonymous() ? > is_alive_closure->do_object_b(_klasses->java_mirror()) : > class_loader() == NULL || is_alive_closure->do_object_b(class_loader()); > assert(!alive || claimed(), "must be claimed"); > return alive; > } > > > And ClassLoaderDataGraph::do_unloading() does: > > while (data != NULL) { > if (data->keep_alive() || data->is_alive(is_alive_closure)) { > ... continue ... Thanks for changing this. I think it would be good to move the data->keep_alive() check into the is_alive function. StefanK > >> >> http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/classLoaderData.hpp.patch >> >> Unnecessary change: >> >> bool is_unloading() const { >> - assert(!(is_the_null_class_loader_data() && _unloading), "The null class loader can never be unloaded"); >> + assert(!(this == the_null_class_loader_data() && _unloading), "The null class loader can never be unloaded"); >> return _unloading; >> } > > Fixed. > >> >> >> http://cr.openjdk.java.net/~coleenp/8000662_3/src/share/vm/classfile/systemDictionary.cpp.patch >> >> I don't know if this is needed or not. I thought we would have registered some sort of object in the resolved_references to keep the mirror alive. But I guess that's not the case. >> >> (*appendix_result) = Handle(THREAD, appendix); >> + // the target is stored in the cpCache and if a reference to this >> + // MethodName is dropped we need a way to make sure the >> + // class_loader containing this method is kept alive. >> + ClassLoaderData* this_key = InstanceKlass::cast(accessing_klass())->class_loader_data(); >> + this_key->record_dependency(m->method_holder(), CHECK_NULL); // Can throw OOM >> return methodHandle(THREAD, m); >> } > > This would be nice if it's true. I don't really have a way of proving it though and JSR 292 keeps changing so it might not stay true. I'll add a FIXME comment to this though. > > Coleen > >> >> StefanK >> >> On 11/29/2012 01:43 AM, Coleen Phillimore wrote: >>> >>> Please review updated changes to fix the nashorn OOMs from using jsr 292 anonymous classes. The changes to fix bug 8003720 NPG: Method in interpreter stack frame can be deallocated have been removed from this changeset in favor of the change that Stefan checked in on Monday. Note - there is no target-specific code in this change now. >>> >>> Other changes since last webrev are several cleanups from internal discussions. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8000662_3/ >>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8000662_3 >>> >>> Retesting with NSK vm tests. I'll try to describe things better below in reply to David's questions. >>> >>> On 11/11/2012 11:32 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> :) >>>> >>>> Can you explain the old and new relationships between these various objects please. As I understand it JSR-292 introduced this special kind of class - the anonymous class - and they differ from regular classes in important ways (mainly that they can be collected before their classloader), and pre-NPG this all "just worked". The NPG changes added the ClassLoaderData metadata objects and changed some of the associations that anonymous classes actually relied upon and as a result they stopped getting GC'd in some cases, and were prematurely GC'd in others (I hope I got that right). This changeset addresses these problems. >>> >>> This is correct. I don't think I could have written this better. Yes, in the old Permgen world, when the MethodHandles that contained the mirror to the anonymous class was unreferenced, the klass and all the metadata associated with it would be collected. Now with ClassLoaderData objects, collection of metadata is tied to these objects. The initial naive implementation just added the anonymous classes to the host_klass's ClassLoaderData object, which before b63 (I think) was the boot class loader. So the anonymous classes were never collected. >>> >>> This changeset gives each anonymous class it's own ClassLoaderData object and uses it's java_mirror to determine whether the anonymous class is still live and whether the ClassLoaderData object can be unloaded. >>> >>> We have been doing some tuning to determine how large the metaspace should be for these special cases. That is ongoing. >>> >>>> >>>> I've been trying to follow this from the beginning and still don't have a clear understanding on what the relationships between ClassLoader, Class, "anonymous class" and ClassLoaderData objects are. So a clear picture of what relationships exist (particularly this new 1:N association) would be appreciated, and help make the code changes more understandable to me. >>> >>> I can't draw pictures without a whiteboard! But you may have several CLD objects that correspond to one class_loader oop. Each CLD object points to the class_loader, but the class_loader only points to the primary CLD object. The additional CLD objects are for anonymous classes, which are kept live by their mirrors, not the class_loader. That's the source of many of the changes in this changeset. >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 12/11/2012 1:51 PM, Coleen Phillimore wrote: >>>>> >>>>> This change creates a ClassLoaderData object for each JSR 292 anonymous >>>>> class, so that the metadata and mirror object for the anonymous class >>>>> can be reclaimed when the anonymous class is no longer referenced. The >>>>> java_lang_ClassLoader object for the anonymous class is the same as its >>>>> host_class. Most of this change is to break the assumption that there's >>>>> a 1-1 relationship between java_lang_ClassLoader Java objects and >>>>> ClassLoaderData metadata objects in the VM. Also, nmethods and other >>>>> things that were strong roots for java_lang_ClassLoader objects have to >>>>> also be strong roots for java_lang_Class objects for anonymous classes. >>>>> >>>>> There were also changes to move the dependencies out of the >>>>> java_lang_ClassLoader object to the ClassLoaderData type. This type is >>>>> preallocated so that CMS will have card marks to track additions to the >>>>> dependencies. Please check this, Stefan! >>>>> >>>>> Also, in this change is the addition of mirrors to the interpreter frame >>>>> and a test case that shows why this is necessary. An interpreter frame >>>>> can be running while it's class loader is unloaded in some special >>>>> circumstances. It is easier to do this with JSR292 static MethodHandle >>>>> code. Some people are looking for a platform independent way to do this, >>>>> by changing code in GC. While this target-dependent interpreter code is >>>>> unfortunate, the concept is simple. If the latter effort succeeds, we >>>>> can remove the mirror from the interpreter frame later. A note to >>>>> openjdk developers - I added this mirror to zero but not to shark. More >>>>> testing is necessary. >>>>> >>>>> Please review the following change: >>>>> >>>>> Summary: Add ClassLoaderData object for each anonymous class with >>>>> metaspaces to allocate in. Add mirror interpreter frame. >>>>> >>>>> http://cr.openjdk.java.net/~coleenp/8000662/ >>>>> http://bugs.sun.com/view_bug.do?bug_id=8000662 >>>>> >>>>> Tested with Nashorn tests, NSK full testlist, dacapo with CMS and G1. >>>>> >>>>> Thanks, >>>>> Coleen > From kelly.ohair at oracle.com Thu Nov 29 09:59:19 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 29 Nov 2012 09:59:19 -0800 Subject: RFR: JDK-8004114 build environment change In-Reply-To: References: <4FAD3712.6040600@oracle.com> <2F920579-D7B5-4187-878E-4E057604B8B2@oracle.com> Message-ID: <08BA05D6-141F-459B-9971-AB0F0A579F34@oracle.com> Looks ok to me. -kto On Nov 29, 2012, at 9:37 AM, Gary Collins wrote: > A small tweak to our JPRT settings: > > This change is slated for hsx24 repo. > > http://cr.openjdk.java.net/~collins/JDK-8004114/webrev-00/ > > Thanks > Gary > > From christian.thalinger at oracle.com Thu Nov 29 10:28:40 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 10:28:40 -0800 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B4FF15.6090304@oracle.com> References: <50B4FF15.6090304@oracle.com> Message-ID: <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> On Nov 27, 2012, at 9:57 AM, Aleksey Shipilev wrote: > Hi, > > This is the daizy-fresh thread for reviewing the actual changes to > support the JEP-142 in HotSpot. Please address API issues about > @Contended to concurrency-interest list, Doug had started the thread here: > > http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010208.html > > We are not discussing the design, API and all the general stuff here, > only the reference implementation. I would like to have someone extra > knowledgeable in HotSpot codebase to see whether I do anything stupid there. > > The webrev for the change is here: > http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ Is this a review for a push? hotspot/src/share/vm/classfile/classFileParser.cpp: Is it possible to factor the while-loop to align the fields into a method? hotspot/src/share/vm/classfile/classFileParser.hpp: + bool hasContendedAnnotation() { return has_annotation(_sun_misc_Contended); } We don't use camel-case method names. hotspot/src/share/vm/classfile/vmSymbols.hpp: Please keep the indent aligned. hotspot/src/share/vm/oops/fieldInfo.hpp: I wonder if we have a spare access_flags bit somewhere we could use for is_contended. jdk/src/share/classes/sun/misc/Contended.java: Misses copyright header. -- Chris > > Notable differences against latest version: > - a little denser packing in some corner cases > - support @Contended for static fields > - moved @Contended to sun.misc (go and nag at c-i@ about this) > - bugfixes > > Testing: > - hotspot/test/runtime/8003985/Test8003985 on Linux x86_64 > - jprt, specjvm98 quick run > - jprt full cycle is underway, looking good > > Thanks, > Aleksey. From christian.thalinger at oracle.com Thu Nov 29 10:29:23 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 10:29:23 -0800 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <1354199179.2203.34.camel@mercury> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> <1354037066.29268.10.camel@mercury> <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> <1354199179.2203.34.camel@mercury> Message-ID: <86C99234-14E7-429A-A98E-63E9E43AE8E7@oracle.com> On Nov 29, 2012, at 6:26 AM, Roman Kennke wrote: > Am Dienstag, den 27.11.2012, 10:59 -0800 schrieb Christian Thalinger: >> On Nov 27, 2012, at 9:24 AM, Roman Kennke wrote: >> >>> Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: >>>> On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: >>>> >>>>> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: >>>>>> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: >>>>>> >>>>>>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: >>>>>>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: >>>>>>>> >>>>>>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: >>>>>>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: >>>>>>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi there, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot >>>>>>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. >>>>>>>>>>>>>>>> Here are some details: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For >>>>>>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API >>>>>>>>>>>>>>>> changes in LLVM. >>>>>>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata >>>>>>>>>>>>>>>> class hierarchies in Hotspot. >>>>>>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and >>>>>>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations >>>>>>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a >>>>>>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little >>>>>>>>>>>>>>>> nicer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse >>>>>>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a >>>>>>>>>>>>>>>> bunch of other stuff. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You >>>>>>>>>>>>>>>> can find the full webrev here: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Isn't PrintCompilation doing that already? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The shared code changes look good. I filed: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Chris >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There are also a very minor change required in JDK: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot >>>>>>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will >>>>>>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please let me know if there are any issues or how we can get this >>>>>>>>>>>>>>>> integrated into Hotspot. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: >>>>>>>>>>>>>> >>>>>>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, >>>>>>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, >>>>>>>>>>>>>> from /usr/local/include/llvm/Use.h:28, >>>>>>>>>>>>>> from /usr/local/include/llvm/Value.h:17, >>>>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" >>>>>>>>>>>>>> >>>>>>>>>>>>>> and: >>>>>>>>>>>>>> >>>>>>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, >>>>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, >>>>>>>>>>>>> this happens when certain cflags are not set correctly. The script >>>>>>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the >>>>>>>>>>>>> correct flags. In order for this to work, you need to have the full path >>>>>>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you >>>>>>>>>>>>> using the build script that I provided? >>>>>>>>>>>> >>>>>>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. >>>>>>>>>>>> >>>>>>>>>>>> Now that I have the LLVM_* variables it's even worse: >>>>>>>>>>>> >>>>>>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness >>>>>>>>>>>> >>>>>>>>>>>> It's probably this guy: -Wcast-qual >>>>>>>>>>> >>>>>>>>>>> Got it: >>>>>>>>>>> >>>>>>>>>>> $ java -version >>>>>>>>>>> java version "1.8.0-ea" >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >>>>>>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) >>>>>>>>>> >>>>>>>>>> I ran the compiler regression tests and Shark crashes in 5091921: >>>>>>>>>> >>>>>>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ >>>>>>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating >>>>>>>>>> Passed: compiler/5091921/Test5091921.java >>>>>>>>>> Passed: compiler/5091921/Test6186134.java >>>>>>>>>> Passed: compiler/5091921/Test6196102.java >>>>>>>>>> Passed: compiler/5091921/Test6357214.java >>>>>>>>>> Passed: compiler/5091921/Test6559156.java >>>>>>>>>> Passed: compiler/5091921/Test6753639.java >>>>>>>>>> Passed: compiler/5091921/Test6850611.java >>>>>>>>>> Passed: compiler/5091921/Test6890943.java >>>>>>>>>> Passed: compiler/5091921/Test6897150.java >>>>>>>>>> Passed: compiler/5091921/Test6905845.java >>>>>>>>>> Passed: compiler/5091921/Test6931567.java >>>>>>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts >>>>>>>>>> >>>>>>>>>> You can also run all them with a simple make in test/ by setting: >>>>>>>>>> >>>>>>>>>> PRODUCT_HOME=$JAVA_HOME >>>>>>>>>> TESTDIRS=compiler >>>>>>>>> >>>>>>>>> Alright, I found another fairly grave bug that I would like to include a >>>>>>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for >>>>>>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. >>>>>>>>> LLVM offers atomic loads and stores, which seem to be exactly what is >>>>>>>>> needed for volatile field access. However, it does not provide helper >>>>>>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be >>>>>>>>> the final patch for now (unless you find something else). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ >>>>>>>> >>>>>>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: >>>>>>>> >>>>>>>> $ java -Xcomp -version >>>>>>>> Value type size is target-dependent. Ask TLI. >>>>>>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! >>>>>>>> Stack dump: >>>>>>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' >>>>>>>> Aborted (core dumped) >>>>>>> >>>>>>> Arg! The last couple of changes I did only with LLVM3.2, where the >>>>>>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with >>>>>>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and >>>>>>> use that for SHARK_LLVM_VERSION <= 31. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ >>>>>>> >>>>>>> Hope that works better :-) >>>>>> >>>>>> I'm so sorry but... >>>>>> >>>>>> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' >>>>> >>>>> Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and >>>>> llvm3.1, but apparently not (maybe I shouldn't work after 1am). This >>>>> (hopefully final final) patch re-instates the missing memory_barrier() >>>>> method: >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ >>>>> >>>>> Sorry for the messy back-and-forth. >>>> >>>> Again, so sorry: >>>> >>>> $ java -Xcomp -version >>>> LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! >>>> >>>> Send a new patch tomorrow after some sleep ;-) >>> >>> Yeah, apparently 'replaced by' means that the old thing (the intrinsics) >>> are indeed gone ;-) >>> >>> The problem is that the correct way to implement it (atomic load/store) >>> doesn't work, the 'old way' (the memory_barrier() intrinsic call) >>> doesn't work either, I also tried CreateAtomicRMW() which is probably >>> not 100% correct, but would have done the job, but that doesn't work >>> either (it throws the same error as the atomic load/store ...). The >>> problem seems to only appear on 64bit volatile access. >>> >>> I don't know a really good solution that doesn't require jumping through >>> big hoops, and I don't feel like working around LLVM bugs like this, >>> especially since LLVM 3.2 (which should be released real soon now) works >>> just fine. If you have a suggestion, please let me know, otherwise I >>> suggest the following patch, which gets rid of all the LLVM31 blocks >>> again and creates atomic load/store instructions (and requires LLVM 3.2 >>> which can be found here >>> http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). >>> >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ >> >> That's a reasonable thing to do given the tentative release date of December 16th. While running the compiler regression tests I got a couple of failures. You might want to address them with separate bugs. > > Hi Twisti, > > I see that you committed the patch, thanks a lot for this! However, > there is still the small jdk patch missing: > > http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > Can I push this myself or do you want to do it? Right. You can do it yourself. I would appreciate that. -- Chris > > Cheers, > Roman > > From aleksey.shipilev at oracle.com Thu Nov 29 10:56:57 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Nov 2012 22:56:57 +0400 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> Message-ID: <50B7AFF9.8040203@oracle.com> Thanks for review, Christian! On 11/29/2012 10:28 PM, Christian Thalinger wrote: >> The webrev for the change is here: >> http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ > > Is this a review for a push? Yes, I'm pretty much done with functionality, it passes the tests, and flies through JPRT without problems. > hotspot/src/share/vm/classfile/classFileParser.cpp: > > Is it possible to factor the while-loop to align the fields into a method? The whole method ClassFileParser::parseClassFile cries for refactoring. Alas, separating the contended handling code would be more messy than just fitting in the same flow, since it uses quite of few locals within that method. > hotspot/src/share/vm/classfile/classFileParser.hpp: > > + bool hasContendedAnnotation() { return has_annotation(_sun_misc_Contended); } > > We don't use camel-case method names. OK. > hotspot/src/share/vm/classfile/vmSymbols.hpp: > > Please keep the indent aligned. OK. > hotspot/src/share/vm/oops/fieldInfo.hpp: > > I wonder if we have a spare access_flags bit somewhere we could use for is_contended. Looking at jvm.h, I see there is only single bit left, want me to burn it with contended flag? > jdk/src/share/classes/sun/misc/Contended.java: > > Misses copyright header. Will update. -Aleksey. From coleen.phillimore at oracle.com Thu Nov 29 11:38:31 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 29 Nov 2012 14:38:31 -0500 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B7AFF9.8040203@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> Message-ID: <50B7B9B7.5070508@oracle.com> Hi, I was going to make the same comments as Christian. On 11/29/2012 01:56 PM, Aleksey Shipilev wrote: > Thanks for review, Christian! > > On 11/29/2012 10:28 PM, Christian Thalinger wrote: >>> The webrev for the change is here: >>> http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ >> Is this a review for a push? > Yes, I'm pretty much done with functionality, it passes the tests, and > flies through JPRT without problems. > >> hotspot/src/share/vm/classfile/classFileParser.cpp: >> >> Is it possible to factor the while-loop to align the fields into a method? > The whole method ClassFileParser::parseClassFile cries for refactoring. > Alas, separating the contended handling code would be more messy than > just fitting in the same flow, since it uses quite of few locals within > that method. Yes, it does cry out for refactoring. This is >900 line function now. I didn't see how you could refactor the new code without refactoring the existing code for laying out fields in a class. The code that you added for printing looks like it could be a separate function though. > >> hotspot/src/share/vm/classfile/classFileParser.hpp: >> >> + bool hasContendedAnnotation() { return has_annotation(_sun_misc_Contended); } >> >> We don't use camel-case method names. > OK. > >> hotspot/src/share/vm/classfile/vmSymbols.hpp: >> >> Please keep the indent aligned. > OK. > >> hotspot/src/share/vm/oops/fieldInfo.hpp: >> >> I wonder if we have a spare access_flags bit somewhere we could use for is_contended. > Looking at jvm.h, I see there is only single bit left, want me to burn > it with contended flag? in src/share/vm/oops/klass.hpp you added the boolean _is_contended but it only applies to InstanceKlass, right? It shouldn't be in all types of classes. There are misc_flags in InstanceKlass that you might be able to use instead. It would be a shame to burn our limited access flags on this thing that is unlikely. Also, it appears that you are storing two extra u2 for each field in the class, where they are almost always zero. These are saved in the InstanceKlass and take up a lot of space. Jiangli's done a lot of work to reduce the footprint of the running vm. One of the things she did was to move the generic signature indexes out of this array. You should find a way to do this also. Otherwise, you can have a side data structure that you save with FieldStream to allocate these fields. You shouldn't add footprint for this. We are desperately trying to save footprint! Thanks, Coleen > >> jdk/src/share/classes/sun/misc/Contended.java: >> >> Misses copyright header. > Will update. > > -Aleksey. > From serguei.spitsyn at oracle.com Thu Nov 29 12:14:46 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Nov 2012 12:14:46 -0800 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B73E54.8020800@oracle.com> References: <50B4FF15.6090304@oracle.com> <50B73E54.8020800@oracle.com> Message-ID: <50B7C236.4050007@oracle.com> I'm not pretending to be a reviewer yet. Just a small comment. */src/share/vm/oops/fieldInfo.hpp:* 46 // as an array of 8 shorts 47 enum FieldOffset { 48 access_flags_offset = 0, 49 name_index_offset = 1, 50 signature_index_offset = 2, 51 initval_index_offset = 3, 52 low_offset = 4, 53 high_offset = 5, 54 is_contended_offset = 6, 55 contended_group_offset = 7, 56 field_slots = 8 57 }; It seems the comment about array of 8 shorts is incorrect. Should it be 9? The comment before the fix was about 7 shorts and you add two new elements: 46 // as an array of 7 shorts 47 enum FieldOffset { 48 access_flags_offset = 0, 49 name_index_offset = 1, 50 signature_index_offset = 2, 51 initval_index_offset = 3, 52 low_offset = 4, 53 high_offset = 5, 54 field_slots = 6 55 }; Thanks, Serguei On 11/29/12 2:52 AM, Aleksey Shipilev wrote: > Anyone? > > Thanks, > Aleksey. > > On 11/27/2012 09:57 PM, Aleksey Shipilev wrote: >> Hi, >> >> This is the daizy-fresh thread for reviewing the actual changes to >> support the JEP-142 in HotSpot. Please address API issues about >> @Contended to concurrency-interest list, Doug had started the thread here: >> >> http://cs.oswego.edu/pipermail/concurrency-interest/2012-November/010208.html >> >> We are not discussing the design, API and all the general stuff here, >> only the reference implementation. I would like to have someone extra >> knowledgeable in HotSpot codebase to see whether I do anything stupid there. >> >> The webrev for the change is here: >> http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ >> >> Notable differences against latest version: >> - a little denser packing in some corner cases >> - support @Contended for static fields >> - moved @Contended to sun.misc (go and nag at c-i@ about this) >> - bugfixes >> >> Testing: >> - hotspot/test/runtime/8003985/Test8003985 on Linux x86_64 >> - jprt, specjvm98 quick run >> - jprt full cycle is underway, looking good >> >> Thanks, >> Aleksey. >> From john.cuthbertson at oracle.com Thu Nov 29 13:06:02 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Thu, 29 Nov 2012 21:06:02 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20121129210614.F27AB47BE4@hg.openjdk.java.net> Changeset: 53715fb1597d Author: brutisso Date: 2012-11-20 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/53715fb1597d 7198334: UseNUMA modifies system parameters on non-NUMA system Summary: The flags MinHeapDeltaBytes and UseNUMAInterleaving must be adjusted after the OS have adjusted the UseNUMA flag in the method os::init_2. Reviewed-by: dholmes, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 19c1bd641922 Author: coleenp Date: 2012-11-26 12:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19c1bd641922 8003722: More gcc 4.7 compilation errors Summary: Add a few more this->qualifications. Reviewed-by: coleenp, dholmes Contributed-by: duboscq at ssw.jku.at ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: d0aa87f04bd5 Author: stefank Date: 2012-11-27 10:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0aa87f04bd5 8003720: NPG: Method in interpreter stack frame can be deallocated Summary: Pass down a closure during root scanning to keep the class of the method alive. Reviewed-by: coleenp, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp + test/runtime/8003720/Asmator.java + test/runtime/8003720/Test8003720.java + test/runtime/8003720/Victim.java + test/runtime/8003720/VictimClassLoader.java Changeset: f34d701e952e Author: stefank Date: 2012-11-27 14:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f34d701e952e 8003935: Simplify the needed includes for using Thread::current() Reviewed-by: dholmes, rbackman, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/os/bsd/vm/mutex_bsd.cpp ! src/os/bsd/vm/mutex_bsd.inline.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/threadCritical_bsd.cpp ! src/os/bsd/vm/thread_bsd.inline.hpp ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp + src/share/vm/runtime/thread.inline.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 2fc0334f613a Author: johnc Date: 2012-11-27 14:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2fc0334f613a 7194633: G1: Assertion and guarantee failures in block offset table Summary: Add detailed error messages to assertions and guarantees in G1's block offset table. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/memory/space.cpp Changeset: c24f778e9401 Author: johnc Date: 2012-11-29 11:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c24f778e9401 Merge ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp From rkennke at redhat.com Thu Nov 29 13:41:40 2012 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 29 Nov 2012 22:41:40 +0100 Subject: RFR (L): 8003868: fix shark for latest HotSpot and LLVM [Was: Re: RFR: Fix shark for latest Hotspot and LLVM] In-Reply-To: <86C99234-14E7-429A-A98E-63E9E43AE8E7@oracle.com> References: <1353519094.1744.42.camel@mercury> <34C51B6D-6582-42AB-9BDE-2CF7D721532E@oracle.com> <1353531251.1744.53.camel@mercury> <32151B51-A2A1-4DE4-B5DD-B665E2548704@oracle.com> <6B77725B-3BCF-40E0-AF0B-77E58B36B095@oracle.com> <1353690888.31435.3.camel@mercury> <13D4C44A-91EA-4175-A6E9-23FE2A3D7F79@oracle.com> <1353971930.20183.3.camel@mercury> <1353977057.20183.8.camel@mercury> <1354037066.29268.10.camel@mercury> <4C4FE174-22EA-4982-890A-F784A7977D28@oracle.com> <1354199179.2203.34.camel@mercury> <86C99234-14E7-429A-A98E-63E9E43AE8E7@oracle.com> Message-ID: <1354225300.2203.44.camel@mercury> Am Donnerstag, den 29.11.2012, 10:29 -0800 schrieb Christian Thalinger: > On Nov 29, 2012, at 6:26 AM, Roman Kennke wrote: > > > Am Dienstag, den 27.11.2012, 10:59 -0800 schrieb Christian Thalinger: > >> On Nov 27, 2012, at 9:24 AM, Roman Kennke wrote: > >> > >>> Am Montag, den 26.11.2012, 17:14 -0800 schrieb Christian Thalinger: > >>>> On Nov 26, 2012, at 4:44 PM, Roman Kennke wrote: > >>>> > >>>>> Am Montag, den 26.11.2012, 15:43 -0800 schrieb Christian Thalinger: > >>>>>> On Nov 26, 2012, at 3:18 PM, Roman Kennke wrote: > >>>>>> > >>>>>>> Am Montag, den 26.11.2012, 11:55 -0800 schrieb Christian Thalinger: > >>>>>>>> On Nov 23, 2012, at 9:14 AM, Roman Kennke wrote: > >>>>>>>> > >>>>>>>>> Am Mittwoch, den 21.11.2012, 14:52 -0800 schrieb Christian Thalinger: > >>>>>>>>>> On Nov 21, 2012, at 2:22 PM, Christian Thalinger wrote: > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Nov 21, 2012, at 2:17 PM, Christian Thalinger wrote: > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Nov 21, 2012, at 12:54 PM, Roman Kennke wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Am Mittwoch, den 21.11.2012, 12:47 -0800 schrieb Christian Thalinger: > >>>>>>>>>>>>>> On Nov 21, 2012, at 11:43 AM, Christian Thalinger wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Nov 21, 2012, at 9:31 AM, Roman Kennke wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi there, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> during the last days I worked on fixing the Shark compiler for Hotspot > >>>>>>>>>>>>>>>> to get it to build and run again, with the latest Hotspot code and LLVM. > >>>>>>>>>>>>>>>> Here are some details: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> - A lot of changes are just to make it build and the compiler happy. For > >>>>>>>>>>>>>>>> example, I had to remove a lot of 'const' qualifiers because of API > >>>>>>>>>>>>>>>> changes in LLVM. > >>>>>>>>>>>>>>>> - Most other changes have to do with the split of the oop and metadata > >>>>>>>>>>>>>>>> class hierarchies in Hotspot. > >>>>>>>>>>>>>>>> - Then there have been a few changes caused by LLVM changes and > >>>>>>>>>>>>>>>> improvements, most notably the LLVM intrinsics for atomic operations > >>>>>>>>>>>>>>>> (memory barrier and cmpxchg) have been removed and now have a > >>>>>>>>>>>>>>>> representation directly in LLVM's IR. This makes our code a little > >>>>>>>>>>>>>>>> nicer. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I tested this by running a number of applications, most notably Eclipse > >>>>>>>>>>>>>>>> (which is notoriously difficult on VMs), Java2Demo, SwingSet2 and a > >>>>>>>>>>>>>>>> bunch of other stuff. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I would like to get this integrated into OpenJDK now if possible. You > >>>>>>>>>>>>>>>> can find the full webrev here: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.00/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The changes seem to touch almost only shark files so these should be fine. One question though: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> + develop(bool, SharkShowCompiledMethods, false, \ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Isn't PrintCompilation doing that already? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The shared code changes look good. I filed: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 8003868: fix shark for latest HotSpot and LLVM > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- Chris > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> There are also a very minor change required in JDK: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> In order to build it, apply the patches on hsx/hotspot-comp 's hotspot > >>>>>>>>>>>>>>>> and jdk repositories respectivly. Find my build script here: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/Build8-zero-shark > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> (Review and adjust variables to your settings, most notably you will > >>>>>>>>>>>>>>>> need to change LLVM_CONFIG to point to your LLVM 3.1 installation.) > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Please let me know if there are any issues or how we can get this > >>>>>>>>>>>>>>>> integrated into Hotspot. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Finally I installed LLVM on one of our machines to be able to do a Shark build once in a while. When I try to do a jvmgshark build I get: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In file included from /usr/local/include/llvm/Support/PointerLikeTypeTraits.h:18, > >>>>>>>>>>>>>> from /usr/local/include/llvm/ADT/PointerIntPair.h:17, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Use.h:28, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Value.h:17, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:17, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/DataTypes.h:53:3: error: #error "Must #define __STDC_CONSTANT_MACROS before " "#including Support/DataTypes.h" > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> and: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In file included from /usr/local/include/llvm/Attributes.h:18, > >>>>>>>>>>>>>> from /usr/local/include/llvm/Argument.h:18, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/llvmHeaders.hpp:39, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/shark/sharkEntry.hpp:29, > >>>>>>>>>>>>>> from /home/cthaling/8003868/src/share/vm/compiler/disassembler.cpp:51: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isInt(int64_t)?: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: note: (if you use ?-fpermissive?, G++ will accept your code, but allowing the use of an undeclared name is deprecated) > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:38: error: there are no arguments to ?INT64_C? that depend on a template parameter, so a declaration of ?INT64_C? must be available > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isUInt(uint64_t)?: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:64: error: there are no arguments to ?UINT64_C? that depend on a template parameter, so a declaration of ?UINT64_C? must be available > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h: In function ?bool llvm::isIntN(unsigned int, int64_t)?: > >>>>>>>>>>>>>> /usr/local/include/llvm/Support/MathExtras.h:96: error: ?INT64_C? was not declared in this scope > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Not sure if the latter is because of the former one. Have you seen this before? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yes, it's caused by the former. And yes, I have seen it before. IIRC, > >>>>>>>>>>>>> this happens when certain cflags are not set correctly. The script > >>>>>>>>>>>>> jdk/make/jdk_generic_profile.sh will call llvm-config to figure out the > >>>>>>>>>>>>> correct flags. In order for this to work, you need to have the full path > >>>>>>>>>>>>> to the llvm-config script set in the LLVM_CONFIG env variable. Were you > >>>>>>>>>>>>> using the build script that I provided? > >>>>>>>>>>>> > >>>>>>>>>>>> No. I took your script and got the important environment variables. But I missed the LLVM_* ones. Usually we only build hotspot so we don't have this jdk script. > >>>>>>>>>>>> > >>>>>>>>>>>> Now that I have the LLVM_* variables it's even worse: > >>>>>>>>>>>> > >>>>>>>>>>>> /home/cthaling/8003868/src/share/vm/oops/oop.hpp:72: error: cast from type ?markOopDesc* const volatile*? to type ?markOopDesc**? casts away constness > >>>>>>>>>>>> > >>>>>>>>>>>> It's probably this guy: -Wcast-qual > >>>>>>>>>>> > >>>>>>>>>>> Got it: > >>>>>>>>>>> > >>>>>>>>>>> $ java -version > >>>>>>>>>>> java version "1.8.0-ea" > >>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > >>>>>>>>>>> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal-jvmg, mixed mode) > >>>>>>>>>> > >>>>>>>>>> I ran the compiler regression tests and Shark crashes in 5091921: > >>>>>>>>>> > >>>>>>>>>> cthaling at intelsdv03.us.oracle.com:~/8003868/test$ jtreg -workDir:$EXPORTHOME/jtreg -reportDir:$EXPORTHOME/jtreg -testjdk:$JAVA_HOME -verbose:summary compiler/5091921/ > >>>>>>>>>> Directory "/export/twisti/jtreg/scratch" not found: creating > >>>>>>>>>> Passed: compiler/5091921/Test5091921.java > >>>>>>>>>> Passed: compiler/5091921/Test6186134.java > >>>>>>>>>> Passed: compiler/5091921/Test6196102.java > >>>>>>>>>> Passed: compiler/5091921/Test6357214.java > >>>>>>>>>> Passed: compiler/5091921/Test6559156.java > >>>>>>>>>> Passed: compiler/5091921/Test6753639.java > >>>>>>>>>> Passed: compiler/5091921/Test6850611.java > >>>>>>>>>> Passed: compiler/5091921/Test6890943.java > >>>>>>>>>> Passed: compiler/5091921/Test6897150.java > >>>>>>>>>> Passed: compiler/5091921/Test6905845.java > >>>>>>>>>> Passed: compiler/5091921/Test6931567.java > >>>>>>>>>> /net/sqenfs-1.us.oracle.com/export1/comp/vm/tool/jtreg/execution/linux/bin/jtreg: line 139: 27784 Segmentation fault (core dumped) "${JT_JAVA}" $javaOpts -Dprogram=`basename "$0"` -jar "${JT_HOME}/lib/jtreg.jar" $jtregOpts > >>>>>>>>>> > >>>>>>>>>> You can also run all them with a simple make in test/ by setting: > >>>>>>>>>> > >>>>>>>>>> PRODUCT_HOME=$JAVA_HOME > >>>>>>>>>> TESTDIRS=compiler > >>>>>>>>> > >>>>>>>>> Alright, I found another fairly grave bug that I would like to include a > >>>>>>>>> fix for: apparently, a 'fence' is not enough of a memory barrier for > >>>>>>>>> volatile putfield/getfield (duh). Which basically broke all of j.u.c. > >>>>>>>>> LLVM offers atomic loads and stores, which seem to be exactly what is > >>>>>>>>> needed for volatile field access. However, it does not provide helper > >>>>>>>>> functions for those in llvm::IRBuilder so I wrote my own. This should be > >>>>>>>>> the final patch for now (unless you find something else). > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.03/ > >>>>>>>> > >>>>>>>> Hmm. Maybe I did something wrong but I've already rebuilt twice: > >>>>>>>> > >>>>>>>> $ java -Xcomp -version > >>>>>>>> Value type size is target-dependent. Ask TLI. > >>>>>>>> UNREACHABLE executed at /usr/local/src/llvm-3.1.src/include/llvm/CodeGen/ValueTypes.h:257! > >>>>>>>> Stack dump: > >>>>>>>> 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"java.lang.System::getProperty"' > >>>>>>>> Aborted (core dumped) > >>>>>>> > >>>>>>> Arg! The last couple of changes I did only with LLVM3.2, where the > >>>>>>> problem disappears. Apparently, LLVM3.1 (and pre) don't deal well with > >>>>>>> atomic load/store :-( I re-introduced the CreateMemoryBarrier call and > >>>>>>> use that for SHARK_LLVM_VERSION <= 31. > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.04/ > >>>>>>> > >>>>>>> Hope that works better :-) > >>>>>> > >>>>>> I'm so sorry but... > >>>>>> > >>>>>> /export/twisti/build/8003868/build/linux_amd64_shark/product/libjvm.so: undefined reference to `SharkBuilder::memory_barrier()' > >>>>> > >>>>> Gaaa, what the... I thought I did clean rebuilds with both llvm3.2 and > >>>>> llvm3.1, but apparently not (maybe I shouldn't work after 1am). This > >>>>> (hopefully final final) patch re-instates the missing memory_barrier() > >>>>> method: > >>>>> > >>>>> > >>>>> http://cr.openjdk.java.net/~rkennke/shark/webrev.05/ > >>>>> > >>>>> Sorry for the messy back-and-forth. > >>>> > >>>> Again, so sorry: > >>>> > >>>> $ java -Xcomp -version > >>>> LLVM ERROR: Program used external function 'llvm.memory.barrier' which could not be resolved! > >>>> > >>>> Send a new patch tomorrow after some sleep ;-) > >>> > >>> Yeah, apparently 'replaced by' means that the old thing (the intrinsics) > >>> are indeed gone ;-) > >>> > >>> The problem is that the correct way to implement it (atomic load/store) > >>> doesn't work, the 'old way' (the memory_barrier() intrinsic call) > >>> doesn't work either, I also tried CreateAtomicRMW() which is probably > >>> not 100% correct, but would have done the job, but that doesn't work > >>> either (it throws the same error as the atomic load/store ...). The > >>> problem seems to only appear on 64bit volatile access. > >>> > >>> I don't know a really good solution that doesn't require jumping through > >>> big hoops, and I don't feel like working around LLVM bugs like this, > >>> especially since LLVM 3.2 (which should be released real soon now) works > >>> just fine. If you have a suggestion, please let me know, otherwise I > >>> suggest the following patch, which gets rid of all the LLVM31 blocks > >>> again and creates atomic load/store instructions (and requires LLVM 3.2 > >>> which can be found here > >>> http://llvm.org/svn/llvm-project/llvm/branches/release_32/ ). > >>> > >>> http://cr.openjdk.java.net/~rkennke/shark/webrev.06/ > >> > >> That's a reasonable thing to do given the tentative release date of December 16th. While running the compiler regression tests I got a couple of failures. You might want to address them with separate bugs. > > > > Hi Twisti, > > > > I see that you committed the patch, thanks a lot for this! However, > > there is still the small jdk patch missing: > > > > http://cr.openjdk.java.net/~rkennke/shark/webrev-jdk-00/ > > > > Can I push this myself or do you want to do it? > > Right. You can do it yourself. I would appreciate that. I tried to push to ssh://hg.openjdk.java.net/hsx/hotspot-comp-gate/jdk/ but I got: abort: could not lock repository hsx/hotspot-comp-gate/jdk: Read-only file system Was that the correct repository, or did I do something wrong? Roman From stefan.karlsson at oracle.com Thu Nov 29 14:10:33 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 29 Nov 2012 23:10:33 +0100 Subject: Review request (S): 8004199: Change the ASM package for Test8003720 Message-ID: <50B7DD59.6060709@oracle.com> http://cr.openjdk.java.net/~stefank/8004199/webrev/ * Updated to the new package name. * Fixed copyright header. * Compile to 1.7, to get the test to work with ASM4. StefanK From vladimir.kozlov at oracle.com Thu Nov 29 14:15:30 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Nov 2012 14:15:30 -0800 Subject: Review request (S): 8004199: Change the ASM package for Test8003720 In-Reply-To: <50B7DD59.6060709@oracle.com> References: <50B7DD59.6060709@oracle.com> Message-ID: Good. Thanks, Vladimir On Nov 29, 2012, at 2:10 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8004199/webrev/ > > * Updated to the new package name. > * Fixed copyright header. > * Compile to 1.7, to get the test to work with ASM4. > > StefanK From john.r.rose at oracle.com Thu Nov 29 17:50:01 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 29 Nov 2012 17:50:01 -0800 Subject: Review request (S): 8004199: Change the ASM package for Test8003720 In-Reply-To: <50B7DD59.6060709@oracle.com> References: <50B7DD59.6060709@oracle.com> Message-ID: Reviewed. Thanks for figuring that out. ? John On Nov 29, 2012, at 2:10 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8004199/webrev/ > > * Updated to the new package name. > * Fixed copyright header. > * Compile to 1.7, to get the test to work with ASM4. > > StefanK From john.r.rose at oracle.com Thu Nov 29 18:01:21 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 29 Nov 2012 18:01:21 -0800 Subject: Request for review 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap In-Reply-To: <50B79D9F.2080802@oracle.com> References: <50A0723E.2050401@oracle.com> <50A07BF9.8030509@oracle.com> <50B6AF95.8070607@oracle.com> <50B75147.70805@oracle.com> <50B79D9F.2080802@oracle.com> Message-ID: <63711BE6-55EB-46F4-A79C-DBF73CF14BBC@oracle.com> On Nov 29, 2012, at 9:38 AM, Coleen Phillimore wrote: >> I don't know if this is needed or not. I thought we would have registered some sort of object in the resolved_references to keep the mirror alive. But I guess that's not the case. >> >> (*appendix_result) = Handle(THREAD, appendix); >> + // the target is stored in the cpCache and if a reference to this >> + // MethodName is dropped we need a way to make sure the >> + // class_loader containing this method is kept alive. >> + ClassLoaderData* this_key = InstanceKlass::cast(accessing_klass())->class_loader_data(); >> + this_key->record_dependency(m->method_holder(), CHECK_NULL); // Can throw OOM >> return methodHandle(THREAD, m); >> } > > This would be nice if it's true. I don't really have a way of proving it though and JSR 292 keeps changing so it might not stay true. I'll add a FIXME comment to this though. Short answer: The logic in the comment and the code is correct. Here's the basic info about MemberName for a method: Before resolution, it has references to a klass, a name, and a type. In the resolved state, it has non-null vmtarget that points to a Method. The Method has been looked up from the klass etc. It is common that the Method::method_holder is the same as the klass::as_Klass. But in fact the method_holder might also be a supertype of the original klass. In any case, the MemberName is discarded, and only the Method (and its appendix oop if any) needs to stick around. Therefore, I think it is a good idea to add the Method::method_holder to the dependencies list, in all cases, since nothing else remains to "accompany" the Method* pointer in the linkage information. (The appendix sticks around, but it is an arbitrary oop, not metadata, so it can't help keep the Method's class alive.) ? John From david.holmes at oracle.com Thu Nov 29 19:29:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 13:29:47 +1000 Subject: RFR: JDK-8004114 build environment change In-Reply-To: <08BA05D6-141F-459B-9971-AB0F0A579F34@oracle.com> References: <4FAD3712.6040600@oracle.com> <2F920579-D7B5-4187-878E-4E057604B8B2@oracle.com> <08BA05D6-141F-459B-9971-AB0F0A579F34@oracle.com> Message-ID: <50B8282B.5020605@oracle.com> +1 David On 30/11/2012 3:59 AM, Kelly O'Hair wrote: > Looks ok to me. > > -kto > > On Nov 29, 2012, at 9:37 AM, Gary Collins wrote: > >> A small tweak to our JPRT settings: >> >> This change is slated for hsx24 repo. >> >> http://cr.openjdk.java.net/~collins/JDK-8004114/webrev-00/ >> >> Thanks >> Gary >> >> > From david.holmes at oracle.com Thu Nov 29 19:35:28 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 13:35:28 +1000 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B7AFF9.8040203@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> Message-ID: <50B82980.4020000@oracle.com> On 30/11/2012 4:56 AM, Aleksey Shipilev wrote: > Thanks for review, Christian! > > On 11/29/2012 10:28 PM, Christian Thalinger wrote: >>> The webrev for the change is here: >>> http://shipilev.net/pub/jdk/hotspot/contended/webrev-4/ >> >> Is this a review for a push? > > Yes, I'm pretty much done with functionality, it passes the tests, and > flies through JPRT without problems. This work can not be pushed until the JEP has moved to the Funded state. Meanwhile we should refine any coding issues regarding style/indents/copyrights etc. I'd also like to know what testing has been done so far from the regular hotspot testsuites. There may be places where layout assumptions are being made eg oops first. Note this is not a Review - I'm not familiar enough with this code to review, sorry. Thanks, David ----- >> hotspot/src/share/vm/classfile/classFileParser.cpp: >> >> Is it possible to factor the while-loop to align the fields into a method? > > The whole method ClassFileParser::parseClassFile cries for refactoring. > Alas, separating the contended handling code would be more messy than > just fitting in the same flow, since it uses quite of few locals within > that method. > >> hotspot/src/share/vm/classfile/classFileParser.hpp: >> >> + bool hasContendedAnnotation() { return has_annotation(_sun_misc_Contended); } >> >> We don't use camel-case method names. > > OK. > >> hotspot/src/share/vm/classfile/vmSymbols.hpp: >> >> Please keep the indent aligned. > > OK. > >> hotspot/src/share/vm/oops/fieldInfo.hpp: >> >> I wonder if we have a spare access_flags bit somewhere we could use for is_contended. > > Looking at jvm.h, I see there is only single bit left, want me to burn > it with contended flag? > >> jdk/src/share/classes/sun/misc/Contended.java: >> >> Misses copyright header. > > Will update. > > -Aleksey. > From gary.collins at oracle.com Thu Nov 29 19:53:46 2012 From: gary.collins at oracle.com (gary.collins at oracle.com) Date: Fri, 30 Nov 2012 03:53:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20121130035353.2BB9B47BFB@hg.openjdk.java.net> Changeset: b2dbd323c668 Author: jiangli Date: 2012-11-27 17:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2dbd323c668 8003848: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Summary: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Reviewed-by: bdelsart, sspitsyn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5505fbbae3d3 Author: cjplummer Date: 2012-11-29 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5505fbbae3d3 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp From john.coomes at oracle.com Thu Nov 29 20:31:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:31:53 +0000 Subject: hg: hsx/hotspot-main: 12 new changesets Message-ID: <20121130043154.5AE4547BFE@hg.openjdk.java.net> Changeset: a2df4ee40ecb Author: tbell Date: 2012-11-14 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a2df4ee40ecb 8002026: build-infra: deploy repository building Summary: Change the compare script to handle deploy build artifacts. Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: c81c4a5d8b50 Author: tbell Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c81c4a5d8b50 8001875: build-infra: We must be able to force static linking of stdc++ Summary: Ensure that we build with static linking when requested, or do not build at all Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 582c696033f5 Author: tbell Date: 2012-11-14 10:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/582c696033f5 8001941: build-infra: --disable-precompiled-headers does not seem to work Summary: With this fix the flag will do what it advertises Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in Changeset: f59a07f85125 Author: tbell Date: 2012-11-14 10:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f59a07f85125 8003317: build-infra: Configure fails when current dir is part of a symlink Summary: Call macro for removing symbolic links on a copy of the CURDIR variable before comparing Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: e69396d6d3e8 Author: tbell Date: 2012-11-14 10:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e69396d6d3e8 8003327: build-infra: "/bin/sh: : cannot execute" on solaris Summary: Fix quoting inside cut command used in the pipeline Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/makefiles/MakeHelpers.gmk Changeset: 06f146c05f49 Author: tbell Date: 2012-11-15 00:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/06f146c05f49 Merge Changeset: ecf751a69f6a Author: tbell Date: 2012-11-19 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ecf751a69f6a 8003300: build-infra: fails on solaris when objcopy is not found Summary: Only call BASIC_FIXUP_EXECUTABLE() if objcopy was found. Reviewed-by: tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: f8b0bacd4de5 Author: erikj Date: 2012-11-28 13:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f8b0bacd4de5 8001460: build-infra: Linker warnings on macosx Summary: Only linking against jvm variant specific dirs if they are expected to exist. Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 6ff2e1280dc3 Author: erikj Date: 2012-11-28 13:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6ff2e1280dc3 8003844: build-infra: docs target isn't working properly Summary: Fixed docs and docs-clean target. Added compare support for docs. Reviewed-by: ohair, jjg, ohrstrom ! common/bin/compare.sh ! common/makefiles/Main.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7d7dd520ebfd Author: erikj Date: 2012-11-28 13:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7d7dd520ebfd 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Linking against server jvm first if available. Adding filters and exceptions for hotspot lib compare on solaris. Reviewed-by: ohair, ohrstrom ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/bin/compare_exceptions.sh.incl Changeset: 13bb8c326e7b Author: katleman Date: 2012-11-28 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/13bb8c326e7b Merge Changeset: 16292f54195c Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/16292f54195c Added tag jdk8-b66 for changeset 13bb8c326e7b ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:31:58 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:31:58 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b66 for changeset 65771ad1ca55 Message-ID: <20121130043201.F3D8F47BFF@hg.openjdk.java.net> Changeset: 394515ad2a55 Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/394515ad2a55 Added tag jdk8-b66 for changeset 65771ad1ca55 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:32:05 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:32:05 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b66 for changeset e6af1ad464e3 Message-ID: <20121130043215.A3FE147C00@hg.openjdk.java.net> Changeset: 83df3493ca3c Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/83df3493ca3c Added tag jdk8-b66 for changeset e6af1ad464e3 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:32:19 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:32:19 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b66 for changeset 3eb7f11cb4e0 Message-ID: <20121130043225.3D32D47C01@hg.openjdk.java.net> Changeset: eb06aa51dfc2 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/eb06aa51dfc2 Added tag jdk8-b66 for changeset 3eb7f11cb4e0 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:32:52 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:32:52 +0000 Subject: hg: hsx/hotspot-main/jdk: 35 new changesets Message-ID: <20121130044012.B0C5D47C02@hg.openjdk.java.net> Changeset: 03d22c98b30a Author: ceisserer Date: 2012-11-13 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/03d22c98b30a 7105461: Large JTables are not rendered correctly with Xrender pipeline Reviewed-by: flar, prr ! src/solaris/classes/sun/java2d/xr/XRRenderer.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java Changeset: ed977ca9a969 Author: lana Date: 2012-11-20 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ed977ca9a969 Merge Changeset: 11ba8795bbe9 Author: kshefov Date: 2012-11-14 11:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11ba8795bbe9 7147408: [macosx] Add autodelay to fix a regression test Reviewed-by: serb, alexsch + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.html + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java Changeset: f32a0aee7bb9 Author: alitvinov Date: 2012-11-14 18:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f32a0aee7bb9 6789984: JPasswordField can not receive keyboard input Reviewed-by: naoto, anthony ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodAdapter.java ! src/solaris/classes/sun/awt/X11InputMethod.java Changeset: 0269459afe2a Author: malenkov Date: 2012-11-20 18:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0269459afe2a 8003333: Regression: java/beans/EventHandler/Test6277266.java fails with ACE Reviewed-by: art ! test/java/beans/EventHandler/Test6277266.java Changeset: ea368459cca5 Author: lana Date: 2012-11-20 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea368459cca5 Merge Changeset: c3e7ceb22d37 Author: alanb Date: 2012-11-11 10:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3e7ceb22d37 8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 5d3f8f9e6c58 Author: okutsu Date: 2012-11-12 11:12 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d3f8f9e6c58 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions Reviewed-by: naoto ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/spi/CalendarDataProvider.java + src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.sh + test/java/util/PluggableLocale/CalendarNameProviderTest.java + test/java/util/PluggableLocale/CalendarNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java + test/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider Changeset: be1fb42ef696 Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be1fb42ef696 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes Summary: Adds static utility methods to each primitive wrapper class to allow calculation of a hashCode value from an unboxed primitive. Reviewed-by: darcy, smarks, dholmes ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! test/java/lang/HashCode.java Changeset: 83765e82cacb Author: zhouyx Date: 2012-11-14 13:26 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/83765e82cacb 7201156: jar tool fails to convert file separation characters for list and extract Reviewed-by: alanb, chegar, sherman ! src/share/classes/sun/tools/jar/Main.java + test/tools/jar/JarBackSlash.java Changeset: 0f54a98f9bc9 Author: alanb Date: 2012-11-14 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0f54a98f9bc9 8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 369709a13823 Author: jjg Date: 2012-11-14 07:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/369709a13823 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native Reviewed-by: alanb + src/share/classes/java/lang/annotation/Native.java Changeset: e24123de581c Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e24123de581c 7088952: Add size in bytes constant "BYTES" to primitive type wrapper types Summary: Adds a constant BYTES to each of the primitive wrapper classes (Byte, Character, Double, Float, Integer, Long, Short) with the calculation Primitive.SIZE / Byte.SIZE already made. Reviewed-by: dholmes ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java Changeset: f4de6a38f794 Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4de6a38f794 Merge Changeset: ac22a52a732c Author: jgish Date: 2012-11-15 13:46 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac22a52a732c 6244047: impossible to specify directories to logging FileHandler unless they exist Reviewed-by: alanb ! src/share/classes/java/util/logging/FileHandler.java + test/java/util/logging/CheckLockLocationTest.java Changeset: 51c695958712 Author: weijun Date: 2012-11-16 10:34 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51c695958712 8003263: redundant cast build failure after 8003120 Reviewed-by: alanb ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: 64a42798ea5e Author: naoto Date: 2012-11-15 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64a42798ea5e 7199750: Loading sequence of service provider is changed Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java Changeset: 0ee09f17361e Author: khazra Date: 2012-11-16 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ee09f17361e 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently Summary: Add java/util/prefs to exclusiveAccess.dirs in TEST.ROOT Reviewed-by: alanb, mchung ! test/TEST.ROOT Changeset: 6f20caa6e1e9 Author: bchristi Date: 2012-11-16 17:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f20caa6e1e9 7178922: (props) re-visit how os.name is determined on Mac Reviewed-by: alanb, mchung, skovatch, serb ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 25e5df117021 Author: xuelei Date: 2012-11-18 01:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25e5df117021 8003587: Warning cleanup in package javax.net.ssl Summary: Removes unnecessary imports and adds missing Override annotations Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/SSLContextSpi.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLPermission.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSession.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/net/ssl/X509KeyManager.java Changeset: f740a9ac6eb6 Author: weijun Date: 2012-11-19 11:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f740a9ac6eb6 8002344: Krb5LoginModule config class does not return proper KDC list from DNS Reviewed-by: weijun Contributed-by: Severin Gehwolf , Wang Weijun ! src/share/classes/sun/security/krb5/Config.java + test/sun/security/krb5/config/DNS.java + test/sun/security/krb5/config/NamingManager.java + test/sun/security/krb5/config/dns.sh Changeset: 3877706701b1 Author: alanb Date: 2012-11-19 13:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3877706701b1 8003607: More ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 2d08b404cd91 Author: jzavgren Date: 2012-11-20 09:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d08b404cd91 8000476: Memory Leaks and uninitialized memory access in PKCS11 and other native code Reviewed-by: dsamersoff, valeriep, chegar ! src/share/bin/wildcard.c ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/solaris/bin/java_md_solinux.c Changeset: 914cd9b482c8 Author: ksrini Date: 2012-11-19 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/914cd9b482c8 8001533: java launcher must launch javafx applications Reviewed-by: ksrini, mchung, kcr, alanb Contributed-by: david.dehaven at oracle.com ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/TestHelper.java Changeset: b1c364c84d09 Author: ksrini Date: 2012-11-19 19:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b1c364c84d09 8003660: (launcher) 8001533 regression tests Reviewed-by: ksrini, mchung, kcr, ddehaven Contributed-by: steve.sides at oracle.com + test/tools/launcher/FXLauncherTest.java Changeset: 107a7a52a3c0 Author: lana Date: 2012-11-20 11:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/107a7a52a3c0 Merge Changeset: ccff3b663797 Author: tbell Date: 2012-11-14 10:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ccff3b663797 8001906: build-infra: warning: [path] bad path element on Solaris Summary: Remove unnecesary -cp parameter from compile line Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileDemos.gmk Changeset: 716efc201640 Author: tbell Date: 2012-11-15 00:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/716efc201640 Merge Changeset: 44e845bb5f76 Author: erikj Date: 2012-11-28 09:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44e845bb5f76 8003960: build-infra: Jarsigner launcher has wrong classname Summary: Fixed package name in launcher Reviewed-by: alanb, ohair, ohrstrom ! makefiles/CompileLaunchers.gmk Changeset: ad5741112252 Author: erikj Date: 2012-11-28 13:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad5741112252 8001460: build-infra: Linker warnings on macosx Summary: Remove creation of empty i386 section from fdlibm Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 7ecc80d2ff2e Author: erikj Date: 2012-11-28 13:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ecc80d2ff2e 8003477: build-infra: Remove explicit source file listings for libs when possible Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 51d2fd6d9850 Author: erikj Date: 2012-11-28 13:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51d2fd6d9850 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Reorder libraries on link command line to match old build. Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 54516ed0f99f Author: erikj Date: 2012-11-28 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54516ed0f99f 8003482: build-infra: Use correct manifest in security jars Reviewed-by: ohair, ohrstrom ! makefiles/CreateJars.gmk Changeset: 4d337fae2250 Author: katleman Date: 2012-11-28 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d337fae2250 Merge Changeset: df5619994dc3 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/df5619994dc3 Added tag jdk8-b66 for changeset 4d337fae2250 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:42:34 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:42:34 +0000 Subject: hg: hsx/hotspot-main/langtools: 22 new changesets Message-ID: <20121130044327.2084847C03@hg.openjdk.java.net> Changeset: e6b1abdc11ca Author: rfield Date: 2012-11-13 08:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e6b1abdc11ca 8003306: Compiler crash: calculation of inner class access modifier Summary: Fix binary sense lost in transition to hasTag Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/InnerConstructor.java Changeset: 2901c7b5339e Author: jjg Date: 2012-11-13 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2901c7b5339e 8003299: Cleanup javac Log support for deferred diagnostics Reviewed-by: mcimadamore, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: f14c693a0e48 Author: jjg Date: 2012-11-14 10:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f14c693a0e48 8003412: javac needs to understand java.lang.annotation.Native Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java + test/tools/javac/nativeHeaders/javahComparison/TestClass4.java + test/tools/javac/nativeHeaders/javahComparison/TestClass5.java Changeset: b486794d160d Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b486794d160d Merge Changeset: 33abf479f202 Author: jjg Date: 2012-11-14 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/33abf479f202 7021614: extend com.sun.source API to support parsing javadoc comments Reviewed-by: ksrini, strarup ! make/build.xml + src/share/classes/com/sun/source/doctree/AttributeTree.java + src/share/classes/com/sun/source/doctree/AuthorTree.java + src/share/classes/com/sun/source/doctree/BlockTagTree.java + src/share/classes/com/sun/source/doctree/CommentTree.java + src/share/classes/com/sun/source/doctree/DeprecatedTree.java + src/share/classes/com/sun/source/doctree/DocCommentTree.java + src/share/classes/com/sun/source/doctree/DocRootTree.java + src/share/classes/com/sun/source/doctree/DocTree.java + src/share/classes/com/sun/source/doctree/DocTreeVisitor.java + src/share/classes/com/sun/source/doctree/EndElementTree.java + src/share/classes/com/sun/source/doctree/EntityTree.java + src/share/classes/com/sun/source/doctree/ErroneousTree.java + src/share/classes/com/sun/source/doctree/IdentifierTree.java + src/share/classes/com/sun/source/doctree/InheritDocTree.java + src/share/classes/com/sun/source/doctree/InlineTagTree.java + src/share/classes/com/sun/source/doctree/LinkTree.java + src/share/classes/com/sun/source/doctree/LiteralTree.java + src/share/classes/com/sun/source/doctree/ParamTree.java + src/share/classes/com/sun/source/doctree/ReferenceTree.java + src/share/classes/com/sun/source/doctree/ReturnTree.java + src/share/classes/com/sun/source/doctree/SeeTree.java + src/share/classes/com/sun/source/doctree/SerialDataTree.java + src/share/classes/com/sun/source/doctree/SerialFieldTree.java + src/share/classes/com/sun/source/doctree/SerialTree.java + src/share/classes/com/sun/source/doctree/SinceTree.java + src/share/classes/com/sun/source/doctree/StartElementTree.java + src/share/classes/com/sun/source/doctree/TextTree.java + src/share/classes/com/sun/source/doctree/ThrowsTree.java + src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java + src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java + src/share/classes/com/sun/source/doctree/ValueTree.java + src/share/classes/com/sun/source/doctree/VersionTree.java + src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/Tree.java + src/share/classes/com/sun/source/util/DocTreeScanner.java + src/share/classes/com/sun/source/util/DocTrees.java + src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + src/share/classes/com/sun/tools/javac/parser/LazyDocCommentTable.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java + src/share/classes/com/sun/tools/javac/tree/DocPretty.java + src/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/DocCommentProcessor.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadEntity.java + test/tools/javac/diags/examples/BadGreaterThan.java + test/tools/javac/diags/examples/BadInlineTag.java + test/tools/javac/diags/examples/GreaterThanExpected.java + test/tools/javac/diags/examples/MalformedHTML.java + test/tools/javac/diags/examples/MissingSemicolon.java + test/tools/javac/diags/examples/NoTagName.java + test/tools/javac/diags/examples/RefBadParens.java + test/tools/javac/diags/examples/RefIdentifierExpected.java + test/tools/javac/diags/examples/RefSyntaxError.java + test/tools/javac/diags/examples/RefUnexpectedInput.java + test/tools/javac/diags/examples/UnexpectedContent.java + test/tools/javac/diags/examples/UnterminatedInlineTag.java + test/tools/javac/diags/examples/UnterminatedSignature.java + test/tools/javac/doctree/AttrTest.java + test/tools/javac/doctree/AuthorTest.java + test/tools/javac/doctree/BadTest.java + test/tools/javac/doctree/CodeTest.java + test/tools/javac/doctree/DeprecatedTest.java + test/tools/javac/doctree/DocCommentTester.java + test/tools/javac/doctree/DocRootTest.java + test/tools/javac/doctree/ElementTest.java + test/tools/javac/doctree/EntityTest.java + test/tools/javac/doctree/ExceptionTest.java + test/tools/javac/doctree/FirstSentenceTest.java + test/tools/javac/doctree/InheritDocTest.java + test/tools/javac/doctree/LinkPlainTest.java + test/tools/javac/doctree/LinkTest.java + test/tools/javac/doctree/LiteralTest.java + test/tools/javac/doctree/ParamTest.java + test/tools/javac/doctree/ReferenceTest.java + test/tools/javac/doctree/ReturnTest.java + test/tools/javac/doctree/SeeTest.java + test/tools/javac/doctree/SerialDataTest.java + test/tools/javac/doctree/SerialFieldTest.java + test/tools/javac/doctree/SerialTest.java + test/tools/javac/doctree/SimpleDocTreeVisitorTest.java + test/tools/javac/doctree/SinceTest.java + test/tools/javac/doctree/TagTest.java + test/tools/javac/doctree/ThrowableTest.java + test/tools/javac/doctree/ValueTest.java + test/tools/javac/doctree/VersionTest.java Changeset: bfec2a1cc869 Author: jjg Date: 2012-11-15 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bfec2a1cc869 8000800: javadoc uses static non-final fields Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java Changeset: 467f4f754368 Author: jjg Date: 2012-11-15 14:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/467f4f754368 8003257: refactor javadoc tool option handling Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/ToolOption.java Changeset: 400a4e8accd3 Author: jjg Date: 2012-11-15 19:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/400a4e8accd3 8002079: update DocFile to use a JavaFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: bdcef2ef52d2 Author: jjg Date: 2012-11-15 23:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bdcef2ef52d2 6493690: javadoc should have a javax.tools.Tool service provider installed in tools.jar Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTaskImpl.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + src/share/classes/javax/tools/DocumentationTool.java ! src/share/classes/javax/tools/JavaCompiler.java ! src/share/classes/javax/tools/ToolProvider.java ! test/tools/javadoc/CheckResourceKeys.java + test/tools/javadoc/api/basic/APITest.java + test/tools/javadoc/api/basic/DocletPathTest.java + test/tools/javadoc/api/basic/GetSourceVersionsTest.java + test/tools/javadoc/api/basic/GetTask_DiagListenerTest.java + test/tools/javadoc/api/basic/GetTask_DocletClassTest.java + test/tools/javadoc/api/basic/GetTask_FileManagerTest.java + test/tools/javadoc/api/basic/GetTask_FileObjectsTest.java + test/tools/javadoc/api/basic/GetTask_OptionsTest.java + test/tools/javadoc/api/basic/GetTask_WriterTest.java + test/tools/javadoc/api/basic/IsSupportedOptionTest.java + test/tools/javadoc/api/basic/JavadocTaskImplTest.java + test/tools/javadoc/api/basic/RunTest.java + test/tools/javadoc/api/basic/TagletPathTest.java + test/tools/javadoc/api/basic/Task_reuseTest.java + test/tools/javadoc/api/basic/pkg/C.java + test/tools/javadoc/api/basic/taglets/UnderlineTaglet.java Changeset: 843d3b191773 Author: jjh Date: 2012-11-16 18:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/843d3b191773 8003357: Add support for jtreg -concurrency to langtools/test/Makefile Reviewed-by: jjg ! test/Makefile Changeset: 01c9d4161882 Author: mcimadamore Date: 2012-11-17 19:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/01c9d4161882 8003280: Add lambda tests Summary: Turn on lambda expression, method reference and default method support Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java ! test/tools/javac/defaultMethods/Neg01.java ! test/tools/javac/defaultMethods/Neg02.java ! test/tools/javac/defaultMethods/Neg03.java ! test/tools/javac/defaultMethods/Neg04.java ! test/tools/javac/defaultMethods/Neg05.java ! test/tools/javac/defaultMethods/Neg06.java ! test/tools/javac/defaultMethods/Neg07.java ! test/tools/javac/defaultMethods/Neg08.java ! test/tools/javac/defaultMethods/Neg09.java ! test/tools/javac/defaultMethods/Neg10.java ! test/tools/javac/defaultMethods/Neg11.java ! test/tools/javac/defaultMethods/Neg12.java ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/defaultMethods/Neg13.java ! test/tools/javac/defaultMethods/Neg14.java ! test/tools/javac/defaultMethods/Neg15.java ! test/tools/javac/defaultMethods/Neg16.java ! test/tools/javac/defaultMethods/Pos01.java ! test/tools/javac/defaultMethods/Pos02.java ! test/tools/javac/defaultMethods/Pos04.java ! test/tools/javac/defaultMethods/Pos05.java ! test/tools/javac/defaultMethods/Pos06.java ! test/tools/javac/defaultMethods/Pos07.java ! test/tools/javac/defaultMethods/Pos08.java ! test/tools/javac/defaultMethods/Pos10.java ! test/tools/javac/defaultMethods/Pos11.java ! test/tools/javac/defaultMethods/Pos12.java ! test/tools/javac/defaultMethods/Pos13.java ! test/tools/javac/defaultMethods/Pos14.java ! test/tools/javac/defaultMethods/Pos15.java ! test/tools/javac/defaultMethods/Pos16.java ! test/tools/javac/defaultMethods/TestDefaultBody.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/defaultMethods/fd/FDTest.java ! test/tools/javac/defaultMethods/separate/Separate.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java ! test/tools/javac/diags/examples/CantAccessInnerClsConstr.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantApplySymbolFragment.java ! test/tools/javac/diags/examples/CantApplySymbolsFragment.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/ConditionalTargetCantBeVoid.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/DefaultOverridesObjectMember.java ! test/tools/javac/diags/examples/IncompatibleAbstracts.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/IncompatibleTypesInConditional.java ! test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java ! test/tools/javac/diags/examples/LocalVarNeedsFinal.java ! test/tools/javac/diags/examples/MissingReturnValue.java ! test/tools/javac/diags/examples/MissingReturnValueFragment.java ! test/tools/javac/diags/examples/NoAbstracts.java ! test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotAFunctionalIntf.java ! test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java ! test/tools/javac/diags/examples/OverriddenDefault.java ! test/tools/javac/diags/examples/PotentialLambdaFound.java ! test/tools/javac/diags/examples/RedundantSupertype.java ! test/tools/javac/diags/examples/RefAmbiguousFragment.java ! test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java ! test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/diags/examples/UnexpectedMref.java + test/tools/javac/diags/examples/UnexpectedReturnValue.java ! test/tools/javac/generics/7022054/T7022054pos1.java + test/tools/javac/generics/7022054/T7022054pos1.out ! test/tools/javac/generics/7022054/T7022054pos2.java + test/tools/javac/generics/7022054/T7022054pos2.out + test/tools/javac/lambda/BadAccess.java + test/tools/javac/lambda/BadAccess.out + test/tools/javac/lambda/BadAccess02.java + test/tools/javac/lambda/BadAccess02.out + test/tools/javac/lambda/BadAccess03.java + test/tools/javac/lambda/BadAccess03.out + test/tools/javac/lambda/BadBreakContinue.java + test/tools/javac/lambda/BadBreakContinue.out + test/tools/javac/lambda/BadConv03.java + test/tools/javac/lambda/BadConv03.out + test/tools/javac/lambda/BadConv04.java + test/tools/javac/lambda/BadConv04.out + test/tools/javac/lambda/BadExpressionLambda.java + test/tools/javac/lambda/BadExpressionLambda.out + test/tools/javac/lambda/BadLambdaExpr.java + test/tools/javac/lambda/BadLambdaPos.java + test/tools/javac/lambda/BadLambdaPos.out + test/tools/javac/lambda/BadMethodCall.java + test/tools/javac/lambda/BadMethodCall.out + test/tools/javac/lambda/BadRecovery.java + test/tools/javac/lambda/BadRecovery.out + test/tools/javac/lambda/BadReturn.java + test/tools/javac/lambda/BadReturn.out + test/tools/javac/lambda/BadStatementInLambda.java + test/tools/javac/lambda/BadStatementInLambda.out + test/tools/javac/lambda/BadStatementInLambda02.java + test/tools/javac/lambda/BadStatementInLambda02.out + test/tools/javac/lambda/BadTargetType.java + test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/Conditional01.java + test/tools/javac/lambda/Conditional02.java + test/tools/javac/lambda/Conditional03.java + test/tools/javac/lambda/Conformance01.java + test/tools/javac/lambda/Defender01.java + test/tools/javac/lambda/DisjunctiveTypeTest.java + test/tools/javac/lambda/EffectivelyFinal01.java + test/tools/javac/lambda/EffectivelyFinal01.out ! test/tools/javac/lambda/EffectivelyFinalTest.java ! test/tools/javac/lambda/EffectivelyFinalTest01.out ! test/tools/javac/lambda/EffectivelyFinalTest02.out + test/tools/javac/lambda/ErroneousArg.java + test/tools/javac/lambda/ErroneousArg.out + test/tools/javac/lambda/ErroneousLambdaExpr.java ! test/tools/javac/lambda/InnerConstructor.java + test/tools/javac/lambda/LambdaCapture01.java + test/tools/javac/lambda/LambdaCapture02.java + test/tools/javac/lambda/LambdaCapture03.java + test/tools/javac/lambda/LambdaCapture04.java + test/tools/javac/lambda/LambdaCapture05.java + test/tools/javac/lambda/LambdaCapture06.java + test/tools/javac/lambda/LambdaConv01.java + test/tools/javac/lambda/LambdaConv03.java + test/tools/javac/lambda/LambdaConv05.java + test/tools/javac/lambda/LambdaConv06.java + test/tools/javac/lambda/LambdaConv08.java + test/tools/javac/lambda/LambdaConv09.java + test/tools/javac/lambda/LambdaConv09.out + test/tools/javac/lambda/LambdaConv10.java + test/tools/javac/lambda/LambdaConv10.out + test/tools/javac/lambda/LambdaConv11.java + test/tools/javac/lambda/LambdaConv12.java + test/tools/javac/lambda/LambdaConv13.java + test/tools/javac/lambda/LambdaConv16.java + test/tools/javac/lambda/LambdaConv17.java + test/tools/javac/lambda/LambdaConv18.java + test/tools/javac/lambda/LambdaConv18.out + test/tools/javac/lambda/LambdaConv19.java + test/tools/javac/lambda/LambdaConv20.java + test/tools/javac/lambda/LambdaConv21.java + test/tools/javac/lambda/LambdaConv21.out + test/tools/javac/lambda/LambdaConv22.java + test/tools/javac/lambda/LambdaConv23.java + test/tools/javac/lambda/LambdaConv24.java + test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.out + test/tools/javac/lambda/LambdaExpr01.java + test/tools/javac/lambda/LambdaExpr02.java + test/tools/javac/lambda/LambdaExpr04.java + test/tools/javac/lambda/LambdaExpr05.java + test/tools/javac/lambda/LambdaExpr06.java + test/tools/javac/lambda/LambdaExpr07.java + test/tools/javac/lambda/LambdaExpr08.java + test/tools/javac/lambda/LambdaExpr09.java + test/tools/javac/lambda/LambdaExpr10.java + test/tools/javac/lambda/LambdaExpr10.out + test/tools/javac/lambda/LambdaExpr11.java + test/tools/javac/lambda/LambdaExpr12.java + test/tools/javac/lambda/LambdaExpr13.java + test/tools/javac/lambda/LambdaExpr14.java + test/tools/javac/lambda/LambdaExpr15.java + test/tools/javac/lambda/LambdaExpr16.java + test/tools/javac/lambda/LambdaExpr17.java + test/tools/javac/lambda/LambdaExpr18.java + test/tools/javac/lambda/LambdaExpr19.java + test/tools/javac/lambda/LambdaExpr19.out + test/tools/javac/lambda/LambdaExpr20.java + test/tools/javac/lambda/LambdaExprNotVoid.java + test/tools/javac/lambda/LambdaExprNotVoid.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/LambdaScope01.java + test/tools/javac/lambda/LambdaScope02.java + test/tools/javac/lambda/LambdaScope03.java + test/tools/javac/lambda/LambdaScope04.java + test/tools/javac/lambda/LambdaScope04.out + test/tools/javac/lambda/LocalBreakAndContinue.java + test/tools/javac/lambda/MethodReference01.java + test/tools/javac/lambda/MethodReference02.java + test/tools/javac/lambda/MethodReference03.java + test/tools/javac/lambda/MethodReference04.java + test/tools/javac/lambda/MethodReference04.out + test/tools/javac/lambda/MethodReference05.java + test/tools/javac/lambda/MethodReference06.java + test/tools/javac/lambda/MethodReference07.java + test/tools/javac/lambda/MethodReference08.java + test/tools/javac/lambda/MethodReference08.out + test/tools/javac/lambda/MethodReference09.java + test/tools/javac/lambda/MethodReference09.out + test/tools/javac/lambda/MethodReference10.java + test/tools/javac/lambda/MethodReference11.java + test/tools/javac/lambda/MethodReference12.java + test/tools/javac/lambda/MethodReference13.java + test/tools/javac/lambda/MethodReference14.java + test/tools/javac/lambda/MethodReference15.java + test/tools/javac/lambda/MethodReference16.java + test/tools/javac/lambda/MethodReference17.java + test/tools/javac/lambda/MethodReference18.java + test/tools/javac/lambda/MethodReference19.java + test/tools/javac/lambda/MethodReference20.java + test/tools/javac/lambda/MethodReference20.out + test/tools/javac/lambda/MethodReference21.java + test/tools/javac/lambda/MethodReference21.out + test/tools/javac/lambda/MethodReference22.java + test/tools/javac/lambda/MethodReference22.out + test/tools/javac/lambda/MethodReference23.java + test/tools/javac/lambda/MethodReference23.out + test/tools/javac/lambda/MethodReference24.java + test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference26.java + test/tools/javac/lambda/MethodReference26.out + test/tools/javac/lambda/MethodReference27.java + test/tools/javac/lambda/MethodReference28.java + test/tools/javac/lambda/MethodReference28.out + test/tools/javac/lambda/MethodReference29.java + test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference31.java + test/tools/javac/lambda/MethodReference32.java + test/tools/javac/lambda/MethodReference32.out + test/tools/javac/lambda/MethodReference33.java + test/tools/javac/lambda/MethodReference34.java + test/tools/javac/lambda/MethodReference35.java + test/tools/javac/lambda/MethodReference36.java + test/tools/javac/lambda/MethodReference37.java + test/tools/javac/lambda/MethodReference37.out + test/tools/javac/lambda/MethodReference38.java + test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference39.java + test/tools/javac/lambda/MethodReference39.out + test/tools/javac/lambda/MethodReference40.java + test/tools/javac/lambda/MethodReference40.out + test/tools/javac/lambda/MethodReference41.java + test/tools/javac/lambda/MethodReference42.java + test/tools/javac/lambda/MethodReference43.java + test/tools/javac/lambda/MethodReference44.java + test/tools/javac/lambda/MethodReference45.java + test/tools/javac/lambda/MethodReference45.out + test/tools/javac/lambda/MethodReference46.java + test/tools/javac/lambda/MethodReference47.java + test/tools/javac/lambda/MethodReference47.out + test/tools/javac/lambda/MethodReference48.java + test/tools/javac/lambda/MethodReference49.java + test/tools/javac/lambda/MethodReference50.java + test/tools/javac/lambda/MethodReference50.out + test/tools/javac/lambda/MethodReference51.java + test/tools/javac/lambda/MethodReference51.out + test/tools/javac/lambda/MethodReference52.java + test/tools/javac/lambda/MethodReference52.out + test/tools/javac/lambda/MethodReference53.java + test/tools/javac/lambda/MethodReference53.out + test/tools/javac/lambda/MethodReference54.java + test/tools/javac/lambda/MethodReference54.out ! test/tools/javac/lambda/MethodReferenceParserTest.java + test/tools/javac/lambda/MostSpecific01.java + test/tools/javac/lambda/MostSpecific01.out + test/tools/javac/lambda/MostSpecific02.java + test/tools/javac/lambda/MostSpecific02.out + test/tools/javac/lambda/MostSpecific03.java + test/tools/javac/lambda/MostSpecific03.out + test/tools/javac/lambda/MostSpecific04.java + test/tools/javac/lambda/MostSpecific05.java + test/tools/javac/lambda/MostSpecific06.java + test/tools/javac/lambda/MostSpecific06.out + test/tools/javac/lambda/MostSpecific07.java + test/tools/javac/lambda/MostSpecific07.out + test/tools/javac/lambda/NakedThis.java + test/tools/javac/lambda/SourceLevelTest.java + test/tools/javac/lambda/SourceLevelTest.out + test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType02.java + test/tools/javac/lambda/TargetType03.java + test/tools/javac/lambda/TargetType04.java + test/tools/javac/lambda/TargetType04.out + test/tools/javac/lambda/TargetType05.java + test/tools/javac/lambda/TargetType06.java + test/tools/javac/lambda/TargetType06.out + test/tools/javac/lambda/TargetType07.java + test/tools/javac/lambda/TargetType08.java + test/tools/javac/lambda/TargetType10.java + test/tools/javac/lambda/TargetType10.out + test/tools/javac/lambda/TargetType11.java + test/tools/javac/lambda/TargetType11.out + test/tools/javac/lambda/TargetType12.java + test/tools/javac/lambda/TargetType13.java + test/tools/javac/lambda/TargetType13.out + test/tools/javac/lambda/TargetType14.java + test/tools/javac/lambda/TargetType14.out + test/tools/javac/lambda/TargetType15.java + test/tools/javac/lambda/TargetType16.java + test/tools/javac/lambda/TargetType16.out + test/tools/javac/lambda/TargetType17.java + test/tools/javac/lambda/TargetType17.out + test/tools/javac/lambda/TargetType18.java + test/tools/javac/lambda/TargetType19.java + test/tools/javac/lambda/TargetType19.out + test/tools/javac/lambda/TargetType20.java + test/tools/javac/lambda/TargetType20.out + test/tools/javac/lambda/TargetType21.java + test/tools/javac/lambda/TargetType21.out + test/tools/javac/lambda/TargetType22.java + test/tools/javac/lambda/TargetType22.out + test/tools/javac/lambda/TargetType23.java + test/tools/javac/lambda/TargetType23.out + test/tools/javac/lambda/TargetType24.java + test/tools/javac/lambda/TargetType24.out + test/tools/javac/lambda/TargetType25.java + test/tools/javac/lambda/TargetType26.java + test/tools/javac/lambda/TargetType26.out + test/tools/javac/lambda/TargetType27.java + test/tools/javac/lambda/TargetType27.out + test/tools/javac/lambda/TargetType28.java + test/tools/javac/lambda/TargetType28.out + test/tools/javac/lambda/TargetType29.java + test/tools/javac/lambda/TargetType30.java + test/tools/javac/lambda/TargetType31.java + test/tools/javac/lambda/TargetType32.java + test/tools/javac/lambda/TargetType33.java + test/tools/javac/lambda/TargetType33.out + test/tools/javac/lambda/TargetType34.java + test/tools/javac/lambda/TargetType35.java + test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType37.java + test/tools/javac/lambda/TargetType38.java + test/tools/javac/lambda/TargetType38.out + test/tools/javac/lambda/TargetType39.java + test/tools/javac/lambda/TargetType39.out + test/tools/javac/lambda/TargetType40.java + test/tools/javac/lambda/TargetType40.out + test/tools/javac/lambda/TargetType41.java + test/tools/javac/lambda/TargetType41.out + test/tools/javac/lambda/TargetType42.java + test/tools/javac/lambda/TargetType43.java + test/tools/javac/lambda/TargetType43.out + test/tools/javac/lambda/TargetType44.java + test/tools/javac/lambda/TargetType44.out + test/tools/javac/lambda/TargetType45.java + test/tools/javac/lambda/TargetType45.out + test/tools/javac/lambda/TargetType46.java + test/tools/javac/lambda/TargetType46.out + test/tools/javac/lambda/TargetType47.java + test/tools/javac/lambda/TargetType48.java + test/tools/javac/lambda/TargetType49.java + test/tools/javac/lambda/TargetType49.out + test/tools/javac/lambda/TargetType50.java + test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TestInvokeDynamic.java + test/tools/javac/lambda/TestSelfRef.java + test/tools/javac/lambda/VoidCompatibility.java + test/tools/javac/lambda/VoidCompatibility.out + test/tools/javac/lambda/abort/Abort.java + test/tools/javac/lambda/badMemberRefBytecode/Main.java + test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java + test/tools/javac/lambda/badMemberRefBytecode/Use.java + test/tools/javac/lambda/funcInterfaces/Helper.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.out + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out + test/tools/javac/lambda/funcInterfaces/NonSAM1.java + test/tools/javac/lambda/funcInterfaces/NonSAM1.out + test/tools/javac/lambda/funcInterfaces/NonSAM2.java + test/tools/javac/lambda/funcInterfaces/NonSAM2.out + test/tools/javac/lambda/funcInterfaces/NonSAM3.java + test/tools/javac/lambda/funcInterfaces/NonSAM3.out + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.java + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.java + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.out + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.java + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.out + test/tools/javac/lambda/lambdaExpression/LambdaTest1.java + test/tools/javac/lambda/lambdaExpression/LambdaTest2.java + test/tools/javac/lambda/lambdaExpression/LambdaTest3.java + test/tools/javac/lambda/lambdaExpression/LambdaTest4.java + test/tools/javac/lambda/lambdaExpression/LambdaTest5.java + test/tools/javac/lambda/lambdaExpression/LambdaTest6.java + test/tools/javac/lambda/lambdaExpression/SamConversion.java + test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java + test/tools/javac/lambda/methodReference/BridgeMethod.java + test/tools/javac/lambda/methodReference/MethodRef1.java + test/tools/javac/lambda/methodReference/MethodRef2.java + test/tools/javac/lambda/methodReference/MethodRef3.java + test/tools/javac/lambda/methodReference/MethodRef4.java + test/tools/javac/lambda/methodReference/MethodRef5.java + test/tools/javac/lambda/methodReference/MethodRef6.java + test/tools/javac/lambda/methodReference/MethodRef7.java + test/tools/javac/lambda/methodReference/MethodRef_neg.java + test/tools/javac/lambda/methodReference/MethodRef_neg.out + test/tools/javac/lambda/methodReference/SamConversion.java + test/tools/javac/lambda/methodReference/SamConversionComboTest.java + test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java + test/tools/javac/lambda/speculative/A.java + test/tools/javac/lambda/speculative/DiamondFinder.java + test/tools/javac/lambda/speculative/Main.java + test/tools/javac/lambda/speculative/Main.out + test/tools/javac/lambda/typeInference/InferenceTest11.java + test/tools/javac/lambda/typeInference/InferenceTest2.java + test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/lambda/typeInference/InferenceTest3.java + test/tools/javac/lambda/typeInference/InferenceTest4.java + test/tools/javac/lambda/typeInference/InferenceTest5.java + test/tools/javac/lambda/typeInference/InferenceTest789.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out + test/tools/javac/lambda/typeInference/InferenceTest_neg5.java + test/tools/javac/lambda/typeInference/InferenceTest_neg5.out + test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: c0f0c41cafa0 Author: jjg Date: 2012-11-19 11:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c0f0c41cafa0 8001098: Provide a simple light-weight "plug-in" mechanism for javac Reviewed-by: mcimadamore + src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! 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/resources/javac.properties + test/tools/javac/plugin/showtype/Identifiers.java + test/tools/javac/plugin/showtype/Identifiers.out + test/tools/javac/plugin/showtype/Identifiers_PI.out + test/tools/javac/plugin/showtype/ShowTypePlugin.java + test/tools/javac/plugin/showtype/Test.java Changeset: 522a1ee72340 Author: bpatel Date: 2012-11-19 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/522a1ee72340 8002304: Group methods by types in methods summary section Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/script.js ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java + test/com/sun/javadoc/testMethodTypes/pkg1/A.java + test/com/sun/javadoc/testMethodTypes/pkg1/B.java + test/com/sun/javadoc/testMethodTypes/pkg1/D.java ! test/tools/javadoc/api/basic/APITest.java Changeset: 2531de382983 Author: jjg Date: 2012-11-19 16:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2531de382983 8003655: Add javac.jvm.ClassFile.V52 Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java Changeset: a25c53e12bd0 Author: jjg Date: 2012-11-20 07:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a25c53e12bd0 8003649: regression/langtools: tools/javac/doctree Reviewed-by: ksrini ! test/tools/javac/doctree/DocCommentTester.java Changeset: fb97eaf93d61 Author: jjg Date: 2012-11-20 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fb97eaf93d61 8003650: java.lang.Exception: expected string not found: pkg/package-frame.html Reviewed-by: ksrini ! test/tools/javadoc/api/basic/GetTask_WriterTest.java ! test/tools/javadoc/api/basic/RunTest.java Changeset: 7538e419a588 Author: mcimadamore Date: 2012-11-20 15:43 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7538e419a588 8003663: lambda test fails on Windows Summary: fix path separator issue in test Reviewed-by: jjg ! test/tools/javac/lambda/abort/Abort.java Changeset: d898d9ee352f Author: rfield Date: 2012-11-20 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d898d9ee352f 8003639: convert lambda testng tests to jtreg and add them Reviewed-by: mcimadamore + test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/lambda/lambdaExecution/InInterface.java + test/tools/javac/lambda/lambdaExecution/InnerConstructor.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java + test/tools/javac/lambda/lambdaExecution/TBlock.java + test/tools/javac/lambda/lambdaExecution/TMapper.java + test/tools/javac/lambda/lambdaExecution/TPredicate.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestFDCCE.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerVarArgsThis.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNew.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNewInner.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestTypeConversion.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgs.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsExt.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsThis.java + test/tools/javac/lambdaShapes/TEST.properties + test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/ClassCase.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Hierarchy.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/HierarchyGenerator.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Rule.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/RuleGroup.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTNode.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTParser.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTShape.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java Changeset: 09ba1bfab344 Author: lana Date: 2012-11-20 11:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/09ba1bfab344 Merge - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java Changeset: da48ab364ea4 Author: erikj Date: 2012-11-28 13:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/da48ab364ea4 8003844: build-infra: docs target isn't working properly Summary: Adding resources to bootstrap javadoc.jar. Adding missing .js resource suffix Reviewed-by: ohair, jjg, ohrstrom ! makefiles/BuildLangtools.gmk Changeset: 20230f8b0eef Author: katleman Date: 2012-11-28 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/20230f8b0eef Merge Changeset: 303b09787a69 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/303b09787a69 Added tag jdk8-b66 for changeset 20230f8b0eef ! .hgtags From alejandro.murillo at oracle.com Fri Nov 30 01:04:14 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 30 Nov 2012 09:04:14 +0000 Subject: hg: hsx/hsx24/hotspot: 4 new changesets Message-ID: <20121130090424.5E48847C26@hg.openjdk.java.net> Changeset: 94984276a8dc Author: katleman Date: 2012-11-15 19:48 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/94984276a8dc Added tag jdk7u12-b02 for changeset ce5983a3e0b2 ! .hgtags Changeset: 8e459e9615fd Author: katleman Date: 2012-11-29 19:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8e459e9615fd Added tag jdk7u12-b03 for changeset 94984276a8dc ! .hgtags Changeset: b9e0f2c87dd6 Author: amurillo Date: 2012-11-29 22:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b9e0f2c87dd6 Merge Changeset: ed9b424d5e43 Author: amurillo Date: 2012-11-29 22:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ed9b424d5e43 Added tag hs24-b26 for changeset b9e0f2c87dd6 ! .hgtags From aleksey.shipilev at oracle.com Fri Nov 30 02:44:29 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 30 Nov 2012 14:44:29 +0400 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B82980.4020000@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> <50B82980.4020000@oracle.com> Message-ID: <50B88E0D.6030404@oracle.com> On 11/30/2012 07:35 AM, David Holmes wrote: > This work can not be pushed until the JEP has moved to the Funded state. So... How should one move it to the Funded state? > I'd also like to know what testing has been done so far from the regular > hotspot testsuites. There may be places where layout assumptions are > being made eg oops first. Are JPRT acceptance tests enough, or we should do the out-of-cycle VM testing before the integration? -Aleksey. From alejandro.murillo at oracle.com Fri Nov 30 03:45:21 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 30 Nov 2012 11:45:21 +0000 Subject: hg: hsx/hsx24/hotspot: 8003550: new hotspot build - hs24-b27 Message-ID: <20121130114529.B354947C2A@hg.openjdk.java.net> Changeset: d1d909eefb31 Author: amurillo Date: 2012-11-29 22:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d1d909eefb31 8003550: new hotspot build - hs24-b27 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Fri Nov 30 04:14:25 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 22:14:25 +1000 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B88E0D.6030404@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> <50B82980.4020000@oracle.com> <50B88E0D.6030404@oracle.com> Message-ID: <50B8A321.3080206@oracle.com> On 30/11/2012 8:44 PM, Aleksey Shipilev wrote: > On 11/30/2012 07:35 AM, David Holmes wrote: >> This work can not be pushed until the JEP has moved to the Funded state. > > So... How should one move it to the Funded state? http://openjdk.java.net/jeps/1 "A Group Lead, an Area Lead, or the OpenJDK Lead can move a proposal from Candidate to Funded and from Funded to Completed." >> I'd also like to know what testing has been done so far from the regular >> hotspot testsuites. There may be places where layout assumptions are >> being made eg oops first. > > Are JPRT acceptance tests enough, or we should do the out-of-cycle VM > testing before the integration? JPRT tests are no where near enough - they are absolute minimum. We should try to get VM test suites executed: runthese, nsk, plus regression tests. David ----- > -Aleksey. > From coleen.phillimore at oracle.com Fri Nov 30 04:19:15 2012 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 30 Nov 2012 07:19:15 -0500 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B88E0D.6030404@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> <50B82980.4020000@oracle.com> <50B88E0D.6030404@oracle.com> Message-ID: <50B8A443.9090603@oracle.com> I sent a code review of this code also, did you see it? I am very concerned with the additional footprint that this allocates for contended flags for each field. Did I read this code correctly? I don't think this code can be pushed until this is resolved. Thanks, Coleen On 11/30/2012 5:44 AM, Aleksey Shipilev wrote: > On 11/30/2012 07:35 AM, David Holmes wrote: >> This work can not be pushed until the JEP has moved to the Funded state. > So... How should one move it to the Funded state? > >> I'd also like to know what testing has been done so far from the regular >> hotspot testsuites. There may be places where layout assumptions are >> being made eg oops first. > Are JPRT acceptance tests enough, or we should do the out-of-cycle VM > testing before the integration? > > -Aleksey. > From aleksey.shipilev at oracle.com Fri Nov 30 04:25:01 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 30 Nov 2012 16:25:01 +0400 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B8A443.9090603@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> <50B82980.4020000@oracle.com> <50B88E0D.6030404@oracle.com> <50B8A443.9090603@oracle.com> Message-ID: <50B8A59D.9030806@oracle.com> Yes I did, Coleen, thanks for additional review. I will try to address/revisit these along with other issues outlined in other reviews. Stay tuned for another webrev coming :) -Aleksey. On 11/30/2012 04:19 PM, Coleen Phillimore wrote: > > I sent a code review of this code also, did you see it? I am very > concerned with the additional footprint that this allocates for > contended flags for each field. Did I read this code correctly? I > don't think this code can be pushed until this is resolved. > Thanks, > Coleen > > On 11/30/2012 5:44 AM, Aleksey Shipilev wrote: >> On 11/30/2012 07:35 AM, David Holmes wrote: >>> This work can not be pushed until the JEP has moved to the Funded state. >> So... How should one move it to the Funded state? >> >>> I'd also like to know what testing has been done so far from the regular >>> hotspot testsuites. There may be places where layout assumptions are >>> being made eg oops first. >> Are JPRT acceptance tests enough, or we should do the out-of-cycle VM >> testing before the integration? >> >> -Aleksey. >> > From vitalyd at gmail.com Fri Nov 30 05:05:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 08:05:47 -0500 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: <50B8A59D.9030806@oracle.com> References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> <50B82980.4020000@oracle.com> <50B88E0D.6030404@oracle.com> <50B8A443.9090603@oracle.com> <50B8A59D.9030806@oracle.com> Message-ID: Hi Aleksey, Can you please make PrintFieldLayout at least a diagnostic flag? It would be useful to see its output for users in product builds. Thanks Sent from my phone On Nov 30, 2012 7:25 AM, "Aleksey Shipilev" wrote: > Yes I did, Coleen, thanks for additional review. I will try to > address/revisit these along with other issues outlined in other reviews. > Stay tuned for another webrev coming :) > > -Aleksey. > > On 11/30/2012 04:19 PM, Coleen Phillimore wrote: > > > > I sent a code review of this code also, did you see it? I am very > > concerned with the additional footprint that this allocates for > > contended flags for each field. Did I read this code correctly? I > > don't think this code can be pushed until this is resolved. > > Thanks, > > Coleen > > > > On 11/30/2012 5:44 AM, Aleksey Shipilev wrote: > >> On 11/30/2012 07:35 AM, David Holmes wrote: > >>> This work can not be pushed until the JEP has moved to the Funded > state. > >> So... How should one move it to the Funded state? > >> > >>> I'd also like to know what testing has been done so far from the > regular > >>> hotspot testsuites. There may be places where layout assumptions are > >>> being made eg oops first. > >> Are JPRT acceptance tests enough, or we should do the out-of-cycle VM > >> testing before the integration? > >> > >> -Aleksey. > >> > > > > From aleksey.shipilev at oracle.com Fri Nov 30 05:07:13 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 30 Nov 2012 17:07:13 +0400 Subject: RFR (M): CR 8003985: Support @Contended Annotation - JEP 142 In-Reply-To: References: <50B4FF15.6090304@oracle.com> <12D86B29-377E-45B8-83D8-CF531BC0939D@oracle.com> <50B7AFF9.8040203@oracle.com> <50B82980.4020000@oracle.com> <50B88E0D.6030404@oracle.com> <50B8A443.9090603@oracle.com> <50B8A59D.9030806@oracle.com> Message-ID: <50B8AF81.7080508@oracle.com> I can, but I will be hit in the back with footprint issue again. If that is not a problem for Hotspot maintainers, I can make it diagnostic. -Aleksey. On 11/30/2012 05:05 PM, Vitaly Davidovich wrote: > Hi Aleksey, > > Can you please make PrintFieldLayout at least a diagnostic flag? It > would be useful to see its output for users in product builds. > > Thanks > > Sent from my phone > > On Nov 30, 2012 7:25 AM, "Aleksey Shipilev" > wrote: > > Yes I did, Coleen, thanks for additional review. I will try to > address/revisit these along with other issues outlined in other reviews. > Stay tuned for another webrev coming :) > > -Aleksey. > > On 11/30/2012 04:19 PM, Coleen Phillimore wrote: > > > > I sent a code review of this code also, did you see it? I am very > > concerned with the additional footprint that this allocates for > > contended flags for each field. Did I read this code correctly? I > > don't think this code can be pushed until this is resolved. > > Thanks, > > Coleen > > > > On 11/30/2012 5:44 AM, Aleksey Shipilev wrote: > >> On 11/30/2012 07:35 AM, David Holmes wrote: > >>> This work can not be pushed until the JEP has moved to the > Funded state. > >> So... How should one move it to the Funded state? > >> > >>> I'd also like to know what testing has been done so far from the > regular > >>> hotspot testsuites. There may be places where layout assumptions are > >>> being made eg oops first. > >> Are JPRT acceptance tests enough, or we should do the out-of-cycle VM > >> testing before the integration? > >> > >> -Aleksey. > >> > > > From stefan.karlsson at oracle.com Fri Nov 30 09:05:33 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 30 Nov 2012 18:05:33 +0100 Subject: Review request (S): 8004199: Change the ASM package for Test8003720 In-Reply-To: <50B7DD59.6060709@oracle.com> References: <50B7DD59.6060709@oracle.com> Message-ID: <50B8E75D.50300@oracle.com> Thanks for the reviews, Vladimir and John. StefanK On 2012-11-29 23:10, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8004199/webrev/ > > * Updated to the new package name. > * Fixed copyright header. > * Compile to 1.7, to get the test to work with ASM4. > > StefanK From Vladimir.Kozlov at oracle.com Fri Nov 30 12:38:57 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2012 12:38:57 -0800 Subject: RFR (small) 6518907: cleanup IA64 specific code in Hotspot In-Reply-To: <50B7BF2D.3010704@oracle.com> References: <50B7BF2D.3010704@oracle.com> Message-ID: <50B91961.7010101@oracle.com> I put webrev on open server: http://cr.openjdk.java.net/~kvn/6518907/webrev/ One thing concern me is code change in os.cpp for Win64: + // On Windows AMD64 link() does not work as there's no back link on the stack. + #elif (defined(IA64) || defined(AMD64)) && defined(_WIN32) Can someone familiar with Windows confirm if the statement in the comment and code change are correct? And in os_windows.cpp EXCEPTION_REG_NAT_CONSUMPTION is defined twice. Thanks, Vladimir On 11/29/12 12:01, Morris Meyer wrote: > Gentlefolk, > > I have taken a second pass at > https://jbs.oracle.com/bugs/browse/JDK-6518907 and incorporated the > comments of Goetz Lindenmaier of SAP accordingly, and their changes to > src/os/windows/vm/os_windows.cpp specifically. > > Thanks to all for the first review. > > --mm > > JBS - https://jbs.oracle.com/bugs/browse/JDK-6518907 > WEBREV - http://javaweb.us.oracle.com/~mameyer/webrevs/02/JDK-6518907/ From christian.thalinger at oracle.com Fri Nov 30 13:32:51 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 30 Nov 2012 21:32:51 +0000 Subject: hg: hsx/hotspot-main/jdk: 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Message-ID: <20121130213308.044BF47C4A@hg.openjdk.java.net> Changeset: b0f008ab45d7 Author: twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java From gary.collins at oracle.com Fri Nov 30 14:05:32 2012 From: gary.collins at oracle.com (gary.collins at oracle.com) Date: Fri, 30 Nov 2012 22:05:32 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20121130220539.AF3FC47C4D@hg.openjdk.java.net> Changeset: 6a93eda4e0f5 Author: collins Date: 2012-11-29 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6a93eda4e0f5 8004114: build environment change Summary: Modifications needed to JPRT to allow for building hard float abi and new bundle changes Reviewed-by: ohair, coleenp ! make/jprt.properties Changeset: 48dbf98e800c Author: collins Date: 2012-11-30 11:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/48dbf98e800c Merge From john.cuthbertson at oracle.com Fri Nov 30 16:27:28 2012 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 01 Dec 2012 00:27:28 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20121201002738.BC0E247C52@hg.openjdk.java.net> Changeset: 90273fc0a981 Author: coleenp Date: 2012-11-29 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/90273fc0a981 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Reviewed-by: twisti, jrose, stefank ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/prims/unsafe.cpp Changeset: dad48145e775 Author: stefank Date: 2012-11-29 23:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dad48145e775 8004199: Change the ASM package for Test8003720 Reviewed-by: kvn, jrose ! test/runtime/8003720/Asmator.java ! test/runtime/8003720/Test8003720.java Changeset: 5fafdef522c6 Author: johnc Date: 2012-11-30 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5fafdef522c6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp From alejandro.murillo at oracle.com Fri Nov 30 18:58:18 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 01 Dec 2012 02:58:18 +0000 Subject: hg: hsx/hsx25/hotspot: 26 new changesets Message-ID: <20121201025909.72A5C47C64@hg.openjdk.java.net> Changeset: 2f6dc76eb8e5 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2f6dc76eb8e5 Added tag jdk8-b66 for changeset 01684f7fee1b ! .hgtags Changeset: e1d42ba865de Author: amurillo Date: 2012-11-16 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e1d42ba865de 8003541: new hotspot build - hs25-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 49cbd3e25ba9 Author: zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/49cbd3e25ba9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp Changeset: 3ed6de6e139b Author: coleenp Date: 2012-11-20 20:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3ed6de6e139b Merge Changeset: 73e64867adb7 Author: mikael Date: 2012-11-21 09:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/73e64867adb7 8003690: Example code in JVMTI GetStackTrace documentation is broken Summary: Fixed to minor errors in example code Reviewed-by: sspitsyn, dholmes ! src/share/vm/prims/jvmti.xml Changeset: 6b881a6b0665 Author: dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6b881a6b0665 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp Changeset: ca1be5fbe6ff Author: dholmes Date: 2012-11-21 21:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca1be5fbe6ff Merge Changeset: 7c15faa95ce7 Author: mikael Date: 2012-11-27 07:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7c15faa95ce7 8003879: Duplicate definitions in vmStructs Summary: Removed duplicate entries Reviewed-by: dholmes, sspitsyn ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: bbc14465e7db Author: zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bbc14465e7db 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp Changeset: 5de2a5bd519e Author: zgu Date: 2012-11-28 06:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5de2a5bd519e Merge Changeset: fe81517cfb77 Author: hseigel Date: 2012-11-28 08:17 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fe81517cfb77 6924920: Class Data Sharing limit on the java version string can create failures Summary: Truncate the java version string and add a hash value if it is too long. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/filemap.cpp Changeset: b51dc8df86e5 Author: coleenp Date: 2012-11-28 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b51dc8df86e5 Merge Changeset: 59c790074993 Author: coleenp Date: 2012-11-28 17:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/59c790074993 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. Reviewed-by: dholmes, sspitsyn, dcubed, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 53715fb1597d Author: brutisso Date: 2012-11-20 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/53715fb1597d 7198334: UseNUMA modifies system parameters on non-NUMA system Summary: The flags MinHeapDeltaBytes and UseNUMAInterleaving must be adjusted after the OS have adjusted the UseNUMA flag in the method os::init_2. Reviewed-by: dholmes, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 19c1bd641922 Author: coleenp Date: 2012-11-26 12:31 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/19c1bd641922 8003722: More gcc 4.7 compilation errors Summary: Add a few more this->qualifications. Reviewed-by: coleenp, dholmes Contributed-by: duboscq at ssw.jku.at ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: d0aa87f04bd5 Author: stefank Date: 2012-11-27 10:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0aa87f04bd5 8003720: NPG: Method in interpreter stack frame can be deallocated Summary: Pass down a closure during root scanning to keep the class of the method alive. Reviewed-by: coleenp, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp + test/runtime/8003720/Asmator.java + test/runtime/8003720/Test8003720.java + test/runtime/8003720/Victim.java + test/runtime/8003720/VictimClassLoader.java Changeset: f34d701e952e Author: stefank Date: 2012-11-27 14:20 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f34d701e952e 8003935: Simplify the needed includes for using Thread::current() Reviewed-by: dholmes, rbackman, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/os/bsd/vm/mutex_bsd.cpp ! src/os/bsd/vm/mutex_bsd.inline.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/threadCritical_bsd.cpp ! src/os/bsd/vm/thread_bsd.inline.hpp ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp + src/share/vm/runtime/thread.inline.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 2fc0334f613a Author: johnc Date: 2012-11-27 14:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2fc0334f613a 7194633: G1: Assertion and guarantee failures in block offset table Summary: Add detailed error messages to assertions and guarantees in G1's block offset table. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/memory/space.cpp Changeset: c24f778e9401 Author: johnc Date: 2012-11-29 11:23 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c24f778e9401 Merge ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b2dbd323c668 Author: jiangli Date: 2012-11-27 17:03 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b2dbd323c668 8003848: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Summary: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Reviewed-by: bdelsart, sspitsyn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5505fbbae3d3 Author: cjplummer Date: 2012-11-29 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5505fbbae3d3 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 90273fc0a981 Author: coleenp Date: 2012-11-29 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/90273fc0a981 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Reviewed-by: twisti, jrose, stefank ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/prims/unsafe.cpp Changeset: dad48145e775 Author: stefank Date: 2012-11-29 23:02 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dad48145e775 8004199: Change the ASM package for Test8003720 Reviewed-by: kvn, jrose ! test/runtime/8003720/Asmator.java ! test/runtime/8003720/Test8003720.java Changeset: 5fafdef522c6 Author: johnc Date: 2012-11-30 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5fafdef522c6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: b61d9c88b759 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b61d9c88b759 Merge Changeset: 25bdce771bb3 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/25bdce771bb3 Added tag hs25-b11 for changeset b61d9c88b759 ! .hgtags From alejandro.murillo at oracle.com Fri Nov 30 20:10:14 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 01 Dec 2012 04:10:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20121201041023.A9B5B47C65@hg.openjdk.java.net> Changeset: 2f6dc76eb8e5 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f6dc76eb8e5 Added tag jdk8-b66 for changeset 01684f7fee1b ! .hgtags Changeset: b61d9c88b759 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b61d9c88b759 Merge Changeset: 25bdce771bb3 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/25bdce771bb3 Added tag hs25-b11 for changeset b61d9c88b759 ! .hgtags Changeset: 816b7e5bf2ed Author: amurillo Date: 2012-11-30 17:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/816b7e5bf2ed 8004248: new hotspot build - hs25-b12 Reviewed-by: jcoomes ! make/hotspot_version