From erik.helin at oracle.com Fri Nov 1 06:16:59 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 1 Nov 2013 14:16:59 +0100 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle In-Reply-To: <5271C64A.8010001@oracle.com> References: <5271C64A.8010001@oracle.com> Message-ID: <20131101131659.GA6464@ehelin-thinkpad> Hi Coleen, this looks great, just one minor nit: could you please update the comment starting at jvmtiImpl.cpp:242 (which explains why using allow_unhandled_oop is correct) to use _class_holder instead of _class_loader? Thanks, Erik On 2013-10-30, Coleen Phillimore wrote: > 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might > not work with anonymous classes > Summary: Walk methods in breakpoints for marking on stack so they > aren't deallocated by redefine classes. Use class_holder rather > than class_loader to keep GC from reclaiming class owning the > method. > > This is two bug fixes to the same code. > > open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ > bug link https://bugs.openjdk.java.net/browse/JDK-8026946 > https://bugs.openjdk.java.net/browse/JDK-8026948 > > Tested with vm.quick.testlist - and verified the jdi tests eg > nsk/jdi/BScenarios/hotswap/tc01x001 test this path. > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Nov 1 07:09:20 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 01 Nov 2013 10:09:20 -0400 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle In-Reply-To: <20131101131659.GA6464@ehelin-thinkpad> References: <5271C64A.8010001@oracle.com> <20131101131659.GA6464@ehelin-thinkpad> Message-ID: <5273B610.4040802@oracle.com> On 11/1/2013 9:16 AM, Erik Helin wrote: > Hi Coleen, > > this looks great, just one minor nit: could you please update the > comment starting at jvmtiImpl.cpp:242 (which explains why using > allow_unhandled_oop is correct) to use _class_holder instead of > _class_loader? I fixed it and the : in JvmtiBreakpoint:s. Thanks for the code review. Coleen > > Thanks, > Erik > > On 2013-10-30, Coleen Phillimore wrote: >> 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might >> not work with anonymous classes >> Summary: Walk methods in breakpoints for marking on stack so they >> aren't deallocated by redefine classes. Use class_holder rather >> than class_loader to keep GC from reclaiming class owning the >> method. >> >> This is two bug fixes to the same code. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8026946 >> https://bugs.openjdk.java.net/browse/JDK-8026948 >> >> Tested with vm.quick.testlist - and verified the jdi tests eg >> nsk/jdi/BScenarios/hotswap/tc01x001 test this path. >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Fri Nov 1 07:09:46 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 01 Nov 2013 10:09:46 -0400 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle In-Reply-To: <527288B2.2030407@oracle.com> References: <5271C64A.8010001@oracle.com> <527288B2.2030407@oracle.com> Message-ID: <5273B62A.1060904@oracle.com> On 10/31/2013 12:43 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > It looks good, thank you for fixing it! Thanks for the code review Serguei. Coleen > > Thanks, > Serguei > > On 10/30/13 7:54 PM, Coleen Phillimore wrote: >> 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might >> not work with anonymous classes >> Summary: Walk methods in breakpoints for marking on stack so they >> aren't deallocated by redefine classes. Use class_holder rather than >> class_loader to keep GC from reclaiming class owning the method. >> >> This is two bug fixes to the same code. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8026946 >> https://bugs.openjdk.java.net/browse/JDK-8026948 >> >> Tested with vm.quick.testlist - and verified the jdi tests eg >> nsk/jdi/BScenarios/hotswap/tc01x001 test this path. >> >> Thanks, >> Coleen > From staffan.larsen at oracle.com Fri Nov 1 07:29:00 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 1 Nov 2013 15:29:00 +0100 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH, andle In-Reply-To: <5271C64A.8010001@oracle.com> References: <5271C64A.8010001@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 31 okt 2013, at 03:54, Coleen Phillimore wrote: > 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes > Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. > > This is two bug fixes to the same code. > > open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ > bug link https://bugs.openjdk.java.net/browse/JDK-8026946 > https://bugs.openjdk.java.net/browse/JDK-8026948 > > Tested with vm.quick.testlist - and verified the jdi tests eg nsk/jdi/BScenarios/hotswap/tc01x001 test this path. > > Thanks, > Coleen From john.coomes at oracle.com Fri Nov 1 12:32:26 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 19:32:26 +0000 Subject: hg: hsx/hotspot-main: 60 new changesets Message-ID: <20131101193231.66BB7628EA@hg.openjdk.java.net> Changeset: 187a759c08ba Author: alanb Date: 2013-10-02 04:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/187a759c08ba 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Reviewed-by: mduigou, tbell ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: 6b8f5030e5ad Author: bpatel Date: 2013-10-04 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6b8f5030e5ad 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7c0e2fd8be4d Author: lana Date: 2013-10-08 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7c0e2fd8be4d Merge Changeset: 3ece65f23ed2 Author: lana Date: 2013-10-11 00:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3ece65f23ed2 Merge Changeset: 7dea0ce25bdc Author: pbhat Date: 2013-05-30 16:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7dea0ce25bdc Merge ! common/autoconf/generated-configure.sh Changeset: d081bdbf904d Author: jqzuo Date: 2013-06-10 16:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d081bdbf904d Merge ! common/autoconf/generated-configure.sh Changeset: b59990653fb9 Author: pbhat Date: 2013-06-21 18:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b59990653fb9 Merge ! common/autoconf/generated-configure.sh Changeset: dd345e4b51fb Author: pbhat Date: 2013-07-05 11:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dd345e4b51fb Merge ! common/autoconf/generated-configure.sh Changeset: 24cc2d9b0af5 Author: pbhat Date: 2013-07-18 16:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/24cc2d9b0af5 Merge ! common/autoconf/generated-configure.sh Changeset: 4a4c9e7bc6c9 Author: pbhat Date: 2013-07-25 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4a4c9e7bc6c9 Merge Changeset: 63d794ade242 Author: pbhat Date: 2013-08-02 09:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/63d794ade242 Merge Changeset: a5485b9a2d14 Author: pbhat Date: 2013-08-09 14:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a5485b9a2d14 Merge Changeset: 028ac95111b9 Author: pbhat Date: 2013-08-16 14:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/028ac95111b9 Merge Changeset: 4b686cbc32c7 Author: pbhat Date: 2013-08-23 09:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4b686cbc32c7 Merge ! common/autoconf/generated-configure.sh Changeset: ec583e324aaf Author: pbhat Date: 2013-08-30 10:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ec583e324aaf Merge ! common/autoconf/generated-configure.sh Changeset: 96f00091b570 Author: pbhat Date: 2013-09-05 11:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/96f00091b570 Merge ! common/autoconf/generated-configure.sh Changeset: 69096d4b1da2 Author: pbhat Date: 2013-09-12 12:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/69096d4b1da2 Merge ! common/autoconf/generated-configure.sh Changeset: 5a306baf3bb7 Author: pbhat Date: 2013-09-19 14:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5a306baf3bb7 Merge ! common/autoconf/generated-configure.sh Changeset: 88ca3ff9ce2d Author: billyh Date: 2013-09-25 10:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/88ca3ff9ce2d 8025262: new64jre/new64jdk wrappers should be removed, build 32-bit AU during windows-amd64 builds instead Reviewed-by: amenkov, jqzuo ! make/install-rules.gmk Changeset: c8066e5d7a7b Author: pbhat Date: 2013-09-26 11:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c8066e5d7a7b Merge Changeset: 00ae95ca1755 Author: pbhat Date: 2013-10-03 09:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/00ae95ca1755 Merge Changeset: 7deff16cf438 Author: jqzuo Date: 2013-10-14 18:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7deff16cf438 Merge ! common/autoconf/generated-configure.sh Changeset: ec48d637778a Author: tbell Date: 2013-10-09 18:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ec48d637778a 8023611: Win32 and win64: Remove all the WARNINGS in JDK 8 builds for Windows 2008 and MSVS 2010 SP1 Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 174a54ce39c4 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/174a54ce39c4 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.conf.nfs.example ! common/autoconf/builddeps.m4 ! common/autoconf/compare.sh.in ! common/autoconf/config.h.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/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk ! common/makefiles/devkit/Makefile ! common/makefiles/devkit/Tools.gmk ! common/makefiles/javadoc/CORE_PKGS.gmk ! common/makefiles/javadoc/Javadoc.gmk ! common/makefiles/javadoc/NON_CORE_PKGS.gmk ! common/makefiles/javadoc/Notes.html Changeset: 6274d4cd22d3 Author: erikj Date: 2013-10-14 11:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6274d4cd22d3 8025921: Make LOG=debug output more readable Reviewed-by: tbell, ihse ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk Changeset: 547316ea137d Author: katleman Date: 2013-10-16 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/547316ea137d Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/CORE_PKGS.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: ac748011cbbf Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ac748011cbbf Added tag jdk8-b112 for changeset 547316ea137d ! .hgtags Changeset: 4d23143c676a Author: lana Date: 2013-10-10 08:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4d23143c676a Merge Changeset: fd3b32cc4b6e Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fd3b32cc4b6e Merge Changeset: 3f9873789d44 Author: mduigou Date: 2013-10-11 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3f9873789d44 8025796: hgforest.sh could trigger unbuffered output from hg without complicated machinations Reviewed-by: mduigou Contributed-by: Dmitry Samersoff ! common/bin/hgforest.sh Changeset: d35943431696 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d35943431696 Merge Changeset: af87dabb4263 Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/af87dabb4263 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! common/makefiles/RMICompilation.gmk Changeset: ce8c63017f11 Author: chegar Date: 2013-10-13 21:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ce8c63017f11 Merge Changeset: 28be3d174c92 Author: chegar Date: 2013-10-15 13:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/28be3d174c92 Merge Changeset: af81988013b5 Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/af81988013b5 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk Changeset: 9ec6626d43bb Author: mduigou Date: 2013-10-17 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9ec6626d43bb 8026062: webrev.ksh: fix bug title web scraping, remove teamware, sac, "open bug", -l and wxfile support Reviewed-by: weijun, dsamersoff, darcy, jrose, tbell ! make/scripts/webrev.ksh Changeset: 77473affb9c0 Author: lana Date: 2013-10-17 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/77473affb9c0 Merge ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk Changeset: 35c14ec3e12f Author: lana Date: 2013-10-17 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/35c14ec3e12f Merge Changeset: ac09e62d5e6b Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ac09e62d5e6b Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk Changeset: 9d5284dfc00d Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9d5284dfc00d Merge Changeset: 5b4f14990dd1 Author: ihse Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5b4f14990dd1 8001912: Improve detection of msvcr100.dll Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 65c1752b4c38 Author: katleman Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/65c1752b4c38 Merge Changeset: 17d195bd56fc Author: erikj Date: 2013-10-18 11:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/17d195bd56fc 8025869: make docs doesn't regenerate docs correctly after changing API doc comments in jaxp sources Reviewed-by: ihse, tbell ! common/makefiles/JavaCompilation.gmk Changeset: e27dda53d4f5 Author: erikj Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e27dda53d4f5 Merge Changeset: 1a853fac18ff Author: erikj Date: 2013-10-21 11:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1a853fac18ff 8026528: [build] configure does not recognize newer make in cygwin Reviewed-by: tbell, ksrini, ihse ! NewMakefile.gmk ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: dffe654ab24c Author: ihse Date: 2013-10-22 11:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dffe654ab24c 8001925: Add useful help messages if freetype is not found on Windows Reviewed-by: erikj, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 Changeset: 56db38956113 Author: ihse Date: 2013-10-22 12:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/56db38956113 8026864: Deprecate --disable-macosx-runtime-support. Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 9e177e7fc438 Author: katleman Date: 2013-10-22 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9e177e7fc438 Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/makefiles/JavaCompilation.gmk Changeset: 4293401d683b Author: katleman Date: 2013-10-22 16:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4293401d683b 8027068: Update to NewMakefile.gmk check of MAKE_VERSION broke jdk8-build nightly builds on windows, saying 3.82.90 is too low Reviewed-by: ihse, tbell, wetmore ! NewMakefile.gmk Changeset: 269497597620 Author: tbell Date: 2013-10-22 16:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/269497597620 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 2cc1a52d37ef Author: tbell Date: 2013-10-22 16:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2cc1a52d37ef Merge Changeset: 6f19b2440412 Author: ihse Date: 2013-10-23 13:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6f19b2440412 8001922: Improve freetype handling. Reviewed-by: erikj ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 ! common/autoconf/spec.gmk.in Changeset: 6ba4c7cb623e Author: erikj Date: 2013-10-23 17:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6ba4c7cb623e 8026888: Licensee build failure due to wrong libs being called Reviewed-by: tbell, ihse, simonis ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: a36df87b3901 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a36df87b3901 Added tag jdk8-b113 for changeset 6ba4c7cb623e ! .hgtags Changeset: b098ee22aa97 Author: erikj Date: 2013-10-24 10:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b098ee22aa97 8009280: JCE jurisdiction policy files not copied into jdk/lib/security Reviewed-by: tbell, ihse ! common/makefiles/JavaCompilation.gmk Changeset: 3c48e11c3901 Author: dholmes Date: 2013-10-24 20:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3c48e11c3901 8016096: [macosx] jawt_md.h shipped with jdk is outdated Summary: Revised build system and added platform specific headers for Mac OS X Reviewed-by: ihse, erikj Contributed-by: david.dehaven at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 72ef61df77e5 Author: ihse Date: 2013-10-25 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/72ef61df77e5 8027300: configure should use LIBS instead of LDFLAGS when testing freetype Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: dfbc93f26f38 Author: dcubed Date: 2013-10-25 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dfbc93f26f38 8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy Summary: Fix whitespace/indent issues. Reviewed-by: hseigel, coleenp, erikj, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/NativeCompilation.gmk Changeset: 4f2011496393 Author: katleman Date: 2013-10-28 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4f2011496393 Merge Changeset: b65d48f6938a Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b65d48f6938a Added tag jdk8-b114 for changeset 4f2011496393 ! .hgtags From john.coomes at oracle.com Fri Nov 1 12:32:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 19:32:37 +0000 Subject: hg: hsx/hotspot-main/corba: 24 new changesets Message-ID: <20131101193252.6F563628EB@hg.openjdk.java.net> Changeset: 66fc1a749867 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/66fc1a749867 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 43cec76d1d62 Author: katleman Date: 2013-10-16 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/43cec76d1d62 Merge Changeset: 54aa9b7d743d Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/54aa9b7d743d Added tag jdk8-b112 for changeset 43cec76d1d62 ! .hgtags Changeset: 81d694b1ab2f Author: msheppar Date: 2013-06-14 16:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/81d694b1ab2f 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: ab6eae733bce Author: chegar Date: 2013-07-15 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/ab6eae733bce Merge Changeset: e5ea72df9806 Author: chegar Date: 2013-07-22 13:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e5ea72df9806 Merge Changeset: be4fdc568d73 Author: mchung Date: 2013-07-22 19:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/be4fdc568d73 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: b0aeb77f0292 Author: chegar Date: 2013-07-25 17:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/b0aeb77f0292 Merge Changeset: a72f506e3058 Author: chegar Date: 2013-08-02 09:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a72f506e3058 Merge Changeset: 0717fc6f2960 Author: chegar Date: 2013-08-09 14:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0717fc6f2960 Merge Changeset: 6b5db99e194c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/6b5db99e194c Merge - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava Changeset: 9c75c61d97f8 Author: msheppar Date: 2013-08-19 15:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/9c75c61d97f8 8022940: Enhance CORBA translations Reviewed-by: coffeys, alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java Changeset: 2caa37dfd7cd Author: chegar Date: 2013-08-23 22:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2caa37dfd7cd Merge Changeset: a5788ab042dc Author: chegar Date: 2013-08-30 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a5788ab042dc Merge Changeset: 118a211bb3ba Author: chegar Date: 2013-09-06 09:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/118a211bb3ba Merge Changeset: cc52d582df09 Author: chegar Date: 2013-09-14 19:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/cc52d582df09 Merge Changeset: 396854c032bb Author: chegar Date: 2013-10-03 19:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/396854c032bb Merge Changeset: 47513cdce4ed Author: chegar Date: 2013-10-13 22:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/47513cdce4ed Merge Changeset: 438c54c148a6 Author: erikj Date: 2013-10-16 13:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/438c54c148a6 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/BuildCorba.gmk Changeset: 1a71d800b032 Author: wetmore Date: 2013-10-16 23:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/1a71d800b032 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Reviewed-by: katleman, dholmes ! makefiles/BuildCorba.gmk Changeset: 1c01208087b5 Author: lana Date: 2013-10-17 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/1c01208087b5 Merge ! makefiles/BuildCorba.gmk Changeset: a259ff3e42d9 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a259ff3e42d9 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 0bbccf77c23e Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/0bbccf77c23e Added tag jdk8-b113 for changeset a259ff3e42d9 ! .hgtags Changeset: d425685e0b74 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d425685e0b74 Added tag jdk8-b114 for changeset 0bbccf77c23e ! .hgtags From john.coomes at oracle.com Fri Nov 1 12:33:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 19:33:06 +0000 Subject: hg: hsx/hotspot-main/jaxp: 38 new changesets Message-ID: <20131101193428.72C6A628EC@hg.openjdk.java.net> Changeset: 84a2b2ee6fc6 Author: aefimov Date: 2013-10-01 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/84a2b2ee6fc6 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java Changeset: f031b2fe21cd Author: dfuchs Date: 2013-10-04 19:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f031b2fe21cd 8025745: Clarify API documentation of JAXP factories. Summary: Clarifies usage of ServiceLoader in JAXP factories. Reviewed-by: alanb, joehw, psandoz ! src/javax/xml/datatype/DatatypeFactory.java ! src/javax/xml/parsers/DocumentBuilderFactory.java ! src/javax/xml/parsers/SAXParserFactory.java ! src/javax/xml/stream/XMLEventFactory.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/stream/XMLOutputFactory.java ! src/javax/xml/transform/TransformerFactory.java ! src/javax/xml/validation/SchemaFactory.java ! src/javax/xml/xpath/XPathFactory.java Changeset: dbecbb685503 Author: mfang Date: 2013-10-08 09:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/dbecbb685503 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java Changeset: 1c074a0c2b97 Author: mfang Date: 2013-10-08 09:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/1c074a0c2b97 Merge Changeset: d69f4ac43d64 Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d69f4ac43d64 Merge Changeset: cdc3577cba0b Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/cdc3577cba0b Merge Changeset: acae2e8a46df Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/acae2e8a46df 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: c1f9158fbb9c Author: katleman Date: 2013-10-16 11:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/c1f9158fbb9c Merge Changeset: e85dd07c0eea Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e85dd07c0eea Added tag jdk8-b112 for changeset c1f9158fbb9c ! .hgtags Changeset: b76629725522 Author: joehw Date: 2013-10-10 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b76629725522 8003262: reverse translation required changes in xalan resource bundles Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java Changeset: 2107c9baa457 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2107c9baa457 Merge Changeset: cff4e3bf530a Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/cff4e3bf530a Merge Changeset: 46ccc5fbc523 Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/46ccc5fbc523 Merge Changeset: de8c803d4958 Author: aefimov Date: 2013-10-13 13:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/de8c803d4958 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Reviewed-by: alanb, shade ! src/com/sun/org/apache/xpath/internal/XPathContext.java Changeset: 4712979714d1 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4712979714d1 Merge Changeset: 91ae0f2045bc Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/91ae0f2045bc Merge Changeset: eb169222d3f2 Author: joehw Date: 2013-10-14 22:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/eb169222d3f2 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb ! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java Changeset: ecb66dc473c1 Author: joehw Date: 2013-07-16 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ecb66dc473c1 8012425: Transform TransformerFactory Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 7a2014318343 Author: joehw Date: 2013-07-17 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/7a2014318343 8017298: Better XML support Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/xml/internal/stream/Entity.java Changeset: a59549c3ad60 Author: dfuchs Date: 2013-07-17 18:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a59549c3ad60 8013502: Improve stream factories Reviewed-by: joehw, mullan, lancea ! src/javax/xml/stream/FactoryFinder.java Changeset: 4b0b2b5c4cc8 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4b0b2b5c4cc8 Merge Changeset: 40b8abe19642 Author: chegar Date: 2013-07-29 14:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/40b8abe19642 Merge ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 720db2e27962 Author: joehw Date: 2013-07-31 00:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/720db2e27962 8014530: Better digital signature processing Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: cd9347628c7c Author: joehw Date: 2013-07-31 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/cd9347628c7c 8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing Reviewed-by: lancea, alanb, dfuchs, mullan ! src/com/sun/xml/internal/stream/Entity.java Changeset: ecbddaa85462 Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ecbddaa85462 Merge Changeset: c5e80c1fa32f Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/c5e80c1fa32f Merge ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: f952c33ebfdb Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f952c33ebfdb Merge Changeset: ce16a5aa1507 Author: joehw Date: 2013-08-20 09:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ce16a5aa1507 8022682: Supporting XOM Reviewed-by: alanb, chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java + src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java Changeset: cc3b64366048 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/cc3b64366048 Merge Changeset: 2b77e12ff69d Author: chegar Date: 2013-10-11 19:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2b77e12ff69d Merge ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java Changeset: 6f220761f643 Author: chegar Date: 2013-10-15 14:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/6f220761f643 Merge Changeset: 0c3f951630fe Author: joehw Date: 2013-10-17 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0c3f951630fe 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/util/URI.java Changeset: 951c1f7fdb10 Author: joehw Date: 2013-10-17 16:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/951c1f7fdb10 8016500: Unlocalized warnigs. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: 31c82bc71ae3 Author: lana Date: 2013-10-17 15:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/31c82bc71ae3 Merge Changeset: 2f1e1e2c2242 Author: lana Date: 2013-10-17 17:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2f1e1e2c2242 Merge Changeset: 0046d2278204 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0046d2278204 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 1b1e12117fe2 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/1b1e12117fe2 Added tag jdk8-b113 for changeset 0046d2278204 ! .hgtags Changeset: d3b6da1b3e25 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d3b6da1b3e25 Added tag jdk8-b114 for changeset 1b1e12117fe2 ! .hgtags From john.coomes at oracle.com Fri Nov 1 12:34:43 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 19:34:43 +0000 Subject: hg: hsx/hotspot-main/jaxws: 27 new changesets Message-ID: <20131101193542.8DF21628ED@hg.openjdk.java.net> Changeset: b0610cd08440 Author: mkos Date: 2013-10-04 16:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b0610cd08440 8025054: Update JAX-WS RI integration to 2.2.9-b130926.1035 Reviewed-by: chegar ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64EncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/binary/SchemaBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DDataPattern.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DPattern.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DXMLPrinter.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DataPatternBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/GrammarBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/AnyNameClass.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/NameClassBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/SimpleNameClass.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/compact/UCode_UCodeESC_CharStream.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/xml/SchemaParser.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/xml/sax/JAXPXMLReaderCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundFault.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundOperation.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundPortType.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLFault.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLInput.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLMessage.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLModel.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOperation.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOutput.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPart.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPort.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPortType.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLService.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/javax/annotation/PostConstruct.java ! src/share/jaxws_classes/javax/annotation/PreDestroy.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/Marshaller.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java Changeset: e56be3a2287a Author: coffeys Date: 2013-10-05 08:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/e56be3a2287a 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java Changeset: 1d6c13d3b8de Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/1d6c13d3b8de Merge Changeset: 7c0a7937f6ef Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/7c0a7937f6ef Merge Changeset: 602fdd7bb765 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/602fdd7bb765 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: dbdd5c762509 Author: katleman Date: 2013-10-16 11:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/dbdd5c762509 Merge Changeset: 9ca9735d9966 Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/9ca9735d9966 Added tag jdk8-b112 for changeset dbdd5c762509 ! .hgtags Changeset: da77e343f458 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/da77e343f458 Merge Changeset: 66a12ce67d3a Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/66a12ce67d3a Merge Changeset: 328b8b96773b Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/328b8b96773b Merge Changeset: 43240b8b995b Author: mkos Date: 2013-08-01 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/43240b8b995b 8017505: Better Client Service Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java + src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java + src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyUtils.java Changeset: 358f32260d1f Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/358f32260d1f Merge Changeset: 5212665bea32 Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/5212665bea32 Merge Changeset: d9704ab517d5 Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d9704ab517d5 Merge Changeset: fca8869ccfd0 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/fca8869ccfd0 Merge Changeset: a6e2adde013e Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/a6e2adde013e Merge Changeset: f6376ba97cea Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/f6376ba97cea Merge Changeset: d3a65e8912c9 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/d3a65e8912c9 Merge Changeset: da8141b6e344 Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/da8141b6e344 Merge Changeset: 2dc8ae7eb53b Author: chegar Date: 2013-10-11 19:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/2dc8ae7eb53b Merge Changeset: 01facfebe17b Author: chegar Date: 2013-10-15 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/01facfebe17b Merge Changeset: be7d1f874b96 Author: lana Date: 2013-10-17 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/be7d1f874b96 Merge Changeset: 17f1b13cd401 Author: simonis Date: 2013-10-21 15:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/17f1b13cd401 8026874: During JAXWS build the newly built JAXP classes should be in the bootclasspath (not only in the classpath) Reviewed-by: erikj ! makefiles/BuildJaxws.gmk Changeset: f20820d1582f Author: katleman Date: 2013-10-22 16:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/f20820d1582f Merge Changeset: 9261f342aa73 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/9261f342aa73 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 9ad289610fc6 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/9ad289610fc6 Added tag jdk8-b113 for changeset 9261f342aa73 ! .hgtags Changeset: e126d8eca69b Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/e126d8eca69b Added tag jdk8-b114 for changeset 9ad289610fc6 ! .hgtags From john.coomes at oracle.com Fri Nov 1 12:47:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 19:47:38 +0000 Subject: hg: hsx/hotspot-main/jdk: 308 new changesets Message-ID: <20131101205306.4CFEE628F5@hg.openjdk.java.net> Changeset: 8a041011b6e6 Author: jgodinez Date: 2013-09-27 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a041011b6e6 6870661: Setting a custom PrintService on a PrinterJob leads to a PrinterException Reviewed-by: prr, jgodinez Contributed-by: patrick at reini.net ! src/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintDialog.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java + test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java Changeset: 31b8d4931a09 Author: prr Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31b8d4931a09 8020190: Fatal: Bug in native code: jfieldID must match object Reviewed-by: jgodinez, vadim ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/native/sun/font/freetypeScaler.c Changeset: 6ef33b4553a4 Author: vadim Date: 2013-09-30 12:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ef33b4553a4 8001119: [fingbugs] Evaluate necessity to make some arrays package protected Reviewed-by: prr, bae + src/share/classes/com/sun/imageio/plugins/bmp/BMPCompressionTypes.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java Changeset: e2604b873b36 Author: prr Date: 2013-10-01 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2604b873b36 8007386: On physical machine (video card is Intel Q45) the text is blank. Reviewed-by: prr, jchen ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 96ff585555f4 Author: vadim Date: 2013-10-02 10:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/96ff585555f4 8024343: Change different color with the "The XOR alternation color" combobox, the color of the image can not shown immediately. Reviewed-by: ceisserer, prr, bae ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java + test/sun/java2d/AcceleratedXORModeTest.java Changeset: 5f3d984d8207 Author: prr Date: 2013-10-02 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f3d984d8207 8025837: Extraneous changes in the fix for 8007386 Reviewed-by: jgodinez, jchen ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: f53aeb3c7eed Author: prr Date: 2013-10-02 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f53aeb3c7eed 7179526: xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36 Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java ! src/solaris/classes/sun/java2d/xr/MaskTile.java ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java + src/solaris/classes/sun/java2d/xr/XRDrawLine.java ! src/solaris/classes/sun/java2d/xr/XRRenderer.java + test/java/awt/Graphics/LineClipTest.java Changeset: a15cad0e12d3 Author: bae Date: 2013-10-03 11:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a15cad0e12d3 8022632: Reading a PNG file fails because of WBMPImageReaderSpi.canDecodeInput() Reviewed-by: prr, jgodinez ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java + test/javax/imageio/plugins/wbmp/StreamResetTest.java Changeset: 2f11a00279ec Author: jchen Date: 2013-10-03 13:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f11a00279ec 8025280: [parfait] warnings from b107 for jdk.src.share.native.sun.java2d.loops: JNI exception pending, JNI critical region violation Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/Blit.c ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/DrawPath.c ! src/share/native/sun/java2d/loops/DrawPolygons.c ! src/share/native/sun/java2d/loops/FillPath.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/MaskBlit.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ScaledBlit.c ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: e88d39b110dd Author: jchen Date: 2013-10-03 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e88d39b110dd 8025480: [parfait] "JNI exception pending" warnings from b107 for jdk.src.share.native.sun.java2d Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/Disposer.c ! src/share/native/sun/java2d/SurfaceData.c Changeset: 3c1b13ad0677 Author: jchen Date: 2013-10-03 13:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c1b13ad0677 8025309: [parfait] JNI-related warnings from b107 for jdk.src.share.native.sun.java2d.pipe Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c ! src/share/native/sun/java2d/pipe/Region.c ! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c ! src/share/native/sun/java2d/pipe/SpanClipRenderer.c Changeset: d37594b689ce Author: jchen Date: 2013-10-03 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d37594b689ce 8025664: [parfait] warnings from b62 for jdk.src.share.native.sun.font Reviewed-by: prr, jgodinez ! src/share/native/sun/font/freetypeScaler.c Changeset: 0ed939dc4230 Author: jchen Date: 2013-10-03 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ed939dc4230 8025294: [parfait] JNI-related warnings from b107 for jdk.src.solaris.native.sun.java2d.x11 Reviewed-by: prr, jgodinez ! src/solaris/native/sun/java2d/x11/X11Renderer.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c Changeset: 8fd757f31470 Author: jchen Date: 2013-10-04 16:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8fd757f31470 8025940: Windows build fails after the fix for 8025280 Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/MaskBlit.c Changeset: 727b60f9c09c Author: lana Date: 2013-10-08 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/727b60f9c09c Merge Changeset: e4e151f6ae50 Author: yan Date: 2013-09-27 12:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e4e151f6ae50 8025249: [javadoc] fix some javadoc errors in javax/swing/ Reviewed-by: alexsch, yan Contributed-by: Taras Ledkov ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableCellRenderer.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/Element.java ! src/share/classes/javax/swing/text/View.java Changeset: ca45169cb4eb Author: pchelko Date: 2013-09-27 14:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ca45169cb4eb 8024122: [TEST] need test to cover JDK-7146572 Reviewed-by: anthony, yan Contributed-by: Alexander Stepanov + test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html + test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java Changeset: ad7db846c951 Author: pchelko Date: 2013-09-27 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad7db846c951 8025503: [macosx] FileDialog allows file selection with apple.awt.fileDialogForDirectories = true Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/CFileDialog.m Changeset: 260bc59ca253 Author: pchelko Date: 2013-09-27 18:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/260bc59ca253 8016563: Test closed/java/awt/dnd/ImageTransferTest/ImageTransferTest.html fails Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: bfff9e9120ec Author: malenkov Date: 2013-09-27 22:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bfff9e9120ec 8012716: java.beans.EventHandler.create method should check if the given listenerInterface is a public interface Reviewed-by: art, mchung ! src/share/classes/java/beans/EventHandler.java Changeset: 0042f54f65d0 Author: malenkov Date: 2013-09-27 22:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0042f54f65d0 7117595: ArrayIndexOutOfBoundsException in Win32GraphicsEnvironment if display is removed Reviewed-by: anthony, serb ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: 603cd3cefbb0 Author: malenkov Date: 2013-09-30 22:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/603cd3cefbb0 8025652: [macos] build failed Reviewed-by: serb ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: cdfa2301a291 Author: serb Date: 2013-10-01 04:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cdfa2301a291 7150100: [macosx] "0123456789" is selected in the TextField Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/SelectionVisible/SelectionVisible.html + test/java/awt/TextArea/SelectionVisible/SelectionVisible.java + test/java/awt/TextField/SelectionVisible/SelectionVisible.html + test/java/awt/TextField/SelectionVisible/SelectionVisible.java Changeset: 2d8418d68a3c Author: kshefov Date: 2013-10-01 13:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2d8418d68a3c 7125471: [macosx] NofocusListDblClickTest should wait between doublr clicks Reviewed-by: anthony, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/List/NofocusListDblClickTest/NofocusListDblClickTest.java Changeset: 329011aad090 Author: kshefov Date: 2013-10-01 13:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/329011aad090 8012468: [TEST_BUG] javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 0887aad989fb Author: kshefov Date: 2013-10-01 13:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0887aad989fb 8012466: [TEST_BUG] javax/swing/JInternalFrame/Test6505027.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/JInternalFrame/Test6505027.java Changeset: 1043bd1f7fca Author: kshefov Date: 2013-10-01 13:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1043bd1f7fca 8004294: [TEST_BUG] javax/swing/JSpinner/4973721/bug4973721.java failed on win2003 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSpinner/4973721/bug4973721.java Changeset: 68157255f3eb Author: kshefov Date: 2013-10-01 13:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/68157255f3eb 8012461: [TEST_BUG] closed/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.xml Changeset: 172405287fde Author: kshefov Date: 2013-10-01 13:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/172405287fde 7133545: [macosx] closed/javax/swing/JSplitPane/4514858/bug4514858.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4514858/bug4514858.java Changeset: 291e66f4cb83 Author: kshefov Date: 2013-10-01 13:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/291e66f4cb83 7133532: [macosx] closed/javax/swing/JScrollBar/bug4202954/bug4202954.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JScrollBar/bug4202954/bug4202954.java Changeset: 560ede42bd2e Author: kshefov Date: 2013-10-01 14:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/560ede42bd2e 8025707: Frogot to add a file to fix for JDK-8012461 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/red.gif Changeset: a0c28e64c049 Author: alitvinov Date: 2013-10-01 18:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a0c28e64c049 8025145: [macosx]: java 7 does not recognize tiff image on clipboard Reviewed-by: anthony, serb Contributed-by: anton.nashatyrev at oracle.com ! src/macosx/lib/flavormap.properties Changeset: 5e205645d990 Author: pchelko Date: 2013-10-02 11:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e205645d990 7124363: [macosx] ClassCastException: CFileDialog cannot be cast to LWWindowPeer Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1189f954d52f Author: pchelko Date: 2013-10-02 11:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1189f954d52f 8024163: [macosx] NullPointerException at javax.swing.TransferHandler$DropHandler.handleDrag since jdk8b93, 7u40b28 Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/native/sun/awt/CDropTarget.m + test/java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java + test/java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java Changeset: 01198c681710 Author: pchelko Date: 2013-10-02 11:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01198c681710 8024600: [macosx] code prevents use of -Xlint:auxiliaryclass,empty in jdk build Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java + src/macosx/classes/com/apple/eawt/_OpenAppHandler.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java + src/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java Changeset: 287e0a7731ff Author: pchelko Date: 2013-10-02 16:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/287e0a7731ff 8024158: [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 244f2ee51f31 Author: leonidr Date: 2013-10-02 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/244f2ee51f31 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java Changeset: f40f2421c60f Author: serb Date: 2013-10-02 21:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f40f2421c60f 8013563: Memory leak in JFrame on Linux Reviewed-by: anthony, art ! src/share/classes/java/awt/Window.java + test/java/awt/Window/WindowsLeak/WindowsLeak.java Changeset: 1da5d306e84b Author: cl Date: 2013-10-02 11:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1da5d306e84b 8025409: Fix javadoc comments errors and warning reported by doclint report Reviewed-by: anthony, yan ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/CheckboxGroup.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/FlowLayout.java ! src/share/classes/java/awt/FontMetrics.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/Label.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/Sides.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 998578a87c0e Author: bagiras Date: 2013-10-03 16:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/998578a87c0e 8013553: [macosx] java.awt.FileDialog removes file extensions Reviewed-by: leonidr, serb ! src/macosx/native/sun/awt/CFileDialog.m Changeset: 1533a379deb0 Author: anthony Date: 2013-10-03 18:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1533a379deb0 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Summary: Load the lwawt native library on Mac regardless of the headless/headful mode. Also, some minor cleanup. Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 39b674405270 Author: alexsch Date: 2013-10-03 19:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39b674405270 7092283: Property Window.locationByPlatform is not cleared by calling setVisible(false) Reviewed-by: anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/LocationByPlatform/LocationByPlatformTest.java Changeset: 6ffe50fe06bd Author: mcherkas Date: 2013-10-04 20:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ffe50fe06bd 8020688: Broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. Reviewed-by: anthony, alexsch ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/applet/AppletStub.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/FocusTraversalPolicy.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/Transferable.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/ActionListener.java ! src/share/classes/java/awt/event/ComponentAdapter.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/ComponentListener.java ! src/share/classes/java/awt/event/ContainerAdapter.java ! src/share/classes/java/awt/event/ContainerEvent.java ! src/share/classes/java/awt/event/ContainerListener.java ! src/share/classes/java/awt/event/FocusAdapter.java ! src/share/classes/java/awt/event/FocusEvent.java ! src/share/classes/java/awt/event/FocusListener.java ! src/share/classes/java/awt/event/ItemEvent.java ! src/share/classes/java/awt/event/ItemListener.java ! src/share/classes/java/awt/event/KeyAdapter.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/event/MouseAdapter.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/event/MouseListener.java ! src/share/classes/java/awt/event/MouseMotionAdapter.java ! src/share/classes/java/awt/event/MouseMotionListener.java ! src/share/classes/java/awt/event/WindowAdapter.java ! src/share/classes/java/awt/event/WindowEvent.java ! src/share/classes/java/awt/event/WindowFocusListener.java ! src/share/classes/java/awt/event/WindowListener.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/BoundedRangeModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/FocusManager.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/ProgressMonitorInputStream.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/WindowConstants.java ! src/share/classes/javax/swing/border/Border.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeExpansionListener.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeModelListener.java ! src/share/classes/javax/swing/event/TreeSelectionListener.java ! src/share/classes/javax/swing/event/TreeWillExpandListener.java ! src/share/classes/javax/swing/filechooser/FileFilter.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/table/TableModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/ExpandVetoException.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeNode.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/sun/swing/PrintingStatus.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java Changeset: 01b40315f872 Author: alexsch Date: 2013-10-07 16:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01b40315f872 8025438: [macosx] right JNFCall* method should be used in JDK-8008728 fix Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 72afa269fa3b Author: alexsch Date: 2013-10-07 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72afa269fa3b 8007219: [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Frame/MaximizedToMaximized/MaximizedToMaximized.java Changeset: 546c0ebfbf56 Author: cl Date: 2013-10-07 11:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/546c0ebfbf56 8025840: Fix all the doclint warnings about trademark Reviewed-by: art ! src/share/classes/javax/swing/AbstractAction.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultCellEditor.java ! src/share/classes/javax/swing/DefaultListCellRenderer.java ! src/share/classes/javax/swing/DefaultListModel.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ScrollPaneLayout.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/BevelBorder.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/EtchedBorder.java ! src/share/classes/javax/swing/border/LineBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/SoftBevelBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java ! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/ListSelectionEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeSelectionEvent.java ! src/share/classes/javax/swing/event/UndoableEditEvent.java ! src/share/classes/javax/swing/plaf/BorderUIResource.java ! src/share/classes/javax/swing/plaf/ColorUIResource.java ! src/share/classes/javax/swing/plaf/DimensionUIResource.java ! src/share/classes/javax/swing/plaf/FontUIResource.java ! src/share/classes/javax/swing/plaf/IconUIResource.java ! src/share/classes/javax/swing/plaf/InsetsUIResource.java ! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/DateFormatter.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultFormatterFactory.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/TabStop.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/html/Option.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/CannotRedoException.java ! src/share/classes/javax/swing/undo/CannotUndoException.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: bdc8abbce9c1 Author: yan Date: 2013-10-08 13:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bdc8abbce9c1 8025236: [javadoc] fix some errors in AWT Reviewed-by: yan, anthony Contributed-by: Dmitry Ginzburg ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/java/awt/im/InputMethodHighlight.java Changeset: 01022f461570 Author: pchelko Date: 2013-10-08 15:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01022f461570 7158311: GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux 8001463: Regression : Deadlock between AWT-XAWT thread and AWT-EventQueue-0 Thread when screen resolution changes Reviewed-by: art, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a5d0730342a5 Author: pchelko Date: 2013-10-08 15:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a5d0730342a5 8025585: Win: Popups in JFXPanel do not receive MouseWheel events Reviewed-by: anthony, art ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 85a72bb00d74 Author: bagiras Date: 2013-10-08 16:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85a72bb00d74 8000425: FileDialog documentation should be enhanced Reviewed-by: serb, anthony ! src/share/classes/java/awt/FileDialog.java Changeset: 01607de6265d Author: bagiras Date: 2013-10-08 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01607de6265d 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java Changeset: 184b16f4e61f Author: bagiras Date: 2013-10-08 17:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/184b16f4e61f 7199196: Incremental transfer is broken because of a typo Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 42d3ea1c35b4 Author: malenkov Date: 2013-10-08 18:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42d3ea1c35b4 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 6914b883c3bb Author: malenkov Date: 2013-10-08 18:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6914b883c3bb 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 Reviewed-by: art, anthony ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: a2dd2b411723 Author: alexsch Date: 2013-10-08 18:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a2dd2b411723 7081594: Windows owned by an always-on-top window DO NOT automatically become always-on-top Reviewed-by: art, anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/AlwaysOnTop/AlwaysOnTopFieldTest.java Changeset: 0c06c38dfc3e Author: serb Date: 2013-10-08 21:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c06c38dfc3e 8022119: test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails Reviewed-by: art, anthony ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: b218a14bdc8a Author: serb Date: 2013-10-08 23:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b218a14bdc8a 8025603: Unused methods in the awt text peers should be removed Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/windows/classes/sun/awt/windows/WButtonPeer.java ! src/windows/classes/sun/awt/windows/WCheckboxPeer.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLabelPeer.java ! src/windows/classes/sun/awt/windows/WListPeer.java ! src/windows/classes/sun/awt/windows/WScrollbarPeer.java ! src/windows/classes/sun/awt/windows/WTextAreaPeer.java ! src/windows/classes/sun/awt/windows/WTextComponentPeer.java ! src/windows/classes/sun/awt/windows/WTextFieldPeer.java ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextField.cpp Changeset: e591ac19174f Author: leonidr Date: 2013-10-09 01:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e591ac19174f 8004050: [macosx] The 'ESC' key does not work with jdk8 Reviewed-by: alexsch, serb ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java Changeset: c1ef9ebac26a Author: lana Date: 2013-10-08 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1ef9ebac26a Merge ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Changeset: 78b4dc33e6e6 Author: twisti Date: 2013-09-26 18:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78b4dc33e6e6 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName() Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MemberName.java Changeset: eb2c81533876 Author: weijun Date: 2013-09-27 15:25 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eb2c81533876 8024861: Incomplete token triggers GSS-API NullPointerException Reviewed-by: mullan ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java + test/sun/security/jgss/spnego/MechTokenMissing.java Changeset: 95f609fcb639 Author: ehelin Date: 2013-09-26 16:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/95f609fcb639 8025502: Exclude tests due to JDK-8025427 Reviewed-by: ksrini ! test/ProblemList.txt Changeset: 914f8d4570df Author: mduigou Date: 2013-09-27 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/914f8d4570df 8025595: Remove alt-rt.jar, used by +AggressiveOps (jdk repo portion of JDK-8024826) Reviewed-by: alanb, chegar, dholmes, ksrini ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt ! test/java/util/TreeMap/Clone.java Changeset: fbe6f5dbb24f Author: mduigou Date: 2013-09-27 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fbe6f5dbb24f 8023339: Refined Collection.removeIf UOE conditions Reviewed-by: mduigou Contributed-by: paul.sandoz at oracle.com ! src/share/classes/java/util/Collection.java ! test/java/util/Collection/MOAT.java Changeset: 91222be67b27 Author: mduigou Date: 2013-09-27 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/91222be67b27 8023340: Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced. Reviewed-by: psandoz, jjg ! src/share/classes/java/util/List.java Changeset: 754db1268be1 Author: dxu Date: 2013-09-27 17:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/754db1268be1 8025128: File.createTempFile fails if prefix is absolute path Summary: Use only the file name from the supplied prefix for backward compatibility Reviewed-by: alanb, chegar ! src/share/classes/java/io/File.java ! test/java/io/File/createTempFile/SpecialTempFile.java Changeset: d921ce805abe Author: mduigou Date: 2013-09-27 17:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d921ce805abe 8025610: Add explicit @throws NPE documentation to Optional constructor and Optional.of Reviewed-by: briangoetz, chegar, alanb ! src/share/classes/java/util/Optional.java Changeset: 0b535e920dd5 Author: lana Date: 2013-09-27 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0b535e920dd5 Merge Changeset: 15955d335cd0 Author: jfranck Date: 2013-09-30 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/15955d335cd0 8007072: Update Core Reflection for Type Annotations to match latest spec 8022324: j.l.Class.getAnnotatedInterfaces() for array type returns wrong value 8024915: j.l.r.Executable.getAnnotatedReceiverType() should return null for static methods Summary: Update javadoc and implementation of reflection for type annotations to match latest spec Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/AnnotatedArrayType.java ! src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java ! src/share/classes/java/lang/reflect/AnnotatedType.java ! src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java ! src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/annotation/typeAnnotations/GetAnnotatedInterfaces.java + test/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java ! test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java Changeset: 89174cddaec8 Author: jfranck Date: 2013-09-30 12:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89174cddaec8 8009719: core reflection should get type annotation data from the VM lazily Summary: Remove typeAnnotations field from Method, Constructor, and Field, update Executable and Field to fetch data on demand. Reviewed-by: darcy, erikj ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! 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/Method.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/reflect/Executable.c + src/share/native/java/lang/reflect/Field.c Changeset: cceaad499685 Author: sla Date: 2013-09-30 12:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cceaad499685 8023492: jfr.jar gets loaded even though it's not used Reviewed-by: erikj, mgronlun ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java Changeset: ede1fd12e0da Author: allwin Date: 2013-09-30 14:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ede1fd12e0da 8012923: [parfait] File Descriptor Leak in jdk/src/windows/demo/jvmti/hprof/hprof_md.c Reviewed-by: chegar, sla, sspitsyn, mgronlun ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d0de46a2cbd0 Author: ascarpino Date: 2013-09-19 11:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d0de46a2cbd0 7122707: Security Providers need to have their version numbers updated for JDK8 Reviewed-by: xuelei ! src/macosx/classes/apple/security/AppleProvider.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/com/sun/security/sasl/Provider.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/jgss/SunProvider.java ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/rsa/SunRsaSign.java ! src/share/classes/sun/security/smartcardio/SunPCSC.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java + test/java/security/Provider/ProviderVersionCheck.java Changeset: 2434e79fc41f Author: ascarpino Date: 2013-09-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2434e79fc41f 8004283: test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failing intermittently Reviewed-by: vinnie ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: e4c897b33cb7 Author: ascarpino Date: 2013-09-02 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e4c897b33cb7 8009438: sun/security/pkcs11/Secmod tests failing on Ubuntu 12.04 Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/Secmod.java Changeset: b4c259743371 Author: naoto Date: 2013-09-30 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4c259743371 8016110: Japanese char (MS932) 0x5C cannot be used as an argument when quoted Reviewed-by: ksrini, akhil ! src/windows/bin/cmdtoargs.c + test/tools/launcher/I18NArgTest.java Changeset: f8b3ab514564 Author: psandoz Date: 2013-10-01 12:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8b3ab514564 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Reviewed-by: alanb ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java Changeset: bf52ea6bd9eb Author: aefimov Date: 2013-10-01 17:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf52ea6bd9eb 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea + test/javax/xml/jaxp/parsers/8024707/TestFunc.java + test/javax/xml/jaxp/parsers/8024707/XSLT.java + test/javax/xml/jaxp/parsers/8024707/in.xml + test/javax/xml/jaxp/parsers/8024707/test.xsl Changeset: 8cfb2bddd95e Author: mduigou Date: 2013-09-30 15:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cfb2bddd95e 7057785: Add note about optional support of recursive methods for self-referential Collection/Map Reviewed-by: scolebourne, darcy, mduigou Contributed-by: Stephen Colebourne ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Map.java Changeset: f2e2326f787b Author: mduigou Date: 2013-10-01 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2e2326f787b 8025067: Unconditionally throw NPE if null op provided to Arrays.parallelPrefix Reviewed-by: henryjen, chegar, psandoz ! src/share/classes/java/util/Arrays.java ! test/java/util/Arrays/ParallelPrefix.java Changeset: c32ab940a183 Author: mduigou Date: 2013-10-01 10:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c32ab940a183 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Reviewed-by: lancea, chegar ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent Changeset: 5a7bd9825c01 Author: vlivanov Date: 2013-09-23 19:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5a7bd9825c01 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: twisti, kvn, rbackman Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/Stable.java Changeset: 1ed675532589 Author: vlivanov Date: 2013-09-18 20:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ed675532589 8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping Reviewed-by: jrose ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: bf1118ab775b Author: emc Date: 2013-10-01 17:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf1118ab775b 8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Summary: Fixed issue with type annotation reflection framework that would cause getType of AnnotatedTypes to be null if no annotations were present. Reviewed-by: darcy, jfranck ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java Changeset: 84e7f6685319 Author: ksrini Date: 2013-10-01 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84e7f6685319 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Reviewed-by: naoto, mfang ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource.java Changeset: d90928a89af5 Author: drchase Date: 2013-09-27 13:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d90928a89af5 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Summary: Inserted code to convert specific exceptions, case-by-case, plus a test. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/8022701/BogoLoader.java + test/java/lang/invoke/8022701/InvokeSeveralWays.java + test/java/lang/invoke/8022701/Invoker.java + test/java/lang/invoke/8022701/MHIllegalAccess.java + test/java/lang/invoke/8022701/MethodSupplier.java Changeset: 3fca37c636be Author: xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java Changeset: 914c29c10bce Author: okutsu Date: 2013-10-02 15:31 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/914c29c10bce 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Reviewed-by: peytoia ! src/share/classes/java/util/GregorianCalendar.java + test/java/util/Calendar/Bug6902861.java Changeset: 368172cb6dc5 Author: coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/368172cb6dc5 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java Changeset: 82e3150778e0 Author: okutsu Date: 2013-10-02 17:57 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/82e3150778e0 8022666: java.util.Calendar.set(int,int,int,int,int,int) documentation typo Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java Changeset: e1b04fd49204 Author: psandoz Date: 2013-10-01 18:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e1b04fd49204 8025535: Unsafe typecast in java.util.stream.SortedOps Reviewed-by: mduigou, chegar ! src/share/classes/java/util/stream/SortedOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java Changeset: 3bb89c509d59 Author: egahlin Date: 2013-10-01 17:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3bb89c509d59 6696975: JTop plugin fails if connected readonly to target JVM Reviewed-by: mchung, jbachorik, sla, sjiang ! src/share/demo/management/JTop/JTop.java Changeset: a6ac824b463d Author: wetmore Date: 2013-10-02 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a6ac824b463d 8025694: Rename getStrongSecureRandom based on feedback 8014838: getStrongSecureRandom() should require at least one implementation Reviewed-by: mullan, darcy ! src/share/classes/java/security/SecureRandom.java ! src/share/lib/security/java.security-windows ! test/sun/security/provider/SecureRandom/StrongSecureRandom.java Changeset: cb8946eda85b Author: emc Date: 2013-10-02 19:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb8946eda85b 8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions Summary: Fix behavior of parameter reflection API for malformed class files. Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java + src/share/classes/java/lang/reflect/MalformedParametersException.java ! src/share/classes/java/lang/reflect/Parameter.java + test/java/lang/reflect/Parameter/BadClassFiles.java Changeset: 811c35a6a58f Author: psandoz Date: 2013-10-02 16:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/811c35a6a58f 8025534: Unsafe typecast in java.util.stream.Streams.Nodes 8025538: Unsafe typecast in java.util.stream.SpinedBuffer 8025533: Unsafe typecast in java.util.stream.Streams.RangeIntSpliterator.splitPoint() 8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray() Reviewed-by: chegar ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Streams.java Changeset: c55a7941050c Author: psandoz Date: 2013-10-03 10:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c55a7941050c 8025567: Mark relevant public stream tests as serialization hostile Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java Changeset: 5d6dc0cba08f Author: dsamersoff Date: 2013-10-03 16:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d6dc0cba08f 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Summary: There's no guarantee that the java process has executed far enough to be found by jps when we try to obtain it's pid. Reviewed-by: sla ! test/sun/management/jdp/JdpTest.sh Changeset: 9c32a9490eac Author: kizune Date: 2013-10-03 17:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c32a9490eac 8025738: locale related test fails on langtools mac 10.7 test host Reviewed-by: ksrini ! test/tools/launcher/DiacriticTest.java Changeset: 8d8b809dd294 Author: rfield Date: 2013-10-03 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d8b809dd294 8010433: Remove lambda metafactory work-around to JDK-8005119 Summary: Restore invokespecial to lambda metafactory Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java Changeset: 1b3616c4a836 Author: rfield Date: 2013-10-03 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b3616c4a836 8020849: jdk/lambda/vm/DefaultMethodsTest.java Summary: Bridge generation has been removed from the VM. Fix is to remove tests that no longer make sense. Reviewed-by: ksrini ! test/jdk/lambda/vm/DefaultMethodsTest.java Changeset: 01b8604e8268 Author: rriggs Date: 2013-08-22 10:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01b8604e8268 8024896: Refactor java.time serialization tests into separate subpackage Summary: Move serialization tests to .serial subpackage Reviewed-by: sherman Contributed-by: paul.rank at oracle.com ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/serial/TCKDuration.java + test/java/time/tck/java/time/serial/TCKInstant.java + test/java/time/tck/java/time/serial/TCKLocalDate.java + test/java/time/tck/java/time/serial/TCKLocalDateTime.java + test/java/time/tck/java/time/serial/TCKLocalTime.java + test/java/time/tck/java/time/serial/TCKMonthDay.java + test/java/time/tck/java/time/serial/TCKOffsetDateTime.java + test/java/time/tck/java/time/serial/TCKOffsetTime.java + test/java/time/tck/java/time/serial/TCKPeriod.java + test/java/time/tck/java/time/serial/TCKYear.java + test/java/time/tck/java/time/serial/TCKYearMonth.java + test/java/time/tck/java/time/serial/TCKZoneId.java + test/java/time/tck/java/time/serial/TCKZoneOffset.java + test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/serial/TCKZoneRules.java Changeset: e813b58bd6db Author: rriggs Date: 2013-10-03 15:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e813b58bd6db 8024427: Missing java.time.chrono serialization tests Summary: Add tests and cleanup existing serialization tests Reviewed-by: sherman ! src/share/classes/java/time/temporal/ValueRange.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java + test/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java + test/java/time/tck/java/time/serial/TCKClockSerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java < test/java/time/tck/java/time/serial/TCKDuration.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java < test/java/time/tck/java/time/serial/TCKInstant.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDate.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDateTime.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalTime.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java < test/java/time/tck/java/time/serial/TCKMonthDay.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetDateTime.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetTime.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java < test/java/time/tck/java/time/serial/TCKPeriod.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java < test/java/time/tck/java/time/serial/TCKYearMonth.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java < test/java/time/tck/java/time/serial/TCKYear.java ! test/java/time/tck/java/time/serial/TCKZoneIdSerialization.java < test/java/time/tck/java/time/serial/TCKZoneId.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java < test/java/time/tck/java/time/serial/TCKZoneOffset.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java < test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneRules.java ! test/java/time/test/java/time/AbstractTest.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java Changeset: 77ba1e67707c Author: allwin Date: 2013-10-04 15:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77ba1e67707c 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Reviewed-by: sla, jbachorik ! test/ProblemList.txt Changeset: b5aad88cbf12 Author: vinnie Date: 2013-10-04 16:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b5aad88cbf12 8008296: keytool utility doesn't support '-importpassword' command Reviewed-by: weijun ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/keytool/Resources.java + test/sun/security/tools/keytool/StorePasswords.java + test/sun/security/tools/keytool/StorePasswordsByShell.sh Changeset: 1de0fac9b962 Author: rriggs Date: 2013-08-29 20:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1de0fac9b962 8023764: Optimize Period addition Summary: Optimise plus/minus for common cases Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/ZonedDateTime.java Changeset: 356df1b99976 Author: rriggs Date: 2013-08-30 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/356df1b99976 8023763: Rename ChronoDateImpl Summary: Rename ChronoDateImpl to ChronoLocalDateImpl Reviewed-by: sherman Contributed-by: scolebourne at joda.org - src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: 5d73f7a2db51 Author: rriggs Date: 2013-09-04 15:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d73f7a2db51 8023762: Add ChronoPeriod interface and bind period to Chronology Summary: Make Period ISO-only, adding a Chronology-specific period concept Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoPeriod.java + src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/Temporal.java ! test/java/time/tck/java/time/TCKPeriod.java + test/java/time/tck/java/time/chrono/TCKChronoPeriod.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: 79077f1641cc Author: rriggs Date: 2013-09-14 22:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79077f1641cc 8024835: Change until() to accept any compatible temporal Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java Changeset: 14a187dc4ffe Author: rriggs Date: 2013-10-04 12:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/14a187dc4ffe 8024999: Instant.Parse typo in example Summary: javadoc only fix to correct example to use "." and "Z" Reviewed-by: sherman ! src/share/classes/java/time/Instant.java Changeset: f9c701ba04e7 Author: rriggs Date: 2013-09-14 22:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f9c701ba04e7 8024807: Add getChronlogy() to CLDT/CZDT Summary: Alternative to method is clunky and hard to find Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java Changeset: e12b912ab98e Author: rriggs Date: 2013-09-14 22:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e12b912ab98e 8024834: Better return type for TemporalField resolve Summary: Allow resolve method to return more than just ChronoLocalDate Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalField.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java Changeset: 7736abdf0805 Author: rfield Date: 2013-10-04 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7736abdf0805 8021186: jdk/lambda/vm/DefaultMethodsTest.java fails Summary: remove DefaultMethodsTest from jdk/test/problemList.txt Reviewed-by: mduigou ! test/ProblemList.txt Changeset: 66181f7991bd Author: bpatel Date: 2013-10-04 15:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/66181f7991bd 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! make/docs/Makefile Changeset: 7d2112abbb1d Author: coffeys Date: 2013-10-04 16:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d2112abbb1d 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar + test/javax/xml/ws/clientjar/TestService.java + test/javax/xml/ws/clientjar/TestWsImport.java Changeset: 44da760eed4b Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44da760eed4b 8024761: JSR 292 improve performance of generic invocation Summary: use a per-MH one element cache for MH.asType to speed up MH.invoke; also cache enough MH constants to cache LMF.metafactory Reviewed-by: twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/InvokeGeneric.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java Changeset: 97d5cc1e7586 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/97d5cc1e7586 8001105: findVirtual of Object[].clone produces internal error Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type. Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 91535ade7349 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/91535ade7349 8019417: JSR 292 javadoc should clarify method handle arity limits Summary: clarification of erroneous reading of spec. that led to 7194534 Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/BigArityTest.java Changeset: d391e062b983 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d391e062b983 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException Summary: Document error conditions that may occur when calling a "spreader" method handle. Use IAE in all cases. Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: acdf5bf1a918 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/acdf5bf1a918 8001108: an attempt to use "" as a method name should elicit NoSuchMethodException Summary: add an explicit check for leading "<", upgrade the unit tests Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: df6236da299d Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/df6236da299d 8024599: JSR 292 direct method handles need to respect initialization rules for static members Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding invocation. Reviewed-by: twisti, darcy, abuckley, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/CallStaticInitOrder.java Changeset: eb3cfc69c16e Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eb3cfc69c16e 8001110: method handles should have a collectArguments transform, generalizing asCollector Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: b670477bff8f Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b670477bff8f 8025112: JSR 292 spec updates for security manager and caller sensitivity Summary: align CONSTANT_MethodHandle and Lookup.find* API calls, clarify security manager & @CallerSensitive interactions Reviewed-by: mchung, twisti ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/TestPrivateMember.java Changeset: 6623c675e734 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6623c675e734 8024438: JSR 292 API specification maintenance for JDK 8 Summary: add wildcard to unreflectConstructor, various clarifications and minor edits Reviewed-by: mchung, darcy, twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/sun/invoke/WrapperInstance.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RevealDirectTest.java Changeset: 0ac9dc315071 Author: alanb Date: 2013-10-07 11:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ac9dc315071 8025983: Typo in Javadoc of Files.isRegularFile() Reviewed-by: mchung, chegar ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java Changeset: f0ad3e2918b4 Author: henryjen Date: 2013-10-07 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f0ad3e2918b4 8025968: Integrate test improvements made in lambda repo Reviewed-by: psandoz ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java Changeset: 0cffe1dab0bf Author: henryjen Date: 2013-10-07 15:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0cffe1dab0bf 8026009: Changes for 8025968 break all stream tests Reviewed-by: mduigou ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java Changeset: 0d5f4f1782e8 Author: xuelei Date: 2013-10-07 18:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0d5f4f1782e8 6956398: make ephemeral DH key match the length of the certificate key Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java Changeset: b90dcd1a71bf Author: psandoz Date: 2013-10-08 11:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b90dcd1a71bf 8025136: SplittableRandom enchancements Reviewed-by: psandoz, martin Contributed-by: Doug Lea
, Guy Steele ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: 95bb56c61276 Author: alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java Changeset: 748207aa9620 Author: lana Date: 2013-10-08 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/748207aa9620 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 575d4bc3bcae Author: lana Date: 2013-10-11 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/575d4bc3bcae Merge ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 28191d3ff921 Author: erikj Date: 2013-10-09 16:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28191d3ff921 8026144: Missing mkdir in Images.gmk Reviewed-by: tbell ! makefiles/Images.gmk Changeset: 86df2e879eca Author: tbell Date: 2013-10-09 18:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86df2e879eca 8023611: Win32 and win64: Remove all the WARNINGS in JDK 8 builds for Windows 2008 and MSVS 2010 SP1 Reviewed-by: erikj ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 98d98ec01f07 Author: tbell Date: 2013-10-09 23:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98d98ec01f07 Merge Changeset: 9c60860b1812 Author: ihse Date: 2013-10-10 15:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c60860b1812 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! 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/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GendataTZDB.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.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/PatchList.solaris ! makefiles/ProfileNames.gmk ! makefiles/Profiles.gmk ! makefiles/Setup.gmk ! makefiles/SignJars.gmk ! makefiles/Tools.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! 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/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/awt/ToBin.java Changeset: cf3ee0e2c1a5 Author: erikj Date: 2013-10-14 11:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf3ee0e2c1a5 8025612: rt.jar still has old specification value in the manifest Reviewed-by: alanb, dholmes, tbell, wetmore ! make/tools/manifest.mf Changeset: 986acae7efe9 Author: ihse Date: 2013-10-15 13:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/986acae7efe9 8001933: Move Gensrc*.gmk and Gendata*.gmk into separate directories. Reviewed-by: erikj, tbell ! makefiles/BuildJdk.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk ! makefiles/GenerateData.gmk - makefiles/GenerateJavaSources.gmk + makefiles/GenerateSources.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/gendata/GendataBreakIterator.gmk + makefiles/gendata/GendataFontConfig.gmk + makefiles/gendata/GendataHtml32dtd.gmk + makefiles/gendata/GendataTZDB.gmk + makefiles/gendata/GendataTimeZone.gmk + makefiles/gensrc/GensrcBuffer.gmk + makefiles/gensrc/GensrcCLDR.gmk + makefiles/gensrc/GensrcCharacterData.gmk + makefiles/gensrc/GensrcCharsetCoder.gmk + makefiles/gensrc/GensrcCharsetMapping.gmk + makefiles/gensrc/GensrcExceptions.gmk + makefiles/gensrc/GensrcIcons.gmk + makefiles/gensrc/GensrcJDWP.gmk + makefiles/gensrc/GensrcJObjC.gmk + makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk + makefiles/gensrc/GensrcMisc.gmk + makefiles/gensrc/GensrcProperties.gmk + makefiles/gensrc/GensrcSwing.gmk + makefiles/gensrc/GensrcX11Wrappers.gmk Changeset: eef656e1bdeb Author: ksrini Date: 2013-10-16 07:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eef656e1bdeb 8026500: [infra] remove extraneous docs in solaris images Reviewed-by: erikj, mchung, tbell ! makefiles/Images.gmk - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: f002f5f3a16c Author: katleman Date: 2013-10-16 12:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f002f5f3a16c Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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/Profiles.gmk ! makefiles/profile-includes.txt - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: bef8f6d429de Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bef8f6d429de Added tag jdk8-b112 for changeset f002f5f3a16c ! .hgtags Changeset: f1e31376f419 Author: robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 2ea162b2ff55 Author: alanb Date: 2013-10-09 09:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ea162b2ff55 8008662: Add @jdk.Exported to JDK-specific/exported APIs Reviewed-by: chegar, vinnie, dfuchs, mchung, mullan, darcy ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayReference.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/BooleanType.java ! src/share/classes/com/sun/jdi/BooleanValue.java ! src/share/classes/com/sun/jdi/Bootstrap.java ! src/share/classes/com/sun/jdi/ByteType.java ! src/share/classes/com/sun/jdi/ByteValue.java ! src/share/classes/com/sun/jdi/CharType.java ! src/share/classes/com/sun/jdi/CharValue.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/ClassObjectReference.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/DoubleType.java ! src/share/classes/com/sun/jdi/DoubleValue.java ! src/share/classes/com/sun/jdi/Field.java ! src/share/classes/com/sun/jdi/FloatType.java ! src/share/classes/com/sun/jdi/FloatValue.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/IntegerType.java ! src/share/classes/com/sun/jdi/IntegerValue.java ! src/share/classes/com/sun/jdi/InterfaceType.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/Locatable.java ! src/share/classes/com/sun/jdi/Location.java ! src/share/classes/com/sun/jdi/LongType.java ! src/share/classes/com/sun/jdi/LongValue.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/Mirror.java ! src/share/classes/com/sun/jdi/MonitorInfo.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/PathSearchingVirtualMachine.java ! src/share/classes/com/sun/jdi/PrimitiveType.java ! src/share/classes/com/sun/jdi/PrimitiveValue.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/ShortType.java ! src/share/classes/com/sun/jdi/ShortValue.java ! src/share/classes/com/sun/jdi/StackFrame.java ! src/share/classes/com/sun/jdi/StringReference.java ! src/share/classes/com/sun/jdi/ThreadGroupReference.java ! src/share/classes/com/sun/jdi/ThreadReference.java ! src/share/classes/com/sun/jdi/Type.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/Value.java ! src/share/classes/com/sun/jdi/VirtualMachine.java ! src/share/classes/com/sun/jdi/VirtualMachineManager.java ! src/share/classes/com/sun/jdi/VoidType.java ! src/share/classes/com/sun/jdi/VoidValue.java ! src/share/classes/com/sun/jdi/connect/AttachingConnector.java ! src/share/classes/com/sun/jdi/connect/Connector.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/Transport.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/package-info.java - src/share/classes/com/sun/jdi/connect/package.html ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/connect/spi/Connection.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java + src/share/classes/com/sun/jdi/connect/spi/package-info.java - src/share/classes/com/sun/jdi/connect/spi/package.html ! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/BreakpointEvent.java ! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java ! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java ! src/share/classes/com/sun/jdi/event/Event.java ! src/share/classes/com/sun/jdi/event/EventIterator.java ! src/share/classes/com/sun/jdi/event/EventQueue.java ! src/share/classes/com/sun/jdi/event/EventSet.java ! src/share/classes/com/sun/jdi/event/ExceptionEvent.java ! src/share/classes/com/sun/jdi/event/LocatableEvent.java ! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java ! src/share/classes/com/sun/jdi/event/MethodExitEvent.java ! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java ! src/share/classes/com/sun/jdi/event/StepEvent.java ! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java ! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java ! src/share/classes/com/sun/jdi/event/VMDeathEvent.java ! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java ! src/share/classes/com/sun/jdi/event/VMStartEvent.java ! src/share/classes/com/sun/jdi/event/WatchpointEvent.java + src/share/classes/com/sun/jdi/event/package-info.java - src/share/classes/com/sun/jdi/event/package.html + src/share/classes/com/sun/jdi/package-info.java - src/share/classes/com/sun/jdi/package.html ! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/BreakpointRequest.java ! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java ! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/EventRequest.java ! src/share/classes/com/sun/jdi/request/EventRequestManager.java ! src/share/classes/com/sun/jdi/request/ExceptionRequest.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java ! src/share/classes/com/sun/jdi/request/MethodExitRequest.java ! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java ! src/share/classes/com/sun/jdi/request/StepRequest.java ! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java ! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java ! src/share/classes/com/sun/jdi/request/VMDeathRequest.java ! src/share/classes/com/sun/jdi/request/WatchpointRequest.java + src/share/classes/com/sun/jdi/request/package-info.java - src/share/classes/com/sun/jdi/request/package.html ! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java ! src/share/classes/com/sun/management/GarbageCollectorMXBean.java ! src/share/classes/com/sun/management/GcInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java + src/share/classes/com/sun/management/package-info.java - src/share/classes/com/sun/management/package.html ! src/share/classes/com/sun/net/httpserver/Authenticator.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpContext.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/httpserver/HttpHandler.java ! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java ! src/share/classes/com/sun/net/httpserver/HttpServer.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsExchange.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/net/httpserver/HttpsServer.java ! src/share/classes/com/sun/net/httpserver/package-info.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/httpserver/spi/package-info.java ! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java ! src/share/classes/com/sun/nio/sctp/Association.java ! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java ! src/share/classes/com/sun/nio/sctp/HandlerResult.java ! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java ! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java ! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/Notification.java ! src/share/classes/com/sun/nio/sctp/NotificationHandler.java ! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.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/nio/sctp/SendFailedNotification.java ! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java ! src/share/classes/com/sun/nio/sctp/package-info.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTNumericCredential.java ! src/share/classes/com/sun/security/auth/NTSid.java ! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java ! src/share/classes/com/sun/security/auth/NTUserPrincipal.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/PrincipalComparator.java ! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/UnixPrincipal.java ! src/share/classes/com/sun/security/auth/UserPrincipal.java ! src/share/classes/com/sun/security/auth/X500Principal.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java + src/share/classes/com/sun/security/auth/callback/package-info.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java + src/share/classes/com/sun/security/auth/login/package-info.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java + src/share/classes/com/sun/security/auth/module/package-info.java + src/share/classes/com/sun/security/auth/package-info.java ! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/com/sun/security/jgss/GSSUtil.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/jgss/InquireType.java + src/share/classes/com/sun/security/jgss/package-info.java ! src/share/classes/com/sun/tools/attach/AgentInitializationException.java ! src/share/classes/com/sun/tools/attach/AgentLoadException.java ! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java ! src/share/classes/com/sun/tools/attach/AttachPermission.java ! src/share/classes/com/sun/tools/attach/VirtualMachine.java ! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java + src/share/classes/com/sun/tools/attach/package-info.java - src/share/classes/com/sun/tools/attach/package.html ! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java + src/share/classes/com/sun/tools/attach/spi/package-info.java - src/share/classes/com/sun/tools/attach/spi/package.html ! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java ! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java + src/share/classes/com/sun/tools/jconsole/package-info.java - src/share/classes/com/sun/tools/jconsole/package.html ! src/solaris/classes/com/sun/management/OSMBeanFactory.java Changeset: 91a752e3d50b Author: vinnie Date: 2013-10-09 10:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/91a752e3d50b 8008171: Refactor KeyStore.DomainLoadStoreParameter as a standalone class Reviewed-by: mullan, weijun + src/share/classes/java/security/DomainLoadStoreParameter.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/provider/DomainKeyStore.java ! test/sun/security/provider/KeyStore/DKSTest.java Changeset: 1cd20806fd5c Author: psandoz Date: 2013-10-09 15:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1cd20806fd5c 8020061: Clarify reporting characteristics between splits Reviewed-by: alanb, chegar ! src/share/classes/java/util/Spliterator.java Changeset: cf6e39cfdf50 Author: mchung Date: 2013-10-09 06:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf6e39cfdf50 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Reviewed-by: dfuchs, chegar ! src/share/classes/java/util/logging/Level.java + test/java/util/logging/Level/CustomLevel.java + test/java/util/logging/Level/myresource.properties Changeset: e3b70e601c1c Author: rriggs Date: 2013-10-09 11:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3b70e601c1c 8024612: java/time/tck/java/time/format/TCKDateTimeFormatters.java failed Summary: The test should be using the Locale.Category.FORMAT to verify the test data Reviewed-by: lancea ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java Changeset: 09e2a73aa1dc Author: rriggs Date: 2013-09-26 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/09e2a73aa1dc 8025718: Enhance error messages for parsing Summary: Add values and types to exception messages Reviewed-by: lancea Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/format/Parsed.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java Changeset: c070001c4f60 Author: henryjen Date: 2013-10-09 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c070001c4f60 8023524: Mechanism to dump generated lambda classes / log lambda code generation Reviewed-by: plevart, mchung, forax, jjb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/ProxyClassesDumper.java + test/java/lang/invoke/lambda/LogGeneratedClassesTest.java Changeset: d42fe440bda8 Author: rriggs Date: 2013-10-09 13:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d42fe440bda8 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Summary: Add appendValueReduced method based on a ChronoLocalDate to provide context for the value Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java Changeset: b86e6700266e Author: bpb Date: 2013-10-09 11:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b86e6700266e 8016252: More defensive HashSet.readObject Summary: Add data validation checks in readObject(). Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashSet.java + test/java/util/HashSet/Serialization.java Changeset: 1597066b58ee Author: valeriep Date: 2013-10-08 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1597066b58ee 7196382: PKCS11 provider should support 2048-bit DH Summary: Query and enforce range checking using the values from native PKCS11 library. Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java + test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java Changeset: 3da8be8d13bf Author: valeriep Date: 2013-10-08 11:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3da8be8d13bf 8012900: CICO ignores AAD in GCM mode Summary: Change GCM decryption to not return result until tag verification passed Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherFeedback.java ! src/share/classes/com/sun/crypto/provider/CounterMode.java ! src/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GCTR.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/javax/crypto/CipherSpi.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java Changeset: f4305254f92f Author: valeriep Date: 2013-10-08 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4305254f92f 8014374: Cannot initialize "AES/GCM/NoPadding" on wrap/unseal on solaris with OracleUcrypto Summary: Removed OracleUcrypto provider regression tests from OpenJDK Reviewed-by: xuelei - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java Changeset: e044b0151858 Author: valeriep Date: 2013-10-08 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e044b0151858 8025967: addition of -Werror broke the old build Summary: Fixed and suppressed compiler warnings on rawtypes Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/sun/instrument/InstrumentationImpl.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/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/security/provider/AuthPolicyFile.java ! src/share/classes/sun/security/provider/SubjectCodeSource.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: 7a7b73a40bb1 Author: valeriep Date: 2013-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7a7b73a40bb1 Merge - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html Changeset: 673f8045311e Author: bpb Date: 2013-10-09 17:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/673f8045311e 7189139: BigInteger's staticRandom field can be a source of bottlenecks. Summary: Use ThreadLocalRandom instead of SecureRandom. Reviewed-by: shade, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigInteger.java Changeset: eab3c09745b6 Author: bchristi Date: 2013-10-09 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eab3c09745b6 8024709: TreeMap.DescendingKeyIterator 'remove' confuses iterator position Summary: Override remove() method in DescendingKeyIterator Reviewed-by: alanb, mduigou, psandoz ! src/share/classes/java/util/TreeMap.java ! test/java/util/Collection/MOAT.java Changeset: c13309f658e1 Author: darcy Date: 2013-10-09 18:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c13309f658e1 8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Reviewed-by: mduigou, briangoetz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/DoubleStream.java Changeset: e901a618dcff Author: sjiang Date: 2013-10-10 08:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e901a618dcff 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Reviewed-by: dfuchs, dholmes ! test/javax/management/monitor/CounterMonitorThresholdTest.java Changeset: e8097e1e18a7 Author: sjiang Date: 2013-10-10 08:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8097e1e18a7 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/monitor/NullAttributeValueTest.java Changeset: a30f6fd581b3 Author: sjiang Date: 2013-10-10 09:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a30f6fd581b3 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java Changeset: 74b4d20769fd Author: weijun Date: 2013-10-10 15:24 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/74b4d20769fd 8026235: keytool NSS test should use 64 bit lib on Solaris Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 6aa637dde16e Author: sla Date: 2013-10-10 09:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6aa637dde16e 8025427: jstat tests fails on 32-bit platforms Reviewed-by: ehelin, dsamersoff, dholmes, sspitsyn ! src/share/classes/sun/tools/jstat/RowClosure.java ! test/ProblemList.txt ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 998560cccefc Author: allwin Date: 2013-10-10 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/998560cccefc 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Reviewed-by: sla, mgronlun, dholmes, jbachorik, chegar ! test/com/sun/jdi/NoLaunchOptionTest.java Changeset: 254173b48dcb Author: dholmes Date: 2013-10-10 04:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/254173b48dcb 8026232: Move libnpt from profile compact1 to compact3 Reviewed-by: mchung, alanb ! makefiles/profile-includes.txt Changeset: 99b7bbe0474f Author: dl Date: 2013-10-10 09:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/99b7bbe0474f 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Reviewed-by: alanb, dholmes ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: 8294c49d23b3 Author: michaelm Date: 2013-10-10 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8294c49d23b3 7076487: (sctp) SCTP API classes does not exist in JDK for Mac Reviewed-by: alanb, chegar ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java Changeset: cab80088c671 Author: sjiang Date: 2013-10-10 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cab80088c671 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Reviewed-by: dholmes, jbachorik ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java Changeset: f25d9d8811ca Author: jfranck Date: 2013-10-10 18:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f25d9d8811ca 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Reviewed-by: darcy, psandoz ! src/share/classes/java/lang/reflect/Array.java + test/java/lang/Class/forName/arrayClass/Class1.java + test/java/lang/Class/forName/arrayClass/Class2.java + test/java/lang/Class/forName/arrayClass/Class3.java + test/java/lang/Class/forName/arrayClass/Class4.java + test/java/lang/Class/forName/arrayClass/ExceedMaxDim.java ! test/java/lang/reflect/Array/ExceedMaxDim.java Changeset: 4abfcbac1cb6 Author: emc Date: 2013-10-10 18:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4abfcbac1cb6 8026011: java.lang.reflect.MalformedParametersException introduces doclint warnings Summary: Add javadoc comments to members of MalformedParametersException Reviewed-by: darcy ! src/share/classes/java/lang/reflect/MalformedParametersException.java Changeset: a1d91e198ddf Author: lana Date: 2013-10-10 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1d91e198ddf Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/sun/security/tools/keytool/autotest.sh Changeset: 1863a7e3a1c9 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1863a7e3a1c9 Merge Changeset: 1a067bc31098 Author: lana Date: 2013-10-10 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a067bc31098 Merge Changeset: 4ad76262bac8 Author: mullan Date: 2013-10-11 08:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4ad76262bac8 8007292: Add JavaFX internal packages to package.access Summary: build hooks to allow closed restricted packages to be added to java.security file Reviewed-by: erikj, dholmes, tbell ! make/java/security/Makefile ! make/tools/Makefile + make/tools/addtorestrictedpkgs/Makefile + make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java ! makefiles/CopyFiles.gmk ! makefiles/Tools.gmk ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 76df579c0b93 Author: mullan Date: 2013-10-11 09:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/76df579c0b93 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: cb373cf43294 Author: dxu Date: 2013-10-11 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb373cf43294 8025712: (props) Possible memory leak in java_props_md.c / ParseLocale Reviewed-by: naoto, chegar ! src/solaris/native/java/lang/java_props_md.c Changeset: d23247aa7462 Author: vinnie Date: 2013-10-11 20:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d23247aa7462 8026301: DomainKeyStore doesn't cleanup correctly when storing to keystore Reviewed-by: mullan ! src/share/classes/sun/security/provider/DomainKeyStore.java Changeset: 94493b5800bb Author: vinnie Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/94493b5800bb Merge Changeset: 9632de07d963 Author: alanb Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9632de07d963 8019526: (fs) Files.lines, etc without Charset parameter Reviewed-by: psandoz, henryjen ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java ! test/java/nio/file/Files/StreamTest.java Changeset: 4561460bf570 Author: rfield Date: 2013-10-11 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4561460bf570 8026213: Reflection support for private interface methods Reviewed-by: forax, psandoz, dholmes, jfranck Contributed-by: karen.kinnear at oracle.com ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java + test/java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java Changeset: fb202a8e83c9 Author: xuelei Date: 2013-10-13 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fb202a8e83c9 8026119: Regression test DHEKeySizing.java failing intermittently Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java Changeset: 9f8bfdd99129 Author: dfuchs Date: 2013-10-14 10:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f8bfdd99129 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Reviewed-by: alanb, psandoz, mchung ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/ServiceLoader.java Changeset: 077237e4613f Author: tyan Date: 2013-10-14 11:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/077237e4613f 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Reviewed-by: chegar, alanb ! test/java/net/Socks/SocksProxyVersion.java Changeset: f15a0087181e Author: stefank Date: 2013-10-14 14:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f15a0087181e 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Reviewed-by: coleenp, sla Contributed-by: stefan.karlsson at oracle.com, coleen.phillimore at oracle.com ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh Changeset: 96644227daed Author: lana Date: 2013-10-11 23:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/96644227daed Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk Changeset: 3a5c987ff3a0 Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a5c987ff3a0 Merge Changeset: dd0deeb04933 Author: michaelm Date: 2013-10-14 22:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd0deeb04933 8014719: HttpClient/ProxyTest.java failing with IAE HttpURLPermission.parseURI Reviewed-by: alanb, chegar + src/share/classes/java/net/HostPortrange.java ! src/share/classes/java/net/HttpURLConnection.java - src/share/classes/java/net/HttpURLPermission.java + src/share/classes/java/net/URLPermission.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 + test/java/net/URLPermission/URLPermissionTest.java + test/java/net/URLPermission/URLTest.java + test/java/net/URLPermission/policy.1 + test/java/net/URLPermission/policy.2 + test/java/net/URLPermission/policy.3 Changeset: 94d4aa2fb414 Author: henryjen Date: 2013-10-14 17:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/94d4aa2fb414 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Reviewed-by: chegar ! test/java/lang/invoke/lambda/LogGeneratedClassesTest.java Changeset: 50e88f25255f Author: joehw Date: 2013-10-14 22:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/50e88f25255f 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb + test/javax/xml/jaxp/validation/8015092/XPathWhiteSpaceTest.java + test/javax/xml/jaxp/validation/8015092/idIxpns.xsd + test/javax/xml/jaxp/validation/8015092/idIxpns1.xsd + test/javax/xml/jaxp/validation/8015092/idJ029.xsd + test/javax/xml/jaxp/validation/8015092/idJimp.xsd Changeset: abe8d432f714 Author: jbachorik Date: 2013-10-15 10:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abe8d432f714 6804470: JvmstatCountersTest.java test times out on slower machines Summary: Increasing the default timeout to cater for the slower machines Reviewed-by: alanb ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Changeset: 0b6632e570b0 Author: alanb Date: 2013-10-15 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0b6632e570b0 8026398: Can't load jdk.Exported, ClassNotFoundException Reviewed-by: chegar, mchung ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java Changeset: 2c16140fb515 Author: dfuchs Date: 2013-10-15 13:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c16140fb515 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Summary: The test 'threadGroup.getParent() == null' can sometimes throw ACE and needs to be wrapped in doPrivileged. Reviewed-by: alanb, mchung, dholmes ! src/share/classes/sun/awt/AppContext.java ! test/TEST.groups + test/java/util/logging/TestMainAppContext.java Changeset: ea422834f880 Author: rriggs Date: 2013-09-26 23:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea422834f880 8025720: Separate temporal interface layer Summary: Remove ZoneId and Chronology from TemporalField interface Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java Changeset: 110107410393 Author: scolebourne Date: 2013-07-09 21:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/110107410393 8025719: Change Chronology to an interface Summary: Split Chronology and add AbstractChronology Reviewed-by: darcy Contributed-by: scolebourne at joda.org + src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! test/java/time/tck/java/time/chrono/CopticChronology.java Changeset: 087c8c1d2631 Author: rriggs Date: 2013-10-15 13:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/087c8c1d2631 8025722: TemporalAdjusters and TemporalQueries Summary: Move static from interfaces methods to supporting classes Reviewed-by: sherman ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAdjusters.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalQueries.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/util/Formatter.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/TestIsoChronology.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java ! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java ! test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/util/TestFormatter.java Changeset: b3baca585b7f Author: jbachorik Date: 2013-04-23 09:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3baca585b7f 8011081: Improve jhat Summary: Properly escape HTML output Reviewed-by: alanb, mschoene, sundar ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java Changeset: 37f6f4dbfc6d Author: ksrini Date: 2013-05-07 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37f6f4dbfc6d 8013506: Better Pack200 data handling Reviewed-by: jrose, kizune, mschoene ! src/share/native/com/sun/java/util/jar/pack/zip.cpp Changeset: 139a01719eec Author: jchen Date: 2013-05-09 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/139a01719eec 8013510: Augment image writing code Reviewed-by: bae, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: f2068f4244a5 Author: bae Date: 2013-05-14 12:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2068f4244a5 8014093: Improve parsing of images Reviewed-by: prr, jgodinez ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 65d5a6e53d12 Author: alexsch Date: 2013-05-20 14:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/65d5a6e53d12 8013744: Better tabling for AWT Reviewed-by: art, malenkov, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 52be85d5149b Author: bae Date: 2013-05-20 15:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/52be85d5149b 8014102: Improve image conversion Reviewed-by: mschoene, prr, jgodinez ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 08b88f831dd1 Author: malenkov Date: 2013-05-20 19:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/08b88f831dd1 8012071: Better Building of Beans Reviewed-by: art, skoivu ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/MetaData.java Changeset: 140c474ab8b9 Author: malenkov Date: 2013-05-31 21:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/140c474ab8b9 8012277: Improve AWT DataFlavor Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 23fe888b698d Author: weijun Date: 2013-05-08 09:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23fe888b698d 8014341: Better service from Kerberos servers Summary: read incoming data safely and take care of null return value Reviewed-by: valeriep, ahgross ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java Changeset: 532343ec60b7 Author: weijun Date: 2013-06-13 10:21 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/532343ec60b7 8013739: Better LDAP resource management Reviewed-by: ahgross, mchung, xuelei ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 6d9ec6877a7f Author: weijun Date: 2013-06-13 10:31 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d9ec6877a7f 8015731: Subject java.security.auth.subject to improvements Reviewed-by: skoivu, mullan ! src/share/classes/javax/security/auth/Subject.java Changeset: ccca37ca416a Author: jchen Date: 2013-06-13 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ccca37ca416a 8014098: Better profile validation Reviewed-by: bae, mschoene, prr ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c Changeset: 5a14ecd30b4e Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5a14ecd30b4e 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! make/com/sun/jmx/Makefile ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java Changeset: 7addece3f21e Author: jbachorik Date: 2013-06-20 08:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7addece3f21e 8014085: Better serialization support in JMX classes Reviewed-by: alanb, dfuchs, skoivu ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/JMXPrincipal.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java Changeset: eb29deb3c1db Author: chegar Date: 2013-06-27 10:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eb29deb3c1db Merge Changeset: 0a06ec55aacd Author: bae Date: 2013-07-01 15:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a06ec55aacd 8017287: Better resource disposal Reviewed-by: prr, vadim, skoivu ! src/share/classes/sun/java2d/Disposer.java Changeset: 51204df822d3 Author: erikj Date: 2013-07-03 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51204df822d3 8012146: Improve tool support Reviewed-by: ksrini, dholmes, alanb, anthony ! makefiles/CompileLaunchers.gmk ! makefiles/Images.gmk ! test/Makefile Changeset: 888fd0ad7e1e Author: ascarpino Date: 2013-07-03 15:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/888fd0ad7e1e 8011071: Better crypto provider handling Reviewed-by: hawtin, valeriep ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/provider/DSAPrivateKey.java ! src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java Changeset: a06b764cc2d0 Author: dsamersoff Date: 2013-07-08 16:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a06b764cc2d0 8008589: Better MBean permission validation Summary: Better MBean permission validation Reviewed-by: skoivu, dfuchs, mchung, sjiang ! src/share/classes/javax/management/MBeanTrustPermission.java Changeset: 9c6de162771c Author: smarks Date: 2013-07-11 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c6de162771c 8014987: Augment serialization handling Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java Changeset: c40752886882 Author: jfranck Date: 2013-07-15 14:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c40752886882 8014349: (cl) Class.getDeclaredClass problematic in some class loader configurations Reviewed-by: mchung, ahgross, darcy ! src/share/classes/java/lang/Class.java ! src/share/native/java/lang/Class.c Changeset: 48548e40187a Author: mchung Date: 2013-07-15 20:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/48548e40187a 8017291: Cast Proxies Aside Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ClassLoader.java Changeset: 047c99b53994 Author: chegar Date: 2013-07-15 18:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/047c99b53994 Merge ! src/share/classes/java/lang/Thread.java - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/swing/SwingUtilities2.java - test/java/util/Comparators/BasicTest.java Changeset: 3062c96e79e0 Author: chegar Date: 2013-07-16 12:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3062c96e79e0 Merge Changeset: e1497f102a8a Author: malenkov Date: 2013-07-16 21:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e1497f102a8a 8019617: Better view of objects Reviewed-by: art, skoivu ! src/share/classes/javax/swing/text/html/ObjectView.java Changeset: 69a2dc92fefe Author: michaelm Date: 2013-07-18 18:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69a2dc92fefe 8015743: Address internet addresses Reviewed-by: alanb, khazra, skoivu ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! test/java/net/Inet6Address/serialize/Serialize.java Changeset: 5d8f1e697cd8 Author: okutsu Date: 2013-07-19 12:14 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d8f1e697cd8 8001029: Add new date/time capability Reviewed-by: mchung, hawtin ! src/share/classes/java/util/TimeZone.java + test/java/util/TimeZone/SetDefaultSecurityTest.java Changeset: fe90bd20865b Author: sjiang Date: 2013-07-19 13:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fe90bd20865b 8014534: Better profiling support Summary: Validation of parameters Reviewed-by: sspitsyn, skoivu, mchung ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c Changeset: 0a51ccf778b3 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a51ccf778b3 Merge Changeset: 3725e8a70ae9 Author: mchung Date: 2013-07-22 19:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3725e8a70ae9 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 5bde952bf23c Author: sgabdura Date: 2013-07-23 09:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bde952bf23c 8016357: Update hotspot diagnostic class Summary: Add security check to HotSpotDiagnostic.dumpHeap Reviewed-by: fparain, sla, ahgross ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c Changeset: 5bdc55e87cae Author: weijun Date: 2013-07-17 18:46 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bdc55e87cae 8020696: Merge problem for KdcComm.java Reviewed-by: chegar ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: 490c67c5d9a2 Author: jchen Date: 2013-07-24 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/490c67c5d9a2 8020293: JVM crash Reviewed-by: prr, jgodinez ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: bcce47d9d8da Author: jbachorik Date: 2013-07-19 16:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bcce47d9d8da 8019584: javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Reviewed-by: mchung, sjiang, dfuchs, ahgross ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java Changeset: d7a0bbf526f8 Author: jbachorik Date: 2013-07-29 04:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d7a0bbf526f8 8021577: JCK test api/javax_management/jmx_serial/modelmbean/ModelMBeanNotificationInfo/serial/index.html#Input has failed since jdk 7u45 b01 Reviewed-by: alanb, dfuchs, ahgross ! src/share/classes/javax/management/MBeanNotificationInfo.java Changeset: 1a1e42c8e988 Author: chegar Date: 2013-07-25 19:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a1e42c8e988 Merge ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/javax/security/auth/Subject.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/security/pkcs11/P11Key.java - test/java/util/Collections/EmptySortedSet.java Changeset: 446bc20447a1 Author: chegar Date: 2013-07-29 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/446bc20447a1 Merge Changeset: e537b7f5f39b Author: naoto Date: 2013-08-01 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e537b7f5f39b 8021286: Improve MacOS resourcing Reviewed-by: okutsu - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m Changeset: 44a063555ccd Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44a063555ccd Merge Changeset: 17e1675e3d1e Author: serb Date: 2013-08-04 02:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17e1675e3d1e 8021282: Better recycling of object instances Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaUtils.java Changeset: ba7566de89c6 Author: sjiang Date: 2013-08-06 10:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba7566de89c6 8019292: Better Attribute Value Exceptions Reviewed-by: dfuchs, dholmes, ahgross ! src/share/classes/javax/management/BadAttributeValueExpException.java Changeset: 23476862c55b Author: malenkov Date: 2013-08-07 14:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23476862c55b 8021969: The index_AccessAllowed jnlp can not load successfully with exception thrown in the log. Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: db9539b0061d Author: jbachorik Date: 2013-08-08 19:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db9539b0061d 8021360: object not exported" on start of JMXConnectorServer for RMI-IIOP protocol with security manager Reviewed-by: alanb, ahgross, smarks, coffeys ! src/share/classes/com/sun/jmx/remote/protocol/iiop/IIOPProxyImpl.java Changeset: 077d8c2cc5f6 Author: chegar Date: 2013-08-09 14:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/077d8c2cc5f6 Merge ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/net/package.html ! src/share/classes/java/util/TimeZone.java ! src/share/native/java/net/net_util.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! test/Makefile Changeset: e82ddcc1b2fb Author: serb Date: 2013-08-12 19:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e82ddcc1b2fb 8021275: Better screening for ScreenMenu Reviewed-by: art ! src/macosx/classes/com/apple/laf/ScreenMenu.java Changeset: 3e3cbd93f4f1 Author: twisti Date: 2013-08-12 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3e3cbd93f4f1 8022066: Evaluation of method reference to signature polymorphic method crashes VM Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/MethodHandleConstants.java Changeset: e173b8786362 Author: ksrini Date: 2013-08-14 10:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e173b8786362 8021355: REGRESSION: Five closed/java/awt/SplashScreen tests fail since 7u45 b01 on Linux, Solaris Reviewed-by: dholmes, anthony, ahgross, erikj ! src/solaris/bin/java_md_solinux.c Changeset: 31010ca3da3e Author: chegar Date: 2013-08-15 21:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31010ca3da3e Merge ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: 3f85c96eafcc Author: weijun Date: 2013-08-14 15:25 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f85c96eafcc 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: 50bdb9577b27 Author: erikj Date: 2013-08-19 12:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/50bdb9577b27 8022719: tools/launcher/RunpathTest.java fails after 8012146 Reviewed-by: chegar ! test/tools/launcher/RunpathTest.java Changeset: 0f279113c95a Author: erikj Date: 2013-08-19 14:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0f279113c95a 8023231: Remove comma from jtreg bug line Reviewed-by: alanb, chegar ! test/tools/launcher/RunpathTest.java Changeset: ad35b4b6ce8e Author: chegar Date: 2013-08-23 12:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad35b4b6ce8e Merge Changeset: 29f73bc50bd4 Author: chegar Date: 2013-08-30 09:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/29f73bc50bd4 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/solaris/native/java/net/NetworkInterface.c - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: a8593bc7c29d Author: chegar Date: 2013-09-06 09:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8593bc7c29d Merge ! src/share/classes/java/lang/Class.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 22ea25e71b4c Author: chegar Date: 2013-09-14 19:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/22ea25e71b4c Merge Changeset: 240072825ada Author: chegar Date: 2013-10-03 19:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/240072825ada Merge ! make/sun/awt/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp ! src/solaris/bin/java_md_solinux.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/java/util/regex/PatternTest.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/tools/launcher/RunpathTest.java Changeset: adbf6d61c820 Author: chegar Date: 2013-10-07 11:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/adbf6d61c820 8025991: tools/launcher/RunpathTest.java fails Reviewed-by: erikj ! test/tools/launcher/RunpathTest.java Changeset: 99832c718cb8 Author: chegar Date: 2013-10-15 09:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/99832c718cb8 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3dbfab65c17e Author: chegar Date: 2013-10-15 13:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3dbfab65c17e Merge ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/lang/ClassLoader.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 27ac58b9a62a Author: chegar Date: 2013-10-15 20:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27ac58b9a62a 8026513: ProblemList.txt Updates (10/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: 78ffa90c77b2 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78ffa90c77b2 Merge Changeset: 3676f04e6553 Author: bpb Date: 2013-10-15 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3676f04e6553 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Summary: Modify UHE exception message for EAI_AGAIN failures. Reviewed-by: alanb, chegar, michaelm, dsamersoff Contributed-by: Brian Burkhalter ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: e33aea66caa3 Author: dholmes Date: 2013-10-15 20:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e33aea66caa3 8026378: TEST_BUG: Clean up TEST.groups Reviewed-by: mduigou, mchung, alanb ! test/TEST.groups Changeset: a70aab9b373e Author: weijun Date: 2013-10-16 14:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a70aab9b373e 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/krb5/KrbCred.java Changeset: 9ea6a464c147 Author: igerasim Date: 2013-10-15 21:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9ea6a464c147 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Summary: Properly close PipedStreams. Additional testing for malformed input Reviewed-by: darcy, sherman ! test/java/util/zip/GZIP/GZIPInZip.java Changeset: 76a7c0bc74fd Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/76a7c0bc74fd 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateClasses.gmk ! makefiles/Setup.gmk ! src/share/classes/sun/tools/tree/Node.java Changeset: e078fd8a78f6 Author: erikj Date: 2013-10-16 15:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e078fd8a78f6 Merge Changeset: d8eec0e3a023 Author: robm Date: 2013-10-16 15:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d8eec0e3a023 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Reviewed-by: chegar, alanb ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/Socket/GetLocalAddress.java Changeset: 445667b19e32 Author: dfuchs Date: 2013-10-16 17:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/445667b19e32 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Reviewed-by: psandoz, mchung, alanb, chegar ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java Changeset: 2ef43f3a901c Author: dfuchs Date: 2013-10-16 20:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2ef43f3a901c 8013839: Enhance Logger API for handling of resource bundles 4814565: (rb) add method to get basename from a ResourceBundle Summary: adds Logger.setResourceBundle(ResourceBundle) and ResourceBundle.getBaseBundleName() Reviewed-by: mchung, naoto ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle_fr.java + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle.properties + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle_fr.java + test/java/util/logging/Logger/logrb/resources/PropertyBundle.properties + test/java/util/logging/Logger/logrb/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle_fr.java + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle.properties + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle_fr.properties Changeset: cf9cb3d241a3 Author: mduigou Date: 2013-10-16 13:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cf9cb3d241a3 8025910: rename substream(long) -> skip and remove substream(long,long) Reviewed-by: psandoz, henryjen ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java Changeset: 60e3cdbe8cdf Author: aefimov Date: 2013-10-13 14:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60e3cdbe8cdf 8025255: (tz) Support tzdata2013g Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: e2e3c2c249e2 Author: henryjen Date: 2013-10-16 21:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2e3c2c249e2 8026768: java.util.Map.Entry comparingBy methods missing @since 1.8 Reviewed-by: dholmes ! src/share/classes/java/util/Map.java Changeset: ce266885222d Author: peytoia Date: 2013-10-17 13:57 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce266885222d 8025703: Update LSR datafile for BCP 47 Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleEquivalentMaps.java + test/java/util/Locale/Bug8025703.java ! test/java/util/Locale/tools/language-subtag-registry.txt Changeset: a45acc8de0f3 Author: wetmore Date: 2013-10-16 23:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a45acc8de0f3 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Reviewed-by: katleman, dholmes ! makefiles/GenerateClasses.gmk Changeset: 37e3dcb798c3 Author: weijun Date: 2013-10-17 20:56 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37e3dcb798c3 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 0a6730b5e192 Author: drchase Date: 2013-10-16 17:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a6730b5e192 8022718: Runtime accessibility checking: protected class, if extended, should be accessible from another package Summary: Modify accessibility check; it was muddled about Java vs JVM protection terminology. Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/reflect/Reflection.java + test/java/lang/invoke/accessProtectedSuper/BogoLoader.java + test/java/lang/invoke/accessProtectedSuper/MethodInvoker.java + test/java/lang/invoke/accessProtectedSuper/Test.java + test/java/lang/invoke/accessProtectedSuper/anotherpkg/MethodSupplierOuter.java Changeset: 36fe6a9bd43e Author: rriggs Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/36fe6a9bd43e 8026516: javadoc errors in java.time Summary: Corrected links to TemporalQuery and TemporalField.resolve Reviewed-by: mduigou, darcy, lancea ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java Changeset: 5d866df64ae3 Author: mullan Date: 2013-10-17 10:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d866df64ae3 8026346: test/java/lang/SecurityManager/CheckPackageAccess.java failing Reviewed-by: vinnie ! src/share/lib/security/java.security-macosx ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 04e8b8fc6906 Author: mullan Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04e8b8fc6906 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/net/HttpURLPermission.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 85a73ad28c53 Author: mullan Date: 2013-10-17 11:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85a73ad28c53 Merge Changeset: 456a9b199208 Author: rriggs Date: 2013-10-17 13:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/456a9b199208 8026183: minor documentation problems in java.lang.invoke 8015808: Typo in MethodHandle javadoc Summary: Fix typos and javadoc markup and extraneous paragraph tags Reviewed-by: lancea ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java Changeset: bc04f561bb78 Author: joehw Date: 2013-10-17 11:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc04f561bb78 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea + test/javax/xml/jaxp/validation/8015243/AnyURITest.java + test/javax/xml/jaxp/validation/8015243/anyURI_b006.xsd Changeset: fa38f8e0accd Author: juh Date: 2013-10-17 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fa38f8e0accd 8026233: test/sun/security/tools/keytool/StorePasswords.java needs to clean up files Reviewed-by: vinnie ! test/sun/security/tools/keytool/StorePasswords.java Changeset: 64c0ac7cd936 Author: lancea Date: 2013-10-17 15:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64c0ac7cd936 8026812: doclint clean up for java.sql and javax.sql Reviewed-by: mduigou ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java Changeset: 3735d81552a7 Author: mchung Date: 2013-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3735d81552a7 8015912: jdeps support to output in dot file format 8026255: Switch jdeps to follow traditional Java option style Reviewed-by: alanb ! test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java Changeset: c1af85c48819 Author: mduigou Date: 2013-10-17 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1af85c48819 8004138: ForkJoinTask leaks exceptions Reviewed-by: chegar, mduigou, psandoz, martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java Changeset: e76bb2436b04 Author: bpb Date: 2013-10-17 15:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e76bb2436b04 8026832: Clean up straggling doclint warnings in java.math Summary: Fix empty paragraph tag warnings. Reviewed-by: lancea ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: 187d5ccb5b18 Author: lana Date: 2013-10-17 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/187d5ccb5b18 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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/Setup.gmk ! makefiles/Tools.gmk + makefiles/gendata/GendataBreakIterator.gmk ! makefiles/profile-includes.txt - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: b73fb7920645 Author: lana Date: 2013-10-17 15:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b73fb7920645 Merge - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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 - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: c1616a944d1c Author: weijun Date: 2013-10-18 08:57 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1616a944d1c 7025699: Policy Tool is not accessible by keyboard Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java ! test/sun/security/tools/policytool/Alias.html ! test/sun/security/tools/policytool/OpenPolicy.html ! test/sun/security/tools/policytool/UpdatePermissions.html Changeset: 969e8c6c26cc Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/969e8c6c26cc Merge ! makefiles/Import.gmk ! makefiles/Tools.gmk Changeset: c4ab67d1e0ce Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c4ab67d1e0ce Merge ! makefiles/Tools.gmk Changeset: a5b57fca66da Author: ihse Date: 2013-10-16 20:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a5b57fca66da 8025715: Split CompileNativeLibraries.gmk Reviewed-by: erikj ! makefiles/CompileNativeLibraries.gmk + makefiles/lib/Awt2dLibraries.gmk + makefiles/lib/CoreLibraries.gmk + makefiles/lib/NetworkingLibraries.gmk + makefiles/lib/NioLibraries.gmk + makefiles/lib/PlatformLibraries.gmk + makefiles/lib/SecurityLibraries.gmk + makefiles/lib/ServiceabilityLibraries.gmk + makefiles/lib/SoundLibraries.gmk Changeset: 1e99d539088d Author: katleman Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1e99d539088d Merge Changeset: 7ec4ddc36ad6 Author: erikj Date: 2013-10-17 16:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ec4ddc36ad6 8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! makefiles/CopyIntoClasses.gmk Changeset: 11e90e4167d4 Author: erikj Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11e90e4167d4 Merge Changeset: 3a6ac3484b05 Author: cl Date: 2013-10-21 23:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a6ac3484b05 8026974: solaris build missing java-rmi.cgi Reviewed-by: ksrini ! makefiles/CompileLaunchers.gmk Changeset: b121e84392fa Author: erikj Date: 2013-10-22 11:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b121e84392fa 8026966: Most native libs broken on mac in jdk8/build Reviewed-by: ihse, anthony ! makefiles/lib/PlatformLibraries.gmk Changeset: 9850efaedc50 Author: katleman Date: 2013-10-22 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9850efaedc50 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk + makefiles/lib/Awt2dLibraries.gmk + makefiles/lib/CoreLibraries.gmk + makefiles/lib/NetworkingLibraries.gmk + makefiles/lib/NioLibraries.gmk + makefiles/lib/PlatformLibraries.gmk + makefiles/lib/SecurityLibraries.gmk + makefiles/lib/ServiceabilityLibraries.gmk + makefiles/lib/SoundLibraries.gmk Changeset: 698937f18761 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/698937f18761 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties ! makefiles/jprt.properties Changeset: 81431a7c17cf Author: tbell Date: 2013-10-22 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/81431a7c17cf Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/net/HttpURLPermission.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: aabaae5de1ee Author: ihse Date: 2013-10-23 13:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aabaae5de1ee 8001922: Improve freetype handling. Reviewed-by: erikj ! makefiles/CopyFiles.gmk ! makefiles/lib/Awt2dLibraries.gmk Changeset: ab0e61a57df7 Author: chegar Date: 2013-10-23 13:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ab0e61a57df7 8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 Reviewed-by: mduigou, dxu, erikj, ihse ! makefiles/lib/NioLibraries.gmk Changeset: 5b4261b4b72a Author: erikj Date: 2013-10-23 17:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b4261b4b72a 8026888: Licensee build failure due to wrong libs being called Reviewed-by: tbell, ihse, simonis ! makefiles/lib/Awt2dLibraries.gmk Changeset: b88aa723a5fa Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b88aa723a5fa Added tag jdk8-b113 for changeset 5b4261b4b72a ! .hgtags Changeset: 110c4fe4c354 Author: erikj Date: 2013-10-24 10:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/110c4fe4c354 8009280: JCE jurisdiction policy files not copied into jdk/lib/security Reviewed-by: tbell, ihse ! makefiles/BuildJdk.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + makefiles/CreateSecurityJars.gmk ! makefiles/SignJars.gmk Changeset: f40f639e1f52 Author: dholmes Date: 2013-10-24 20:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f40f639e1f52 8016096: [macosx] jawt_md.h shipped with jdk is outdated Summary: Revised build system and added platform specific headers for Mac OS X Reviewed-by: anthony, art, ihse, erikj Contributed-by: david.dehaven at oracle.com ! makefiles/CopyFiles.gmk ! makefiles/gensrc/GensrcX11Wrappers.gmk + src/macosx/javavm/export/jawt_md.h + src/macosx/javavm/export/jni_md.h + src/macosx/javavm/export/jvm_md.h ! src/macosx/native/sun/awt/AWTSurfaceLayers.h ! src/macosx/native/sun/awt/CMenuComponent.h ! src/macosx/native/sun/awt/jawt.m ! src/macosx/native/sun/font/CoreTextSupport.h ! src/share/javavm/export/jawt.h Changeset: f3c95d961557 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f3c95d961557 8025673: [macosx] Disable X11 AWT toolkit Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X Reviewed-by: anthony, art, ihse, erikj Contributed-by: david.dehaven at oracle.com ! makefiles/CompileJavaClasses.gmk ! makefiles/GenerateSources.gmk ! makefiles/Tools.gmk ! makefiles/lib/Awt2dLibraries.gmk ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! 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/sun/awt/fontpath.c ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh Changeset: 5813af4c02e4 Author: dcubed Date: 2013-10-25 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5813af4c02e4 8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy Summary: Fix whitespace/indent issues. Reviewed-by: hseigel, coleenp, erikj, ihse ! makefiles/Import.gmk Changeset: 1628a137edca Author: katleman Date: 2013-10-28 16:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1628a137edca Merge Changeset: f26a0c8071bd Author: erikj Date: 2013-10-29 15:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f26a0c8071bd 8027298: broken link in jdk8b113 macosx binaries Reviewed-by: dcubed, ihse ! makefiles/Import.gmk Changeset: 62982664dc72 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/62982664dc72 Added tag jdk8-b114 for changeset f26a0c8071bd ! .hgtags From alejandro.murillo at oracle.com Fri Nov 1 13:51:12 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 01 Nov 2013 20:51:12 +0000 Subject: hg: hsx/hsx25/hotspot: 37 new changesets Message-ID: <20131101205237.2101C628F4@hg.openjdk.java.net> Changeset: e006d2e25bc7 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e006d2e25bc7 8025673: [macosx] Disable X11 AWT toolkit Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X Reviewed-by: dholmes Contributed-by: david.dehaven at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: 913a35723a0a Author: katleman Date: 2013-10-28 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/913a35723a0a Merge Changeset: 7fd913010dbb Author: katleman Date: 2013-10-29 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7fd913010dbb Merge Changeset: ddc3758f68db Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ddc3758f68db Added tag jdk8-b114 for changeset 7fd913010dbb ! .hgtags Changeset: f94a9f0746d8 Author: amurillo Date: 2013-10-25 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f94a9f0746d8 8027173: new hotspot build - hs25-b57 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e64f1fe9756b Author: farvidsson Date: 2013-10-24 10:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e64f1fe9756b 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes. Reviewed-by: coleenp, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp Changeset: d70a665e25d7 Author: iklam Date: 2013-10-24 22:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d70a665e25d7 8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9 Reviewed-by: dcubed, iveresov Contributed-by: gerard.ziemski at oracle.com ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: e4f478e7781b Author: jbachorik Date: 2013-10-25 09:07 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e4f478e7781b 8027294: Prepare hotspot for non TOD based uptime counter Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime. Reviewed-by: dholmes, sla ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: a6177f601c64 Author: hseigel Date: 2013-10-25 11:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a6177f601c64 8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space. Reviewed-by: stefank, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 634715d59d9e Author: hseigel Date: 2013-10-25 11:13 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/634715d59d9e Merge Changeset: 209aa13ab8c0 Author: coleenp Date: 2013-10-25 15:19 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/209aa13ab8c0 8024927: Nashorn performance regression with CompressedOops Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops Reviewed-by: stefank, hseigel, goetz ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CompressedOops/CompressedClassPointers.java Changeset: b4aa8fc5d0d5 Author: ccheung Date: 2013-10-25 22:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b4aa8fc5d0d5 Merge ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/memory/metaspace.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1a04de1aaedb Author: dsamersoff Date: 2013-10-28 21:41 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1a04de1aaedb 8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot Summary: Fixed two compilation-breaking nits Reviewed-by: sla, dholmes ! agent/src/os/bsd/ps_proc.c Changeset: 85730a185147 Author: ccheung Date: 2013-10-30 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85730a185147 Merge Changeset: 292050e5d5ea Author: dholmes Date: 2013-10-24 00:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/292050e5d5ea 8026877: Error in opening JAR file when invalid jar specified with -Xbootclasspath/a on OpenJDK build Reviewed-by: coleenp, twisti ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/thread.cpp Changeset: 066778844ed9 Author: jprovino Date: 2013-10-27 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/066778844ed9 Merge Changeset: f2f9139ccde9 Author: jprovino Date: 2013-10-30 16:06 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f2f9139ccde9 Merge Changeset: a007575ea726 Author: vladidan Date: 2013-10-30 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a007575ea726 Merge Changeset: 3b3133d93fb6 Author: brutisso Date: 2013-10-28 13:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3b3133d93fb6 8027132: Print deprecation warning message for the flags controlling the CMS foreground collector Reviewed-by: stefank, ehelin, ysr, tschatzl ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestCMSForegroundFlags.java Changeset: 6d965678f21e Author: ehelin Date: 2013-10-31 21:20 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6d965678f21e Merge Changeset: bd3237e0e18d Author: twisti Date: 2013-10-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bd3237e0e18d 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: jrose, roland ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/handles.cpp Changeset: cbe8ba0fb8fc Author: twisti Date: 2013-10-24 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cbe8ba0fb8fc Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: f01788f13696 Author: adlertz Date: 2013-10-25 10:13 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f01788f13696 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal Reviewed-by: roland ! src/share/vm/opto/postaloc.cpp Changeset: 7ae254fd0b3c Author: adlertz Date: 2013-10-25 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7ae254fd0b3c Merge Changeset: 6c2f07d1495f Author: roland Date: 2013-10-28 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6c2f07d1495f 8027140: Assertion in compiler when running bigapps/Kitchensink/stability Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced Reviewed-by: twisti, iveresov ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: bfdb530cdffa Author: roland Date: 2013-10-28 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bfdb530cdffa Merge Changeset: a196f1aaec86 Author: anoll Date: 2013-10-25 22:57 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a196f1aaec86 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Summary: Exit compiler threads early during startup so that wrong error message is not printed Reviewed-by: iveresov, twisti ! src/share/vm/compiler/compileBroker.cpp + test/compiler/startup/StartupOutput.java Changeset: 8c16f426dbb2 Author: iveresov Date: 2013-10-28 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8c16f426dbb2 Merge Changeset: fc1632f5021a Author: iveresov Date: 2013-10-28 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fc1632f5021a Merge Changeset: a57a165b8296 Author: rbackman Date: 2013-10-28 08:34 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a57a165b8296 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Reviewed-by: kvn, roland ! src/share/vm/opto/library_call.cpp ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Changeset: 60a32bb8ff99 Author: rbackman Date: 2013-10-30 13:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/60a32bb8ff99 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Reviewed-by: duke ! src/share/vm/opto/loopTransform.cpp + test/compiler/intrinsics/mathexact/NestedMathExactTest.java Changeset: 4d3575d37a07 Author: iveresov Date: 2013-10-30 22:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4d3575d37a07 8026735: Stream tests throw java.lang.IncompatibleClassChangeError Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1 Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp + test/compiler/inlining/InlineDefaultMethod.java Changeset: 946a8294ab15 Author: iveresov Date: 2013-10-31 04:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/946a8294ab15 8024919: G1: SPECjbb2013 crashes due to a broken object reference Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 2dcd0bd2920d Author: iveresov Date: 2013-10-31 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2dcd0bd2920d Merge Changeset: 0836a3c28c6a Author: iveresov Date: 2013-10-31 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0836a3c28c6a Merge Changeset: 3b32d287da89 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3b32d287da89 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: afd012c940e4 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/afd012c940e4 Added tag hs25-b57 for changeset 3b32d287da89 ! .hgtags From john.coomes at oracle.com Fri Nov 1 14:07:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 21:07:56 +0000 Subject: hg: hsx/hotspot-main/langtools: 76 new changesets Message-ID: <20131101211151.1E82B628F6@hg.openjdk.java.net> Changeset: 16194509e483 Author: vromero Date: 2013-09-27 10:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/16194509e483 8024497: crash returning this-referencing lambda from default method Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/lambda/8024497/CrashUsingReturningThisRefLambdaFromDefaultMetTest.java Changeset: b7d8b71e1658 Author: jlahoda Date: 2013-09-27 17:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b7d8b71e1658 8022765: Compiler crashes with exception on wrong usage of an annotation. Summary: Error recovery for incorrect annotation attribute values - ensure the values are always attributed appropriately Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/annotations/neg/8022765/T8022765.java + test/tools/javac/annotations/neg/8022765/T8022765.out + test/tools/javac/annotations/neg/8022765/VerifyAnnotationsAttributed.java Changeset: 2c24a04ebfb4 Author: kizune Date: 2013-09-27 21:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2c24a04ebfb4 6978886: javadoc shows stacktrace after print error resulting from disk full Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java Changeset: 699b86e82656 Author: sogoel Date: 2013-09-27 10:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/699b86e82656 8025537: Convert 2 javac/enumdeclarations tests in jtreg for regression ws Reviewed-by: jjg + test/tools/javac/enum/EnumAsIdentifier.java + test/tools/javac/enum/EnumAsIdentifier.out + test/tools/javac/enum/EnumAsIdentifier4.out + test/tools/javac/enum/EnumAsIdentifier5.out + test/tools/javac/enum/EnumMembersOrder.java + test/tools/javac/enum/EnumMembersOrder.out Changeset: 4ed8565fa536 Author: mduigou Date: 2013-09-27 11:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4ed8565fa536 8024842: Define ABS_TEST_OUTPUT_DIR via TEST_OUTPUT_DIR Reviewed-by: ihse, erikj, vromero ! test/Makefile Changeset: dee28dd47e12 Author: rfield Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dee28dd47e12 8025548: langtools test tools/javac/lambda/methodReference/BridgeMethod.java incorrectly assumes no other methods generated in lambda class Reviewed-by: vromero ! test/tools/javac/lambda/methodReference/BridgeMethod.java Changeset: 82044fe8c7f7 Author: ksrini Date: 2013-09-27 16:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/82044fe8c7f7 8015073: c.s.t.javac.api.JavacTool.getTask() - more informative exception Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! test/tools/javac/api/TestJavacTask.java Changeset: 34223fc58c1a Author: lana Date: 2013-09-27 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/34223fc58c1a Merge Changeset: 84161510f257 Author: emc Date: 2013-09-28 13:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/84161510f257 8025413: NPE in Type.java due to recent change Summary: isCompound throws a NPE for noType and other types. Made it return a reasonable result instead. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java + test/tools/javac/processing/model/type/InheritedAP.java Changeset: 1a3e8347f3dd Author: kizune Date: 2013-10-01 17:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1a3e8347f3dd 7118749: NPE in CreateSymbols caused by bad diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java Changeset: de1c5dbe6c28 Author: emc Date: 2013-10-01 17:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/de1c5dbe6c28 8021339: Compile-time error during casting array to intersection Summary: Add ability to have arrays in intersection types. Reviewed-by: jjg, vromero ! 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 + test/tools/javac/ArraysInIntersections.java + test/tools/javac/InferArraysInIntersections.java ! test/tools/javac/generics/typevars/6680106/T6680106.out Changeset: 1e6088da1740 Author: vromero Date: 2013-10-02 17:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1e6088da1740 8023679: Improve error message for '_' used as a lambda parameter name Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/UnderscoreInLambdaExpression.java Changeset: c13305cf8528 Author: jlahoda Date: 2013-10-04 08:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c13305cf8528 8025118: Annotation processing api returns default modifier for interface without default methods Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/processing/model/element/TestTypeElement.java Changeset: c0d44b1e6b6a Author: kizune Date: 2013-10-04 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c0d44b1e6b6a 7096170: should remove unused support for enabling javac logging Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 379c04c090cf Author: darcy Date: 2013-10-04 10:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/379c04c090cf 8025913: Rename jdk.Supported to jdk.Exported Reviewed-by: psandoz, forax, lancea, alanb, mchung, jjg ! 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/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocSourcePositions.java ! src/share/classes/com/sun/source/util/DocTreePath.java ! src/share/classes/com/sun/source/util/DocTreePathScanner.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/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java + src/share/classes/jdk/Exported.java - src/share/classes/jdk/Supported.java Changeset: 6e186ca11ec0 Author: bpatel Date: 2013-10-04 13:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6e186ca11ec0 8008164: Invisible table captions in javadoc-generated html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.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/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.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/internal/toolkit/resources/stylesheet.css + test/com/sun/javadoc/testHtmlTableStyles/TestHtmlTableStyles.java + test/com/sun/javadoc/testHtmlTableStyles/pkg1/TestTable.java + test/com/sun/javadoc/testHtmlTableStyles/pkg2/TestUse.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: 3344ea7404b1 Author: bpatel Date: 2013-10-04 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3344ea7404b1 8024756: method grouping tabs are not selectable Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java Changeset: 2fa6ced325cc Author: jjg Date: 2013-10-04 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2fa6ced325cc 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/errors/TestBadProcessor.java Changeset: 515d54c1b063 Author: jjg Date: 2013-10-04 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/515d54c1b063 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/javax/tools/Diagnostic.java Changeset: 3e3c321710be Author: jjg Date: 2013-10-04 15:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3e3c321710be 8025970: Spurious characters in JavaCompiler Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: bb87db832b31 Author: ksrini Date: 2013-10-04 16:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bb87db832b31 8003537: javap use internal class name when printing bound of type variable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/BoundsTypeVariableTest.java Changeset: 15651a673358 Author: ksrini Date: 2013-10-04 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/15651a673358 8005542: jtreg test OverrideBridge.java contains @ignore Reviewed-by: jjg Contributed-by: steve.sides at oracle.com - test/tools/javac/generics/OverrideBridge.java Changeset: 4dd7ffbf01fb Author: darcy Date: 2013-10-07 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4dd7ffbf01fb 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java Changeset: 4dfcf3a6902f Author: lana Date: 2013-10-08 14:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4dfcf3a6902f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: 2f43529df42f Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2f43529df42f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: 343aeb2033f0 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/343aeb2033f0 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 954dd199d6ff Author: katleman Date: 2013-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/954dd199d6ff Merge Changeset: 8f54b4231c28 Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8f54b4231c28 Added tag jdk8-b112 for changeset 954dd199d6ff ! .hgtags Changeset: ea000904db62 Author: alundblad Date: 2013-10-08 15:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ea000904db62 8024415: Bug in javac Pretty: Wrong precedence in JCConditional trees Summary: Fixed precedence and associativity issues with pretty printing of JCConditional expressions. Reviewed-by: jfranck Contributed-by: Andreas Lundblad , Matthew Dempsky ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/T8024415.java Changeset: 0be3f1820e8b Author: jlahoda Date: 2013-10-09 13:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0be3f1820e8b 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) Summary: Should not generate non-public $assertionsDisabled field into interfaces Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/defaultMethods/Assertions.java + test/tools/javac/defaultMethods/CannotChangeAssertionsStateAfterInitialized.java Changeset: 1b469fd31e35 Author: jlahoda Date: 2013-10-09 13:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1b469fd31e35 8025087: Annotation processing api returns default modifier for interface static method Summary: ClassReader must not set Flags.DEFAULT for interface static methods Reviewed-by: vromero, jjg ! make/build.xml ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java + test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java + test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java + test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/processing/model/element/TestExecutableElement.java Changeset: 1e7ad879f15e Author: alundblad Date: 2013-10-10 08:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1e7ad879f15e 8021237: clean up JavacAnnotatedConstruct Summary: Refactored the static helper methods in JavacAnnoConstructs into ordinary methods and put them in a common superclass (AnnoConstruct) of Symbol and Type. Reviewed-by: jjg, vromero, jfranck + src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java - src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java Changeset: 933ba3f81a87 Author: bpatel Date: 2013-10-10 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/933ba3f81a87 8025633: Fix javadoc to generate valid anchor names Reviewed-by: jjg ! 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/AnnotationTypeFieldWriterImpl.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/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/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/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/SectionName.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java + test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java + test/com/sun/javadoc/testAnchorNames/pkg1/DeprMemClass.java + test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java ! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java Changeset: 6dcf94e32a3a Author: emc Date: 2013-10-10 13:55 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6dcf94e32a3a 8019461: Clean up javac diagnostics 7196553: Review error messages for repeating annotations Summary: Changes to the diagnostic messages to improve clarity and JLS coherence Reviewed-by: jjg ! 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/resources/compiler.properties - test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/InterfaceOrArrayExpected.java + test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java Changeset: b1b4a6dcc282 Author: emc Date: 2013-10-10 20:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b1b4a6dcc282 8008762: Type annotation on inner class in anonymous class show up as regular type annotations 8015257: type annotation with TYPE_USE and FIELD attributed differently if repeated. 8013409: test failures for type annotations Summary: Fixes to address some problems in type annotations Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java + test/tools/javac/annotations/typeAnnotations/classfile/testanoninner.template ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java Changeset: f068d235c4f7 Author: jjg Date: 2013-10-10 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f068d235c4f7 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Reviewed-by: darcy ! test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Changeset: 8f293c710369 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8f293c710369 Merge Changeset: bf33f4f81b40 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bf33f4f81b40 Merge - test/tools/javac/diags/examples/DuplicateAnnotation.java Changeset: 1ce8405af5fe Author: rfield Date: 2013-10-10 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1ce8405af5fe 8012557: Implement lambda methods on interfaces as private 8016320: Method reference in subinterface of type I.super::foo produces exception at runtime Summary: Now that the VM supports interface instance private methods, lambda methods and lambda bridges are always private. Access is now through invokespecial. Reviewed-by: vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/8012557/A.java + test/tools/javac/lambda/8012557/B.java + test/tools/javac/lambda/8012557/C.java + test/tools/javac/lambda/8012557/PrivateLambdas.java + test/tools/javac/lambda/8012557/SAM.java + test/tools/javac/lambda/8016320/IllegalBridgeModifier.java Changeset: 872c4a898b38 Author: jlahoda Date: 2013-10-11 15:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/872c4a898b38 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Reviewed-by: darcy, jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.out Changeset: f329c374da4b Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f329c374da4b Merge Changeset: b024fe427d24 Author: jjg Date: 2013-10-14 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b024fe427d24 8026368: doclint does not report empty tags when tag closed implicitly Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out Changeset: 87b5bfef7edb Author: jlahoda Date: 2013-10-14 22:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/87b5bfef7edb 8014016: javac is too late detecting invalid annotation usage Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter Reviewed-by: jjg, emc, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.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/MemberEnter.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateFunctionalInterface.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Processor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Source.java Changeset: b9e3b55a908c Author: jjg Date: 2013-10-14 16:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b9e3b55a908c 8026371: "tidy" issues in langtools/src/**/*.html files Reviewed-by: darcy + src/share/classes/com/sun/javadoc/package-info.java - src/share/classes/com/sun/javadoc/package.html + src/share/classes/com/sun/tools/classfile/package-info.java - src/share/classes/com/sun/tools/classfile/package.html + src/share/classes/com/sun/tools/doclets/formats/html/markup/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html + src/share/classes/com/sun/tools/doclets/formats/html/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html + src/share/classes/com/sun/tools/doclets/package-info.java - src/share/classes/com/sun/tools/doclets/package.html + src/share/classes/com/sun/tools/javap/package-info.java - src/share/classes/com/sun/tools/javap/package.html ! src/share/classes/javax/lang/model/overview.html ! src/share/classes/javax/tools/overview.html Changeset: 7d266a2b31b2 Author: jjg Date: 2013-10-14 22:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7d266a2b31b2 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javadoc/8025693/Test.java Changeset: 09a414673570 Author: jjg Date: 2013-10-14 23:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/09a414673570 8025998: Missing LV table in lambda bodies Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/lambda/LocalVariableTable.java Changeset: 79649bf21a92 Author: jlahoda Date: 2013-10-15 16:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/79649bf21a92 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java + test/tools/javac/tree/NoPrivateTypesExported.java Changeset: bf6b11347b1a Author: bpatel Date: 2013-10-15 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bf6b11347b1a 8026370: javadoc creates empty Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java + test/com/sun/javadoc/testTagOutput/TestTagOutput.java + test/com/sun/javadoc/testTagOutput/pkg1/DeprecatedTag.java Changeset: 70a301b35e71 Author: vromero Date: 2013-10-15 19:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/70a301b35e71 8025816: javac crash with method reference with a type variable as the site Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/T8025816/CrashMethodReferenceWithSiteTypeVarTest.java Changeset: d8d6b58f1ebf Author: vromero Date: 2013-10-15 21:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d8d6b58f1ebf 8024947: javac should issue the potentially ambiguous overload warning only where the problem appears Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.out Changeset: 84df20dc604a Author: bpatel Date: 2013-07-24 15:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/84df20dc604a 8016675: Make Javadoc pages more robust Reviewed-by: jlaskey, ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + test/com/sun/javadoc/testWindowTitle/TestWindowTitle.java + test/com/sun/javadoc/testWindowTitle/p1/C1.java + test/com/sun/javadoc/testWindowTitle/p2/C2.java Changeset: 8b3e2cc5f1de Author: chegar Date: 2013-07-25 19:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8b3e2cc5f1de Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0d75d3b96477 Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0d75d3b96477 Merge Changeset: 2d1a54d213c2 Author: chegar Date: 2013-08-09 14:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2d1a54d213c2 Merge Changeset: 84b6d75ff2c9 Author: chegar Date: 2013-08-15 21:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/84b6d75ff2c9 Merge Changeset: a540e2a926cf Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a540e2a926cf Merge Changeset: a8f0c3583a86 Author: chegar Date: 2013-08-30 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a8f0c3583a86 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 6250a7f0aba6 Author: chegar Date: 2013-09-06 10:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6250a7f0aba6 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java Changeset: a6901af8a2e4 Author: chegar Date: 2013-09-14 20:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a6901af8a2e4 Merge Changeset: 2c13a5da6854 Author: chegar Date: 2013-10-03 19:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2c13a5da6854 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java - src/share/classes/com/sun/tools/javac/code/Annotations.java - test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej - test/tools/javac/lambda/TargetType10.out - test/tools/javac/lambda/typeInference/InferenceTest5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out Changeset: 86e57f576e65 Author: chegar Date: 2013-10-11 19:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/86e57f576e65 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java Changeset: 46feacb99698 Author: chegar Date: 2013-10-15 14:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/46feacb99698 Merge - src/share/classes/com/sun/javadoc/package.html - src/share/classes/com/sun/tools/classfile/package.html - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html - src/share/classes/com/sun/tools/doclets/formats/html/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html - src/share/classes/com/sun/tools/doclets/package.html - src/share/classes/com/sun/tools/javap/package.html Changeset: 90c9ae4bc756 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/90c9ae4bc756 Merge Changeset: dd073728085d Author: chegar Date: 2013-10-15 21:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dd073728085d Merge Changeset: 19e8eebfbe52 Author: jlahoda Date: 2013-10-15 22:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/19e8eebfbe52 8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing Summary: A mostly automated rename Annotate.Annotator->Annotate.Worker and enterAnnotation->run. Reviewed-by: emc, jjg ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.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/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: b0c086cd4520 Author: jjg Date: 2013-10-15 15:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b0c086cd4520 8026564: import changes from type-annotations forest Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.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/Lower.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/T7042623.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.java ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java - test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/OldArray.out ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out - test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateScoping.java + test/tools/javac/diags/examples/CantAnnotateScoping1.java - test/tools/javac/diags/examples/CantAnnotateStaticClass.java ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java Changeset: d7e155f874a7 Author: jjg Date: 2013-10-16 10:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d7e155f874a7 8026704: Build failure with --enable-debug Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - test/tools/javac/lambda/LocalVariableTable.java Changeset: 7f6481e5fe3a Author: emc Date: 2013-10-16 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7f6481e5fe3a 8026286: Improper locking of annotation queues causes assertion failures. 8026063: Calls to annotate.flush() cause incorrect type annotations to be generated. Summary: Fix locking in ClassReader.java Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/annotations/typeAnnotations/TestAnonInnerInstance1.java ! test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java Changeset: a48d3b981083 Author: mnunez Date: 2013-10-17 13:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a48d3b981083 8015372: Update tests for Method Parameter Reflection API to check whether a parameter is final Reviewed-by: jjg, jfranck ! test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnnotationTest.out ! test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AnonymousClass.out ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/Constructors.out ! test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/EnumTest.out ! test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/InstanceMethods.out ! test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LambdaTest.out ! test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/LocalClassTest.out ! test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.out ! test/tools/javac/MethodParameters/ReflectionVisitor.java ! test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/StaticMethods.out ! test/tools/javac/MethodParameters/Tester.java ! test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParameters/UncommonParamNames.out Changeset: 4d8af6fda907 Author: mnunez Date: 2013-10-17 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4d8af6fda907 8008192: Better ordering checks needed in repeatingAnnotations/combo/ReflectionTest Reviewed-by: jjg, jfranck ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java Changeset: defadd528513 Author: mchung Date: 2013-10-17 13:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/defadd528513 8015912: jdeps support to output in dot file format 8026255: Switch jdeps to follow traditional Java option style Reviewed-by: alanb ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/Profile.java - src/share/classes/com/sun/tools/jdeps/Profiles.java ! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java ! test/tools/jdeps/Test.java + test/tools/jdeps/b/B.java + test/tools/jdeps/c/C.java + test/tools/jdeps/c/I.java + test/tools/jdeps/d/D.java + test/tools/jdeps/e/E.java + test/tools/jdeps/f/F.java + test/tools/jdeps/g/G.java + test/tools/jdeps/m/Bar.java + test/tools/jdeps/m/Foo.java + test/tools/jdeps/m/Gee.java Changeset: bca97b47f0a2 Author: lana Date: 2013-10-17 16:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bca97b47f0a2 Merge Changeset: 127c2e74d2cf Author: tbell Date: 2013-10-22 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/127c2e74d2cf 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 54150586ba78 Author: katleman Date: 2013-10-23 08:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/54150586ba78 Merge Changeset: 850d2602ae98 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/850d2602ae98 Added tag jdk8-b113 for changeset 54150586ba78 ! .hgtags Changeset: fea486d30d41 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fea486d30d41 Added tag jdk8-b114 for changeset 850d2602ae98 ! .hgtags From john.coomes at oracle.com Fri Nov 1 14:12:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Nov 2013 21:12:01 +0000 Subject: hg: hsx/hotspot-main/nashorn: 51 new changesets Message-ID: <20131101211250.AFA6F628F7@hg.openjdk.java.net> Changeset: 982dd6e1bf4f Author: lana Date: 2013-09-27 18:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/982dd6e1bf4f Merge Changeset: 2016a6b9e1f3 Author: hannesw Date: 2013-09-27 16:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2016a6b9e1f3 8025515: Performance issues with Source.getLine() Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/Source.java + test/script/basic/JDK-8025515.js Changeset: 1809c9e97c71 Author: hannesw Date: 2013-09-27 17:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1809c9e97c71 8025520: Array.prototype.slice should only copy defined elements Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8025520.js Changeset: efc40aacaee4 Author: hannesw Date: 2013-09-30 15:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/efc40aacaee4 8025589: Array.prototype.shift should only copy defined elements in generic mode Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8025589.js Changeset: ad5f9ce2a95b Author: jlaskey Date: 2013-09-30 10:24 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ad5f9ce2a95b Merge Changeset: 787e36fdf69a Author: jlaskey Date: 2013-09-30 12:06 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/787e36fdf69a Merge Changeset: 7272ec90f2c6 Author: sundar Date: 2013-09-30 21:33 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7272ec90f2c6 8025629: load function should support a way to load scripts from classpath Reviewed-by: lagergren, hannesw, attila ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java + test/script/trusted/JDK-8025629.js + test/src/jdk/nashorn/internal/runtime/resources/load_test.js Changeset: f5aefbe76cec Author: jlaskey Date: 2013-09-30 18:09 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f5aefbe76cec 8025689: fx:base.js classes not loading Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/base.js Changeset: cd7fb58043cb Author: sundar Date: 2013-10-01 14:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/cd7fb58043cb 8025488: Error.captureStackTrace should not format error stack Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8025488.js + test/script/basic/JDK-8025488.js.EXPECTED Changeset: 3470bc26128f Author: sundar Date: 2013-10-04 16:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3470bc26128f 8025771: Enhance Nashorn Contexts Reviewed-by: jlaskey, hannesw - make/java.security.override ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! test/script/basic/JDK-8023026.js + test/script/sandbox/arrayclass.js + test/script/sandbox/arrayclass.js.EXPECTED Changeset: 6345d08fd5de Author: hannesw Date: 2013-10-08 11:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6345d08fd5de 8025213: Assignment marks variable as defined too early Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025213.js + test/script/basic/JDK-8025213.js.EXPECTED Changeset: 8c326f8c6799 Author: sundar Date: 2013-10-08 13:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8c326f8c6799 8026033: Switch should load expression even when there are no cases in it Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026033.js + test/script/basic/JDK-8026033.js.EXPECTED Changeset: 025e2ff9e91b Author: hannesw Date: 2013-10-08 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/025e2ff9e91b 8025965: Specialized functions with same weight replace each other in TreeSet Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 19dba6637f20 Author: sundar Date: 2013-10-08 14:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/19dba6637f20 8026039: future strict names are allowed as function name and argument name of a strict function Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/error/JDK-8026039.js + test/script/error/JDK-8026039.js.EXPECTED Changeset: c9921761903b Author: hannesw Date: 2013-10-08 15:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/c9921761903b 8026042: FoldConstants need to guard against ArrayLiteralNode Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8026042.js + test/script/basic/JDK-8026042.js.EXPECTED Changeset: 346ba5b8a488 Author: sundar Date: 2013-10-08 16:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/346ba5b8a488 8026048: Function constructor should convert arguments to String before performing any syntax checks Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeFunction.java + test/script/basic/JDK-8026048.js Changeset: 3551855c4f40 Author: lana Date: 2013-10-08 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3551855c4f40 Merge - make/java.security.override Changeset: b48b719c5efc Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b48b719c5efc Merge - make/java.security.override Changeset: 45399f3ef717 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/45399f3ef717 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildNashorn.gmk ! makefiles/Makefile Changeset: 6a4fdb3bb4e3 Author: katleman Date: 2013-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6a4fdb3bb4e3 Merge Changeset: 103590fc1e0a Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/103590fc1e0a Added tag jdk8-b112 for changeset 6a4fdb3bb4e3 ! .hgtags Changeset: 8d29733ad609 Author: sundar Date: 2013-10-09 10:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8d29733ad609 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026112.js Changeset: 1e03d7caa68b Author: sundar Date: 2013-10-09 13:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1e03d7caa68b 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8026125.js Changeset: ec3094d9d5d5 Author: hannesw Date: 2013-10-09 14:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ec3094d9d5d5 8026008: Constant folding removes var statement Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8026008.js + test/script/basic/JDK-8026008.js.EXPECTED Changeset: 03a68e7ca1d5 Author: lagergren Date: 2013-10-09 17:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/03a68e7ca1d5 8026137: Fix Issues with Binary Evaluation Order Reviewed-by: hannesw, jlaskey Contributed-by: marcus.lagergren at oracle.com, attila.szegedi at oracle.com ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java - src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8026137.js + test/script/basic/JDK-8026137.js.EXPECTED Changeset: 7cc5ff16380f Author: sundar Date: 2013-10-10 11:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7cc5ff16380f 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/script/assert.js ! test/script/basic/JDK-8019508.js ! test/script/basic/JDK-8019508.js.EXPECTED ! test/script/basic/JDK-8019553.js ! test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/JDK-8019791.js ! test/script/basic/JDK-8019791.js.EXPECTED ! test/script/basic/JDK-8019805.js ! test/script/basic/JDK-8019805.js.EXPECTED + test/script/basic/JDK-8026167.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-100.js.EXPECTED ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-293.js.EXPECTED ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-40.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-98.js.EXPECTED ! test/script/basic/eval.js ! test/script/basic/eval.js.EXPECTED Changeset: e60bbcf2f6b6 Author: sundar Date: 2013-10-10 13:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e60bbcf2f6b6 8026248: importClass has to be a varargs function Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026248.js + test/script/basic/JDK-8026248.js.EXPECTED Changeset: f6263ae511c2 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f6263ae511c2 Merge Changeset: 34f7a699cdef Author: sundar Date: 2013-10-10 14:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/34f7a699cdef 8026162: "this" in SAM adapter functions is wrong Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java + test/script/basic/JDK-8026162.js Changeset: ed3da7a574a0 Author: lagergren Date: 2013-10-10 16:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ed3da7a574a0 8026250: Logging nullpointer bugfix and javadoc warnings Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java Changeset: a781ea074521 Author: sundar Date: 2013-10-10 21:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a781ea074521 8026264: Getter, setter function name mangling issues Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8026264.js Changeset: 375c2f2d41c8 Author: sundar Date: 2013-10-11 06:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/375c2f2d41c8 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Reviewed-by: jlaskey ! test/script/basic/JDK-8025488.js Changeset: 56be5161f0d2 Author: sundar Date: 2013-10-11 09:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/56be5161f0d2 Merge Changeset: 1c154cee43d9 Author: hannesw Date: 2013-10-11 10:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1c154cee43d9 8026292: Megamorphic setter fails with boolean value Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8026292.js Changeset: fb091f9052a6 Author: sundar Date: 2013-10-11 11:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fb091f9052a6 8026302: source representation of getter and setter methods is wrong Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8026302.js + test/script/basic/JDK-8026302.js.EXPECTED ! test/script/basic/objects.js.EXPECTED Changeset: 062579f50371 Author: sundar Date: 2013-10-11 14:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/062579f50371 8026317: $ in the function name results in wrong function being invoked Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/Namespace.java + test/script/basic/JDK-8026317.js + test/script/basic/JDK-8026317.js.EXPECTED Changeset: b35d175207f6 Author: sundar Date: 2013-10-11 14:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b35d175207f6 Merge Changeset: 1b0a71a9920a Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1b0a71a9920a Merge Changeset: 6cb4f20d971f Author: jlaskey Date: 2013-10-11 14:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6cb4f20d971f 8026309: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 8c617a092d68 Author: hannesw Date: 2013-10-14 11:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8c617a092d68 8026016: too many relinks dominate avatar.js http benchmark Reviewed-by: sundar, jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026016.js + test/script/basic/JDK-8026016.js.EXPECTED Changeset: d155c4a7703c Author: attila Date: 2013-10-14 12:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d155c4a7703c 8026113: Nashorn arrays should automatically convert to Java arrays Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: 64e841576c68 Author: attila Date: 2013-10-15 15:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/64e841576c68 8026397: Fix ambiguity with array conversion, including passing JS NativeArrays in Java variable arity methods' vararg array position Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/messages.properties ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: aa452eb4a5d0 Author: hannesw Date: 2013-10-15 17:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/aa452eb4a5d0 8026367: Add a sync keyword to mozilla_compat Reviewed-by: sundar, attila, lagergren ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026367.js ! test/script/sandbox/loadcompat.js Changeset: b3ee112a328e Author: jlaskey Date: 2013-10-15 13:14 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b3ee112a328e 8026498: Revert: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 9a13e95cc40f Author: sundar Date: 2013-10-15 22:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9a13e95cc40f Merge Changeset: 1899da5c71d3 Author: hannesw Date: 2013-10-16 10:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1899da5c71d3 8026692: eval() throws NullPointerException with --compile-only Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/JDK-8026692.js Changeset: 2d5f9f77c199 Author: hannesw Date: 2013-10-16 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2d5f9f77c199 8026693: getType() called on DISCARD node Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java + test/script/basic/JDK-8026693.js Changeset: adc5639fc4b9 Author: sundar Date: 2013-10-17 13:02 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/adc5639fc4b9 Merge Changeset: 676cd7bf5e09 Author: lana Date: 2013-10-17 16:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/676cd7bf5e09 Merge Changeset: 79f7b79bf97b Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/79f7b79bf97b Added tag jdk8-b113 for changeset 676cd7bf5e09 ! .hgtags Changeset: f109bb255b80 Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f109bb255b80 Added tag jdk8-b114 for changeset 79f7b79bf97b ! .hgtags From alejandro.murillo at oracle.com Fri Nov 1 18:24:54 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 02 Nov 2013 01:24:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20131102012512.785946291B@hg.openjdk.java.net> Changeset: e006d2e25bc7 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e006d2e25bc7 8025673: [macosx] Disable X11 AWT toolkit Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X Reviewed-by: dholmes Contributed-by: david.dehaven at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: 913a35723a0a Author: katleman Date: 2013-10-28 16:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/913a35723a0a Merge Changeset: 7fd913010dbb Author: katleman Date: 2013-10-29 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7fd913010dbb Merge Changeset: ddc3758f68db Author: cl Date: 2013-10-31 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ddc3758f68db Added tag jdk8-b114 for changeset 7fd913010dbb ! .hgtags Changeset: 3b32d287da89 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b32d287da89 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: afd012c940e4 Author: amurillo Date: 2013-11-01 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/afd012c940e4 Added tag hs25-b57 for changeset 3b32d287da89 ! .hgtags Changeset: 5b84039ca739 Author: amurillo Date: 2013-11-01 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5b84039ca739 8027580: new hotspot build - hs25-b58 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Sat Nov 2 00:24:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Nov 2013 17:24:01 +1000 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <52747344.8080807@oracle.com> References: <52747344.8080807@oracle.com> Message-ID: <5274A891.3020105@oracle.com> Hi Henry, Looks to me like the script that tries to hack the -j option has messed up: -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 -en/ws/tl/common/makefiles Note the -j3 which seems to have been inserted into the middle of /hjen/ws ... David On 2/11/2013 1:36 PM, Henry Jen wrote: > Hi, > > I am trying to setup build environment on a new installation, and > encounter following build error. > > I suspect this is because of missing some required tools and software, > however, the error message is not helpful. > > Tried to echo the make commang used, but as you can see the output seems > to be scrambled. Is there a way to find out what exact command causing > problem? I tried to configure --with-jobs=1, that doesn't help. > > The Gnu make version is 4.0, let me know what else information I can > collect to help diagnosis the problem. > > Cheers, > Henry > > >> >> INFO: ZIP_DEBUGINFO_FILES=1 >> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >> -I/home/hjen/ws/tl/common/makefiles >> -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >> /usr/bin/make: invalid option -- '/' >> /usr/bin/make: invalid option -- '/' >> Usage: make [options] [target] ... >> Options: >> -b, -m Ignored for compatibility. >> -B, --always-make Unconditionally make all targets. >> -C DIRECTORY, --directory=DIRECTORY >> Change to DIRECTORY before doing anything. >> -d Print lots of debugging information. >> --debug[=FLAGS] Print various types of debugging >> information. >> -e, --environment-overrides >> Environment variables override makefiles. >> --eval=STRING Evaluate STRING as a makefile statement. >> -f FILE, --file=FILE, --makefile=FILE >> Read FILE as a makefile. >> -h, --help Print this message and exit. >> -i, --ignore-errors Ignore errors from recipes. >> -I DIRECTORY, --include-dir=DIRECTORY >> Search DIRECTORY for included makefiles. >> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with >> no arg. >> -k, --keep-going Keep going when some targets can't be made. >> -l [N], --load-average[=N], --max-load[=N] >> Don't start multiple jobs unless load is >> below N. >> -L, --check-symlink-times Use the latest mtime between symlinks >> and target. >> -n, --just-print, --dry-run, --recon >> Don't actually run any recipe; just >> print them. >> -o FILE, --old-file=FILE, --assume-old=FILE >> Consider FILE to be very old and don't >> remake it. >> -O[TYPE], --output-sync[=TYPE] >> Synchronize output of parallel jobs by >> TYPE. >> -p, --print-data-base Print make's internal database. >> -q, --question Run no recipe; exit status says if up to >> date. >> -r, --no-builtin-rules Disable the built-in implicit rules. >> -R, --no-builtin-variables Disable the built-in variable settings. >> -s, --silent, --quiet Don't echo recipes. >> -S, --no-keep-going, --stop >> Turns off -k. >> -t, --touch Touch targets instead of remaking them. >> --trace Print tracing information. >> -v, --version Print the version number of make and exit. >> -w, --print-directory Print the current directory. >> --no-print-directory Turn off -w, even if it was turned on >> implicitly. >> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >> Consider FILE to be infinitely new. >> --warn-undefined-variables Warn when an undefined variable is >> referenced. >> >> This program built for x86_64-unknown-linux-gnu >> Report bugs to >> make[5]: *** [ad_stuff] Error 2 >> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >> target 'ad_stuff' failed >> make[4]: *** [product] Error 2 >> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >> 'product' failed >> make[3]: *** [generic_build2] Error 2 >> Makefile:216: recipe for target 'generic_build2' failed >> make[2]: *** [product] Error 2 >> Makefile:167: recipe for target 'product' failed >> make[1]: *** >> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> HotspotWrapper.gmk:44: recipe for target >> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >> failed >> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >> target 'hotspot-only' failed >> make: *** [hotspot-only] Error 2 From daniel.daugherty at oracle.com Sat Nov 2 08:14:35 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 02 Nov 2013 11:14:35 -0400 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <5274A891.3020105@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> Message-ID: <527516DB.2090106@oracle.com> > The Gnu make version is 4.0, I'm pretty sure the OpenJDK builds don't work on any version of GNUMake newer than 3.81. Checkout this version: $ ls -l /java/devtools/linux/bin/make381 -rwxrwxr-x 1 nobody nobody 635027 Sep 16 2009 /java/devtools/linux/bin/make381 Dan On 11/2/13 3:24 AM, David Holmes wrote: > Hi Henry, > > Looks to me like the script that tries to hack the -j option has > messed up: > > -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h > -j3 -en/ws/tl/common/makefiles > > Note the -j3 which seems to have been inserted into the middle of > /hjen/ws ... > > David > > On 2/11/2013 1:36 PM, Henry Jen wrote: >> Hi, >> >> I am trying to setup build environment on a new installation, and >> encounter following build error. >> >> I suspect this is because of missing some required tools and software, >> however, the error message is not helpful. >> >> Tried to echo the make commang used, but as you can see the output seems >> to be scrambled. Is there a way to find out what exact command causing >> problem? I tried to configure --with-jobs=1, that doesn't help. >> >> The Gnu make version is 4.0, let me know what else information I can >> collect to help diagnosis the problem. >> >> Cheers, >> Henry >> >> >>> >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>> -I/home/hjen/ws/tl/common/makefiles >>> -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>> /usr/bin/make: invalid option -- '/' >>> /usr/bin/make: invalid option -- '/' >>> Usage: make [options] [target] ... >>> Options: >>> -b, -m Ignored for compatibility. >>> -B, --always-make Unconditionally make all targets. >>> -C DIRECTORY, --directory=DIRECTORY >>> Change to DIRECTORY before doing >>> anything. >>> -d Print lots of debugging information. >>> --debug[=FLAGS] Print various types of debugging >>> information. >>> -e, --environment-overrides >>> Environment variables override makefiles. >>> --eval=STRING Evaluate STRING as a makefile statement. >>> -f FILE, --file=FILE, --makefile=FILE >>> Read FILE as a makefile. >>> -h, --help Print this message and exit. >>> -i, --ignore-errors Ignore errors from recipes. >>> -I DIRECTORY, --include-dir=DIRECTORY >>> Search DIRECTORY for included makefiles. >>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with >>> no arg. >>> -k, --keep-going Keep going when some targets can't be >>> made. >>> -l [N], --load-average[=N], --max-load[=N] >>> Don't start multiple jobs unless load is >>> below N. >>> -L, --check-symlink-times Use the latest mtime between symlinks >>> and target. >>> -n, --just-print, --dry-run, --recon >>> Don't actually run any recipe; just >>> print them. >>> -o FILE, --old-file=FILE, --assume-old=FILE >>> Consider FILE to be very old and don't >>> remake it. >>> -O[TYPE], --output-sync[=TYPE] >>> Synchronize output of parallel jobs by >>> TYPE. >>> -p, --print-data-base Print make's internal database. >>> -q, --question Run no recipe; exit status says if up to >>> date. >>> -r, --no-builtin-rules Disable the built-in implicit rules. >>> -R, --no-builtin-variables Disable the built-in variable settings. >>> -s, --silent, --quiet Don't echo recipes. >>> -S, --no-keep-going, --stop >>> Turns off -k. >>> -t, --touch Touch targets instead of remaking them. >>> --trace Print tracing information. >>> -v, --version Print the version number of make and >>> exit. >>> -w, --print-directory Print the current directory. >>> --no-print-directory Turn off -w, even if it was turned on >>> implicitly. >>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>> Consider FILE to be infinitely new. >>> --warn-undefined-variables Warn when an undefined variable is >>> referenced. >>> >>> This program built for x86_64-unknown-linux-gnu >>> Report bugs to >>> make[5]: *** [ad_stuff] Error 2 >>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>> target 'ad_stuff' failed >>> make[4]: *** [product] Error 2 >>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>> 'product' failed >>> make[3]: *** [generic_build2] Error 2 >>> Makefile:216: recipe for target 'generic_build2' failed >>> make[2]: *** [product] Error 2 >>> Makefile:167: recipe for target 'product' failed >>> make[1]: *** >>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>> >>> Error 2 >>> HotspotWrapper.gmk:44: recipe for target >>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>> >>> failed >>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>> target 'hotspot-only' failed >>> make: *** [hotspot-only] Error 2 From erik.joelsson at oracle.com Mon Nov 4 01:37:04 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Nov 2013 10:37:04 +0100 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <527516DB.2090106@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <527516DB.2090106@oracle.com> Message-ID: <52776AC0.3030005@oracle.com> On 2013-11-02 16:14, Daniel D. Daugherty wrote: > > The Gnu make version is 4.0, > > I'm pretty sure the OpenJDK builds don't work on any version of > GNUMake newer than 3.81. Checkout this version: > Actually, we have been using 3.81, 3.82 and 3.82.* for a long while depending on platform. We recently made the version check accept 4.0 since Cygwin installs it by default now and it works on that platform. > $ ls -l /java/devtools/linux/bin/make381 > -rwxrwxr-x 1 nobody nobody 635027 Sep 16 2009 > /java/devtools/linux/bin/make381 > This should work as a workaround until we get to the bottom of this. /Erik > Dan > > > On 11/2/13 3:24 AM, David Holmes wrote: >> Hi Henry, >> >> Looks to me like the script that tries to hack the -j option has >> messed up: >> >> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >> -j3 -en/ws/tl/common/makefiles >> >> Note the -j3 which seems to have been inserted into the middle of >> /hjen/ws ... >> >> David >> >> On 2/11/2013 1:36 PM, Henry Jen wrote: >>> Hi, >>> >>> I am trying to setup build environment on a new installation, and >>> encounter following build error. >>> >>> I suspect this is because of missing some required tools and software, >>> however, the error message is not helpful. >>> >>> Tried to echo the make commang used, but as you can see the output >>> seems >>> to be scrambled. Is there a way to find out what exact command causing >>> problem? I tried to configure --with-jobs=1, that doesn't help. >>> >>> The Gnu make version is 4.0, let me know what else information I can >>> collect to help diagnosis the problem. >>> >>> Cheers, >>> Henry >>> >>> >>>> >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>> -I/home/hjen/ws/tl/common/makefiles >>>> -I/home/hjen/ws/tl/common/makefiles >>>> -I/home/hjen/ws/tl/common/makefiles >>>> /usr/bin/make: invalid option -- '/' >>>> /usr/bin/make: invalid option -- '/' >>>> Usage: make [options] [target] ... >>>> Options: >>>> -b, -m Ignored for compatibility. >>>> -B, --always-make Unconditionally make all targets. >>>> -C DIRECTORY, --directory=DIRECTORY >>>> Change to DIRECTORY before doing >>>> anything. >>>> -d Print lots of debugging information. >>>> --debug[=FLAGS] Print various types of debugging >>>> information. >>>> -e, --environment-overrides >>>> Environment variables override >>>> makefiles. >>>> --eval=STRING Evaluate STRING as a makefile statement. >>>> -f FILE, --file=FILE, --makefile=FILE >>>> Read FILE as a makefile. >>>> -h, --help Print this message and exit. >>>> -i, --ignore-errors Ignore errors from recipes. >>>> -I DIRECTORY, --include-dir=DIRECTORY >>>> Search DIRECTORY for included makefiles. >>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with >>>> no arg. >>>> -k, --keep-going Keep going when some targets can't be >>>> made. >>>> -l [N], --load-average[=N], --max-load[=N] >>>> Don't start multiple jobs unless load is >>>> below N. >>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>> and target. >>>> -n, --just-print, --dry-run, --recon >>>> Don't actually run any recipe; just >>>> print them. >>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>> Consider FILE to be very old and don't >>>> remake it. >>>> -O[TYPE], --output-sync[=TYPE] >>>> Synchronize output of parallel jobs by >>>> TYPE. >>>> -p, --print-data-base Print make's internal database. >>>> -q, --question Run no recipe; exit status says if up to >>>> date. >>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>> -s, --silent, --quiet Don't echo recipes. >>>> -S, --no-keep-going, --stop >>>> Turns off -k. >>>> -t, --touch Touch targets instead of remaking them. >>>> --trace Print tracing information. >>>> -v, --version Print the version number of make and >>>> exit. >>>> -w, --print-directory Print the current directory. >>>> --no-print-directory Turn off -w, even if it was turned on >>>> implicitly. >>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>> Consider FILE to be infinitely new. >>>> --warn-undefined-variables Warn when an undefined variable is >>>> referenced. >>>> >>>> This program built for x86_64-unknown-linux-gnu >>>> Report bugs to >>>> make[5]: *** [ad_stuff] Error 2 >>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>> target 'ad_stuff' failed >>>> make[4]: *** [product] Error 2 >>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>> 'product' failed >>>> make[3]: *** [generic_build2] Error 2 >>>> Makefile:216: recipe for target 'generic_build2' failed >>>> make[2]: *** [product] Error 2 >>>> Makefile:167: recipe for target 'product' failed >>>> make[1]: *** >>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>> >>>> Error 2 >>>> HotspotWrapper.gmk:44: recipe for target >>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>> >>>> failed >>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>> target 'hotspot-only' failed >>>> make: *** [hotspot-only] Error 2 > From erik.joelsson at oracle.com Mon Nov 4 01:38:21 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Nov 2013 10:38:21 +0100 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <5274AA2C.2070901@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> <5274AA2C.2070901@oracle.com> Message-ID: <52776B0D.7050308@oracle.com> This seems to be make 4.0 specific. I saw the same error when trying a home built make 4.0 on Solaris the other day (for a completely different reason so I didn't pursue the problem). We will investigate. /Erik On 2013-11-02 08:30, Henry Jen wrote: > What I don't understand(misleading me) is that my previous Ubuntu > setup has same directory structure, but not seeing this problem. > > Cheers, > Henry > > On 11/02/2013 12:27 AM, Henry Jen wrote: >> Yes, I just verified that's the result of sed. Following patch fix it. >> I don't quite understand why we need that line. >> >> Cheers, >> Henry >> >> diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh >> --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 >> -0700 >> +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 >> -0700 >> @@ -64,7 +64,6 @@ >> echo "$MFLAGS" \ >> | sed ' >> s/^-/ -/ >> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >> s/ -j[0-9][0-9]*/ -j/ >> s/ -j\([^ ]\)/ -j -\1/ >> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >> >> >> On 11/02/2013 12:24 AM, David Holmes wrote: >>> Hi Henry, >>> >>> Looks to me like the script that tries to hack the -j option has >>> messed up: >>> >>> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>> -j3 >>> -en/ws/tl/common/makefiles >>> >>> Note the -j3 which seems to have been inserted into the middle of >>> /hjen/ws ... >>> >>> David >>> >>> On 2/11/2013 1:36 PM, Henry Jen wrote: >>>> Hi, >>>> >>>> I am trying to setup build environment on a new installation, and >>>> encounter following build error. >>>> >>>> I suspect this is because of missing some required tools and software, >>>> however, the error message is not helpful. >>>> >>>> Tried to echo the make commang used, but as you can see the output >>>> seems >>>> to be scrambled. Is there a way to find out what exact command causing >>>> problem? I tried to configure --with-jobs=1, that doesn't help. >>>> >>>> The Gnu make version is 4.0, let me know what else information I can >>>> collect to help diagnosis the problem. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>>> >>>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>>> -I/home/hjen/ws/tl/common/makefiles >>>>> -I/home/hjen/ws/tl/common/makefiles >>>>> -I/home/hjen/ws/tl/common/makefiles >>>>> /usr/bin/make: invalid option -- '/' >>>>> /usr/bin/make: invalid option -- '/' >>>>> Usage: make [options] [target] ... >>>>> Options: >>>>> -b, -m Ignored for compatibility. >>>>> -B, --always-make Unconditionally make all targets. >>>>> -C DIRECTORY, --directory=DIRECTORY >>>>> Change to DIRECTORY before doing >>>>> anything. >>>>> -d Print lots of debugging information. >>>>> --debug[=FLAGS] Print various types of debugging >>>>> information. >>>>> -e, --environment-overrides >>>>> Environment variables override >>>>> makefiles. >>>>> --eval=STRING Evaluate STRING as a makefile >>>>> statement. >>>>> -f FILE, --file=FILE, --makefile=FILE >>>>> Read FILE as a makefile. >>>>> -h, --help Print this message and exit. >>>>> -i, --ignore-errors Ignore errors from recipes. >>>>> -I DIRECTORY, --include-dir=DIRECTORY >>>>> Search DIRECTORY for included >>>>> makefiles. >>>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs >>>>> with >>>>> no arg. >>>>> -k, --keep-going Keep going when some targets can't be >>>>> made. >>>>> -l [N], --load-average[=N], --max-load[=N] >>>>> Don't start multiple jobs unless >>>>> load is >>>>> below N. >>>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>>> and target. >>>>> -n, --just-print, --dry-run, --recon >>>>> Don't actually run any recipe; just >>>>> print them. >>>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>>> Consider FILE to be very old and don't >>>>> remake it. >>>>> -O[TYPE], --output-sync[=TYPE] >>>>> Synchronize output of parallel jobs by >>>>> TYPE. >>>>> -p, --print-data-base Print make's internal database. >>>>> -q, --question Run no recipe; exit status says if >>>>> up to >>>>> date. >>>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>>> -s, --silent, --quiet Don't echo recipes. >>>>> -S, --no-keep-going, --stop >>>>> Turns off -k. >>>>> -t, --touch Touch targets instead of remaking them. >>>>> --trace Print tracing information. >>>>> -v, --version Print the version number of make and >>>>> exit. >>>>> -w, --print-directory Print the current directory. >>>>> --no-print-directory Turn off -w, even if it was turned on >>>>> implicitly. >>>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>>> Consider FILE to be infinitely new. >>>>> --warn-undefined-variables Warn when an undefined variable is >>>>> referenced. >>>>> >>>>> This program built for x86_64-unknown-linux-gnu >>>>> Report bugs to >>>>> make[5]: *** [ad_stuff] Error 2 >>>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>>> target 'ad_stuff' failed >>>>> make[4]: *** [product] Error 2 >>>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>>> 'product' failed >>>>> make[3]: *** [generic_build2] Error 2 >>>>> Makefile:216: recipe for target 'generic_build2' failed >>>>> make[2]: *** [product] Error 2 >>>>> Makefile:167: recipe for target 'product' failed >>>>> make[1]: *** >>>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>>> >>>>> >>>>> >>>>> Error 2 >>>>> HotspotWrapper.gmk:44: recipe for target >>>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>>> >>>>> >>>>> >>>>> failed >>>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>>> target 'hotspot-only' failed >>>>> make: *** [hotspot-only] Error 2 From erik.joelsson at oracle.com Tue Nov 5 04:27:27 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Nov 2013 13:27:27 +0100 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <52788DB1.1070300@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> <5274AA2C.2070901@oracle.com> <52776B0D.7050308@oracle.com> <52788DB1.1070300@oracle.com> Message-ID: <5278E42F.9030108@oracle.com> So this only happens in hotspot because of make/linux/makefiles/adjust-mflags.sh. I would suggest this change to fix it. It adds -I to a set of options that cannot be combined with -j sharing the same dash (since -I requires an argument). diff -r ddc3758f68db make/linux/makefiles/adjust-mflags.sh --- a/make/linux/makefiles/adjust-mflags.sh +++ b/make/linux/makefiles/adjust-mflags.sh @@ -64,7 +64,7 @@ echo "$MFLAGS" \ | sed ' s/^-/ -/ - s/ -\([^ ][^ ]*\)j/ -\1 -j/ + s/ -\([^ I][^ ]*\)j/ -\1 -j/ s/ -j[0-9][0-9]*/ -j/ s/ -j\([^ ]\)/ -j -\1/ s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ /Erik On 2013-11-05 07:18, Henry Jen wrote: > Yes, GNU make 4.0 change the format of MFLAGS so that there is no > longer space between -I and folder. > > Cheers, > Henry > > > On 11/04/2013 01:38 AM, Erik Joelsson wrote: >> This seems to be make 4.0 specific. I saw the same error when trying a >> home built make 4.0 on Solaris the other day (for a completely different >> reason so I didn't pursue the problem). >> >> We will investigate. >> >> /Erik >> >> On 2013-11-02 08:30, Henry Jen wrote: >>> What I don't understand(misleading me) is that my previous Ubuntu >>> setup has same directory structure, but not seeing this problem. >>> >>> Cheers, >>> Henry >>> >>> On 11/02/2013 12:27 AM, Henry Jen wrote: >>>> Yes, I just verified that's the result of sed. Following patch fix it. >>>> I don't quite understand why we need that line. >>>> >>>> Cheers, >>>> Henry >>>> >>>> diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh >>>> --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 >>>> 2013 >>>> -0700 >>>> +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 >>>> 2013 >>>> -0700 >>>> @@ -64,7 +64,6 @@ >>>> echo "$MFLAGS" \ >>>> | sed ' >>>> s/^-/ -/ >>>> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >>>> s/ -j[0-9][0-9]*/ -j/ >>>> s/ -j\([^ ]\)/ -j -\1/ >>>> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >>>> >>>> >>>> On 11/02/2013 12:24 AM, David Holmes wrote: >>>>> Hi Henry, >>>>> >>>>> Looks to me like the script that tries to hack the -j option has >>>>> messed up: >>>>> >>>>> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>>>> -j3 >>>>> -en/ws/tl/common/makefiles >>>>> >>>>> Note the -j3 which seems to have been inserted into the middle of >>>>> /hjen/ws ... >>>>> >>>>> David >>>>> >>>>> On 2/11/2013 1:36 PM, Henry Jen wrote: >>>>>> Hi, >>>>>> >>>>>> I am trying to setup build environment on a new installation, and >>>>>> encounter following build error. >>>>>> >>>>>> I suspect this is because of missing some required tools and >>>>>> software, >>>>>> however, the error message is not helpful. >>>>>> >>>>>> Tried to echo the make commang used, but as you can see the output >>>>>> seems >>>>>> to be scrambled. Is there a way to find out what exact command >>>>>> causing >>>>>> problem? I tried to configure --with-jobs=1, that doesn't help. >>>>>> >>>>>> The Gnu make version is 4.0, let me know what else information I can >>>>>> collect to help diagnosis the problem. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> >>>>>>> >>>>>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>>>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>>>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>>>>>> -j3 >>>>>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>> Usage: make [options] [target] ... >>>>>>> Options: >>>>>>> -b, -m Ignored for compatibility. >>>>>>> -B, --always-make Unconditionally make all targets. >>>>>>> -C DIRECTORY, --directory=DIRECTORY >>>>>>> Change to DIRECTORY before doing >>>>>>> anything. >>>>>>> -d Print lots of debugging information. >>>>>>> --debug[=FLAGS] Print various types of debugging >>>>>>> information. >>>>>>> -e, --environment-overrides >>>>>>> Environment variables override >>>>>>> makefiles. >>>>>>> --eval=STRING Evaluate STRING as a makefile >>>>>>> statement. >>>>>>> -f FILE, --file=FILE, --makefile=FILE >>>>>>> Read FILE as a makefile. >>>>>>> -h, --help Print this message and exit. >>>>>>> -i, --ignore-errors Ignore errors from recipes. >>>>>>> -I DIRECTORY, --include-dir=DIRECTORY >>>>>>> Search DIRECTORY for included >>>>>>> makefiles. >>>>>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs >>>>>>> with >>>>>>> no arg. >>>>>>> -k, --keep-going Keep going when some targets can't be >>>>>>> made. >>>>>>> -l [N], --load-average[=N], --max-load[=N] >>>>>>> Don't start multiple jobs unless >>>>>>> load is >>>>>>> below N. >>>>>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>>>>> and target. >>>>>>> -n, --just-print, --dry-run, --recon >>>>>>> Don't actually run any recipe; just >>>>>>> print them. >>>>>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>>>>> Consider FILE to be very old and >>>>>>> don't >>>>>>> remake it. >>>>>>> -O[TYPE], --output-sync[=TYPE] >>>>>>> Synchronize output of parallel >>>>>>> jobs by >>>>>>> TYPE. >>>>>>> -p, --print-data-base Print make's internal database. >>>>>>> -q, --question Run no recipe; exit status says if >>>>>>> up to >>>>>>> date. >>>>>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>>>>> -R, --no-builtin-variables Disable the built-in variable >>>>>>> settings. >>>>>>> -s, --silent, --quiet Don't echo recipes. >>>>>>> -S, --no-keep-going, --stop >>>>>>> Turns off -k. >>>>>>> -t, --touch Touch targets instead of remaking >>>>>>> them. >>>>>>> --trace Print tracing information. >>>>>>> -v, --version Print the version number of make and >>>>>>> exit. >>>>>>> -w, --print-directory Print the current directory. >>>>>>> --no-print-directory Turn off -w, even if it was turned on >>>>>>> implicitly. >>>>>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>>>>> Consider FILE to be infinitely new. >>>>>>> --warn-undefined-variables Warn when an undefined variable is >>>>>>> referenced. >>>>>>> >>>>>>> This program built for x86_64-unknown-linux-gnu >>>>>>> Report bugs to >>>>>>> make[5]: *** [ad_stuff] Error 2 >>>>>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: >>>>>>> recipe for >>>>>>> target 'ad_stuff' failed >>>>>>> make[4]: *** [product] Error 2 >>>>>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>>>>> 'product' failed >>>>>>> make[3]: *** [generic_build2] Error 2 >>>>>>> Makefile:216: recipe for target 'generic_build2' failed >>>>>>> make[2]: *** [product] Error 2 >>>>>>> Makefile:167: recipe for target 'product' failed >>>>>>> make[1]: *** >>>>>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Error 2 >>>>>>> HotspotWrapper.gmk:44: recipe for target >>>>>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> failed >>>>>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>>>>> target 'hotspot-only' failed >>>>>>> make: *** [hotspot-only] Error 2 >> From niclas.adlertz at oracle.com Tue Nov 5 04:45:13 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 05 Nov 2013 13:45:13 +0100 Subject: CFV: New hotspot Group Member: Rickard =?ISO-8859-1?Q?B=E4ckman?= Message-ID: <5278E859.4070906@oracle.com> I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to Membership in the hotspot Group. Rickard is an Oracle engineer, working for the compiler team. He has been working in the HotSpot team since 2010. Rickard is a Committer in the HotSpot project and has currently contributed 32 changes. Votes are due by Tuesday, November 19, 2013. Only current Members of the hotspot Group [1] 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 [2]. Kind Regards, Niclas Adlertz [1] http://openjdk.java.net/census/#hotspot [2] http://openjdk.java.net/groups/#member-vote From roland.westrelin at oracle.com Tue Nov 5 05:07:37 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Nov 2013 14:07:37 +0100 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A_Rickard_?= =?iso-8859-1?Q?B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: Vote: yes Roland. From bengt.rutisson at oracle.com Tue Nov 5 05:08:39 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Nov 2013 14:08:39 +0100 Subject: =?ISO-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A?= =?ISO-8859-1?Q?_Rickard_B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <5278EDD7.2030902@oracle.com> Vote: yes Bengt On 11/5/13 1:45 PM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to > Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has > been working in the HotSpot team since 2010. Rickard is a Committer in > the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Tue Nov 5 05:38:29 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Nov 2013 14:38:29 +0100 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A_Rickard_B=C3=A4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: Vote: yes On Tue, Nov 5, 2013 at 1:45 PM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to > Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has been > working in the HotSpot team since 2010. Rickard is a Committer in the > HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From karen.kinnear at oracle.com Tue Nov 5 05:42:52 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 5 Nov 2013 08:42:52 -0500 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A_Rickard_?= =?iso-8859-1?Q?B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: Vote: yes On Nov 5, 2013, at 7:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has been working in the HotSpot team since 2010. Rickard is a Committer in the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From zhengyu.gu at oracle.com Tue Nov 5 05:56:52 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 05 Nov 2013 08:56:52 -0500 Subject: =?ISO-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A?= =?ISO-8859-1?Q?_Rickard_B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <5278F924.8050007@oracle.com> Vote: yes -Zhengyu On 11/5/2013 7:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to > Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has > been working in the HotSpot team since 2010. Rickard is a Committer in > the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Tue Nov 5 06:28:18 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 05 Nov 2013 09:28:18 -0500 Subject: =?ISO-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A?= =?ISO-8859-1?Q?_Rickard_B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <52790082.1060509@oracle.com> Vote: yes Dan On 11/5/13 7:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to > Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has > been working in the HotSpot team since 2010. Rickard is a Committer in > the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > > From coleen.phillimore at oracle.com Tue Nov 5 07:21:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Tue, 05 Nov 2013 10:21:01 -0500 Subject: =?ISO-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A?= =?ISO-8859-1?Q?_Rickard_B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <52790CDD.9080700@oracle.com> Vote: yes On 11/5/2013 7:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to > Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has > been working in the HotSpot team since 2010. Rickard is a Committer in > the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From erik.joelsson at oracle.com Tue Nov 5 08:31:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Nov 2013 17:31:54 +0100 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <8E86C732-FADF-4938-B83E-91123AB4BA6F@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> <5274AA2C.2070901@oracle.com> <52776B0D.7050308@oracle.com> <52788DB1.1070300@oracle.com> <5278E42F.9030108@oracle.com> <8E86C732-FADF-4938-B83E-91123AB4BA6F@oracle.com> Message-ID: <52791D7A.3070908@oracle.com> You are right, that would be more correct. /Erik On 2013-11-05 17:13, Henry Jen wrote: > +1, that would work. > > I just wondering if it?s better to have I in both bracket to be tolerant to case like -RsI, although it?s not a problem now, but that seems legal options to me. > > Cheers, > Henry > > On Nov 5, 2013, at 4:27 AM, Erik Joelsson wrote: > >> So this only happens in hotspot because of make/linux/makefiles/adjust-mflags.sh. I would suggest this change to fix it. It adds -I to a set of options that cannot be combined with -j sharing the same dash (since -I requires an argument). >> >> diff -r ddc3758f68db make/linux/makefiles/adjust-mflags.sh >> --- a/make/linux/makefiles/adjust-mflags.sh >> +++ b/make/linux/makefiles/adjust-mflags.sh >> @@ -64,7 +64,7 @@ >> echo "$MFLAGS" \ >> | sed ' >> s/^-/ -/ >> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >> + s/ -\([^ I][^ ]*\)j/ -\1 -j/ >> s/ -j[0-9][0-9]*/ -j/ >> s/ -j\([^ ]\)/ -j -\1/ >> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >> >> /Erik >> >> On 2013-11-05 07:18, Henry Jen wrote: >>> Yes, GNU make 4.0 change the format of MFLAGS so that there is no longer space between -I and folder. >>> >>> Cheers, >>> Henry >>> >>> >>> On 11/04/2013 01:38 AM, Erik Joelsson wrote: >>>> This seems to be make 4.0 specific. I saw the same error when trying a >>>> home built make 4.0 on Solaris the other day (for a completely different >>>> reason so I didn't pursue the problem). >>>> >>>> We will investigate. >>>> >>>> /Erik >>>> >>>> On 2013-11-02 08:30, Henry Jen wrote: >>>>> What I don't understand(misleading me) is that my previous Ubuntu >>>>> setup has same directory structure, but not seeing this problem. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> On 11/02/2013 12:27 AM, Henry Jen wrote: >>>>>> Yes, I just verified that's the result of sed. Following patch fix it. >>>>>> I don't quite understand why we need that line. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh >>>>>> --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 >>>>>> -0700 >>>>>> +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 >>>>>> -0700 >>>>>> @@ -64,7 +64,6 @@ >>>>>> echo "$MFLAGS" \ >>>>>> | sed ' >>>>>> s/^-/ -/ >>>>>> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >>>>>> s/ -j[0-9][0-9]*/ -j/ >>>>>> s/ -j\([^ ]\)/ -j -\1/ >>>>>> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >>>>>> >>>>>> >>>>>> On 11/02/2013 12:24 AM, David Holmes wrote: >>>>>>> Hi Henry, >>>>>>> >>>>>>> Looks to me like the script that tries to hack the -j option has >>>>>>> messed up: >>>>>>> >>>>>>> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>>>>>> -j3 >>>>>>> -en/ws/tl/common/makefiles >>>>>>> >>>>>>> Note the -j3 which seems to have been inserted into the middle of >>>>>>> /hjen/ws ... >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 2/11/2013 1:36 PM, Henry Jen wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am trying to setup build environment on a new installation, and >>>>>>>> encounter following build error. >>>>>>>> >>>>>>>> I suspect this is because of missing some required tools and software, >>>>>>>> however, the error message is not helpful. >>>>>>>> >>>>>>>> Tried to echo the make commang used, but as you can see the output >>>>>>>> seems >>>>>>>> to be scrambled. Is there a way to find out what exact command causing >>>>>>>> problem? I tried to configure --with-jobs=1, that doesn't help. >>>>>>>> >>>>>>>> The Gnu make version is 4.0, let me know what else information I can >>>>>>>> collect to help diagnosis the problem. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Henry >>>>>>>> >>>>>>>> >>>>>>>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>>>>>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>>>>>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>>>>>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>>>> Usage: make [options] [target] ... >>>>>>>>> Options: >>>>>>>>> -b, -m Ignored for compatibility. >>>>>>>>> -B, --always-make Unconditionally make all targets. >>>>>>>>> -C DIRECTORY, --directory=DIRECTORY >>>>>>>>> Change to DIRECTORY before doing >>>>>>>>> anything. >>>>>>>>> -d Print lots of debugging information. >>>>>>>>> --debug[=FLAGS] Print various types of debugging >>>>>>>>> information. >>>>>>>>> -e, --environment-overrides >>>>>>>>> Environment variables override >>>>>>>>> makefiles. >>>>>>>>> --eval=STRING Evaluate STRING as a makefile >>>>>>>>> statement. >>>>>>>>> -f FILE, --file=FILE, --makefile=FILE >>>>>>>>> Read FILE as a makefile. >>>>>>>>> -h, --help Print this message and exit. >>>>>>>>> -i, --ignore-errors Ignore errors from recipes. >>>>>>>>> -I DIRECTORY, --include-dir=DIRECTORY >>>>>>>>> Search DIRECTORY for included >>>>>>>>> makefiles. >>>>>>>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs >>>>>>>>> with >>>>>>>>> no arg. >>>>>>>>> -k, --keep-going Keep going when some targets can't be >>>>>>>>> made. >>>>>>>>> -l [N], --load-average[=N], --max-load[=N] >>>>>>>>> Don't start multiple jobs unless >>>>>>>>> load is >>>>>>>>> below N. >>>>>>>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>>>>>>> and target. >>>>>>>>> -n, --just-print, --dry-run, --recon >>>>>>>>> Don't actually run any recipe; just >>>>>>>>> print them. >>>>>>>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>>>>>>> Consider FILE to be very old and don't >>>>>>>>> remake it. >>>>>>>>> -O[TYPE], --output-sync[=TYPE] >>>>>>>>> Synchronize output of parallel jobs by >>>>>>>>> TYPE. >>>>>>>>> -p, --print-data-base Print make's internal database. >>>>>>>>> -q, --question Run no recipe; exit status says if >>>>>>>>> up to >>>>>>>>> date. >>>>>>>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>>>>>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>>>>>>> -s, --silent, --quiet Don't echo recipes. >>>>>>>>> -S, --no-keep-going, --stop >>>>>>>>> Turns off -k. >>>>>>>>> -t, --touch Touch targets instead of remaking them. >>>>>>>>> --trace Print tracing information. >>>>>>>>> -v, --version Print the version number of make and >>>>>>>>> exit. >>>>>>>>> -w, --print-directory Print the current directory. >>>>>>>>> --no-print-directory Turn off -w, even if it was turned on >>>>>>>>> implicitly. >>>>>>>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>>>>>>> Consider FILE to be infinitely new. >>>>>>>>> --warn-undefined-variables Warn when an undefined variable is >>>>>>>>> referenced. >>>>>>>>> >>>>>>>>> This program built for x86_64-unknown-linux-gnu >>>>>>>>> Report bugs to >>>>>>>>> make[5]: *** [ad_stuff] Error 2 >>>>>>>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>>>>>>> target 'ad_stuff' failed >>>>>>>>> make[4]: *** [product] Error 2 >>>>>>>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>>>>>>> 'product' failed >>>>>>>>> make[3]: *** [generic_build2] Error 2 >>>>>>>>> Makefile:216: recipe for target 'generic_build2' failed >>>>>>>>> make[2]: *** [product] Error 2 >>>>>>>>> Makefile:167: recipe for target 'product' failed >>>>>>>>> make[1]: *** >>>>>>>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Error 2 >>>>>>>>> HotspotWrapper.gmk:44: recipe for target >>>>>>>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> failed >>>>>>>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>>>>>>> target 'hotspot-only' failed >>>>>>>>> make: *** [hotspot-only] Error 2 From vladimir.kozlov at oracle.com Tue Nov 5 09:05:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Nov 2013 09:05:33 -0800 Subject: =?ISO-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A?= =?ISO-8859-1?Q?_Rickard_B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <5279255D.50300@oracle.com> Vote: yes On 11/5/13 4:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has been working in the HotSpot team since 2010. > Rickard is a Committer in the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From martijnverburg at gmail.com Tue Nov 5 10:23:56 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 5 Nov 2013 18:23:56 +0000 Subject: JavaFX log analyser & visualiser of Hotspot JIT Message-ID: Hi all, Thought I'd bring some attention to a pretty cool tool started by Chris Newland which he's kindly donated to the Adopt OpenJDK GitHub org. It's a JavaFX tool for analysing PrintCompilationDetail logs and visualising some of the compilation behaviour. https://github.com/AdoptOpenJDK/jitwatch Cheers, Martijn From david.holmes at oracle.com Tue Nov 5 13:01:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Nov 2013 07:01:26 +1000 Subject: =?ISO-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A?= =?ISO-8859-1?Q?_Rickard_B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <52795CA6.3090705@oracle.com> Vote: yes David On 5/11/2013 10:45 PM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to > Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has > been working in the HotSpot team since 2010. Rickard is a Committer in > the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From igor.veresov at oracle.com Tue Nov 5 15:43:49 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Nov 2013 15:43:49 -0800 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A_Rickard_?= =?iso-8859-1?Q?B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <3D91575B-367E-4202-8A99-DECB66757F1E@oracle.com> Vote: yes On Nov 5, 2013, at 4:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has been working in the HotSpot team since 2010. Rickard is a Committer in the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From john.r.rose at oracle.com Tue Nov 5 19:54:47 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Nov 2013 19:54:47 -0800 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A_Rickard_?= =?iso-8859-1?Q?B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <3B4760BC-0DAB-420A-A05E-4C8528E405E1@oracle.com> Vote: yes! From bengt.rutisson at oracle.com Wed Nov 6 07:57:47 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Nov 2013 16:57:47 +0100 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <527A66FB.8060001@oracle.com> On 2013-11-06 16:48, Bengt Rutisson wrote: > I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to > Membership in the HotSpot Group. Copy-n-paste error. Jesper's OpenJDK user name is jwilhelm. Bengt > > Jesper is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Jesper is a Committer in the > HotSpot project and has currently contributed 14 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From bengt.rutisson at oracle.com Wed Nov 6 06:54:40 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Nov 2013 15:54:40 +0100 Subject: CFV: New hotspot Group Member: Erik Helin Message-ID: <527A5830.9050703@oracle.com> I hereby nominate Erik Helin (OpenJDK user name: ehelin) to Membership in the HotSpot Group. Erik is an Oracle engineer, working for the GC team. He has been working in the HotSpot team since 2012. Erik is a Committer in the HotSpot project and has currently contributed 31 changes. Votes are due by Wednesday, November 20, 2013. Only current Members of the HotSpot Group [1] 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 [2]. Kind Regards, Bengt [1] http://openjdk.java.net/census/#hotspot [2] http://openjdk.java.net/groups/#member-vote From bengt.rutisson at oracle.com Wed Nov 6 07:48:23 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Nov 2013 16:48:23 +0100 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson Message-ID: <527A64C7.1030502@oracle.com> I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to Membership in the HotSpot Group. Jesper is an Oracle engineer, working for the GC team. He has been working in the HotSpot team since 2010. Jesper is a Committer in the HotSpot project and has currently contributed 14 changes. Votes are due by Wednesday, November 20, 2013. Only current Members of the HotSpot Group [1] 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 [2]. Kind Regards, Bengt [1] http://openjdk.java.net/census/#hotspot [2] http://openjdk.java.net/groups/#member-vote From bengt.rutisson at oracle.com Wed Nov 6 06:52:45 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Nov 2013 15:52:45 +0100 Subject: CFV: New hotspot Group Member: Mikael Gerdin Message-ID: <527A57BD.4020504@oracle.com> I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to Membership in the HotSpot Group. Mikael is an Oracle engineer, working for the GC team. He has been working in the HotSpot team since 2010. Mikael is a Committer in the HotSpot project and has currently contributed 24 changes. Votes are due by Wednesday, November 20, 2013. Only current Members of the HotSpot Group [1] 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 [2]. Kind Regards, Bengt [1] http://openjdk.java.net/census/#hotspot [2] http://openjdk.java.net/groups/#member-vote From bengt.rutisson at oracle.com Wed Nov 6 07:59:28 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Nov 2013 16:59:28 +0100 Subject: CFV: New hotspot Group Member: Thomas Schatzl Message-ID: <527A6760.7030101@oracle.com> I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to Membership in the HotSpot Group. Thomas is an Oracle engineer, working for the GC team. He has been working in the HotSpot team since early 2013. Thomas is a Committer in the HotSpot project and has currently contributed 28 changes. Votes are due by Wednesday, November 20, 2013. Only current Members of the HotSpot Group [1] 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 [2]. Kind Regards, Bengt [1] http://openjdk.java.net/census/#hotspot [2] http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Wed Nov 6 10:03:10 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Nov 2013 19:03:10 +0100 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: Vote: yes On Wed, Nov 6, 2013 at 3:52 PM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to Membership > in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been working > in the HotSpot team since 2010. Mikael is a Committer in the HotSpot project > and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Wed Nov 6 10:03:34 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Nov 2013 19:03:34 +0100 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: Vote: yes On Wed, Nov 6, 2013 at 4:59 PM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to Membership > in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been working > in the HotSpot team since early 2013. Thomas is a Committer in the HotSpot > project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Wed Nov 6 10:20:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Nov 2013 10:20:48 -0800 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <527A8880.3020804@oracle.com> Vote: yes On 11/6/13 7:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to > Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since early 2013. Thomas is a Committer in > the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Wed Nov 6 10:22:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Nov 2013 10:22:00 -0800 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <527A88C8.1020902@oracle.com> Vote: yes On 11/6/13 6:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to > Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Mikael is a Committer in the > HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Wed Nov 6 13:37:18 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 06 Nov 2013 16:37:18 -0500 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <527AB68E.4050300@oracle.com> Vote: yes On 11/6/2013 9:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to > Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Mikael is a Committer in the > HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Wed Nov 6 13:37:36 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 06 Nov 2013 16:37:36 -0500 Subject: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527A5830.9050703@oracle.com> References: <527A5830.9050703@oracle.com> Message-ID: <527AB6A0.9030104@oracle.com> Vote: yes On 11/6/2013 9:54 AM, Bengt Rutisson wrote: > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to Membership > in the HotSpot Group. > > Erik is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2012. Erik is a Committer in the > HotSpot project and has currently contributed 31 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Wed Nov 6 13:37:52 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 06 Nov 2013 16:37:52 -0500 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <527AB6B0.3080803@oracle.com> Vote: yes On 11/6/2013 10:48 AM, Bengt Rutisson wrote: > I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to > Membership in the HotSpot Group. > > Jesper is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Jesper is a Committer in the > HotSpot project and has currently contributed 14 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Wed Nov 6 13:38:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Wed, 06 Nov 2013 16:38:11 -0500 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <527AB6C3.4020506@oracle.com> Vote: yes On 11/6/2013 10:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to > Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since early 2013. Thomas is a Committer in > the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From markus.gronlund at oracle.com Wed Nov 6 14:06:55 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Wed, 06 Nov 2013 22:06:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20131106220713.0F822623DF@hg.openjdk.java.net> Changeset: ea79ab313e98 Author: mgerdin Date: 2013-10-30 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea79ab313e98 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Summary: Use 2-byte loads to load indexes from the byte code stream to avoid out of bounds reads. Reviewed-by: coleenp, sspitsyn ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: fdd464c8d62e Author: acorn Date: 2013-10-30 09:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fdd464c8d62e 8027304: Lambda: inheriting abstract + 1 default -> default, not ICCE Reviewed-by: hseigel, zgu ! src/share/vm/classfile/defaultMethods.cpp Changeset: 4fe7815b04f5 Author: acorn Date: 2013-10-30 09:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4fe7815b04f5 Merge Changeset: c8fc12209830 Author: coleenp Date: 2013-10-31 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c8fc12209830 8027616: Off by one error in putback for compressed oops nashorn performance improvement Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other. Reviewed-by: stefank, hseigel, zgu ! src/share/vm/memory/metaspace.cpp Changeset: 910026b800b8 Author: coleenp Date: 2013-11-01 10:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/910026b800b8 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodHandle 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. Reviewed-by: sspitsyn, ehelin, sla ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 42790b7e4d48 Author: mgronlun Date: 2013-11-01 15:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/42790b7e4d48 Merge ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: f8b56489e455 Author: mgronlun Date: 2013-11-01 17:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f8b56489e455 Merge Changeset: 04df110c8655 Author: mgronlun Date: 2013-11-02 20:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/04df110c8655 Merge From igor.veresov at oracle.com Wed Nov 6 14:14:49 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 6 Nov 2013 14:14:49 -0800 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: Vote: yes igor On Nov 6, 2013, at 6:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been working in the HotSpot team since 2010. Mikael is a Committer in the HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From igor.veresov at oracle.com Wed Nov 6 14:15:18 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 6 Nov 2013 14:15:18 -0800 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: Vote: yes igor On Nov 6, 2013, at 7:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been working in the HotSpot team since early 2013. Thomas is a Committer in the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Wed Nov 6 14:33:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Nov 2013 14:33:52 -0800 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> Message-ID: <527AC3D0.4080201@oracle.com> Hi, Volker I finished the sync. Hotspot passed clean. JDK passed builds and testing on our platforms with few known failures (2 javac regression tests TypeInferenceComboTest.java and DefaultMethodsTest.java). Yes, I did not expect they will do such global cleanup so later in the game for jdk8: https://bugs.openjdk.java.net/browse/JDK-8001931 http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 Syncing more frequent will not help with such big changes. I only hope it will not happen again in near future until we merge PPC64 code into main forest. As I said I did my best to resolve conflicts and, I think, the only problem left is AIX changes in makefiles/CompileNativeLibraries.gmk which you need to move to new makefiles/lib/*.gmk files. File a bug "PPC64: 8025715 changes broke AIX build after sync" and send me the fix. I will have to verify JDK build on our platforms with it. I am fine with resolving easy conflicts and leaving hard one to you :) Regards, Vladimir PS: even mailing system freak-out :) -------------------------------------------------------------- Your mail to 'ppc-aix-port-dev' with the subject hg: ppc-aix-port/stage/jdk: 740 new changesets Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 456885 bytes with a limit of 400 KB -------------------------------------------------------------- On 11/6/13 8:35 AM, Volker Simonis wrote: > Hi Vladimir, > > thank you for starting syncing again! > > Please see my comments inline: > > On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov > wrote: >> I was not able to resolve all conflicts. AIX build is definitely broken. >> >> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >> indention). >> >> I had problem with common/autoconf/platform.m4 when resolving conflicts at >> the end of file (below "Make compilation sanity check"). And for >> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >> >> ppc64 repo: >> >> ADDED_CFLAGS=" ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >> ADDED_CXXFLAGS=" ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >> ADDED_LDFLAGS=" ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >> > > Yes, this is the right way how it should be done now that we have > ${COMPILER_TARGET_BITS_FLAG} > >> jdk8 repo: >> >> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >> >> >> Merging toolchain.m4 was even more painful. >> >> An other one was jdk/makefiles/CompileLaunchers.gmk >> >> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. Code from >> it was moved into jdk/makefiles/lib files: >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >> >> I was not able to do anything there. It definitely broke AIX build so you >> need to implement it again. Sorry. > > Well, works as expected:( > > I know no good way how we could solve these problems (apart from > integration shared changes more early into the main repositories of > course). > > I could of course offer to do the merge such that all the AIX changes > would still be good. But how could I share a merge change with you? > Would you like to get only the files which I had to resolve manually? > Or better all the files which are changed by the merge? You could then > merge, copy my files over the sources and do the remaining resolving > in the closed directories. > > What do you think, should we try it this way next time? > >> >> I started JDK and Hotspot JPRT test runs. If they passed I will push what I >> have and then you need to fix it for AIX. >> > > I'm ready to start... > >> Regards, >> Vladimir >> From jon.masamitsu at oracle.com Wed Nov 6 14:40:32 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 06 Nov 2013 14:40:32 -0800 Subject: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527A5830.9050703@oracle.com> References: <527A5830.9050703@oracle.com> Message-ID: <527AC560.2070300@oracle.com> Vote: yes On 11/6/2013 6:54 AM, Bengt Rutisson wrote: > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to Membership > in the HotSpot Group. > > Erik is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2012. Erik is a Committer in the > HotSpot project and has currently contributed 31 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From jon.masamitsu at oracle.com Wed Nov 6 14:41:43 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 06 Nov 2013 14:41:43 -0800 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <527AC5A7.4030102@oracle.com> Vote: yes On 11/6/2013 6:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to > Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Mikael is a Committer in the > HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From jon.masamitsu at oracle.com Wed Nov 6 14:42:05 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 06 Nov 2013 14:42:05 -0800 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <527AC5BD.50205@oracle.com> Vote: yes On 11/6/2013 7:48 AM, Bengt Rutisson wrote: > I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to > Membership in the HotSpot Group. > > Jesper is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Jesper is a Committer in the > HotSpot project and has currently contributed 14 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From jon.masamitsu at oracle.com Wed Nov 6 14:42:33 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 06 Nov 2013 14:42:33 -0800 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <527AC5D9.9040708@oracle.com> Vote: yes On 11/6/2013 7:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to > Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since early 2013. Thomas is a Committer in > the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Wed Nov 6 17:14:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 11:14:04 +1000 Subject: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527A5830.9050703@oracle.com> References: <527A5830.9050703@oracle.com> Message-ID: <527AE95C.7040804@oracle.com> Vote: yes David On 7/11/2013 12:54 AM, Bengt Rutisson wrote: > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to Membership > in the HotSpot Group. > > Erik is an Oracle engineer, working for the GC team. He has been working > in the HotSpot team since 2012. Erik is a Committer in the HotSpot > project and has currently contributed 31 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Wed Nov 6 17:14:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 11:14:37 +1000 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <527AE97D.6050406@oracle.com> Vote: yes David On 7/11/2013 1:48 AM, Bengt Rutisson wrote: > I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to > Membership in the HotSpot Group. > > Jesper is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Jesper is a Committer in the > HotSpot project and has currently contributed 14 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Wed Nov 6 17:16:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 11:16:51 +1000 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <527AEA03.6070800@oracle.com> Vote: yes David On 7/11/2013 12:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to > Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Mikael is a Committer in the > HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Wed Nov 6 17:17:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 11:17:13 +1000 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <527AEA19.5030202@oracle.com> Vote: yes David On 7/11/2013 1:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to > Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since early 2013. Thomas is a Committer in > the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Wed Nov 6 17:34:50 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 11:34:50 +1000 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: <527AC3D0.4080201@oracle.com> References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> <527AC3D0.4080201@oracle.com> Message-ID: <527AEE3A.4060909@oracle.com> As you probably now realize there has been some large-scale cleanup work done by the build-infra team on the new build. This appears to be continuiing with the removal of the old build and subsequent change from using makefiles to just make again as the main directory. I suggest keeping an eye on build-dev mailing list. David On 7/11/2013 8:33 AM, Vladimir Kozlov wrote: > Hi, Volker > > I finished the sync. > > Hotspot passed clean. JDK passed builds and testing on our platforms > with few known failures (2 javac regression tests > TypeInferenceComboTest.java and DefaultMethodsTest.java). > > Yes, I did not expect they will do such global cleanup so later in the > game for jdk8: > > https://bugs.openjdk.java.net/browse/JDK-8001931 > http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 > > Syncing more frequent will not help with such big changes. I only hope > it will not happen again in near future until we merge PPC64 code into > main forest. > > As I said I did my best to resolve conflicts and, I think, the only > problem left is AIX changes in makefiles/CompileNativeLibraries.gmk > which you need to move to new makefiles/lib/*.gmk files. > File a bug "PPC64: 8025715 changes broke AIX build after sync" and send > me the fix. I will have to verify JDK build on our platforms with it. > > I am fine with resolving easy conflicts and leaving hard one to you :) > > Regards, > Vladimir > > PS: even mailing system freak-out :) > -------------------------------------------------------------- > Your mail to 'ppc-aix-port-dev' with the subject > > hg: ppc-aix-port/stage/jdk: 740 new changesets > > Is being held until the list moderator can review it for approval. > The reason it is being held: > > Message body is too big: 456885 bytes with a limit of 400 KB > -------------------------------------------------------------- > > On 11/6/13 8:35 AM, Volker Simonis wrote: >> Hi Vladimir, >> >> thank you for starting syncing again! >> >> Please see my comments inline: >> >> On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov >> wrote: >>> I was not able to resolve all conflicts. AIX build is definitely broken. >>> >>> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >>> indention). >>> >>> I had problem with common/autoconf/platform.m4 when resolving >>> conflicts at >>> the end of file (below "Make compilation sanity check"). And for >>> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >>> >>> ppc64 repo: >>> >>> ADDED_CFLAGS=" >>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_CXXFLAGS=" >>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_LDFLAGS=" >>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>> >> >> Yes, this is the right way how it should be done now that we have >> ${COMPILER_TARGET_BITS_FLAG} >> >>> jdk8 repo: >>> >>> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>> >>> >>> Merging toolchain.m4 was even more painful. >>> >>> An other one was jdk/makefiles/CompileLaunchers.gmk >>> >>> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. >>> Code from >>> it was moved into jdk/makefiles/lib files: >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >>> >>> I was not able to do anything there. It definitely broke AIX build so >>> you >>> need to implement it again. Sorry. >> >> Well, works as expected:( >> >> I know no good way how we could solve these problems (apart from >> integration shared changes more early into the main repositories of >> course). >> >> I could of course offer to do the merge such that all the AIX changes >> would still be good. But how could I share a merge change with you? >> Would you like to get only the files which I had to resolve manually? >> Or better all the files which are changed by the merge? You could then >> merge, copy my files over the sources and do the remaining resolving >> in the closed directories. >> >> What do you think, should we try it this way next time? >> >>> >>> I started JDK and Hotspot JPRT test runs. If they passed I will push >>> what I >>> have and then you need to fix it for AIX. >>> >> >> I'm ready to start... >> >>> Regards, >>> Vladimir >>> From daniel.daugherty at oracle.com Wed Nov 6 18:20:24 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 06 Nov 2013 21:20:24 -0500 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <527AF8E8.70503@oracle.com> Vote: yes Dan On 11/6/13 9:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to > Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Mikael is a Committer in the > HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > > From daniel.daugherty at oracle.com Wed Nov 6 18:20:42 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 06 Nov 2013 21:20:42 -0500 Subject: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527A5830.9050703@oracle.com> References: <527A5830.9050703@oracle.com> Message-ID: <527AF8FA.8020307@oracle.com> Vote: yes Dan On 11/6/13 9:54 AM, Bengt Rutisson wrote: > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to Membership > in the HotSpot Group. > > Erik is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2012. Erik is a Committer in the > HotSpot project and has currently contributed 31 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > > From daniel.daugherty at oracle.com Wed Nov 6 18:21:37 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 06 Nov 2013 21:21:37 -0500 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <527AF931.7070304@oracle.com> Vote: yes Dan On 11/6/13 10:48 AM, Bengt Rutisson wrote: > I hereby nominate Jesper Wilhelmsson (OpenJDK user name: jwilhelm) to > Membership in the HotSpot Group. > > Jesper is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Jesper is a Committer in the > HotSpot project and has currently contributed 14 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > > From daniel.daugherty at oracle.com Wed Nov 6 18:22:06 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 06 Nov 2013 21:22:06 -0500 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <527AF94E.9070107@oracle.com> Vote: yes Dan On 11/6/13 10:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to > Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since early 2013. Thomas is a Committer in > the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > > From john.r.rose at oracle.com Wed Nov 6 20:33:42 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Nov 2013 20:33:42 -0800 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <5F0652EC-911F-4739-84AD-D3F53242FC08@oracle.com> Vote: yes From volker.simonis at gmail.com Thu Nov 7 00:09:59 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Nov 2013 09:09:59 +0100 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: <527AEE3A.4060909@oracle.com> References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> <527AC3D0.4080201@oracle.com> <527AEE3A.4060909@oracle.com> Message-ID: Hi David, I'm aware of these changes and the only real solution for this problem is to put our changes into the main forest as fast as possible. Thanks, Volker On Thu, Nov 7, 2013 at 2:34 AM, David Holmes wrote: > As you probably now realize there has been some large-scale cleanup work > done by the build-infra team on the new build. This appears to be > continuiing with the removal of the old build and subsequent change from > using makefiles to just make again as the main directory. > > I suggest keeping an eye on build-dev mailing list. > > David > > > On 7/11/2013 8:33 AM, Vladimir Kozlov wrote: >> >> Hi, Volker >> >> I finished the sync. >> >> Hotspot passed clean. JDK passed builds and testing on our platforms >> with few known failures (2 javac regression tests >> TypeInferenceComboTest.java and DefaultMethodsTest.java). >> >> Yes, I did not expect they will do such global cleanup so later in the >> game for jdk8: >> >> https://bugs.openjdk.java.net/browse/JDK-8001931 >> http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 >> >> Syncing more frequent will not help with such big changes. I only hope >> it will not happen again in near future until we merge PPC64 code into >> main forest. >> >> As I said I did my best to resolve conflicts and, I think, the only >> problem left is AIX changes in makefiles/CompileNativeLibraries.gmk >> which you need to move to new makefiles/lib/*.gmk files. >> File a bug "PPC64: 8025715 changes broke AIX build after sync" and send >> me the fix. I will have to verify JDK build on our platforms with it. >> >> I am fine with resolving easy conflicts and leaving hard one to you :) >> >> Regards, >> Vladimir >> >> PS: even mailing system freak-out :) >> -------------------------------------------------------------- >> Your mail to 'ppc-aix-port-dev' with the subject >> >> hg: ppc-aix-port/stage/jdk: 740 new changesets >> >> Is being held until the list moderator can review it for approval. >> The reason it is being held: >> >> Message body is too big: 456885 bytes with a limit of 400 KB >> -------------------------------------------------------------- >> >> On 11/6/13 8:35 AM, Volker Simonis wrote: >>> >>> Hi Vladimir, >>> >>> thank you for starting syncing again! >>> >>> Please see my comments inline: >>> >>> On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov >>> wrote: >>>> >>>> I was not able to resolve all conflicts. AIX build is definitely broken. >>>> >>>> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >>>> indention). >>>> >>>> I had problem with common/autoconf/platform.m4 when resolving >>>> conflicts at >>>> the end of file (below "Make compilation sanity check"). And for >>>> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >>>> >>>> ppc64 repo: >>>> >>>> ADDED_CFLAGS=" >>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_CXXFLAGS=" >>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_LDFLAGS=" >>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>> >>> >>> Yes, this is the right way how it should be done now that we have >>> ${COMPILER_TARGET_BITS_FLAG} >>> >>>> jdk8 repo: >>>> >>>> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>> >>>> >>>> Merging toolchain.m4 was even more painful. >>>> >>>> An other one was jdk/makefiles/CompileLaunchers.gmk >>>> >>>> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. >>>> Code from >>>> it was moved into jdk/makefiles/lib files: >>>> >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >>>> >>>> I was not able to do anything there. It definitely broke AIX build so >>>> you >>>> need to implement it again. Sorry. >>> >>> >>> Well, works as expected:( >>> >>> I know no good way how we could solve these problems (apart from >>> integration shared changes more early into the main repositories of >>> course). >>> >>> I could of course offer to do the merge such that all the AIX changes >>> would still be good. But how could I share a merge change with you? >>> Would you like to get only the files which I had to resolve manually? >>> Or better all the files which are changed by the merge? You could then >>> merge, copy my files over the sources and do the remaining resolving >>> in the closed directories. >>> >>> What do you think, should we try it this way next time? >>> >>>> >>>> I started JDK and Hotspot JPRT test runs. If they passed I will push >>>> what I >>>> have and then you need to fix it for AIX. >>>> >>> >>> I'm ready to start... >>> >>>> Regards, >>>> Vladimir >>>> > From volker.simonis at gmail.com Thu Nov 7 00:18:38 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Nov 2013 09:18:38 +0100 Subject: JDK-6890703: dtrace.o causes linker warnings In-Reply-To: References: Message-ID: Hi, so it seems this is really a DTrace bug. The OpenSolaris folks have opened the following issue for it: https://www.illumos.org/issues/4296 Can somebody of you Oracle folks please do the same for Oracle Solaris/DTrace? Thanks, Volker On Thu, Oct 24, 2013 at 7:46 PM, Volker Simonis wrote: > Hi, > > we always get linker warnings like: > > Linking vm... > ld: warning: symbol `Universe::_narrow_oop' has differing types: > (file universe.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol `Universe::_methodKlassObj' has differing types: > (file universe.o type=OBJT; file dtrace.o type=FUNC); > > when compiling the HotSpot on Solaris. > > I just found that there already exists a bug for this issue: > "JDK-6890703: dtrace.o causes linker warnings" > (https://bugs.openjdk.java.net/browse/JDK-6890703) but unfortunately > no solution. > > I also found out, that this problem is related to newer dtrace versions. > > Taking the following 'extern.d' dtrace program: > > extern UseCompressedOops; > > dtrace:helper: > { > this->done = ``UseCompressedOops; > } > > and compiling it with '/usr/sbin/dtrace -64 -D_LP64 -C -I. -G > -xlazyload -o /tmp/dtrace.o -s extern.d' results in following object > files: > > For dtrace: Sun D 1.4.1 > > [Index] Value Size Type Bind Other Shndx Name > > [2] | 0| 2009|OBJT |GLOB |0 |2 |___SUNW_dof > [1] | 0| 0|FUNC |GLOB |0 |UNDEF |UseCompressedOops > > but for dtrace: Sun D 1.1 > > [Index] Value Size Type Bind Other Shndx Name > > [2] | 0| 2007|OBJT |GLOB |0 |2 |___SUNW_dof > [1] | 0| 0|NOTY |GLOB |0 |UNDEF |UseCompressedOops > > So the newer dtrace makes the external reference to ' > UseCompressedOops' of type 'FUNC' which conflicts with HotSpot's > definition of UseCompressedOops' and results in a warning. On the > other hand, the old version of dtrace makes the external reference to > be of type 'NOTY' which doesn't seem to bother the linker. > > I have no idea if this behaviour can be influenced (e.g. by giving the > externel reference the right type in D). > > Is there any DTrace wizard out there who knows how this can be fixed? > > Thank you and best regards, > Volker From goetz.lindenmaier at sap.com Thu Nov 7 03:01:27 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 11:01:27 +0000 Subject: RFR(XS): 8027964: Adapt PPC to 6843347: Boundary values in some public GC options cause crashes Message-ID: <4295855A5C1DE049A61835A1887419CC2C47D6EF@DEWDFEMB12A.global.corp.sap> Hi, Please review this change. It's really small, ppc only and required by the last update of the ppc staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8027964/ Best regards, Goetz Lindenmaier From goetz.lindenmaier at sap.com Thu Nov 7 03:02:51 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 11:02:51 +0000 Subject: RFR(XS): 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts Message-ID: <4295855A5C1DE049A61835A1887419CC2C47D6FD@DEWDFEMB12A.global.corp.sap> Hi, Please review this change. It's really small, ppc only and required by the last update of the ppc staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8027965/ Best regards, Goetz Lindenmaier From goetz.lindenmaier at sap.com Thu Nov 7 03:04:00 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 11:04:00 +0000 Subject: RFR(XS): 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call Message-ID: <4295855A5C1DE049A61835A1887419CC2C47D70B@DEWDFEMB12A.global.corp.sap> Hi, Please review this change. It's really small, ppc only and required by the last update of the ppc staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8027966/ Best regards, Goetz Lindenmaier From goetz.lindenmaier at sap.com Thu Nov 7 03:05:09 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 11:05:09 +0000 Subject: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops Message-ID: <4295855A5C1DE049A61835A1887419CC2C47D71D@DEWDFEMB12A.global.corp.sap> Hi, Please review this change. It's really small, ppc only and required by the last update of the ppc staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8027968/ Best regards, Goetz Lindenmaier From goetz.lindenmaier at sap.com Thu Nov 7 03:06:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 11:06:12 +0000 Subject: RFR(XS): 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM Message-ID: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> Hi, Please review this change. It's really small, ppc only and required by the last update of the ppc staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8027969/ Best regards, Goetz Lindenmaier From david.holmes at oracle.com Thu Nov 7 03:15:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 21:15:30 +1000 Subject: RFR(XS): 8027964: Adapt PPC to 6843347: Boundary values in some public GC options cause crashes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D6EF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D6EF@DEWDFEMB12A.global.corp.sap> Message-ID: <527B7652.4020708@oracle.com> Looks fine to me. David On 7/11/2013 9:01 PM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027964/ > > Best regards, > Goetz Lindenmaier > From david.holmes at oracle.com Thu Nov 7 03:15:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 21:15:44 +1000 Subject: RFR(XS): 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D6FD@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D6FD@DEWDFEMB12A.global.corp.sap> Message-ID: <527B7660.2030805@oracle.com> Looks fine to me. David On 7/11/2013 9:02 PM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027965/ > > Best regards, > Goetz Lindenmaier > > From david.holmes at oracle.com Thu Nov 7 03:16:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 21:16:02 +1000 Subject: RFR(XS): 8027966: Adapt PPC to 8023657: New type profiling points: arguments to call In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D70B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D70B@DEWDFEMB12A.global.corp.sap> Message-ID: <527B7672.7090104@oracle.com> Looks fine to me. David On 7/11/2013 9:04 PM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027966/ > > Best regards, > Goetz Lindenmaier > > From david.holmes at oracle.com Thu Nov 7 03:23:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Nov 2013 21:23:07 +1000 Subject: RFR(XS): 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> Message-ID: <527B781B.20105@oracle.com> Looks fine to me. (Though I don't understand why the new argument was added as it seems unused everywhere ??) David On 7/11/2013 9:06 PM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027969/ > > Best regards, > Goetz Lindenmaier > From volker.simonis at gmail.com Thu Nov 7 03:38:06 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Nov 2013 12:38:06 +0100 Subject: RFR(XS): 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <527B781B.20105@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> <527B781B.20105@oracle.com> Message-ID: It is used in the TemplateInterpreter but it was added to AbstractInterpreter so we need to add it to CppInterprter as well (altough we currently don't use it for the CppInterpreter). On Thu, Nov 7, 2013 at 12:23 PM, David Holmes wrote: > Looks fine to me. (Though I don't understand why the new argument was added > as it seems unused everywhere ??) > > David > > > On 7/11/2013 9:06 PM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> Please review this change. It's really small, ppc only and required by >> the last >> update of the ppc staging repository. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8027969/ >> >> Best regards, >> Goetz Lindenmaier >> > From zhengyu.gu at oracle.com Thu Nov 7 05:41:29 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 07 Nov 2013 08:41:29 -0500 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <527B9889.8030607@oracle.com> Vote: yes -Zhengyu On 11/6/2013 9:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to > Membership in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Mikael is a Committer in the > HotSpot project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From zhengyu.gu at oracle.com Thu Nov 7 05:41:46 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 07 Nov 2013 08:41:46 -0500 Subject: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527AB6A0.9030104@oracle.com> References: <527A5830.9050703@oracle.com> <527AB6A0.9030104@oracle.com> Message-ID: <527B989A.2040704@oracle.com> Vote: yes -Zhengyu On 11/6/2013 4:37 PM, Coleen Phillmore wrote: > Vote: yes > > On 11/6/2013 9:54 AM, Bengt Rutisson wrote: >> I hereby nominate Erik Helin (OpenJDK user name: ehelin) to >> Membership in the HotSpot Group. >> >> Erik is an Oracle engineer, working for the GC team. He has been >> working in the HotSpot team since 2012. Erik is a Committer in the >> HotSpot project and has currently contributed 31 changes. >> >> Votes are due by Wednesday, November 20, 2013. >> >> Only current Members of the HotSpot Group [1] 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 [2]. >> >> Kind Regards, >> Bengt >> >> [1] http://openjdk.java.net/census/#hotspot >> [2] http://openjdk.java.net/groups/#member-vote > From zhengyu.gu at oracle.com Thu Nov 7 05:42:13 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 07 Nov 2013 08:42:13 -0500 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <527B98B5.9080207@oracle.com> Vote: yes -Zhengyu On 11/6/2013 10:48 AM, Bengt Rutisson wrote: > I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to > Membership in the HotSpot Group. > > Jesper is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since 2010. Jesper is a Committer in the > HotSpot project and has currently contributed 14 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From zhengyu.gu at oracle.com Thu Nov 7 05:42:32 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 07 Nov 2013 08:42:32 -0500 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <527B98C8.6040101@oracle.com> Vote: yes -Zhengyu On 11/6/2013 10:59 AM, Bengt Rutisson wrote: > I hereby nominate Thomas Schatzl (OpenJDK user name:tschatzl) to > Membership in the HotSpot Group. > > Thomas is an Oracle engineer, working for the GC team. He has been > working in the HotSpot team since early 2013. Thomas is a Committer in > the HotSpot project and has currently contributed 28 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From roland.westrelin at oracle.com Thu Nov 7 05:53:07 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 14:53:07 +0100 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <8157A179-90FF-4FB8-8DD4-D59AD1E6B847@oracle.com> Vote: yes Roland. From roland.westrelin at oracle.com Thu Nov 7 05:53:41 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 14:53:41 +0100 Subject: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527A5830.9050703@oracle.com> References: <527A5830.9050703@oracle.com> Message-ID: Vote: yes Roland. From roland.westrelin at oracle.com Thu Nov 7 05:54:10 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 14:54:10 +0100 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <7AF0A850-F841-4F98-A5FE-EC61A913AC18@oracle.com> Vote: yes Roland. From roland.westrelin at oracle.com Thu Nov 7 05:54:35 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 7 Nov 2013 14:54:35 +0100 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <4DBA864F-72DE-46BC-BE86-30D3F7D39646@oracle.com> Vote: yes Roland. From coleen.phillimore at oracle.com Thu Nov 7 07:10:58 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 07 Nov 2013 10:10:58 -0500 Subject: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D71D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D71D@DEWDFEMB12A.global.corp.sap> Message-ID: <527BAD82.2010205@oracle.com> With this one, do you have to change the number of instructions for vtableStubs_ppc64 and in the .ad file, as in pd_code_size_limit? I guess what you'd have is an overestimate with this change. In the x86 and sparc code we added a function instr_size_for_decode_klass_not_null to help with this calculation. Thanks, Coleen On 11/7/2013 6:05 AM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027968/ > > Best regards, > Goetz Lindenmaier > From volker.simonis at gmail.com Thu Nov 7 07:34:23 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Nov 2013 16:34:23 +0100 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: <527AC3D0.4080201@oracle.com> References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> <527AC3D0.4080201@oracle.com> Message-ID: Hi Vladimir, thank you for doing the sync! Strange that your builds passed on Oracle platforms because because I think there's a typo in makefiles/lib/CoreLibraries.gmk which should affect all platforms: diff -r d152c5b01ea8 makefiles/lib/CoreLibraries.gmk --- a/makefiles/lib/CoreLibraries.gmk Tue Nov 05 17:32:53 2013 -0800 +++ b/makefiles/lib/CoreLibraries.gmk Thu Nov 07 15:36:54 2013 +0100 @@ -269,7 +269,7 @@ $(WIN_JAVA_LIB), \ LDFLAGS_SUFFIX_linux := -ljvm -ljava $(LIBZ), \ LDFLAGS_SUFFIX_solaris := -ljvm -ljava $(LIBZ) -lc, \ - LDFLAGS_SUFFIX_aix: = -ljvm -ljava $(LIBZ),\ + LDFLAGS_SUFFIX_aix := -ljvm -ljava $(LIBZ),\ LDFLAGS_SUFFIX_macosx := $(LIBZ) -ljava -ljvm, \ VERSIONINFO_RESOURCE := $(JDK_TOPDIR)/src/windows/resource/version.rc, \ RC_FLAGS := $(RC_FLAGS) \ Maybe that's related to the make version, but with GNU make 3.82 I get an "*** empty variable name" error. If I fix this (and together with Goetz's fixes) the build passes on Linux/PPC64. I think it makes no sense to create a bug for this single character change so I'm packing it together with the other AIX-related changes which I'm currently preparing. Regards, Volker On Wed, Nov 6, 2013 at 11:33 PM, Vladimir Kozlov wrote: > Hi, Volker > > I finished the sync. > > Hotspot passed clean. JDK passed builds and testing on our platforms with > few known failures (2 javac regression tests TypeInferenceComboTest.java and > DefaultMethodsTest.java). > > Yes, I did not expect they will do such global cleanup so later in the game > for jdk8: > > https://bugs.openjdk.java.net/browse/JDK-8001931 > http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 > > Syncing more frequent will not help with such big changes. I only hope it > will not happen again in near future until we merge PPC64 code into main > forest. > > As I said I did my best to resolve conflicts and, I think, the only problem > left is AIX changes in makefiles/CompileNativeLibraries.gmk which you need > to move to new makefiles/lib/*.gmk files. > File a bug "PPC64: 8025715 changes broke AIX build after sync" and send me > the fix. I will have to verify JDK build on our platforms with it. > > I am fine with resolving easy conflicts and leaving hard one to you :) > > Regards, > Vladimir > > PS: even mailing system freak-out :) > -------------------------------------------------------------- > Your mail to 'ppc-aix-port-dev' with the subject > > hg: ppc-aix-port/stage/jdk: 740 new changesets > > Is being held until the list moderator can review it for approval. > The reason it is being held: > > Message body is too big: 456885 bytes with a limit of 400 KB > -------------------------------------------------------------- > > > On 11/6/13 8:35 AM, Volker Simonis wrote: >> >> Hi Vladimir, >> >> thank you for starting syncing again! >> >> Please see my comments inline: >> >> On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov >> wrote: >>> >>> I was not able to resolve all conflicts. AIX build is definitely broken. >>> >>> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >>> indention). >>> >>> I had problem with common/autoconf/platform.m4 when resolving conflicts >>> at >>> the end of file (below "Make compilation sanity check"). And for >>> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >>> >>> ppc64 repo: >>> >>> ADDED_CFLAGS=" ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_CXXFLAGS=" >>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_LDFLAGS=" >>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>> >> >> Yes, this is the right way how it should be done now that we have >> ${COMPILER_TARGET_BITS_FLAG} >> >>> jdk8 repo: >>> >>> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>> >>> >>> Merging toolchain.m4 was even more painful. >>> >>> An other one was jdk/makefiles/CompileLaunchers.gmk >>> >>> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. Code >>> from >>> it was moved into jdk/makefiles/lib files: >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >>> >>> I was not able to do anything there. It definitely broke AIX build so you >>> need to implement it again. Sorry. >> >> >> Well, works as expected:( >> >> I know no good way how we could solve these problems (apart from >> integration shared changes more early into the main repositories of >> course). >> >> I could of course offer to do the merge such that all the AIX changes >> would still be good. But how could I share a merge change with you? >> Would you like to get only the files which I had to resolve manually? >> Or better all the files which are changed by the merge? You could then >> merge, copy my files over the sources and do the remaining resolving >> in the closed directories. >> >> What do you think, should we try it this way next time? >> >>> >>> I started JDK and Hotspot JPRT test runs. If they passed I will push what >>> I >>> have and then you need to fix it for AIX. >>> >> >> I'm ready to start... >> >>> Regards, >>> Vladimir >>> > From coleen.phillimore at oracle.com Thu Nov 7 07:04:23 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 7 Nov 2013 07:04:23 -0800 (PST) Subject: RFR(XS): 8027965: Adapt PPC to 8015107: NPG: Use consistent naming for metaspace concepts In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D6FD@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D6FD@DEWDFEMB12A.global.corp.sap> Message-ID: <527BABF7.7090402@oracle.com> Looks good, Goetz. Coleen On 11/7/2013 6:02 AM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027965/ > > Best regards, > Goetz Lindenmaier > > From yekaterina.kantserova at oracle.com Thu Nov 7 07:48:40 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 07 Nov 2013 16:48:40 +0100 Subject: Fwd: RFR (S): 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary In-Reply-To: <527B9F28.3060303@oracle.com> References: <527B9F28.3060303@oracle.com> Message-ID: <527BB658.4000208@oracle.com> Adding hotspot-dev group. -------- Original Message -------- Subject: RFR (S): 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary Date: Thu, 07 Nov 2013 15:09:44 +0100 From: Yekaterina Kantserova To: Serviceability Dev Hi, Could I please have a review of this fix. The following has been done: - updated OutputAnalyzer and ProcessTool with changes from hotspot/testlibrary; - added test classes AssertsTest and OutputAnalyzerReportingTest from hotspot/testlibrary; - added InputArguments class from hotspot/testlibrary (provides access to the input arguments to the VM); - removed JdkFinder (it's replaced with JDKToolLauncher); - re-wrote JcmdBase to use JDKToolLauncher instead of JdkFinder. Bug: https://bugs.openjdk.java.net/browse/JDK-8015497 Webrev: http://cr.openjdk.java.net/~ykantser/8015497/webrev.00/ Thanks, Katja From goetz.lindenmaier at sap.com Thu Nov 7 08:22:36 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 16:22:36 +0000 Subject: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <527BAD82.2010205@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2C47D71D@DEWDFEMB12A.global.corp.sap> <527BAD82.2010205@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2C47D8B1@DEWDFEMB12A.global.corp.sap> Hi Coleen, thanks for the tip! I fixed it: http://cr.openjdk.java.net/~goetz/webrevs/8027968-2/ Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillmore Sent: Donnerstag, 7. November 2013 16:11 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops With this one, do you have to change the number of instructions for vtableStubs_ppc64 and in the .ad file, as in pd_code_size_limit? I guess what you'd have is an overestimate with this change. In the x86 and sparc code we added a function instr_size_for_decode_klass_not_null to help with this calculation. Thanks, Coleen On 11/7/2013 6:05 AM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027968/ > > Best regards, > Goetz Lindenmaier > From serguei.spitsyn at oracle.com Thu Nov 7 09:36:24 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 07 Nov 2013 09:36:24 -0800 Subject: RFR(XS): 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> Message-ID: <527BCF98.3070102@oracle.com> Hi Goetz, It looks good. Thanks, Serguei On 11/7/13 3:06 AM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027969/ > > Best regards, > Goetz Lindenmaier > From david.r.chase at oracle.com Thu Nov 7 09:50:48 2013 From: david.r.chase at oracle.com (david.r.chase at oracle.com) Date: Thu, 07 Nov 2013 17:50:48 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20131107175102.B90836240E@hg.openjdk.java.net> Changeset: 208ebea980f8 Author: roland Date: 2013-11-04 21:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/208ebea980f8 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I Summary: String.equals() intrinsic shouldn't use integer length input in pointer arithmetic without an i2l. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/intrinsics/stringequals/TestStringEqualsBadLength.java Changeset: e428d5e768e3 Author: rbackman Date: 2013-11-04 10:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e428d5e768e3 8027622: java.time.Instant.create failing since hs25-b56 Reviewed-by: kvn, iveresov ! src/share/vm/opto/compile.cpp + test/compiler/intrinsics/mathexact/CompareTest.java Changeset: a905d33ce13a Author: iveresov Date: 2013-11-05 00:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a905d33ce13a 8027751: C1 crashes in Weblogic with G1 enabled Summary: Keep T_OBJECT operands in registers for logical operations on x64 Reviewed-by: kvn, roland ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 94a83e0f9ce1 Author: iveresov Date: 2013-11-05 01:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/94a83e0f9ce1 8017065: C2 allows safepoint checks to leak into G1 pre-barriers Summary: Make all raw loads strictly respect control dependencies, make sure RCE doesn't move raw loads, add verification of G1 pre-barriers. Reviewed-by: kvn, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.hpp Changeset: 613e6a6fc328 Author: iveresov Date: 2013-11-05 02:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/613e6a6fc328 Merge ! src/share/vm/opto/compile.cpp Changeset: be525e91f65b Author: mikael Date: 2013-11-06 06:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be525e91f65b 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION Summary: Uncommon trap blob did not bang all the stack shadow pages Reviewed-by: kvn, twisti, iveresov, jrose ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp + test/compiler/uncommontrap/UncommonTrapStackBang.java Changeset: 53662b2f1d68 Author: drchase Date: 2013-11-07 10:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/53662b2f1d68 Merge From vladimir.kozlov at oracle.com Thu Nov 7 10:07:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 10:07:34 -0800 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> <527AC3D0.4080201@oracle.com> Message-ID: <527BD6E6.4080706@oracle.com> Thank you for catching it. I agree, no need for separate bug. Thanks, Vladimir On 11/7/13 7:34 AM, Volker Simonis wrote: > Hi Vladimir, > > thank you for doing the sync! > > Strange that your builds passed on Oracle platforms because because I > think there's a typo in makefiles/lib/CoreLibraries.gmk which should > affect all platforms: > > diff -r d152c5b01ea8 makefiles/lib/CoreLibraries.gmk > --- a/makefiles/lib/CoreLibraries.gmk Tue Nov 05 17:32:53 2013 -0800 > +++ b/makefiles/lib/CoreLibraries.gmk Thu Nov 07 15:36:54 2013 +0100 > @@ -269,7 +269,7 @@ > $(WIN_JAVA_LIB), \ > LDFLAGS_SUFFIX_linux := -ljvm -ljava $(LIBZ), \ > LDFLAGS_SUFFIX_solaris := -ljvm -ljava $(LIBZ) -lc, \ > - LDFLAGS_SUFFIX_aix: = -ljvm -ljava $(LIBZ),\ > + LDFLAGS_SUFFIX_aix := -ljvm -ljava $(LIBZ),\ > LDFLAGS_SUFFIX_macosx := $(LIBZ) -ljava -ljvm, \ > VERSIONINFO_RESOURCE := $(JDK_TOPDIR)/src/windows/resource/version.rc, \ > RC_FLAGS := $(RC_FLAGS) \ > > Maybe that's related to the make version, but with GNU make 3.82 I get > an "*** empty variable name" error. > > If I fix this (and together with Goetz's fixes) the build passes on Linux/PPC64. > > I think it makes no sense to create a bug for this single character > change so I'm packing it together with the other AIX-related changes > which I'm currently preparing. > > Regards, > Volker > > > On Wed, Nov 6, 2013 at 11:33 PM, Vladimir Kozlov > wrote: >> Hi, Volker >> >> I finished the sync. >> >> Hotspot passed clean. JDK passed builds and testing on our platforms with >> few known failures (2 javac regression tests TypeInferenceComboTest.java and >> DefaultMethodsTest.java). >> >> Yes, I did not expect they will do such global cleanup so later in the game >> for jdk8: >> >> https://bugs.openjdk.java.net/browse/JDK-8001931 >> http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 >> >> Syncing more frequent will not help with such big changes. I only hope it >> will not happen again in near future until we merge PPC64 code into main >> forest. >> >> As I said I did my best to resolve conflicts and, I think, the only problem >> left is AIX changes in makefiles/CompileNativeLibraries.gmk which you need >> to move to new makefiles/lib/*.gmk files. >> File a bug "PPC64: 8025715 changes broke AIX build after sync" and send me >> the fix. I will have to verify JDK build on our platforms with it. >> >> I am fine with resolving easy conflicts and leaving hard one to you :) >> >> Regards, >> Vladimir >> >> PS: even mailing system freak-out :) >> -------------------------------------------------------------- >> Your mail to 'ppc-aix-port-dev' with the subject >> >> hg: ppc-aix-port/stage/jdk: 740 new changesets >> >> Is being held until the list moderator can review it for approval. >> The reason it is being held: >> >> Message body is too big: 456885 bytes with a limit of 400 KB >> -------------------------------------------------------------- >> >> >> On 11/6/13 8:35 AM, Volker Simonis wrote: >>> >>> Hi Vladimir, >>> >>> thank you for starting syncing again! >>> >>> Please see my comments inline: >>> >>> On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov >>> wrote: >>>> >>>> I was not able to resolve all conflicts. AIX build is definitely broken. >>>> >>>> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >>>> indention). >>>> >>>> I had problem with common/autoconf/platform.m4 when resolving conflicts >>>> at >>>> the end of file (below "Make compilation sanity check"). And for >>>> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >>>> >>>> ppc64 repo: >>>> >>>> ADDED_CFLAGS=" ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_CXXFLAGS=" >>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_LDFLAGS=" >>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>> >>> >>> Yes, this is the right way how it should be done now that we have >>> ${COMPILER_TARGET_BITS_FLAG} >>> >>>> jdk8 repo: >>>> >>>> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>> >>>> >>>> Merging toolchain.m4 was even more painful. >>>> >>>> An other one was jdk/makefiles/CompileLaunchers.gmk >>>> >>>> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. Code >>>> from >>>> it was moved into jdk/makefiles/lib files: >>>> >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >>>> >>>> I was not able to do anything there. It definitely broke AIX build so you >>>> need to implement it again. Sorry. >>> >>> >>> Well, works as expected:( >>> >>> I know no good way how we could solve these problems (apart from >>> integration shared changes more early into the main repositories of >>> course). >>> >>> I could of course offer to do the merge such that all the AIX changes >>> would still be good. But how could I share a merge change with you? >>> Would you like to get only the files which I had to resolve manually? >>> Or better all the files which are changed by the merge? You could then >>> merge, copy my files over the sources and do the remaining resolving >>> in the closed directories. >>> >>> What do you think, should we try it this way next time? >>> >>>> >>>> I started JDK and Hotspot JPRT test runs. If they passed I will push what >>>> I >>>> have and then you need to fix it for AIX. >>>> >>> >>> I'm ready to start... >>> >>>> Regards, >>>> Vladimir >>>> >> From john.coomes at oracle.com Thu Nov 7 10:31:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 18:31:47 +0000 Subject: hg: hsx/hotspot-main/corba: 5 new changesets Message-ID: <20131107183153.E305C62415@hg.openjdk.java.net> Changeset: 52ad44f9a3ec Author: alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/52ad44f9a3ec 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java Changeset: a90e9efa4264 Author: coffeys Date: 2013-10-23 16:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/a90e9efa4264 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java Changeset: 219e616a6a4f Author: lana Date: 2013-10-28 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/219e616a6a4f Merge Changeset: 8d07115924b7 Author: lana Date: 2013-10-31 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/8d07115924b7 Merge Changeset: 5fdc44652089 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5fdc44652089 Added tag jdk8-b115 for changeset 8d07115924b7 ! .hgtags From john.coomes at oracle.com Thu Nov 7 10:32:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 18:32:21 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b115 for changeset e126d8eca69b Message-ID: <20131107183228.6170962417@hg.openjdk.java.net> Changeset: 587560c222a2 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/587560c222a2 Added tag jdk8-b115 for changeset e126d8eca69b ! .hgtags From john.coomes at oracle.com Thu Nov 7 10:31:58 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 18:31:58 +0000 Subject: hg: hsx/hotspot-main/jaxp: 6 new changesets Message-ID: <20131107183217.A42E362416@hg.openjdk.java.net> Changeset: 390e94b9a852 Author: joehw Date: 2013-10-24 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/390e94b9a852 8004476: XSLT Extension Functions Don't Work in WebStart Reviewed-by: dfuchs, lancea, alanb ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java + src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java ! src/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java ! src/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java ! src/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java Changeset: 96562bf197f2 Author: lana Date: 2013-10-28 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/96562bf197f2 Merge Changeset: 1af33ab1bc58 Author: joehw Date: 2013-10-29 14:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/1af33ab1bc58 8027484: Implementation error in SAX2DOM.java Reviewed-by: alanb, lancea ! src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java Changeset: 04778b00286a Author: joehw Date: 2013-10-30 08:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/04778b00286a 8024378: StAX parser shall support JAXP properties Reviewed-by: dfuchs, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java Changeset: f610fd46463e Author: lana Date: 2013-10-31 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f610fd46463e Merge Changeset: e757eb9aee3d Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e757eb9aee3d Added tag jdk8-b115 for changeset f610fd46463e ! .hgtags From john.coomes at oracle.com Thu Nov 7 10:31:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 18:31:41 +0000 Subject: hg: hsx/hotspot-main: 30 new changesets Message-ID: <20131107183143.818AD62413@hg.openjdk.java.net> Changeset: 3dc55f0c1b6f Author: jlaskey Date: 2013-01-28 16:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3dc55f0c1b6f 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk + make/nashorn-rules.gmk ! make/scripts/hgforest.sh Changeset: ecd447139a39 Author: jlaskey Date: 2013-02-04 17:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ecd447139a39 Merge ! common/autoconf/generated-configure.sh Changeset: 9ed388a04fa7 Author: jlaskey Date: 2013-02-06 13:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9ed388a04fa7 8007666: nashorn missing from hgforest.sh Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! common/bin/hgforest.sh Changeset: 8b19b55f695d Author: jlaskey Date: 2013-02-18 19:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8b19b55f695d 8008420: Fix Nashorn forest to build with NEWBUILD=false Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! Makefile ! make/nashorn-rules.gmk Changeset: f9a1cb245484 Author: jlaskey Date: 2013-02-19 10:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f9a1cb245484 8008446: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Defs-internal.gmk Changeset: 887fde71977e Author: jlaskey Date: 2013-02-21 15:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/887fde71977e 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/jdk-rules.gmk ! make/sanity-rules.gmk Changeset: e877cb3eb4d6 Author: jlaskey Date: 2013-02-22 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e877cb3eb4d6 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 528a9984198f Author: jlaskey Date: 2013-02-22 22:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/528a9984198f 8008774: nashorn missing from dependencies after merge with tl Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! common/makefiles/Main.gmk Changeset: 13ddc5c3ebfc Author: jlaskey Date: 2013-03-02 10:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/13ddc5c3ebfc Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk ! make/nashorn-rules.gmk Changeset: 1d38d30196be Author: jlaskey Date: 2013-03-08 14:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1d38d30196be Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: b938d5ee29c3 Author: jlaskey Date: 2013-03-15 11:50 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b938d5ee29c3 Merge Changeset: fe5a388bf8fe Author: jlaskey Date: 2013-03-26 09:13 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fe5a388bf8fe Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 1378ccca1c79 Author: jlaskey Date: 2013-04-09 08:35 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1378ccca1c79 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 8a7e97848471 Author: jlaskey Date: 2013-04-15 08:06 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8a7e97848471 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 6316aefcf716 Author: jlaskey Date: 2013-04-17 08:47 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6316aefcf716 Merge Changeset: dd81e9b5fb38 Author: jlaskey Date: 2013-04-22 13:59 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dd81e9b5fb38 Merge Changeset: 431d16ddfcd9 Author: jlaskey Date: 2013-04-29 21:37 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/431d16ddfcd9 Merge Changeset: 1fca390200c1 Author: jlaskey Date: 2013-05-14 09:04 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1fca390200c1 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 67b5cbe55744 Author: jlaskey Date: 2013-05-23 09:48 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/67b5cbe55744 Merge Changeset: de886178f8e6 Author: jlaskey Date: 2013-06-05 13:08 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/de886178f8e6 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: 520fd54a7c43 Author: jlaskey Date: 2013-07-16 09:08 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/520fd54a7c43 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 67dc3d7d5b5f Author: jlaskey Date: 2013-07-24 08:23 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/67dc3d7d5b5f Merge ! common/autoconf/generated-configure.sh Changeset: 96f207364e46 Author: jlaskey Date: 2013-08-27 16:05 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/96f207364e46 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: ddf76977d04a Author: jlaskey Date: 2013-09-13 10:14 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ddf76977d04a Merge ! common/autoconf/generated-configure.sh ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 8b92b08993a8 Author: jlaskey Date: 2013-09-30 10:23 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8b92b08993a8 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: d832f6171acd Author: jlaskey Date: 2013-10-29 11:48 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d832f6171acd Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 067355edfbf8 Author: vinnie Date: 2013-10-30 17:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/067355edfbf8 8027567: JDK 8 build failure: the correct version of GNU make is being rejected Reviewed-by: chegar, erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 37d2736caf46 Author: lana Date: 2013-10-30 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/37d2736caf46 Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: 763ada2a1d8c Author: lana Date: 2013-10-31 16:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/763ada2a1d8c Merge Changeset: 40e892e2a4f2 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/40e892e2a4f2 Added tag jdk8-b115 for changeset 763ada2a1d8c ! .hgtags From john.coomes at oracle.com Thu Nov 7 10:44:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 18:44:03 +0000 Subject: hg: hsx/hotspot-main/jdk: 212 new changesets Message-ID: <20131107192929.8EB3162425@hg.openjdk.java.net> Changeset: 180c05796c45 Author: bae Date: 2013-10-10 18:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/180c05796c45 7058618: PNG parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java Changeset: 0c2ba6a67b0d Author: morris Date: 2013-10-11 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c2ba6a67b0d 7195597: ThreadStateTest gets different results with -Xcomp Reviewed-by: kvn ! test/java/lang/Thread/ThreadStateTest.java Changeset: 124bffc749ea Author: lana Date: 2013-10-12 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/124bffc749ea Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java - test/java/util/regex/PatternTest.java Changeset: 7ed340e7d894 Author: bae Date: 2013-10-14 15:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ed340e7d894 7058602: BMP parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties ! src/share/classes/java/awt/image/ComponentSampleModel.java Changeset: cb9fa40f73f7 Author: bae Date: 2013-10-14 15:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb9fa40f73f7 7058607: GIF parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 478f7a9b3b12 Author: bae Date: 2013-10-14 16:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/478f7a9b3b12 7058611: JPG parser bugs found via zzuf fuzzing Reviewed-by: prr, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java Changeset: b164c8eb1295 Author: jgodinez Date: 2013-10-14 09:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b164c8eb1295 8022536: closed/javax/print/TextFlavorTest.java fails Reviewed-by: prr, jchen ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! test/java/awt/print/PrinterJob/PrintLatinCJKTest.java + test/javax/print/TextFlavorTest.java Changeset: 8a59181b3c6d Author: vadim Date: 2013-10-15 08:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a59181b3c6d 8023590: REGRESSION: large count of graphics artifacts with Java 8 on Windows 8 on Intel HD card. Reviewed-by: prr, bae ! src/windows/native/sun/java2d/d3d/D3DBadHardware.h Changeset: 0df5cda89a50 Author: jchen Date: 2013-10-15 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0df5cda89a50 8025429: [parfait] warnings from b107 for sun.java2d.cmm: JNI exception pending Reviewed-by: prr, bae ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: c9c945cea665 Author: jgodinez Date: 2013-10-15 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9c945cea665 8015586: [macosx] Test closed/java/awt/print/PrinterJob/PrintToDir.java fails on MacOSX Reviewed-by: prr, jchen ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java + test/java/awt/print/PrinterJob/PrintToDir.java Changeset: 070e8ec9d82c Author: bae Date: 2013-10-16 17:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/070e8ec9d82c 8026702: Fix for 8025429 breaks jdk build on windows Reviewed-by: serb ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 73d212a3b2eb Author: jchen Date: 2013-10-16 14:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/73d212a3b2eb 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test Reviewed-by: prr, vadim, serb ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c Changeset: bcf8e9a59968 Author: jgodinez Date: 2013-10-18 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bcf8e9a59968 8025988: [macosx] Attribute settings don't work for JobAttributes range 8025990: [macosx] Attribute settings don't work for JobAttributes setOrientationRequested, setMedia Reviewed-by: prr, jchen ! src/macosx/native/sun/awt/CPrinterJob.m ! src/share/classes/sun/print/RasterPrinterJob.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! test/java/awt/PrintJob/SaveDialogTitleTest.java Changeset: 2a3e21fe9d0d Author: jgodinez Date: 2013-10-21 13:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a3e21fe9d0d 8026951: Fix for 8025988 breaks jdk build on windows Reviewed-by: prr, jchen ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 923f39485651 Author: bae Date: 2013-10-22 13:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/923f39485651 8026780: Crash on PPC and PPC v2 for Java_awt test suit Reviewed-by: prr, jchen ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 739ed3f0e796 Author: ceisserer Date: 2013-10-22 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/739ed3f0e796 8023483: sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java failed with jdk8 on linux platforms Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/XRBackend.java ! src/solaris/classes/sun/java2d/xr/XRBackendNative.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/classes/sun/java2d/xr/XRPaints.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c + test/java/awt/GradientPaint/GradientTransformTest.java + test/java/awt/GradientPaint/LinearColorSpaceGradientTest.java ! test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java Changeset: c55a8480cc27 Author: ceisserer Date: 2013-10-22 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c55a8480cc27 8023098: XRender : AlphaComposite test results are incorrect. Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java ! src/solaris/classes/sun/java2d/xr/XRColor.java ! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java ! src/solaris/classes/sun/java2d/xr/XRMaskBlit.java + src/solaris/classes/sun/java2d/xr/XRSolidSrcPict.java ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java Changeset: aca4a67e560d Author: vadim Date: 2013-10-23 08:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/aca4a67e560d 8001173: [findbugs] Evaluate FindBug output for sun.font.CompositeFont, sun.font.CompositeFontDescriptor Reviewed-by: prr, bae ! src/share/classes/sun/font/StandardTextSource.java ! src/share/classes/sun/font/TextLabelFactory.java ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 92af0666c168 Author: prr Date: 2013-10-23 08:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92af0666c168 8027169: Xrender: Cleaner version of the fix for 7159455 Nimbus scrollbar glitch Reviewed-by: prr, bae ! src/solaris/classes/sun/java2d/xr/XRPMBlitLoops.java Changeset: d27525c346fa Author: lana Date: 2013-10-24 21:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d27525c346fa Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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 - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/net/HttpURLPermission.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 3371047f56f3 Author: lana Date: 2013-10-31 15:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3371047f56f3 Merge Changeset: 2e59014ef38f Author: alexsch Date: 2013-10-09 13:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2e59014ef38f 8025649: need test to cover JDK-8000423 Reviewed-by: anthony, serb Contributed-by: Alexander Stepanov + test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html + test/java/awt/InputMethods/DiacriticsTest/DiacriticsTest.java Changeset: 84c766f6796b Author: bagiras Date: 2013-10-09 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84c766f6796b 8016356: Any swing frame resizes ugly. Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 929dc0915f8c Author: anthony Date: 2013-10-09 15:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/929dc0915f8c 7159266: [macosx] ApplicationDelegate should not be set in the headless mode Summary: Don't install ApplicationDelegate in headless mode Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m Changeset: 976e5f580124 Author: leonidr Date: 2013-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/976e5f580124 8019623: Lack of synchronization in AppContext.getAppContext() Reviewed-by: anthony, art ! src/share/classes/sun/awt/AppContext.java + test/sun/awt/AppContext/MultiThread/MultiThreadTest.java Changeset: fba62451d705 Author: leonidr Date: 2013-10-09 21:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fba62451d705 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons Reviewed-by: alexsch, serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java + test/com/sun/java/swing/plaf/windows/8016551/bug8016551.java Changeset: cea6ca16142e Author: cl Date: 2013-10-09 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cea6ca16142e 8026021: more fix of javadoc errors and warnings reported by doclint, see the description Reviewed-by: anthony, serb ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/font/LineBreakMeasurer.java ! src/share/classes/java/awt/font/MultipleMaster.java ! src/share/classes/java/awt/font/NumericShaper.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java Changeset: 81ea6299230a Author: serb Date: 2013-10-10 02:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/81ea6299230a 7058662: AiffFileReader throws java.lang.ArithmeticException: division by zero when frame size is zero 7058666: Unexpected exception in AU parser code 7058672: Unexpected exceptions and freezes in WAV parser code Reviewed-by: prr ! src/share/classes/com/sun/media/sound/AiffFileReader.java ! src/share/classes/com/sun/media/sound/AuFileReader.java ! src/share/classes/com/sun/media/sound/WaveFileReader.java + test/javax/sound/sampled/FileReader/ReadersExceptions.java Changeset: 857d6f78f241 Author: pchelko Date: 2013-10-10 11:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/857d6f78f241 8025588: [macosx] Frozen AppKit thread in 7u40 Reviewed-by: anthony, art, serb ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/event/InvocationEvent.java ! src/share/classes/sun/awt/AWTAccessor.java Changeset: 31a156bae7cb Author: pchelko Date: 2013-10-10 19:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31a156bae7cb 8024864: [macosx] Problems with rendering of controls Reviewed-by: serb, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/Paint/bug8024864.java Changeset: de36486eadd2 Author: pchelko Date: 2013-10-11 11:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/de36486eadd2 8026143: [macosx] Maximized state could be inconsistent between peer and frame Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/MaximizedByPlatform/MaximizedByPlatform.java Changeset: d96f9a8cf89a Author: kshefov Date: 2013-10-11 15:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d96f9a8cf89a 7124338: [macosx] Selection lost if a selected item removed from a java.awt.List Reviewed-by: serb, anthony + test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html + test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java Changeset: 2e04843f1c1d Author: art Date: 2013-10-11 16:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2e04843f1c1d 8022185: Fix Raw and unchecked warnings in classes belonging to java.awt.datatransfer Reviewed-by: art, pchelko Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java Changeset: 2f7f6995fa64 Author: pchelko Date: 2013-10-11 17:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f7f6995fa64 8026262: NPE in SystemFlavorMap.getAllNativesForType - regression in jdk8 b110 by fix of #JDK-8024987 Reviewed-by: art, serb ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: af273c9b564a Author: pchelko Date: 2013-10-11 18:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af273c9b564a 8024329: [macosx] JRadioButtonMenuItem behaves like a checkbox when using the ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java Changeset: f65895a2959e Author: lana Date: 2013-10-11 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f65895a2959e Merge - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java - test/java/util/regex/PatternTest.java Changeset: d874963706dc Author: yan Date: 2013-10-14 11:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d874963706dc 8025824: [cleanup] Fix tidy errors and warnings in preformatted HTML files related to 2d/awt/swing Reviewed-by: anthony, alexsch ! src/macosx/classes/com/apple/eawt/event/package.html ! src/macosx/classes/com/apple/eawt/package.html ! src/share/classes/java/awt/color/package.html ! src/share/classes/java/awt/datatransfer/package.html ! src/share/classes/java/awt/dnd/package.html ! src/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/doc-files/FocusSpec.html ! src/share/classes/java/awt/doc-files/Modality.html ! src/share/classes/java/awt/event/package.html ! src/share/classes/java/awt/font/package.html ! src/share/classes/java/awt/geom/package.html ! src/share/classes/java/awt/image/package.html ! src/share/classes/java/awt/image/renderable/package.html ! src/share/classes/java/awt/package.html ! src/share/classes/java/awt/print/package.html ! src/share/classes/javax/print/attribute/package.html ! src/share/classes/javax/print/attribute/standard/package.html ! src/share/classes/javax/print/event/package.html ! src/share/classes/javax/print/package.html ! src/share/classes/javax/swing/border/package.html ! src/share/classes/javax/swing/colorchooser/package.html ! src/share/classes/javax/swing/event/package.html ! src/share/classes/javax/swing/filechooser/package.html ! src/share/classes/javax/swing/plaf/basic/package.html ! src/share/classes/javax/swing/plaf/metal/package.html ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/multi/package.html ! src/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html ! src/share/classes/javax/swing/plaf/nimbus/package.html ! src/share/classes/javax/swing/plaf/package.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/classes/javax/swing/table/package.html ! src/share/classes/javax/swing/text/html/package.html ! src/share/classes/javax/swing/text/html/parser/package.html ! src/share/classes/javax/swing/text/package.html ! src/share/classes/javax/swing/text/rtf/package.html ! src/share/classes/javax/swing/tree/package.html ! src/share/classes/javax/swing/undo/package.html Changeset: 69a17384fe22 Author: malenkov Date: 2013-10-14 13:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69a17384fe22 7165112: Incomprehensible garbage in doc for RootPaneContainer Reviewed-by: alexsch ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/RootPaneContainer.java Changeset: 9f49b055e983 Author: malenkov Date: 2013-10-14 13:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f49b055e983 7016396: (spec) JCK test mentioned in 6735293 is still failing Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/View.java Changeset: 54a6e22b749c Author: malenkov Date: 2013-10-14 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54a6e22b749c 7035495: javax.swing.ImageIcon spec should be clarified Reviewed-by: alexsch ! src/share/classes/javax/swing/ImageIcon.java Changeset: 5e0ed469c36a Author: alexsch Date: 2013-10-14 18:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e0ed469c36a 8005391: Floating behavior of HTMLEditorKit parser Reviewed-by: malenkov, leonidr Contributed-by: Alexander Shusherov ! src/share/classes/javax/swing/text/SimpleAttributeSet.java + test/javax/swing/text/html/8005391/bug8005391.java Changeset: 24fd0716d8d6 Author: alexsch Date: 2013-10-14 18:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/24fd0716d8d6 8020708: NLS mnemonics missing in SwingSet2/JInternalFrame demo Reviewed-by: malenkov, leonidr ! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java + test/javax/swing/JInternalFrame/8020708/bug8020708.java Changeset: 9546631f14ca Author: serb Date: 2013-10-14 20:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9546631f14ca 8019591: JCK: testICSEthrowing_fullScreen fails: no ICSE thrown Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java + test/java/awt/Window/WindowGCInFullScreen/WindowGCInFullScreen.java Changeset: f9548641d699 Author: serb Date: 2013-10-15 20:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f9548641d699 7059886: 6 JCK manual awt/Desktop tests fail with GTKLookAndFeel - GTK intialization issue Reviewed-by: anthony, art Contributed-by: alexander.zvegintsev at oracle.com + src/solaris/classes/sun/misc/GThreadHelper.java ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c Changeset: 89546b9be510 Author: serb Date: 2013-10-15 20:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89546b9be510 8025225: Window.setAlwaysOnTop documentation should be updated Reviewed-by: anthony, art Contributed-by: alexander.zvegintsev at oracle.com ! src/share/classes/java/awt/Window.java Changeset: 229b10e97bd2 Author: bagiras Date: 2013-10-16 19:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/229b10e97bd2 2228674: Fix failed for CR 7162144 Reviewed-by: art, anthony ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java Changeset: 70242d821c66 Author: serb Date: 2013-10-17 20:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70242d821c66 8022657: Add FunctionalInterface annotation to awt interfaces Reviewed-by: anthony, art ! src/share/classes/java/awt/KeyEventDispatcher.java ! src/share/classes/java/awt/KeyEventPostProcessor.java Changeset: 3c2d4569a6a3 Author: serb Date: 2013-10-17 21:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c2d4569a6a3 8026356: [macosx] Found one Java-level deadlock:"AWT-EventQueue-0" && main Reviewed-by: anthony, art ! src/share/classes/java/awt/Component.java Changeset: 5334c651c7ba Author: yan Date: 2013-10-18 15:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5334c651c7ba 7002846: Fix for 6989505 may be incomplete Reviewed-by: anthony, art Contributed-by: Andrei Eremeev ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h Changeset: 84ae644933b6 Author: serb Date: 2013-10-18 20:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84ae644933b6 8026476: Choice does not get mouse events if it does not have enough place for popup menu Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XChoicePeer.java Changeset: d72ca6dac444 Author: leonidr Date: 2013-10-22 16:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d72ca6dac444 8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.m + test/java/awt/event/KeyEvent/8020209/bug8020209.java ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 4ad826a08e6f Author: serb Date: 2013-10-23 16:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4ad826a08e6f 8020851: java.awt.event.WindowEvent spec should state that WINDOW_CLOSED event may not be delivered under certain circumstances Reviewed-by: anthony, art ! src/share/classes/java/awt/event/WindowEvent.java Changeset: cd2e3c63ee42 Author: serb Date: 2013-10-24 14:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd2e3c63ee42 7090424: TestGlyphVectorLayout failed automately with java.lang.StackOverflowError Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XButtonPeer.java ! src/solaris/classes/sun/awt/X11/XCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XLabelPeer.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java + test/java/awt/Paint/ButtonRepaint.java + test/java/awt/Paint/CheckboxRepaint.java + test/java/awt/Paint/ExposeOnEDT.java + test/java/awt/Paint/LabelRepaint.java + test/java/awt/Paint/ListRepaint.java Changeset: 7c84aff91033 Author: pchelko Date: 2013-10-24 19:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7c84aff91033 8027030: AWT Multiple JVM DnD Test Failing on Linux (OEL and Ubuntu) and Solaris (Sparc and x64) Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: c561db53a24c Author: pchelko Date: 2013-10-24 19:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c561db53a24c 8027025: [macosx] getLocationOnScreen returns 0 if parent invisible Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Window/8027025/Test8027025.java Changeset: 6fe5443c3dde Author: alitvinov Date: 2013-10-25 13:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6fe5443c3dde 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays Reviewed-by: alexsch, malenkov Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + test/java/beans/XMLEncoder/Test8027066.java Changeset: 75ae2a980db5 Author: malenkov Date: 2013-10-25 16:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/75ae2a980db5 8026705: [TEST_BUG] java/beans/Introspector/TestTypeResolver.java failed Reviewed-by: art, jfranck ! test/java/beans/Introspector/TestTypeResolver.java Changeset: dab1d3798016 Author: serb Date: 2013-10-25 19:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dab1d3798016 7172770: Default Toolkit implementation return null value for property "awt.dynamicLayoutSupported" Reviewed-by: anthony, art ! src/share/classes/java/awt/Toolkit.java Changeset: 162c57b874d4 Author: lana Date: 2013-10-25 10:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/162c57b874d4 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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 - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html ! src/share/classes/java/awt/datatransfer/DataFlavor.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/sun/awt/AppContext.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 55cab2211ae9 Author: ant Date: 2013-10-29 16:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/55cab2211ae9 8027157: [SwingNode] needs explicit expose for JWindow Reviewed-by: art, anthony ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: bedc29a6d074 Author: malenkov Date: 2013-10-29 17:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bedc29a6d074 8022746: List of spelling errors in API doc Reviewed-by: alexsch, smarks ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/com/apple/laf/AquaMenuPainter.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTreeUI.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/font/CFontManager.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/CTextPipe.m ! src/share/back/commonRef.c ! src/share/back/eventFilter.c ! src/share/back/util.c ! src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java ! src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java ! src/share/classes/com/sun/beans/decoder/ByteElementHandler.java ! src/share/classes/com/sun/beans/decoder/CharElementHandler.java ! src/share/classes/com/sun/beans/decoder/ClassElementHandler.java ! src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java ! src/share/classes/com/sun/beans/decoder/ElementHandler.java ! src/share/classes/com/sun/beans/decoder/FalseElementHandler.java ! src/share/classes/com/sun/beans/decoder/FieldElementHandler.java ! src/share/classes/com/sun/beans/decoder/FloatElementHandler.java ! src/share/classes/com/sun/beans/decoder/IntElementHandler.java ! src/share/classes/com/sun/beans/decoder/JavaElementHandler.java ! src/share/classes/com/sun/beans/decoder/LongElementHandler.java ! src/share/classes/com/sun/beans/decoder/MethodElementHandler.java ! src/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/share/classes/com/sun/beans/decoder/NullElementHandler.java ! src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java ! src/share/classes/com/sun/beans/decoder/ShortElementHandler.java ! src/share/classes/com/sun/beans/decoder/StringElementHandler.java ! src/share/classes/com/sun/beans/decoder/TrueElementHandler.java ! src/share/classes/com/sun/beans/decoder/VarElementHandler.java ! src/share/classes/com/sun/beans/decoder/VoidElementHandler.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormat.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/TokenMgrError.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgentMBean.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpTableSupport.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/Filter.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java ! src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/ssl/internal/ssl/Provider.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/package.html ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/jdi/SocketAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java ! src/share/classes/com/sun/tools/jdi/ThreadListener.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/AlphaComposite.java ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Graphics.java ! src/share/classes/java/awt/Graphics2D.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MediaTracker.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MultipleGradientPaintContext.java ! src/share/classes/java/awt/Polygon.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/Shape.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/FlavorMap.java ! src/share/classes/java/awt/datatransfer/MimeTypeParameterList.java ! src/share/classes/java/awt/dnd/DragGestureListener.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/font/FontRenderContext.java ! src/share/classes/java/awt/font/GlyphMetrics.java ! src/share/classes/java/awt/font/GlyphVector.java ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TransformAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/java/awt/geom/QuadCurve2D.java ! src/share/classes/java/awt/im/InputMethodRequests.java ! src/share/classes/java/awt/image/BandedSampleModel.java ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ComponentColorModel.java ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/java/awt/image/ImageConsumer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/PixelInterleavedSampleModel.java ! src/share/classes/java/awt/image/renderable/RenderableImage.java ! src/share/classes/java/awt/image/renderable/RenderableImageOp.java ! src/share/classes/java/beans/AppletInitializer.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextServiceRevokedListener.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectStreamConstants.java ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/net/Authenticator.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/java/net/InterfaceAddress.java ! src/share/classes/java/net/JarURLConnection.java ! src/share/classes/java/net/ServerSocket.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/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/nio/channels/AsynchronousChannelGroup.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/security/AccessControlException.java ! src/share/classes/java/security/DigestOutputStream.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/cert/CertificateRevokedException.java ! src/share/classes/java/security/spec/ECFieldF2m.java ! src/share/classes/java/sql/Array.java ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/Blob.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Clob.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DataTruncation.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/DriverPropertyInfo.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLIntegrityConstraintViolationException.java ! src/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java ! src/share/classes/java/sql/SQLNonTransientConnectionException.java ! src/share/classes/java/sql/SQLNonTransientException.java ! src/share/classes/java/sql/SQLRecoverableException.java ! src/share/classes/java/sql/SQLSyntaxErrorException.java ! src/share/classes/java/sql/SQLTimeoutException.java ! src/share/classes/java/sql/SQLTransactionRollbackException.java ! src/share/classes/java/sql/SQLTransientConnectionException.java ! src/share/classes/java/sql/SQLTransientException.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Struct.java ! src/share/classes/java/sql/package.html ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/FieldPosition.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RuleBasedCollator.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/MissingFormatWidthException.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/accessibility/AccessibleText.java ! src/share/classes/javax/crypto/NullCipher.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/IIOParam.java ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/event/IIOReadProgressListener.java ! src/share/classes/javax/imageio/event/IIOReadUpdateListener.java ! src/share/classes/javax/imageio/event/IIOReadWarningListener.java ! src/share/classes/javax/imageio/event/IIOWriteWarningListener.java ! src/share/classes/javax/imageio/metadata/IIOMetadata.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormat.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageReaderWriterSpi.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/remote/rmi/package.html ! src/share/classes/javax/naming/Binding.java ! src/share/classes/javax/naming/InsufficientResourcesException.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/print/CancelablePrintJob.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/DocPrintJob.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/attribute/standard/MediaTray.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/share/classes/javax/print/package.html ! src/share/classes/javax/script/AbstractScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java ! src/share/classes/javax/script/Invocable.java ! src/share/classes/javax/script/ScriptEngine.java ! src/share/classes/javax/script/ScriptEngineFactory.java ! src/share/classes/javax/security/sasl/RealmChoiceCallback.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslClient.java ! src/share/classes/javax/security/sasl/SaslException.java ! src/share/classes/javax/smartcardio/CardChannel.java ! src/share/classes/javax/smartcardio/CardTerminal.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiMessage.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/Soundbank.java ! src/share/classes/javax/sound/midi/Synthesizer.java ! src/share/classes/javax/sound/sampled/AudioFormat.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sound/sampled/ReverbType.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java ! src/share/classes/javax/sql/rowset/spi/TransactionalWriter.java ! src/share/classes/javax/sql/rowset/spi/XmlReader.java ! src/share/classes/javax/sql/rowset/spi/XmlWriter.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultRowSorter.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/ScrollPaneConstants.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/plaf/ComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/LoweredBorder.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/table/TableColumnModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GapVector.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/CSSParser.java ! src/share/classes/javax/swing/text/html/FormSubmitEvent.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/FrameSetView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/HTMLFrameHyperlinkEvent.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/xml/crypto/KeySelector.java ! src/share/classes/javax/xml/crypto/MarshalException.java ! src/share/classes/javax/xml/crypto/dsig/TransformException.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java ! src/share/classes/jdi-overview.html ! src/share/classes/jdk/internal/org/objectweb/asm/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java ! src/share/classes/jdk/internal/org/xml/sax/EntityResolver.java ! src/share/classes/jdk/internal/util/xml/XMLStreamException.java ! src/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/share/classes/org/ietf/jgss/GSSContext.java ! src/share/classes/org/ietf/jgss/GSSCredential.java ! src/share/classes/org/ietf/jgss/GSSException.java ! src/share/classes/org/ietf/jgss/GSSManager.java ! src/share/classes/org/ietf/jgss/GSSName.java ! src/share/classes/org/ietf/jgss/package.html ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/font/ExtendedTextSourceLabel.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontRunIterator.java ! src/share/classes/sun/font/LayoutPathImpl.java ! src/share/classes/sun/font/ScriptRun.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/ProcessPath.java ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/pipe/BufferedMaskFill.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/FileMonitoredVm.java ! src/share/classes/sun/management/counter/perf/InstrumentationException.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/misc/CRC16.java ! src/share/classes/sun/misc/CharacterDecoder.java ! src/share/classes/sun/misc/PerformanceLogger.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/TelnetOutputStream.java ! src/share/classes/sun/net/ftp/FtpClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/idn/StringPrep.java ! src/share/classes/sun/net/smtp/SmtpProtocolException.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/http/PosterOutputStream.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/print/PSPathGraphics.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/print/PrintJob2D.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/rmi/rmic/RemoteClass.java ! src/share/classes/sun/rmi/rmic/Util.java ! src/share/classes/sun/rmi/rmic/newrmic/jrmp/StubSkeletonWriter.java ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/security/jca/GetInstance.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/DesCbcEType.java ! src/share/classes/sun/security/pkcs11/P11DHKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/certpath/AdjacencyList.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ReverseBuilder.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/x509/AlgIdDSA.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/Paint9Painter.java ! src/share/classes/sun/text/normalizer/ReplaceableUCharacterIterator.java ! src/share/classes/sun/text/resources/th/CollationData_th.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstat/ColumnFormat.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/tree/ExprExpression.java ! src/share/classes/sun/tools/tree/FieldExpression.java ! src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/TableExample/TableExample4.java ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/zip.cpp ! src/share/native/com/sun/media/sound/PlatformMidi.h ! src/share/native/common/jni_util.h ! src/share/native/java/lang/fdlibm/src/k_rem_pio2.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/awt/image/cvutils/img_dcm.h ! src/share/native/sun/awt/image/cvutils/img_replscale.h ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h ! src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/TibetanReordering.cpp ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/sample/jmx/jmx-scandir/index.html ! src/share/sample/nio/chatserver/ClientReader.java ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/font/XMap.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_BsdOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_SolarisOS_Utils.h ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/multiVis.c ! src/solaris/native/sun/security/smartcardio/MUSCLE/pcsclite.h ! src/windows/classes/com/sun/tools/jdi/SharedMemoryAttachingConnector.java ! src/windows/classes/com/sun/tools/jdi/SharedMemoryListeningConnector.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/net/DualStackPlainSocketImpl.c ! src/windows/native/java/net/icmp.h ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Dialog.h ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp Changeset: d4eb25382baf Author: malenkov Date: 2013-10-29 19:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d4eb25382baf 8027442: JDK compilation fails on MacOS Reviewed-by: alexsch, pchelko ! src/share/classes/java/awt/Component.java Changeset: a2b42e558211 Author: bagiras Date: 2013-10-29 21:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a2b42e558211 8027151: AWT_DnD/Basic_DnD/Automated/DnDMerlinQL/MultipleJVM failing on windows machine Reviewed-by: anthony, pchelko ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: db2838f25a85 Author: pchelko Date: 2013-10-30 12:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db2838f25a85 8027152: Regression: test closed/java/awt/Serialize/NullSerializationTest/NullSerializationTest.html fails since JDK 8 b112 Reviewed-by: art, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsSerialization/OwnedWindowsSerialization.java Changeset: 05f04b1c5bd0 Author: leonidr Date: 2013-10-30 20:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/05f04b1c5bd0 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/FullScreen/8013581/bug8013581.java Changeset: 6f436140049d Author: lana Date: 2013-10-31 16:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f436140049d Merge ! src/share/classes/java/awt/image/ComponentSampleModel.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 042a473535aa Author: mchung Date: 2013-10-17 19:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/042a473535aa 8025799: Restore sun.reflect.Reflection.getCallerClass(int) until a replacement API is provided Reviewed-by: alanb, forax, dholmes, twisti ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjava/reorder-sparc ! makefiles/mapfiles/libjava/reorder-sparcv9 ! makefiles/mapfiles/libjava/reorder-x86 ! src/share/classes/sun/reflect/Reflection.java ! src/share/javavm/export/jvm.h ! src/share/native/sun/reflect/Reflection.c + test/sun/reflect/Reflection/GetCallerClassWithDepth.java Changeset: 8a7b1b615100 Author: darcy Date: 2013-10-17 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a7b1b615100 8026840: Fix new doclint issues in javax.naming Reviewed-by: mchung ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/Context.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/ReferralException.java ! src/share/classes/javax/naming/directory/DirContext.java ! src/share/classes/javax/naming/event/EventContext.java ! src/share/classes/javax/naming/ldap/LdapContext.java ! src/share/classes/javax/naming/ldap/Rdn.java Changeset: 658e121bda42 Author: sherman Date: 2013-10-17 23:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/658e121bda42 8025971: Remove ZoneId.OLD_SHORT_IDS 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, remote file system Summary: removed the compatiblity old short-ids mapping Reviewed-by: okutsu ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/util/Calendar/JavatimeTest.java Changeset: 8479a48d9fd4 Author: sla Date: 2013-10-18 11:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8479a48d9fd4 8021897: EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() Reviewed-by: alanb, sspitsyn ! src/share/back/outStream.c + test/com/sun/jdi/GetUninitializedStringValue.java Changeset: da695008417f Author: alanb Date: 2013-10-18 13:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/da695008417f 8026859: (fs) test/java/nio/file/Files/StreamTest.java fails to compile intermittently Reviewed-by: psandoz ! test/java/nio/file/Files/StreamTest.java Changeset: 4e065f5b4a16 Author: igerasim Date: 2013-10-18 16:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4e065f5b4a16 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed Reviewed-by: alanb ! test/java/util/zip/GZIP/GZIPInZip.java Changeset: 329cf77821e8 Author: alanb Date: 2013-10-18 13:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/329cf77821e8 7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037 Reviewed-by: sherman, ulfzibis ! src/share/classes/sun/nio/fs/Util.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixMountEntry.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java Changeset: 4161f17dfe2b Author: sjiang Date: 2013-10-18 16:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4161f17dfe2b 8026028: [findbugs] findbugs report some issue in com.sun.jmx.snmp package Reviewed-by: psandoz, dfuchs ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java + test/com/sun/jmx/snmp/NoInfoLeakTest.java Changeset: 602aa6fa46c6 Author: alanb Date: 2013-10-18 15:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/602aa6fa46c6 8026876: (fs) Build issue with src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java Reviewed-by: psandoz ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java Changeset: 93f4f012deaf Author: alanb Date: 2013-10-18 16:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/93f4f012deaf Merge Changeset: 8d1d5a5aeb41 Author: robm Date: 2013-10-18 16:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d1d5a5aeb41 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds Reviewed-by: alanb Contributed-by: pavel.punegov at oracle.com ! test/java/lang/ProcessBuilder/InheritIOEHandle.java ! test/java/lang/ProcessBuilder/SiblingIOEHandle.java Changeset: 88436832cfd0 Author: dsamersoff Date: 2013-10-19 00:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88436832cfd0 8004213: JDP packet needs pid, broadcast interval and rmi server hostname fields Summary: Add some extra fileds to jdp packet Reviewed-by: allwin, sla, hirt ! src/share/classes/sun/management/jdp/JdpController.java ! src/share/classes/sun/management/jdp/JdpJmxPacket.java ! test/sun/management/jdp/JdpClient.java ! test/sun/management/jdp/JdpDoSomething.java ! test/sun/management/jdp/JdpTest.sh Changeset: 7a947daa8f51 Author: rriggs Date: 2013-10-18 16:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7a947daa8f51 8025828: Late binding of Chronology to appendValueReduced Summary: Add a listener to the parseContext called when the Chronology changes Reviewed-by: sherman ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! test/java/time/test/java/time/format/TestReducedParser.java Changeset: fbb7510f788d Author: vromero Date: 2013-10-19 17:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fbb7510f788d 8026854: java.time.temporal.TemporalQueries doesn't compile after javac modification to lambda flow analysis Reviewed-by: psandoz ! src/share/classes/java/time/temporal/TemporalQueries.java Changeset: 392acefef659 Author: dsamersoff Date: 2013-10-19 20:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/392acefef659 8024071: In ManagementAgent.start it should be possible to set the jdp.name parameter. Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/classes/sun/management/Agent.java ! test/sun/management/jdp/JdpTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: ede89a97e80a Author: ksrini Date: 2013-10-19 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ede89a97e80a 8026794: Test tools/pack200/TimeStamp.java fails while opening golden.jar.native.IST on linux-ppc(v2) Reviewed-by: dholmes ! src/share/native/com/sun/java/util/jar/pack/zip.cpp Changeset: 71ecbde5e5e4 Author: rfield Date: 2013-10-20 18:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71ecbde5e5e4 8025631: Enhance Lambda construction Reviewed-by: ksrini, ahgross ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java - src/share/classes/java/lang/invoke/MagicLambdaImpl.java Changeset: 30c46debdf0f Author: jbachorik Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30c46debdf0f 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues Reviewed-by: sla, mchung ! test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java Changeset: d8694ad1ed2d Author: jbachorik Date: 2013-10-21 10:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d8694ad1ed2d 8024613: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently Summary: RMID needs a varying amount of time to start its socket server. We need to cater for it. Reviewed-by: sjiang, dfuchs, sla ! test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java Changeset: 567d47fd3fe2 Author: dfuchs Date: 2013-10-21 11:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/567d47fd3fe2 8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7 Summary: When storing Properties to XML only locally defined properties must be saved. Reviewed-by: psandoz, mchung, alanb ! src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java + test/java/util/Properties/LoadAndStoreXMLWithDefaults.java Changeset: c81125493ca6 Author: dfuchs Date: 2013-10-21 12:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c81125493ca6 8026499: Root Logger level can be reset unexpectedly Summary: This fix prevents the logger's level to be re-initialized if it has already been initialized. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java Changeset: 698baf22e081 Author: jbachorik Date: 2013-10-21 13:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/698baf22e081 7140929: NotSerializableNotifTest.java fails intermittently Reviewed-by: sjiang, alanb ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java Changeset: f0c18a5e3ae5 Author: sherman Date: 2013-10-21 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f0c18a5e3ae5 8026842: Remove Time-Zone IDs HST/EST/MST Summary: removed these ids from ZoneId's zid list, supported via short_ids list Reviewed-by: okutsu ! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java Changeset: c1700125d041 Author: darcy Date: 2013-10-21 12:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1700125d041 8022658: Revisit FunctionalInterface on some core libs types Reviewed-by: briangoetz, mduigou, mr ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/Flushable.java ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Comparable.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Readable.java Changeset: e8683d5b2b0a Author: peytoia Date: 2013-10-22 06:13 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8683d5b2b0a 8020037: String.toLowerCase incorrectly increases length, if string contains \u0130 char Reviewed-by: naoto ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/String.java ! test/java/lang/String/ToLowerCase.java Changeset: 3b00bf85a6f5 Author: sherman Date: 2013-10-21 18:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b00bf85a6f5 8008386: (cs) Unmappable leading should be decoded to replacement. Summary: updated the unmappable/malformed detecting handling for db charsets Reviewed-by: naoto ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! test/sun/nio/cs/TestIBMBugs.java + test/sun/nio/cs/TestUnmappable.java Changeset: f581b72e3715 Author: sla Date: 2013-10-21 23:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f581b72e3715 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: coleenp, dcubed, sspitsyn ! test/java/lang/instrument/RedefineMethodInBacktrace.sh ! test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java + test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java Changeset: 975e3a89814e Author: darcy Date: 2013-10-21 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/975e3a89814e 8024603: Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build Reviewed-by: erikj, ihse, chegar ! makefiles/Setup.gmk Changeset: f443d9b863cf Author: juh Date: 2013-10-21 22:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f443d9b863cf Merge Changeset: d0882a1deeb5 Author: juh Date: 2013-10-22 03:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d0882a1deeb5 Merge Changeset: 04ba97b7c2f9 Author: jfranck Date: 2013-10-22 10:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04ba97b7c2f9 8009411: (reflect) Class.getMethods should not include static methods from interfaces Summary: Update getMethods() and getMethod() to filter out interface statics Reviewed-by: darcy Contributed-by: joel.franck at oracle.com, andreas.lundblad at oracle.com, amy.lu at oracle.com, peter.levart at gmail.com ! src/share/classes/java/lang/Class.java ! test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java ! test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java + test/java/lang/reflect/Method/InterfaceStatic/StaticInterfaceMethodInWayOfDefault.java Changeset: bb2fb6be8b2a Author: ykantser Date: 2013-10-22 10:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb2fb6be8b2a 8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt Reviewed-by: sla, jbachorik ! test/ProblemList.txt Changeset: b07856d0de34 Author: alundblad Date: 2013-10-22 12:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b07856d0de34 8004912: Repeating annotations - getAnnotationsByType(Class) is not working as expected for few inheritance scenarios 8019420: Repeatable non-inheritable annotation types are mishandled by Core Reflection Reviewed-by: jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/NonInheritableContainee.java + test/java/lang/annotation/repeatingAnnotations/OrderUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java Changeset: 6f9515a9519f Author: alanb Date: 2013-10-22 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f9515a9519f 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks, mullan Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: f15ad52cffed Author: alanb Date: 2013-10-22 12:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f15ad52cffed 8024833: (fc) FileChannel.map does not handle async close/interrupt correctly Reviewed-by: alanb Contributed-by: chris.w.dennis at gmail.com ! src/share/classes/sun/nio/ch/FileChannelImpl.java + test/java/nio/channels/FileChannel/InterruptMapDeadlock.java Changeset: 6a1989dc302d Author: igerasim Date: 2013-10-15 18:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a1989dc302d 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build Summary: Removing the test as it is unreliable and fails intermittently Reviewed-by: chegar - test/java/net/NetworkInterface/MemLeakTest.java Changeset: 7cafbb397683 Author: chegar Date: 2013-10-22 14:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7cafbb397683 8017779: java/net/Authenticator/B4769350.java fails Reviewed-by: chegar Contributed-by: Tristan Yan , Kurchi Subhra Hazra ! test/java/net/Authenticator/B4769350.java Changeset: 5f4aecd73caa Author: mullan Date: 2013-10-22 08:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f4aecd73caa 8021191: Add isAuthorized check to limited doPrivileged methods Reviewed-by: weijun, xuelei ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java Changeset: 948b390b6952 Author: mullan Date: 2013-10-22 08:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/948b390b6952 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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 - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/lang/invoke/MagicLambdaImpl.java - src/share/classes/java/net/HttpURLPermission.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 3ea9af449b36 Author: mullan Date: 2013-10-22 09:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3ea9af449b36 Merge - test/java/net/NetworkInterface/MemLeakTest.java Changeset: 54869853c06c Author: alanb Date: 2013-10-22 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54869853c06c 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win) Reviewed-by: chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! test/java/nio/channels/SocketChannel/ShortWrite.java Changeset: 9758edb6976f Author: bpb Date: 2013-10-22 10:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9758edb6976f 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6 Summary: Check getaddrinfo return value before calling WSAGetLastError. Reviewed-by: alanb, dsamersoff ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: 23b124cbf242 Author: drchase Date: 2013-10-22 12:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23b124cbf242 8026818: Defmeth failures with -mode invoke Summary: Added test for IllegalAccessException -> IllegalAccessError path to check if root cause was AbstractMethodError Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 72c0f289a8cb Author: kizune Date: 2013-10-22 22:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72c0f289a8cb 8026873: tools/launcher/VersionCheck.java fails in jprt because of jmc.ini Reviewed-by: ksrini ! test/tools/launcher/VersionCheck.java Changeset: 2be08cdd1ced Author: bpb Date: 2013-10-22 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2be08cdd1ced 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE 6445180: URLClassLoader does not describe the behavior of several methods with respect to null arguments Summary: Document when a NPE will be thrown by URLClassLoader constructors, newInstance(), findClass(), and getPermissions(). Reviewed-by: alanb, mduigou, chegar, dholmes, jrose ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/sun/applet/AppletClassLoader.java + test/java/net/URLClassLoader/NullURLTest.java Changeset: c956a5d0618f Author: juh Date: 2013-10-22 11:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c956a5d0618f 8025287: NPE in api/java_security/cert/PKIXRevocationChecker/GeneralTests_GeneralTests Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 9a32af82bd1e Author: darcy Date: 2013-10-22 12:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9a32af82bd1e 8027062: Fix lint and doclint issues in java.lang.{ClassLoader, ClassValue, SecurityManager} Reviewed-by: chegar, forax, alanb, mduigou ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/SecurityManager.java Changeset: e2b814e68956 Author: rriggs Date: 2013-10-22 15:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2b814e68956 8024686: Cleanup of java.time serialization source Summary: optimize serialized form of OffsetTime, OffsetDateTime; correct order of modifiers Reviewed-by: sherman ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java Changeset: d5c2b125ed0f Author: rriggs Date: 2013-10-22 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d5c2b125ed0f Merge Changeset: cd60848c87b2 Author: rriggs Date: 2013-10-22 15:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd60848c87b2 Merge Changeset: 4bb758a77fd7 Author: rriggs Date: 2013-10-22 17:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bb758a77fd7 8026982: javadoc errors in core libs Summary: Cleanup of javadoc -Xlint errors Reviewed-by: lancea, mduigou, darcy, mullan, mchung ! src/share/classes/java/io/ByteArrayInputStream.java ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/DataOutput.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/InputStream.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/PipedReader.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/Serializable.java ! src/share/classes/java/io/SerializablePermission.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/ArrayStoreException.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassCastException.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/Iterable.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/reflect/ReflectPermission.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/net/URLPermission.java ! src/share/classes/java/net/package-info.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Key.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Permission.java ! src/share/classes/java/security/PermissionCollection.java ! src/share/classes/java/security/SecurityPermission.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/java/security/acl/Acl.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/security/cert/PolicyQualifierInfo.java ! src/share/classes/java/security/cert/TrustAnchor.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/Normalizer.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/Queue.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java Changeset: e84413f066e0 Author: mfang Date: 2013-10-22 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e84413f066e0 8026109: [ja] overtranslation of jarsigner in command line output Reviewed-by: naoto ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java Changeset: 25ebb8b61371 Author: mfang Date: 2013-10-22 14:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25ebb8b61371 6607048: clear extra l10n resource files in demo Reviewed-by: naoto, yhuang - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties Changeset: f2ddffb4b165 Author: mfang Date: 2013-10-22 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2ddffb4b165 Merge Changeset: 9fbf35589211 Author: smarks Date: 2013-10-22 14:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9fbf35589211 8026427: deprecate obsolete APIs from java.rmi Reviewed-by: alanb, dfuchs ! src/share/classes/java/rmi/RMISecurityManager.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/server/ServerRef.java ! src/share/classes/java/rmi/server/SocketSecurityException.java Changeset: 0913c3bab168 Author: henryjen Date: 2013-10-22 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0913c3bab168 8025909: Lambda Library Spec Updates 8024179: Document limitations and performance characteristics of stream sources and operations 8024138: (Spec clarification) Lambda Metafacory spec should state DMH constraint on implMethod Reviewed-by: mduigou Contributed-by: brian.goetz at oracle.com, paul.sandoz at oracle.com ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/PrimitiveIterator.java ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/function/package-info.java ! src/share/classes/java/util/stream/BaseStream.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java Changeset: fc7a6fa3589a Author: ascarpino Date: 2013-10-22 19:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fc7a6fa3589a 8025763: Provider does not override new Hashtable methods Reviewed-by: mullan ! src/share/classes/java/security/Provider.java Changeset: b065de1700d3 Author: mullan Date: 2013-10-22 19:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b065de1700d3 Merge - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties Changeset: d545d67e2f68 Author: weijun Date: 2013-10-23 08:32 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d545d67e2f68 8027026: Change keytool -genkeypair to use -keyalg RSA Reviewed-by: alanb, chegar, mullan ! test/ProblemList.txt ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/collator.sh ! test/sun/security/tools/jarsigner/crl.sh ! test/sun/security/tools/jarsigner/jvindex.sh ! test/sun/security/tools/jarsigner/newsize7.sh ! test/sun/security/tools/jarsigner/onlymanifest.sh ! test/sun/security/tools/jarsigner/passtype.sh ! test/sun/security/tools/jarsigner/samename.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/ListKeychainStore.sh ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/emptysubject.sh ! test/sun/security/tools/keytool/importreadall.sh ! test/sun/security/tools/keytool/p12importks.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/selfissued.sh ! test/sun/security/tools/keytool/trystore.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh Changeset: c077a2810782 Author: egahlin Date: 2013-10-23 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c077a2810782 7105883: JDWP: agent crash if there exists a ThreadGroup with null name Reviewed-by: sla, jbachorik ! src/share/back/ThreadGroupReferenceImpl.c + test/com/sun/jdi/NullThreadGroupNameTest.java Changeset: 1b0dfa631b6f Author: michaelm Date: 2013-10-23 11:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b0dfa631b6f 8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/URLPermission/nstest/LookupTest.java + test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/java/net/URLPermission/nstest/SimpleNameService.java + test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java + test/java/net/URLPermission/nstest/policy Changeset: f4970c7abe93 Author: jbachorik Date: 2013-10-23 15:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4970c7abe93 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools Reviewed-by: mchung, sjiang ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java Changeset: f120672b91ef Author: chegar Date: 2013-10-23 14:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f120672b91ef 8020758: HttpCookie constructor does not throw IAE when name contains a space Reviewed-by: michaelm, msheppar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java Changeset: 8c20e9ef8709 Author: sla Date: 2013-10-23 15:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8c20e9ef8709 8026789: Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection Reviewed-by: dcubed ! test/ProblemList.txt + test/java/lang/instrument/NMTHelper.java ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java Changeset: 3cdf6ca3ef47 Author: kizune Date: 2013-10-23 18:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3cdf6ca3ef47 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking Reviewed-by: alanb, ksrini ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties + test/tools/jar/normalize/TestNormal.java Changeset: 2af3f5a61322 Author: coffeys Date: 2013-10-23 16:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2af3f5a61322 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks + test/com/sun/corba/5036554/JavaBug.java + test/com/sun/corba/5036554/README + test/com/sun/corba/5036554/TestCorbaBug.sh + test/com/sun/corba/5036554/bug.idl Changeset: 88acc99132e2 Author: rfield Date: 2013-10-23 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88acc99132e2 8027176: Remove redundant jdk/lambda/vm/DefaultMethodsTest.java Reviewed-by: ksrini - test/jdk/lambda/vm/DefaultMethodsTest.java Changeset: ee7f1c78bec7 Author: coffeys Date: 2013-10-23 20:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ee7f1c78bec7 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs Reviewed-by: chegar ! test/javax/xml/ws/clientjar/TestWsImport.java Changeset: f4129fcfacdc Author: mduigou Date: 2013-10-23 14:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f4129fcfacdc 8024688: further split Map and ConcurrentMap defaults eliminating looping from Map defaults, Map.merge fixes and doc fixes. Reviewed-by: psandoz, dholmes ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java Changeset: d9d3705a992f Author: rfield Date: 2013-10-23 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d9d3705a992f 8025868: Several lang/LMBD JCK tests fail with java.lang.BootstrapMethodError Summary: Wildcard marker interfaces can cause duplicate implemented interfaces in generated lambda class Reviewed-by: briangoetz ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/DupIntf.java Changeset: c9562ac9b812 Author: dxu Date: 2013-10-23 22:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9562ac9b812 7122887: JDK ignores Gnome3 proxy settings Summary: Fix GConf and add to use GProxyResolver to handle network proxy resolution Reviewed-by: chegar ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! test/java/net/ProxySelector/SystemProxies.java Changeset: e6bc0dca294b Author: sla Date: 2013-10-15 12:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6bc0dca294b 8009681: TEST_BUG: MethodExitReturnValuesTest.java may fail when there are unexpected background threads Reviewed-by: sla, allwin Contributed-by: mikael.auno at oracle.com ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java Changeset: 700d62b8d9cc Author: alanb Date: 2013-10-24 13:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/700d62b8d9cc 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable Reviewed-by: rriggs, psandoz, chegar Contributed-by: dl at cs.oswego.edu, alan.bateman at oracle.com ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAdder.java + test/java/util/concurrent/atomic/Serial.java Changeset: e2ec05b2ed94 Author: igerasim Date: 2013-10-23 15:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e2ec05b2ed94 8024521: (process) Async close issues with Process InputStream Reviewed-by: psandoz, martin, alanb, robm ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux + test/java/lang/Runtime/exec/CloseRace.java Changeset: b8927cbfb893 Author: alundblad Date: 2013-10-24 18:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8927cbfb893 8027170: Annotations declared on super-super-class should be overridden by super-class. Reviewed-by: jfranck Contributed-by: andreas.lundblad at oracle.com, peter.levart at gmail.com ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java + test/java/lang/annotation/repeatingAnnotations/InheritedAssociatedAnnotations.java Changeset: 808b9ef4f667 Author: smarks Date: 2013-10-24 10:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/808b9ef4f667 8023862: deprecate HTTP proxying from RMI Reviewed-by: mchung ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/package.html ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java + test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java Changeset: 5fa2fd782993 Author: briangoetz Date: 2013-10-24 13:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5fa2fd782993 8019646: Clarify javadoc contract of LambdaMetafactory Reviewed-by: briangoetz, rfield Contributed-by: dan.smith at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java Changeset: 93e696ba5923 Author: jfranck Date: 2013-10-24 19:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/93e696ba5923 8023651: j.l.r.Constructor.getAnnotatedReceiverType() and j.l.r.Constructor.getAnnotatedReturnType() for inner classes return incorrect result Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/annotation/typeAnnotations/ConstructorReceiverTest.java Changeset: 66884b270b44 Author: twisti Date: 2013-10-24 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/66884b270b44 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: e7bdb2fcc7bc Author: sherman Date: 2013-10-24 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7bdb2fcc7bc 8025003: Base64 should be less strict with padding Summary: updated spec and implementation of mime decoder to be lenient for padding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/Base64GetEncoderTest.java ! test/java/util/Base64/TestBase64.java ! test/java/util/Base64/TestBase64Golden.java Changeset: 05dbf105e70f Author: joehw Date: 2013-10-24 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/05dbf105e70f 8004476: XSLT Extension Functions Don't Work in WebStart Reviewed-by: dfuchs, lancea, alanb + test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml + test/javax/xml/jaxp/transform/jdk8004476/TestBase.java + test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java + test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java + test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml + test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl Changeset: e9ec0ca5bab1 Author: weijun Date: 2013-10-25 08:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e9ec0ca5bab1 8026929: remove accelerators from policytool resources Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java Changeset: d126301ad372 Author: ewang Date: 2013-10-25 11:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d126301ad372 7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt Reviewed-by: alanb, chegar ! test/ProblemList.txt Changeset: 1153022c0a45 Author: jbachorik Date: 2013-10-25 13:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1153022c0a45 8004926: sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out Summary: Improve reliability by converting the test to Java Reviewed-by: dsamersoff, dholmes ! test/TEST.groups ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/lib/testlibrary/jdk/testlibrary/StreamPumper.java + test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh + test/sun/management/jmxremote/bootstrap/LocalManagementTest.java - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh ! test/sun/management/jmxremote/bootstrap/TestApplication.java ! test/sun/management/jmxremote/bootstrap/TestManager.java + test/sun/management/jmxremote/bootstrap/linux-amd64/launcher Changeset: 8ea272253285 Author: smarks Date: 2013-10-25 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8ea272253285 5063500: Formatter spec says "char" is not an integral type 7126305: Wrong Unicode value specified for format conversion character 'd' 8027287: incorrect example in Formatter javadoc Reviewed-by: rriggs, darcy, lancea ! src/share/classes/java/util/Formatter.java Changeset: af4dd45bc7f7 Author: dfuchs Date: 2013-10-28 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/af4dd45bc7f7 8026863: regression in anonymous Logger.setParent method Summary: restore behaviour of setParent in anonymous logger and clarifies the spec with respect to security permissions. Reviewed-by: mchung, prr ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/AnonymousLogger/TestAnonymousLogger.java Changeset: e7639b856256 Author: lana Date: 2013-10-28 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7639b856256 Merge Changeset: ecba02f6be31 Author: sla Date: 2013-10-29 08:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ecba02f6be31 8027371: Add JDI tests for breakpointing and stepping in lambda code Reviewed-by: mchung, sspitsyn + test/com/sun/jdi/LambdaBreakpointTest.java + test/com/sun/jdi/LambdaStepTest.java Changeset: d34c5e860d5f Author: aefimov Date: 2013-10-24 17:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d34c5e860d5f 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Reviewed-by: okutsu, mfang, alanb ! test/ProblemList.txt ! test/sun/util/resources/TimeZone/Bug6317929.java Changeset: a8bbd962f34a Author: jlaskey Date: 2013-01-28 16:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8bbd962f34a 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! THIRD_PARTY_README ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: 41654275896d Author: jlaskey Date: 2013-02-04 17:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/41654275896d Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java ! test/tools/launcher/VersionCheck.java Changeset: a174944b0c00 Author: jlaskey Date: 2013-02-21 15:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a174944b0c00 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/launchers/Makefile Changeset: 25db7658a063 Author: jlaskey Date: 2013-02-22 10:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25db7658a063 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/launchers/Makefile Changeset: ea22045ce09b Author: jlaskey Date: 2013-02-22 14:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea22045ce09b Merge ! makefiles/CreateJars.gmk Changeset: ff68fafd6302 Author: jlaskey Date: 2013-02-22 17:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff68fafd6302 8008756: THIRD_PARTY_README contains Unicode Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! THIRD_PARTY_README Changeset: ce82a0ee7735 Author: jlaskey Date: 2013-02-22 18:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce82a0ee7735 8008757: NEWBUILD=true has separate launcher code for jjs Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/CompileLaunchers.gmk Changeset: 20a827b22a2e Author: jlaskey Date: 2013-02-22 23:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/20a827b22a2e 8008775: Remove non-ascii from jdk/THIRD_PARTY_README Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! THIRD_PARTY_README Changeset: 364e0871f7a3 Author: jlaskey Date: 2013-03-02 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/364e0871f7a3 Merge ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - test/javax/script/RhinoExceptionTest.java ! test/tools/launcher/VersionCheck.java Changeset: 3565c755c49f Author: jlaskey Date: 2013-03-15 11:51 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3565c755c49f Merge ! makefiles/CreateJars.gmk Changeset: 8c223a4f906a Author: jlaskey Date: 2013-03-26 09:12 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8c223a4f906a Merge ! makefiles/CreateJars.gmk Changeset: efbbcd5848cf Author: jlaskey Date: 2013-04-01 10:09 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/efbbcd5848cf Merge Changeset: 39ce82dad57d Author: jlaskey Date: 2013-04-09 08:36 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39ce82dad57d Merge Changeset: ff9683b6854c Author: jlaskey Date: 2013-04-15 08:27 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff9683b6854c Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk Changeset: 1cdf20da340b Author: jlaskey Date: 2013-04-17 08:47 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1cdf20da340b Merge Changeset: 72fa581a83a4 Author: jlaskey Date: 2013-04-22 14:00 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/72fa581a83a4 Merge Changeset: ead9944bbb3b Author: jlaskey Date: 2013-04-29 21:37 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ead9944bbb3b Merge Changeset: 5bde43b1e463 Author: jlaskey Date: 2013-05-14 09:04 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bde43b1e463 Merge Changeset: efd620f8963f Author: jlaskey Date: 2013-05-23 09:48 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/efd620f8963f Merge ! makefiles/CreateJars.gmk Changeset: 193652dff077 Author: jlaskey Date: 2013-05-29 13:22 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/193652dff077 Merge Changeset: 733713d7517c Author: jlaskey Date: 2013-06-05 13:10 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/733713d7517c Merge ! makefiles/CompileLaunchers.gmk Changeset: 3b464e13a776 Author: jlaskey Date: 2013-07-16 09:09 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3b464e13a776 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: c0a2094aaafd Author: jlaskey Date: 2013-07-24 08:22 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c0a2094aaafd Merge - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html Changeset: 528fc8f4281b Author: jlaskey Date: 2013-08-27 16:06 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/528fc8f4281b Merge ! makefiles/CompileLaunchers.gmk Changeset: be6ca7197e0e Author: jlaskey Date: 2013-09-13 10:15 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/be6ca7197e0e Merge ! makefiles/CreateJars.gmk - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: 74b1eb493407 Author: jlaskey Date: 2013-09-30 10:24 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/74b1eb493407 Merge ! makefiles/CreateJars.gmk Changeset: f5c9333b6129 Author: jlaskey Date: 2013-10-29 10:40 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f5c9333b6129 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: 121c34517841 Author: chegar Date: 2013-10-29 17:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/121c34517841 8027466: Revert jdk/THIRD_PARTY_README to known good version Reviewed-by: alanb ! THIRD_PARTY_README Changeset: 6fc2889fe7d0 Author: mfang Date: 2013-10-29 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6fc2889fe7d0 8026108: [it, ja, zh_CN] wrong translation in jar example. Reviewed-by: okutsu, yhuang ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties Changeset: 0cc9bdb22911 Author: mfang Date: 2013-10-29 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0cc9bdb22911 8008437: [sv] over-translation in java command line outputs Reviewed-by: okutsu, yhuang ! src/share/classes/sun/tools/jar/resources/jar_sv.properties Changeset: 331d8ced56dc Author: mfang Date: 2013-10-29 11:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/331d8ced56dc 8025646: [pt_BR] overtranslation of option in java command line output Reviewed-by: naoto, yhuang ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties Changeset: a3ac9c0b19a9 Author: jbachorik Date: 2013-10-29 21:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a3ac9c0b19a9 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926 Reviewed-by: alanb, egahlin ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java Changeset: 8cfc73ad9f31 Author: mfang Date: 2013-10-29 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8cfc73ad9f31 8008647: [es] minor cosmetic issues in translated java command line outputs Reviewed-by: naoto ! src/share/classes/sun/tools/jar/resources/jar_es.properties Changeset: 4071c853edff Author: mfang Date: 2013-10-29 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4071c853edff Merge Changeset: bede752d1e3c Author: mfang Date: 2013-10-29 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bede752d1e3c 8025521: [de] mnemonic conflict in FileChooser for GTK Style feel&look Reviewed-by: naoto ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties Changeset: 5d1bda6c1fe3 Author: jbachorik Date: 2013-10-30 14:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d1bda6c1fe3 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector Summary: Dynamically discover the first available port instead of hard-coding one Reviewed-by: sla, chegar, dfuchs ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java Changeset: 9a5048dc7c0d Author: chegar Date: 2013-10-30 14:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9a5048dc7c0d 8026880: NetworkInterface native initializing code should check fieldID values Reviewed-by: alanb ! src/solaris/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.c Changeset: b04b124418d8 Author: ykantser Date: 2013-10-30 13:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b04b124418d8 8022229: Intermittent test failures in sun/tools/jstatd Reviewed-by: sla, egahlin, jbachorik, allwin + test/lib/testlibrary/jdk/testlibrary/Asserts.java + test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java + test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java + test/lib/testlibrary/jdk/testlibrary/Platform.java + test/lib/testlibrary/jdk/testlibrary/ProcessThread.java + test/lib/testlibrary/jdk/testlibrary/TestThread.java + test/lib/testlibrary/jdk/testlibrary/Utils.java + test/lib/testlibrary/jdk/testlibrary/XRun.java + test/sun/tools/jstatd/JstatGCUtilParser.java + test/sun/tools/jstatd/JstatdTest.java + test/sun/tools/jstatd/TestJstatdDefaults.java + test/sun/tools/jstatd/TestJstatdExternalRegistry.java + test/sun/tools/jstatd/TestJstatdPort.java + test/sun/tools/jstatd/TestJstatdPortAndServer.java + test/sun/tools/jstatd/TestJstatdServer.java + test/sun/tools/jstatd/TestJstatdUsage.java - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out Changeset: 550244957351 Author: mfang Date: 2013-10-30 09:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/550244957351 6192407: s10_70, ko, s1/dvd, minor misspelling under "Select Software Localizations" Reviewed-by: yhuang ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e45b48874ba9 Author: mfang Date: 2013-10-30 09:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e45b48874ba9 6931564: Incorrect display name of Locale for south africa Reviewed-by: yhuang ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 2a714dabb624 Author: jbachorik Date: 2013-10-30 17:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2a714dabb624 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool Reviewed-by: mchung, brutisso ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java Changeset: 7bc67bed3c14 Author: michaelm Date: 2013-10-30 18:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bc67bed3c14 8027570: NullPointerException in URLPermission.hashCode() Reviewed-by: chegar ! src/share/classes/java/net/URLPermission.java ! test/java/net/URLPermission/URLPermissionTest.java Changeset: 281e26d7f325 Author: michaelm Date: 2013-10-30 18:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/281e26d7f325 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.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 - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/lang/invoke/MagicLambdaImpl.java ! src/share/classes/java/net/URLPermission.java - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/java/net/NetworkInterface/MemLeakTest.java - test/jdk/lambda/vm/DefaultMethodsTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out Changeset: 348ffbd19feb Author: lana Date: 2013-10-30 13:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/348ffbd19feb Merge ! makefiles/CreateJars.gmk + makefiles/CreateSecurityJars.gmk Changeset: ddb0b681654a Author: briangoetz Date: 2013-10-29 12:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ddb0b681654a 8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas Reviewed-by: rfield, psandoz ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java Changeset: f731d096530f Author: wetmore Date: 2013-10-30 16:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f731d096530f 8027526: CheckTipsAndVersions.java failing occasionally Reviewed-by: mullan, mchung ! test/java/security/Signature/SignatureGetAlgorithm.java Changeset: e8894e3224d9 Author: darcy Date: 2013-10-30 17:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8894e3224d9 8005294: Consider default methods for additions to AnnotatedElement Reviewed-by: jfranck, plevart, mchung, abuckley, sogoel ! src/share/classes/java/lang/reflect/AnnotatedElement.java + test/java/lang/reflect/AnnotatedElement/TestAnnotatedElementDefaults.java Changeset: 0734e1584d9d Author: bpb Date: 2013-10-30 17:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0734e1584d9d 6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers 8021203: BigInteger.doubleValue/floatValue returns 0.0 instead of Infinity 8021204: Constructor BigInteger(String val, int radix) doesn't detect overflow 8022780: Incorrect BigInteger division because of MutableBigInteger.bitLength() overflow Summary: Prevent construction of overflowed BigIntegers. Reviewed-by: bpb, darcy, psandoz Contributed-by: Dmitry Nadezhin ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/MutableBigInteger.java + test/java/math/BigInteger/BitLengthOverflow.java + test/java/math/BigInteger/DivisionOverflow.java + test/java/math/BigInteger/DoubleValueOverflow.java ! test/java/math/BigInteger/ExtremeShiftingTests.java + test/java/math/BigInteger/StringConstructorOverflow.java + test/java/math/BigInteger/SymmetricRangeTests.java Changeset: 1ea1b24c1a04 Author: smarks Date: 2013-10-30 18:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ea1b24c1a04 8023863: deprecate support for statically-generated stubs from RMI (JRMP) 4449028: exportObject() javadoc should specify behavior for null socket factories Reviewed-by: dfuchs, darcy ! src/share/classes/java/rmi/server/RemoteStub.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java ! src/share/classes/java/rmi/server/package.html Changeset: 18c111c17231 Author: psandoz Date: 2013-10-31 11:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/18c111c17231 8027316: Distinct operation on an unordered stream should not be a barrier Reviewed-by: henryjen, mduigou, briangoetz ! src/share/classes/java/util/stream/DistinctOps.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java Changeset: bb4b1e1e390d Author: jbachorik Date: 2013-10-31 11:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb4b1e1e390d 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled Summary: Make the test less stringent by not requiring the number of loaded classes to increase by a specific number Reviewed-by: sla ! test/ProblemList.txt ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java Changeset: 82ee370c3d7e Author: briangoetz Date: 2013-10-31 10:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/82ee370c3d7e 8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types 8023984: Lambda linkage performance - use a method ref to a static factory instead of a ctor ref Reviewed-by: briangoetz, rfield Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java Changeset: 9732816c9d17 Author: briangoetz Date: 2013-10-29 12:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9732816c9d17 8024633: Lambda linkage performance - initialize generated class earlier Reviewed-by: briangoetz, rfield Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: e93de88661ab Author: dxu Date: 2013-10-31 11:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e93de88661ab 8027155: test/java/io/File/NulFile.java failing when test run in othervm mode Reviewed-by: mchung, alanb ! test/java/io/File/NulFile.java Changeset: c4bbd5963f9c Author: joehw Date: 2013-10-31 13:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c4bbd5963f9c 8024876: [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions Reviewed-by: chegar ! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java Changeset: f82b730c798b Author: lana Date: 2013-10-31 16:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f82b730c798b Merge - src/share/classes/java/lang/invoke/MagicLambdaImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/tools/jar/Main.java - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/zip.cpp ! src/solaris/classes/sun/nio/fs/UnixPath.java - test/java/net/NetworkInterface/MemLeakTest.java - test/jdk/lambda/vm/DefaultMethodsTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out Changeset: a389b4f5723f Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a389b4f5723f Added tag jdk8-b115 for changeset f82b730c798b ! .hgtags From john.coomes at oracle.com Thu Nov 7 11:34:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 19:34:01 +0000 Subject: hg: hsx/hotspot-main/langtools: 32 new changesets Message-ID: <20131107193540.1BECD62427@hg.openjdk.java.net> Changeset: 7af634b1fc5b Author: darcy Date: 2013-10-17 19:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7af634b1fc5b 8026838: Fix new doclint issues in javax.annotation.processing Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/Processor.java Changeset: 7de97abc4a5c Author: jjg Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7de97abc4a5c 8026749: Missing LV table in lambda bodies Reviewed-by: vromero, jlahoda ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/lambda/LocalVariableTable.java Changeset: 130b8c0e570e Author: bpatel Date: 2013-10-18 16:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/130b8c0e570e 8026567: Use meaningful style names for strong and italic styles. Reviewed-by: jjg ! 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/AnnotationTypeFieldWriterImpl.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/ClassWriterImpl.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/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.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/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.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/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLegacyTaglet/Check.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java ! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java ! test/com/sun/javadoc/testTagOutput/TestTagOutput.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java Changeset: c4292590fc70 Author: vromero Date: 2013-10-19 17:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c4292590fc70 8024809: javac, some lambda programs are rejected by flow analysis Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/lambda/8016081/T8016081.java ! test/tools/javac/lambda/LambdaExpr13.java + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTesta.java + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTesta.out + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTestb.java + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTestb.out ! test/tools/javac/lambda/TestSelfRef.java Changeset: e5d3cd43c85e Author: jjg Date: 2013-10-20 12:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e5d3cd43c85e 8025109: Better encapsulation for AnnotatedType Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: ae4f5cb78ebd Author: jjg Date: 2013-10-20 12:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ae4f5cb78ebd 8026791: wrong type_path encoded for method_return on an inner class constructor Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java Changeset: 399c738e5103 Author: ksrini Date: 2013-10-20 12:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/399c738e5103 8026931: MethodParameters tests failing on Windows Reviewed-by: jjg, vromero ! test/tools/javac/MethodParameters/Tester.java Changeset: 9f876bd43f55 Author: vromero Date: 2013-10-21 15:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9f876bd43f55 8026956: test tools/javac/lambda/TargetType58.java is failing after a libs change Reviewed-by: jfranck ! test/tools/javac/lambda/TargetType58.java Changeset: b82982ac3ca2 Author: darcy Date: 2013-10-21 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b82982ac3ca2 8026984: Clarity intended use of jdk.Exported Reviewed-by: psandoz, mr, alanb ! src/share/classes/jdk/Exported.java Changeset: ac839d6f4953 Author: jfranck Date: 2013-10-22 03:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ac839d6f4953 8026855: AnnoConstruct.getAnnotationsByType includes inherited indirectly present annotations even when containee type is not inheritable Summary: In AnnoConstruct.getAnnotationByType() check that the annotation sought after is inherited before looking on supertypes. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java + test/tools/javac/processing/model/element/TestNonInherited.java Changeset: 87c950ea88be Author: ksrini Date: 2013-10-21 20:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/87c950ea88be 8026758: Inefficient code in LambdaToMethod Reviewed-by: jjg, jlahoda, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java Changeset: f003f09144ff Author: jfranck Date: 2013-10-22 10:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f003f09144ff 8026857: AnnoConstruct.getAnnotationsByType does not search supertype for inherited annotations if @SomeContainer({}) is present Summary: An empty container should not stop javac from looking at supertypes for inherited repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java + test/tools/javac/processing/model/element/TestEmptyContainer.java Changeset: 963c57175e40 Author: vromero Date: 2013-10-22 13:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/963c57175e40 8025290: javac implicit versus explicit lambda compilation error Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java + test/tools/javac/lambda/T8025290/ExplicitVSImplicitLambdaTest.java Changeset: 6cd16d8ed2b9 Author: rfield Date: 2013-10-22 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6cd16d8ed2b9 8023668: Desugar serializable lambda bodies using more robust naming scheme Summary: lambda / bridged method-reference naming overhaul Reviewed-by: ksrini, briangoetz ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/MethodParameters/LambdaTest.out ! test/tools/javac/T8019486/WrongLVTForLambdaTest.java + test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java + test/tools/javac/lambda/lambdaNaming/after/TESTNameOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/after/TESTOrderOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/after/TESTTargetName.java + test/tools/javac/lambda/lambdaNaming/after/TESTTargetType.java + test/tools/javac/lambda/lambdaNaming/after/TESTTypesOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/after/TESTVariableAssignmentTarget.java + test/tools/javac/lambda/lambdaNaming/before/TESTNameOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/before/TESTOrderOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/before/TESTTargetName.java + test/tools/javac/lambda/lambdaNaming/before/TESTTargetType.java + test/tools/javac/lambda/lambdaNaming/before/TESTTypesOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/before/TESTVariableAssignmentTarget.java Changeset: 351d6808c1a5 Author: jjg Date: 2013-10-22 17:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/351d6808c1a5 8027119: Cleanup javadoc comments for taglet API Reviewed-by: mduigou ! src/share/classes/com/sun/javadoc/Tag.java Changeset: 41d3ffca22ff Author: jjg Date: 2013-10-22 17:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/41d3ffca22ff Merge Changeset: b05db8c815e8 Author: jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b05db8c815e8 8026508: Invokedynamic instructions don't get line number table entries Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLNTForLambdaTest.java - test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 32ea6ccb7607 Author: rfield Date: 2013-10-23 10:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/32ea6ccb7607 8022720: Method refeerences - private method should be accessible (nested classes) Reviewed-by: jjg, ksrini ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/privateMethodReferences/MethodInvoker.java + test/tools/javac/lambda/privateMethodReferences/MethodSupplier.java + test/tools/javac/lambda/privateMethodReferences/ThirdClass.java Changeset: 8746caa5cf80 Author: bpatel Date: 2013-10-23 13:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8746caa5cf80 8026770: javadoc creates invalid HTML in profile summary pages Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: abc3eaccba73 Author: jlahoda Date: 2013-10-23 23:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/abc3eaccba73 8027191: Fix for JDK-8026861 refers to an incorrect bug number Summary: Reverting changeset b05db8c815e8, so that it can be applied again with a correct bug number Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java - test/tools/javac/T8019486/WrongLNTForLambdaTest.java + test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 864dafc5ab7a Author: jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/864dafc5ab7a 8026861: Wrong LineNumberTable for variable declarations in lambdas Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLNTForLambdaTest.java - test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 31fe30e2deac Author: ksrini Date: 2013-10-23 15:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/31fe30e2deac 8026936: Initialize LamdbaToMethod lazily and as required Reviewed-by: jjg, rfield Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: d2fa3f7e964e Author: emc Date: 2013-10-23 23:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d2fa3f7e964e 8006732: support correct bytecode storage of type annotations in multicatch Summary: Fix issue with annotations being added before attribution, which causes multicatch not to work right and several tests to fail. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java Changeset: 119747cd9f25 Author: emc Date: 2013-10-24 01:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/119747cd9f25 8023682: Incorrect attributes emitted for anonymous class declaration Summary: Cause javac to emit type annotations on new instruction as well as anonymous class supertype for annotated anonymous classes. Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.java + test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java Changeset: 667843bd2193 Author: bpatel Date: 2013-10-24 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/667843bd2193 8006248: Since addition of -Xdoclint, javadoc ignores unknown tags Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java + test/com/sun/javadoc/testCustomTag/TagTestClass.java + test/com/sun/javadoc/testCustomTag/TestCustomTag.java + test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java + test/tools/doclint/CustomTagTest.java + test/tools/doclint/CustomTagTest.out + test/tools/doclint/CustomTagTestWithOption.out ! test/tools/doclint/DocLintTester.java Changeset: 860f1d21763a Author: rfield Date: 2013-10-24 16:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/860f1d21763a 8027220: DefaultMethodsTest: Change test to match spec Reviewed-by: ksrini ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: 44e3ba40e00c Author: lana Date: 2013-10-28 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/44e3ba40e00c Merge Changeset: aa91bc6e8480 Author: mchung Date: 2013-10-30 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/aa91bc6e8480 8027481: jdeps to handle classes with the same package name and correct profile for javax.crypto.* Reviewed-by: alanb, dfuchs ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/Profile.java ! test/tools/jdeps/Basic.java ! test/tools/jdeps/Test.java + test/tools/jdeps/javax/activity/NotCompactProfile.java + test/tools/jdeps/p/Bar.java Changeset: 537fa895fd74 Author: vromero Date: 2013-10-30 18:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/537fa895fd74 8027327: jar files related to test test/tools/javac/ExtDirs/ExtDirTest.java should be removed from the repo Reviewed-by: ksrini ! test/tools/javac/ExtDirs/ExtDirTest.java - test/tools/javac/ExtDirs/ext1/pkg1.jar - test/tools/javac/ExtDirs/ext2/pkg2.jar - test/tools/javac/ExtDirs/ext3/pkg1.jar - test/tools/javac/ExtDirs/ext3/pkg2.jar Changeset: 62a67e0875ff Author: briangoetz Date: 2013-10-30 14:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/62a67e0875ff 8024930: Re-enable disabled bridging tests Reviewed-by: psandoz, rfield ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.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/vm/DefaultMethodsTest.java Changeset: 6b4d6205366c Author: lana Date: 2013-10-31 16:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6b4d6205366c Merge - test/tools/javac/ExtDirs/ext1/pkg1.jar - test/tools/javac/ExtDirs/ext2/pkg2.jar - test/tools/javac/ExtDirs/ext3/pkg1.jar - test/tools/javac/ExtDirs/ext3/pkg2.jar - test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 3c040b04af05 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3c040b04af05 Added tag jdk8-b115 for changeset 6b4d6205366c ! .hgtags From john.coomes at oracle.com Thu Nov 7 11:35:48 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 07 Nov 2013 19:35:48 +0000 Subject: hg: hsx/hotspot-main/nashorn: 29 new changesets Message-ID: <20131107193617.2890062428@hg.openjdk.java.net> Changeset: b01a10c7c7c2 Author: attila Date: 2013-10-17 12:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b01a10c7c7c2 8026161: Don't narrow floating-point literals in the lexer Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8026161.js + test/script/basic/JDK-8026161.js.EXPECTED ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java Changeset: a2065f67857c Author: hannesw Date: 2013-10-17 17:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a2065f67857c 8026701: Array.prototype.splice is slow on dense arrays Reviewed-by: lagergren, sundar, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! test/examples/array-micro.js + test/script/basic/JDK-8026701.js + test/script/basic/JDK-8026701.js.EXPECTED Changeset: 66d27c77b455 Author: hannesw Date: 2013-10-18 12:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/66d27c77b455 8026805: Array.prototype.length doesn't work as expected Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/basic/JDK-8026805.js Changeset: b5b4c98b072b Author: sundar Date: 2013-10-18 18:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b5b4c98b072b Merge Changeset: d8aa87d292eb Author: hannesw Date: 2013-10-18 22:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d8aa87d292eb 8026858: Array length does not handle defined properties correctly Reviewed-by: jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026858.js Changeset: 612886fe324d Author: sundar Date: 2013-10-21 10:09 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/612886fe324d Merge Changeset: f22742d5daa3 Author: kshefov Date: 2013-10-21 13:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f22742d5daa3 8026871: NASHORN TEST: Enable possibility to test Nashorn use of JavaFX canvas. Reviewed-by: jlaskey, sundar ! make/build.xml ! make/project.properties + test/script/jfx.js + test/script/jfx/flyingimage.js + test/script/jfx/flyingimage/flyingimage.png + test/script/jfx/flyingimage/golden/linux.png + test/script/jfx/flyingimage/golden/macosx.png + test/script/jfx/flyingimage/golden/windows.png + test/script/jfx/kaleidoscope.js + test/script/jfx/kaleidoscope/golden/linux.png + test/script/jfx/kaleidoscope/golden/macosx.png + test/script/jfx/kaleidoscope/golden/windows.png Changeset: d8d5b7919c57 Author: sundar Date: 2013-10-22 14:27 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d8d5b7919c57 8027016: Array.prototype.indexOf should return -1 when array is of length zero Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8027016.js Changeset: 6d339d98074e Author: hannesw Date: 2013-10-22 11:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6d339d98074e 8027015: AutoCloseable no longer implements @FunctionalInterface Reviewed-by: lagergren, sundar ! test/script/basic/NASHORN-397.js Changeset: d24a4fabdce1 Author: hannesw Date: 2013-10-22 11:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d24a4fabdce1 8026955: for-in should convert primitive values to object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8026955.js + test/script/basic/JDK-8026955.js.EXPECTED Changeset: 360761288b38 Author: sundar Date: 2013-10-22 17:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/360761288b38 8027024: String.prototype.charAt and charCodeAt do not evaluate 'self' and 'pos' arguments in right order Reviewed-by: jlaskey, attila, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/overview.html + test/script/basic/JDK-8027024.js + test/script/basic/JDK-8027024.js.EXPECTED Changeset: d04028e6b624 Author: sundar Date: 2013-10-22 17:47 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d04028e6b624 Merge Changeset: 0ecbc0188b64 Author: attila Date: 2013-10-22 16:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0ecbc0188b64 8027031: complete merging of loads and converts Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java Changeset: 6f19eb443a47 Author: attila Date: 2013-10-22 17:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/6f19eb443a47 8027037: Make ScriptObjectMirror conversions work for any JSObject Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java Changeset: eae4e4c1f613 Author: sundar Date: 2013-10-22 22:04 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/eae4e4c1f613 8027020: [regression] java.lang.VerifyError: Bad type on operand stack Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptLoader.java Changeset: 734f71f8a2c3 Author: sundar Date: 2013-10-22 22:12 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/734f71f8a2c3 Merge Changeset: 5df55690fd5b Author: sundar Date: 2013-10-23 17:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5df55690fd5b 8027128: jdk.nashorn.api.scripting.JSObject should be an interface Reviewed-by: hannesw, attila, jlaskey + src/jdk/nashorn/api/scripting/AbstractJSObject.java ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! test/script/basic/JDK-8024847.js ! test/script/basic/JDK-8024847.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: f31ee3a2847d Author: sundar Date: 2013-10-23 20:15 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f31ee3a2847d 8027150: ScriptObjectListAdapter won't work as expected Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ListAdapter.java - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java Changeset: 640c1854f742 Author: sundar Date: 2013-10-23 20:21 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/640c1854f742 Merge - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java Changeset: 767e85d2a1b3 Author: lana Date: 2013-10-28 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/767e85d2a1b3 Merge Changeset: 7985ec3782b5 Author: hannesw Date: 2013-10-25 10:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7985ec3782b5 8027042: Evaluation order for binary operators can be improved Reviewed-by: lagergren, jlaskey, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Expression.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java + test/script/basic/JDK-8027042.js + test/script/basic/JDK-8027042.js.EXPECTED Changeset: 71cfb21c68dc Author: hannesw Date: 2013-10-25 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/71cfb21c68dc 8027301: Optimizations for Function.prototype.apply Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: 406f2b672937 Author: jlaskey Date: 2013-10-29 10:40 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/406f2b672937 Merge Changeset: adab2c628923 Author: jlaskey Date: 2013-10-29 14:22 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/adab2c628923 8027447: The wrong string buffer is specified for stderr in $EXEC Reviewed-by: lagergren, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java Changeset: 645197151cc3 Author: jlaskey Date: 2013-10-30 11:28 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/645197151cc3 8027532: nashorn should only use jdk8 apis in the compact1 profile Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Changeset: a002c1bb88f9 Author: sundar Date: 2013-10-30 20:09 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a002c1bb88f9 8027562: eval should load second and subsequent arguments for side effect Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8027562.js + test/script/basic/JDK-8027562.js.EXPECTED Changeset: 5ce78473d6c3 Author: sundar Date: 2013-10-31 12:50 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5ce78473d6c3 Merge Changeset: f0d3ac2474ee Author: lana Date: 2013-10-31 16:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f0d3ac2474ee Merge - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java Changeset: 0fb1a427fbf6 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0fb1a427fbf6 Added tag jdk8-b115 for changeset f0d3ac2474ee ! .hgtags From goetz.lindenmaier at sap.com Thu Nov 7 12:31:53 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 20:31:53 +0000 Subject: RFR(XS): 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <527B781B.20105@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2C47D731@DEWDFEMB12A.global.corp.sap> <527B781B.20105@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2C4829C2@DEWDFEMB12A.global.corp.sap> Hi David, Serguei, Thanks a lot for the fast reviews! Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Thursday, November 07, 2013 12:23 PM To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(XS): 8027969: Adapt PPC to 8026328: Setting a breakpoint on invokedynamic crashes the JVM Looks fine to me. (Though I don't understand why the new argument was added as it seems unused everywhere ??) David On 7/11/2013 9:06 PM, Lindenmaier, Goetz wrote: > Hi, > > Please review this change. It's really small, ppc only and required by the last > update of the ppc staging repository. > > http://cr.openjdk.java.net/~goetz/webrevs/8027969/ > > Best regards, > Goetz Lindenmaier > From vladimir.kozlov at oracle.com Thu Nov 7 12:34:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 12:34:48 -0800 Subject: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <4295855A5C1DE049A61835A1887419CC2C47D8B1@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2C47D71D@DEWDFEMB12A.global.corp.sap> <527BAD82.2010205@oracle.com> <4295855A5C1DE049A61835A1887419CC2C47D8B1@DEWDFEMB12A.global.corp.sap> Message-ID: <527BF968.20506@oracle.com> Good. I assume you will use it in .ad file when you add it. I thought we already have it. Thanks, Vladimir On 11/7/13 8:22 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for the tip! > I fixed it: > > http://cr.openjdk.java.net/~goetz/webrevs/8027968-2/ > > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillmore > Sent: Donnerstag, 7. November 2013 16:11 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops > > > With this one, do you have to change the number of instructions for > vtableStubs_ppc64 and in the .ad file, as in pd_code_size_limit? I > guess what you'd have is an overestimate with this change. In the x86 > and sparc code we added a function instr_size_for_decode_klass_not_null > to help with this calculation. > > Thanks, > Coleen > > On 11/7/2013 6:05 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Please review this change. It's really small, ppc only and required by the last >> update of the ppc staging repository. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8027968/ >> >> Best regards, >> Goetz Lindenmaier >> > From goetz.lindenmaier at sap.com Thu Nov 7 13:18:22 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Nov 2013 21:18:22 +0000 Subject: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops In-Reply-To: <527BF968.20506@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2C47D71D@DEWDFEMB12A.global.corp.sap> <527BAD82.2010205@oracle.com> <4295855A5C1DE049A61835A1887419CC2C47D8B1@DEWDFEMB12A.global.corp.sap> <527BF968.20506@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2C48AAF0@DEWDFEMB12A.global.corp.sap> Now it's in, thanks a lot! Best regards, Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, November 07, 2013 9:35 PM To: hotspot-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops Good. I assume you will use it in .ad file when you add it. I thought we already have it. Thanks, Vladimir On 11/7/13 8:22 AM, Lindenmaier, Goetz wrote: > Hi Coleen, > > thanks for the tip! > I fixed it: > > http://cr.openjdk.java.net/~goetz/webrevs/8027968-2/ > > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillmore > Sent: Donnerstag, 7. November 2013 16:11 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8027968: Adapt PPC to 8024927: Nashorn performance regression with CompressedOops > > > With this one, do you have to change the number of instructions for > vtableStubs_ppc64 and in the .ad file, as in pd_code_size_limit? I > guess what you'd have is an overestimate with this change. In the x86 > and sparc code we added a function instr_size_for_decode_klass_not_null > to help with this calculation. > > Thanks, > Coleen > > On 11/7/2013 6:05 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Please review this change. It's really small, ppc only and required by the last >> update of the ppc staging repository. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8027968/ >> >> Best regards, >> Goetz Lindenmaier >> > From ysr1729 at gmail.com Thu Nov 7 14:03:21 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 7 Nov 2013 14:03:21 -0800 Subject: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A66FB.8060001@oracle.com> References: <527A64C7.1030502@oracle.com> <527A66FB.8060001@oracle.com> Message-ID: vote: yes - ysr On Wed, Nov 6, 2013 at 7:57 AM, Bengt Rutisson wrote: > > On 2013-11-06 16:48, Bengt Rutisson wrote: > >> I hereby nominate Jesper Wilhelmsson (OpenJDK user name: ehelin) to >> Membership in the HotSpot Group. >> > > Copy-n-paste error. Jesper's OpenJDK user name is jwilhelm. > > Bengt > > > >> Jesper is an Oracle engineer, working for the GC team. He has been >> working in the HotSpot team since 2010. Jesper is a Committer in the >> HotSpot project and has currently contributed 14 changes. >> >> Votes are due by Wednesday, November 20, 2013. >> >> Only current Members of the HotSpot Group [1] 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 [2]. >> >> Kind Regards, >> Bengt >> >> [1] http://openjdk.java.net/census/#hotspot >> [2] http://openjdk.java.net/groups/#member-vote >> > > From ysr1729 at gmail.com Thu Nov 7 14:03:53 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 7 Nov 2013 14:03:53 -0800 Subject: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: vote: yes -- ysr On Wed, Nov 6, 2013 at 6:52 AM, Bengt Rutisson wrote: > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to Membership > in the HotSpot Group. > > Mikael is an Oracle engineer, working for the GC team. He has been working > in the HotSpot team since 2010. Mikael is a Committer in the HotSpot > project and has currently contributed 24 changes. > > Votes are due by Wednesday, November 20, 2013. > > Only current Members of the HotSpot Group [1] 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 [2]. > > Kind Regards, > Bengt > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote > From vladimir.kozlov at oracle.com Thu Nov 7 15:38:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Nov 2013 15:38:47 -0800 Subject: opto: How to use MachConstantBase with Call nodes -- needed for ppc port In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D039EEA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D039EEA@DEWDFEMB12A.global.corp.sap> Message-ID: <527C2487.4020800@oracle.com> Goetz, Yes, it would be nice to avoid graph walk. Can you extend what we already do for safepoints on sparc?: void Parse::add_safepoint() { // See if we can avoid this safepoint. No need for a SafePoint immediately // after a Call (except Leaf Call) or another SafePoint. Node *proj = control(); bool add_poll_param = SafePointNode::needs_polling_address_input(); uint parms = add_poll_param ? TypeFunc::Parms+1 : TypeFunc::Parms; It looks like we handle similar situation with simple Safepoint node adding an edge before debug info as you suggested but it will be normal ideal graph edge with input Con node. I am fine if you do it in C2 code directly (but with a lot of testing) because on our platforms we will not use it. Regards, Vladimir On 10/7/13 2:54 AM, Lindenmaier, Goetz wrote: > Hi, > > This is part of the ppc port, but I would like some advice before I open a > bug and prepare a webrev. > > The next change I would like to prepare will be based on this patch: > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0114_opto-hook_to_postprocess_matcher_output_platform_dependent.patch > The method introduced there is later filled with code on ppc: > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/compile_ppc.cpp > > This introduces a walk over the IR after matching, before gcm. In that walk > we add MachConstantBaseNode to the call nodes (CallDynamicJava, CallLeaf and > CallLeafNoFP). > There are two problems why we need this: > > - The functionality to automatically generate an input of MachConstantBaseNode > only works with subclasses of MachConstantNode. > > - Call nodes can not have ordinary operands with ins. > > We decided to implement this additional walk over the IR because it was the solution > with the least change to shared code. > > Actually I would prefer a solution that gets along without this walk. > This would be possible by adding support for ordinary ins/operands in Call nodes. > The ins could be: > [[The 5 basic operands] [the params] [new: the ordinary ins as specified by operands] [the jvms ins] [oop_map ins]] > > oper_input_base() would have to return something like 'TypeFunc::Parms + tf()->_domain->_cnt', > and we would have to add oper_input_end() which does a loop over the opers > and counts the ins required: > oper_input_end() { > int end = oper_input_base() > for (uint i = 1; i < num_opnds(); ++i) { end += _opnds[i]->num_edges(); } > return end; > } > Also, jvms->locoff() etc would have to depend on oper_input_end() in some way. > > Alternatively, one could put the ordinary ins behind jvms, then > oper_input_base() would have to return jvms->endoff(), > and oop_maps would have to use oper_input_end() to locate their first in. > > Further, I would have to add a new MachOperand that represents the > ConstantBase > > What do you think? Would you rather prefer the existing solution, > or should I try to implement what I described? Do you have a better > idea how to add the ConstantBase to Calls? > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Fri Nov 8 06:54:18 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Nov 2013 14:54:18 +0000 Subject: opto: How to use MachConstantBase with Call nodes -- needed for ppc port In-Reply-To: <527C2487.4020800@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D039EEA@DEWDFEMB12A.global.corp.sap> <527C2487.4020800@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2C48B042@DEWDFEMB12A.global.corp.sap> Hi Vladimir, > Yes, it would be nice to avoid graph walk. Well, the graph walk would only be there on PPC, but it's a lot of overhead. > Can you extend what we already do for safepoints on sparc?: Yes, I think that would be a way to do it. I could add MachCallNode::needs_constant_base_input() on all platforms. If set, matcher adds MachConstantBaseNode to the call nodes behind the arguments, before jvms inputs and adapts the jvms offsets. For register allocation, I would have to pimp _in_rms/in_RegMask() in some way. Probably I need to add something to the ad file that gives the register mask to use. This solution does not allow to add TEMP operands to Call nodes, which would be nice, too. But that's not necessary, just a nice-to-have. I'll implement it and come back to you if I have to do something I consider ugly ;) Best regards and thanks for your tips, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 8. November 2013 00:39 To: Lindenmaier, Goetz; hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Christian Thalinger Subject: Re: opto: How to use MachConstantBase with Call nodes -- needed for ppc port Goetz, Yes, it would be nice to avoid graph walk. Can you extend what we already do for safepoints on sparc?: void Parse::add_safepoint() { // See if we can avoid this safepoint. No need for a SafePoint immediately // after a Call (except Leaf Call) or another SafePoint. Node *proj = control(); bool add_poll_param = SafePointNode::needs_polling_address_input(); uint parms = add_poll_param ? TypeFunc::Parms+1 : TypeFunc::Parms; It looks like we handle similar situation with simple Safepoint node adding an edge before debug info as you suggested but it will be normal ideal graph edge with input Con node. I am fine if you do it in C2 code directly (but with a lot of testing) because on our platforms we will not use it. Regards, Vladimir On 10/7/13 2:54 AM, Lindenmaier, Goetz wrote: > Hi, > > This is part of the ppc port, but I would like some advice before I open a > bug and prepare a webrev. > > The next change I would like to prepare will be based on this patch: > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0114_opto-hook_to_postprocess_matcher_output_platform_dependent.patch > The method introduced there is later filled with code on ppc: > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/compile_ppc.cpp > > This introduces a walk over the IR after matching, before gcm. In that walk > we add MachConstantBaseNode to the call nodes (CallDynamicJava, CallLeaf and > CallLeafNoFP). > There are two problems why we need this: > > - The functionality to automatically generate an input of MachConstantBaseNode > only works with subclasses of MachConstantNode. > > - Call nodes can not have ordinary operands with ins. > > We decided to implement this additional walk over the IR because it was the solution > with the least change to shared code. > > Actually I would prefer a solution that gets along without this walk. > This would be possible by adding support for ordinary ins/operands in Call nodes. > The ins could be: > [[The 5 basic operands] [the params] [new: the ordinary ins as specified by operands] [the jvms ins] [oop_map ins]] > > oper_input_base() would have to return something like 'TypeFunc::Parms + tf()->_domain->_cnt', > and we would have to add oper_input_end() which does a loop over the opers > and counts the ins required: > oper_input_end() { > int end = oper_input_base() > for (uint i = 1; i < num_opnds(); ++i) { end += _opnds[i]->num_edges(); } > return end; > } > Also, jvms->locoff() etc would have to depend on oper_input_end() in some way. > > Alternatively, one could put the ordinary ins behind jvms, then > oper_input_base() would have to return jvms->endoff(), > and oop_maps would have to use oper_input_end() to locate their first in. > > Further, I would have to add a new MachOperand that represents the > ConstantBase > > What do you think? Would you rather prefer the existing solution, > or should I try to implement what I described? Do you have a better > idea how to add the ConstantBase to Calls? > > Best regards, > Goetz. > From volker.simonis at gmail.com Fri Nov 8 09:33:15 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Nov 2013 18:33:15 +0100 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: <527BD6E6.4080706@oracle.com> References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> <527AC3D0.4080201@oracle.com> <527BD6E6.4080706@oracle.com> Message-ID: Hi Vladimir, I've prepared a webrev which should fix the build on AIX: http://cr.openjdk.java.net/~simonis/webrevs/8028066 Could you please check if it's OK and push it if it passes? (I've tried Linux/PPC64, Linux/AMD64, Solaris/SPARC and AIX and it worked). Thank you and best regards, Volker On Thu, Nov 7, 2013 at 7:07 PM, Vladimir Kozlov wrote: > Thank you for catching it. I agree, no need for separate bug. > > Thanks, > Vladimir > > > On 11/7/13 7:34 AM, Volker Simonis wrote: >> >> Hi Vladimir, >> >> thank you for doing the sync! >> >> Strange that your builds passed on Oracle platforms because because I >> think there's a typo in makefiles/lib/CoreLibraries.gmk which should >> affect all platforms: >> >> diff -r d152c5b01ea8 makefiles/lib/CoreLibraries.gmk >> --- a/makefiles/lib/CoreLibraries.gmk Tue Nov 05 17:32:53 2013 -0800 >> +++ b/makefiles/lib/CoreLibraries.gmk Thu Nov 07 15:36:54 2013 +0100 >> @@ -269,7 +269,7 @@ >> $(WIN_JAVA_LIB), \ >> LDFLAGS_SUFFIX_linux := -ljvm -ljava $(LIBZ), \ >> LDFLAGS_SUFFIX_solaris := -ljvm -ljava $(LIBZ) -lc, \ >> - LDFLAGS_SUFFIX_aix: = -ljvm -ljava $(LIBZ),\ >> + LDFLAGS_SUFFIX_aix := -ljvm -ljava $(LIBZ),\ >> LDFLAGS_SUFFIX_macosx := $(LIBZ) -ljava -ljvm, \ >> VERSIONINFO_RESOURCE := >> $(JDK_TOPDIR)/src/windows/resource/version.rc, \ >> RC_FLAGS := $(RC_FLAGS) \ >> >> Maybe that's related to the make version, but with GNU make 3.82 I get >> an "*** empty variable name" error. >> >> If I fix this (and together with Goetz's fixes) the build passes on >> Linux/PPC64. >> >> I think it makes no sense to create a bug for this single character >> change so I'm packing it together with the other AIX-related changes >> which I'm currently preparing. >> >> Regards, >> Volker >> >> >> On Wed, Nov 6, 2013 at 11:33 PM, Vladimir Kozlov >> wrote: >>> >>> Hi, Volker >>> >>> I finished the sync. >>> >>> Hotspot passed clean. JDK passed builds and testing on our platforms with >>> few known failures (2 javac regression tests TypeInferenceComboTest.java >>> and >>> DefaultMethodsTest.java). >>> >>> Yes, I did not expect they will do such global cleanup so later in the >>> game >>> for jdk8: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8001931 >>> http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 >>> >>> Syncing more frequent will not help with such big changes. I only hope it >>> will not happen again in near future until we merge PPC64 code into main >>> forest. >>> >>> As I said I did my best to resolve conflicts and, I think, the only >>> problem >>> left is AIX changes in makefiles/CompileNativeLibraries.gmk which you >>> need >>> to move to new makefiles/lib/*.gmk files. >>> File a bug "PPC64: 8025715 changes broke AIX build after sync" and send >>> me >>> the fix. I will have to verify JDK build on our platforms with it. >>> >>> I am fine with resolving easy conflicts and leaving hard one to you :) >>> >>> Regards, >>> Vladimir >>> >>> PS: even mailing system freak-out :) >>> -------------------------------------------------------------- >>> Your mail to 'ppc-aix-port-dev' with the subject >>> >>> hg: ppc-aix-port/stage/jdk: 740 new changesets >>> >>> Is being held until the list moderator can review it for approval. >>> The reason it is being held: >>> >>> Message body is too big: 456885 bytes with a limit of 400 KB >>> -------------------------------------------------------------- >>> >>> >>> On 11/6/13 8:35 AM, Volker Simonis wrote: >>>> >>>> >>>> Hi Vladimir, >>>> >>>> thank you for starting syncing again! >>>> >>>> Please see my comments inline: >>>> >>>> On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov >>>> wrote: >>>>> >>>>> >>>>> I was not able to resolve all conflicts. AIX build is definitely >>>>> broken. >>>>> >>>>> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >>>>> indention). >>>>> >>>>> I had problem with common/autoconf/platform.m4 when resolving conflicts >>>>> at >>>>> the end of file (below "Make compilation sanity check"). And for >>>>> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >>>>> >>>>> ppc64 repo: >>>>> >>>>> ADDED_CFLAGS=" >>>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>>> ADDED_CXXFLAGS=" >>>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>>> ADDED_LDFLAGS=" >>>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>>> >>>> >>>> Yes, this is the right way how it should be done now that we have >>>> ${COMPILER_TARGET_BITS_FLAG} >>>> >>>>> jdk8 repo: >>>>> >>>>> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>>> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>>> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>>> >>>>> >>>>> Merging toolchain.m4 was even more painful. >>>>> >>>>> An other one was jdk/makefiles/CompileLaunchers.gmk >>>>> >>>>> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. Code >>>>> from >>>>> it was moved into jdk/makefiles/lib files: >>>>> >>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >>>>> >>>>> I was not able to do anything there. It definitely broke AIX build so >>>>> you >>>>> need to implement it again. Sorry. >>>> >>>> >>>> >>>> Well, works as expected:( >>>> >>>> I know no good way how we could solve these problems (apart from >>>> integration shared changes more early into the main repositories of >>>> course). >>>> >>>> I could of course offer to do the merge such that all the AIX changes >>>> would still be good. But how could I share a merge change with you? >>>> Would you like to get only the files which I had to resolve manually? >>>> Or better all the files which are changed by the merge? You could then >>>> merge, copy my files over the sources and do the remaining resolving >>>> in the closed directories. >>>> >>>> What do you think, should we try it this way next time? >>>> >>>>> >>>>> I started JDK and Hotspot JPRT test runs. If they passed I will push >>>>> what >>>>> I >>>>> have and then you need to fix it for AIX. >>>>> >>>> >>>> I'm ready to start... >>>> >>>>> Regards, >>>>> Vladimir >>>>> >>> > From alejandro.murillo at oracle.com Fri Nov 8 10:38:07 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Nov 2013 18:38:07 +0000 Subject: hg: hsx/hsx25/hotspot: 24 new changesets Message-ID: <20131108183859.BC14A62478@hg.openjdk.java.net> Changeset: e39b138b2518 Author: acorn Date: 2013-10-19 18:32 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e39b138b2518 8026893: Push 8026365 to TL early and add test Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups + test/runtime/8026365/InvokeSpecialAnonTest.java Changeset: 0e55a181cb08 Author: lana Date: 2013-10-28 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0e55a181cb08 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: ea1b8c643fc8 Author: lana Date: 2013-10-30 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ea1b8c643fc8 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 205834867346 Author: lana Date: 2013-10-31 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/205834867346 Merge Changeset: 9ebaac78a8a0 Author: amurillo Date: 2013-11-05 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9ebaac78a8a0 Merge Changeset: 842b6ce4dfb4 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/842b6ce4dfb4 Added tag jdk8-b115 for changeset 9ebaac78a8a0 ! .hgtags Changeset: 5b84039ca739 Author: amurillo Date: 2013-11-01 08:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5b84039ca739 8027580: new hotspot build - hs25-b58 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ea79ab313e98 Author: mgerdin Date: 2013-10-30 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ea79ab313e98 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Summary: Use 2-byte loads to load indexes from the byte code stream to avoid out of bounds reads. Reviewed-by: coleenp, sspitsyn ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: fdd464c8d62e Author: acorn Date: 2013-10-30 09:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fdd464c8d62e 8027304: Lambda: inheriting abstract + 1 default -> default, not ICCE Reviewed-by: hseigel, zgu ! src/share/vm/classfile/defaultMethods.cpp Changeset: 4fe7815b04f5 Author: acorn Date: 2013-10-30 09:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4fe7815b04f5 Merge Changeset: c8fc12209830 Author: coleenp Date: 2013-10-31 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c8fc12209830 8027616: Off by one error in putback for compressed oops nashorn performance improvement Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other. Reviewed-by: stefank, hseigel, zgu ! src/share/vm/memory/metaspace.cpp Changeset: 910026b800b8 Author: coleenp Date: 2013-11-01 10:32 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/910026b800b8 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodHandle 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. Reviewed-by: sspitsyn, ehelin, sla ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 42790b7e4d48 Author: mgronlun Date: 2013-11-01 15:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/42790b7e4d48 Merge ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: f8b56489e455 Author: mgronlun Date: 2013-11-01 17:10 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f8b56489e455 Merge Changeset: 04df110c8655 Author: mgronlun Date: 2013-11-02 20:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/04df110c8655 Merge Changeset: 208ebea980f8 Author: roland Date: 2013-11-04 21:59 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/208ebea980f8 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I Summary: String.equals() intrinsic shouldn't use integer length input in pointer arithmetic without an i2l. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/intrinsics/stringequals/TestStringEqualsBadLength.java Changeset: e428d5e768e3 Author: rbackman Date: 2013-11-04 10:44 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e428d5e768e3 8027622: java.time.Instant.create failing since hs25-b56 Reviewed-by: kvn, iveresov ! src/share/vm/opto/compile.cpp + test/compiler/intrinsics/mathexact/CompareTest.java Changeset: a905d33ce13a Author: iveresov Date: 2013-11-05 00:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a905d33ce13a 8027751: C1 crashes in Weblogic with G1 enabled Summary: Keep T_OBJECT operands in registers for logical operations on x64 Reviewed-by: kvn, roland ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 94a83e0f9ce1 Author: iveresov Date: 2013-11-05 01:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/94a83e0f9ce1 8017065: C2 allows safepoint checks to leak into G1 pre-barriers Summary: Make all raw loads strictly respect control dependencies, make sure RCE doesn't move raw loads, add verification of G1 pre-barriers. Reviewed-by: kvn, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.hpp Changeset: 613e6a6fc328 Author: iveresov Date: 2013-11-05 02:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/613e6a6fc328 Merge ! src/share/vm/opto/compile.cpp Changeset: be525e91f65b Author: mikael Date: 2013-11-06 06:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/be525e91f65b 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION Summary: Uncommon trap blob did not bang all the stack shadow pages Reviewed-by: kvn, twisti, iveresov, jrose ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp + test/compiler/uncommontrap/UncommonTrapStackBang.java Changeset: 53662b2f1d68 Author: drchase Date: 2013-11-07 10:02 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/53662b2f1d68 Merge Changeset: e510dfdec6dd Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e510dfdec6dd Merge Changeset: 52b076e6ffae Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/52b076e6ffae Added tag hs25-b58 for changeset e510dfdec6dd ! .hgtags From alejandro.murillo at oracle.com Fri Nov 8 14:06:20 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Nov 2013 22:06:20 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20131108220643.DE44762489@hg.openjdk.java.net> Changeset: e39b138b2518 Author: acorn Date: 2013-10-19 18:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e39b138b2518 8026893: Push 8026365 to TL early and add test Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups + test/runtime/8026365/InvokeSpecialAnonTest.java Changeset: 0e55a181cb08 Author: lana Date: 2013-10-28 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0e55a181cb08 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: ea1b8c643fc8 Author: lana Date: 2013-10-30 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea1b8c643fc8 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 205834867346 Author: lana Date: 2013-10-31 16:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/205834867346 Merge Changeset: 9ebaac78a8a0 Author: amurillo Date: 2013-11-05 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9ebaac78a8a0 Merge Changeset: 842b6ce4dfb4 Author: cl Date: 2013-11-07 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/842b6ce4dfb4 Added tag jdk8-b115 for changeset 9ebaac78a8a0 ! .hgtags Changeset: e510dfdec6dd Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e510dfdec6dd Merge Changeset: 52b076e6ffae Author: amurillo Date: 2013-11-08 07:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/52b076e6ffae Added tag hs25-b58 for changeset e510dfdec6dd ! .hgtags Changeset: 20c72bec2707 Author: amurillo Date: 2013-11-08 07:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/20c72bec2707 8028061: new hotspot build - hs25-b59 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.kozlov at oracle.com Fri Nov 8 16:31:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Nov 2013 16:31:43 -0800 Subject: Problems with sync from jdk8/jdk8 to ppc-aix-port/stage In-Reply-To: References: <52293B48.2070607@oracle.com> <5279A64F.9050500@oracle.com> <527AC3D0.4080201@oracle.com> <527BD6E6.4080706@oracle.com> Message-ID: <527D826F.9030203@oracle.com> Builds and tests passed and I pushed changes. Regards, Vladimir On 11/8/13 9:33 AM, Volker Simonis wrote: > Hi Vladimir, > > I've prepared a webrev which should fix the build on AIX: > > http://cr.openjdk.java.net/~simonis/webrevs/8028066 > > Could you please check if it's OK and push it if it passes? (I've > tried Linux/PPC64, Linux/AMD64, Solaris/SPARC and AIX and it worked). > > Thank you and best regards, > Volker > > On Thu, Nov 7, 2013 at 7:07 PM, Vladimir Kozlov > wrote: >> Thank you for catching it. I agree, no need for separate bug. >> >> Thanks, >> Vladimir >> >> >> On 11/7/13 7:34 AM, Volker Simonis wrote: >>> >>> Hi Vladimir, >>> >>> thank you for doing the sync! >>> >>> Strange that your builds passed on Oracle platforms because because I >>> think there's a typo in makefiles/lib/CoreLibraries.gmk which should >>> affect all platforms: >>> >>> diff -r d152c5b01ea8 makefiles/lib/CoreLibraries.gmk >>> --- a/makefiles/lib/CoreLibraries.gmk Tue Nov 05 17:32:53 2013 -0800 >>> +++ b/makefiles/lib/CoreLibraries.gmk Thu Nov 07 15:36:54 2013 +0100 >>> @@ -269,7 +269,7 @@ >>> $(WIN_JAVA_LIB), \ >>> LDFLAGS_SUFFIX_linux := -ljvm -ljava $(LIBZ), \ >>> LDFLAGS_SUFFIX_solaris := -ljvm -ljava $(LIBZ) -lc, \ >>> - LDFLAGS_SUFFIX_aix: = -ljvm -ljava $(LIBZ),\ >>> + LDFLAGS_SUFFIX_aix := -ljvm -ljava $(LIBZ),\ >>> LDFLAGS_SUFFIX_macosx := $(LIBZ) -ljava -ljvm, \ >>> VERSIONINFO_RESOURCE := >>> $(JDK_TOPDIR)/src/windows/resource/version.rc, \ >>> RC_FLAGS := $(RC_FLAGS) \ >>> >>> Maybe that's related to the make version, but with GNU make 3.82 I get >>> an "*** empty variable name" error. >>> >>> If I fix this (and together with Goetz's fixes) the build passes on >>> Linux/PPC64. >>> >>> I think it makes no sense to create a bug for this single character >>> change so I'm packing it together with the other AIX-related changes >>> which I'm currently preparing. >>> >>> Regards, >>> Volker >>> >>> >>> On Wed, Nov 6, 2013 at 11:33 PM, Vladimir Kozlov >>> wrote: >>>> >>>> Hi, Volker >>>> >>>> I finished the sync. >>>> >>>> Hotspot passed clean. JDK passed builds and testing on our platforms with >>>> few known failures (2 javac regression tests TypeInferenceComboTest.java >>>> and >>>> DefaultMethodsTest.java). >>>> >>>> Yes, I did not expect they will do such global cleanup so later in the >>>> game >>>> for jdk8: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8001931 >>>> http://hg.openjdk.java.net/jdk8/jdk8/rev/174a54ce39c4 >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/9c60860b1812 >>>> >>>> Syncing more frequent will not help with such big changes. I only hope it >>>> will not happen again in near future until we merge PPC64 code into main >>>> forest. >>>> >>>> As I said I did my best to resolve conflicts and, I think, the only >>>> problem >>>> left is AIX changes in makefiles/CompileNativeLibraries.gmk which you >>>> need >>>> to move to new makefiles/lib/*.gmk files. >>>> File a bug "PPC64: 8025715 changes broke AIX build after sync" and send >>>> me >>>> the fix. I will have to verify JDK build on our platforms with it. >>>> >>>> I am fine with resolving easy conflicts and leaving hard one to you :) >>>> >>>> Regards, >>>> Vladimir >>>> >>>> PS: even mailing system freak-out :) >>>> -------------------------------------------------------------- >>>> Your mail to 'ppc-aix-port-dev' with the subject >>>> >>>> hg: ppc-aix-port/stage/jdk: 740 new changesets >>>> >>>> Is being held until the list moderator can review it for approval. >>>> The reason it is being held: >>>> >>>> Message body is too big: 456885 bytes with a limit of 400 KB >>>> -------------------------------------------------------------- >>>> >>>> >>>> On 11/6/13 8:35 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi Vladimir, >>>>> >>>>> thank you for starting syncing again! >>>>> >>>>> Please see my comments inline: >>>>> >>>>> On Wed, Nov 6, 2013 at 3:15 AM, Vladimir Kozlov >>>>> wrote: >>>>>> >>>>>> >>>>>> I was not able to resolve all conflicts. AIX build is definitely >>>>>> broken. >>>>>> >>>>>> I have to manually resolve a lot of .m4 and .gmk files (mostly changed >>>>>> indention). >>>>>> >>>>>> I had problem with common/autoconf/platform.m4 when resolving conflicts >>>>>> at >>>>>> the end of file (below "Make compilation sanity check"). And for >>>>>> ADDED_*FLGAS settings I resolved it as in ppc64 repo: >>>>>> >>>>>> ppc64 repo: >>>>>> >>>>>> ADDED_CFLAGS=" >>>>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>>>> ADDED_CXXFLAGS=" >>>>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>>>> ADDED_LDFLAGS=" >>>>>> ${COMPILER_TARGET_BITS_FLAG}${OPENJDK_TARGET_CPU_BITS}" >>>>>> >>>>> >>>>> Yes, this is the right way how it should be done now that we have >>>>> ${COMPILER_TARGET_BITS_FLAG} >>>>> >>>>>> jdk8 repo: >>>>>> >>>>>> ADDED_CFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>>>> ADDED_CXXFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>>>> ADDED_LDFLAGS=" -m${OPENJDK_TARGET_CPU_BITS}" >>>>>> >>>>>> >>>>>> Merging toolchain.m4 was even more painful. >>>>>> >>>>>> An other one was jdk/makefiles/CompileLaunchers.gmk >>>>>> >>>>>> But the main problem was jdk/makefiles/CompileNativeLibraries.gmk. Code >>>>>> from >>>>>> it was moved into jdk/makefiles/lib files: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/a5b57fca66da >>>>>> >>>>>> I was not able to do anything there. It definitely broke AIX build so >>>>>> you >>>>>> need to implement it again. Sorry. >>>>> >>>>> >>>>> >>>>> Well, works as expected:( >>>>> >>>>> I know no good way how we could solve these problems (apart from >>>>> integration shared changes more early into the main repositories of >>>>> course). >>>>> >>>>> I could of course offer to do the merge such that all the AIX changes >>>>> would still be good. But how could I share a merge change with you? >>>>> Would you like to get only the files which I had to resolve manually? >>>>> Or better all the files which are changed by the merge? You could then >>>>> merge, copy my files over the sources and do the remaining resolving >>>>> in the closed directories. >>>>> >>>>> What do you think, should we try it this way next time? >>>>> >>>>>> >>>>>> I started JDK and Hotspot JPRT test runs. If they passed I will push >>>>>> what >>>>>> I >>>>>> have and then you need to fix it for AIX. >>>>>> >>>>> >>>>> I'm ready to start... >>>>> >>>>>> Regards, >>>>>> Vladimir >>>>>> >>>> >> From coleen.phillimore at oracle.com Sun Nov 10 20:24:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Sun, 10 Nov 2013 23:24:02 -0500 Subject: RFR 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field,change Message-ID: <52805BE2.4040204@oracle.com> Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. open webrev at http://cr.openjdk.java.net/~coleenp/8025937/ bug link https://bugs.openjdk.java.net/browse/JDK-8025937 Tested with testcase in time api, java/lang/invoke jtreg tests, NSK mlvm, quick and defmeth tests, jck lang/vm tests, and testcase in changeset. Thanks, Coleen From scolebourne at joda.org Mon Nov 11 05:23:29 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 11 Nov 2013 13:23:29 +0000 Subject: Apparant bug in the JVM Message-ID: I was sent this piece of test code by Dirk Lemmermann. It fails randomly on JDK8 b114 import static java.time.temporal.ChronoUnit.DAYS; import java.time.Instant; public class TestInstantBug { public static void main(String[] args) { Instant now = Instant.now(); System.out.println("now = " + now); for (int i = 0; i < 100000; i++) { System.out.println(i); Instant truncated = now.truncatedTo(DAYS); System.out.println(truncated); } } } The code does not change any variables during the loop. Instant is immutable and well written to my knowledge. My debugging shows some horrible behaviour. I copied Instant.java and edited it, adding it to the bootclasspath. This is the original code in Instant.java: private static Instant create(long seconds, int nanoOfSecond) { if ((seconds | nanoOfSecond) == 0) { return EPOCH; } if (seconds < MIN_SECOND || seconds > MAX_SECOND) { throw new DateTimeException("Instant exceeds minimum or maximum instant"); } return new Instant(seconds, nanoOfSecond); } The second if statement randomly fails. Worse, the use of a System.out.println() on the "seconds" variable causes the if statement to reset. Given this test code: private static Instant create(long seconds, int nanoOfSecond) { if ((seconds | nanoOfSecond) == 0) { return EPOCH; } System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); if (seconds < MIN_SECOND || seconds > MAX_SECOND) { System.out.println(MIN_SECOND); System.out.println(MAX_SECOND); System.out.println(seconds); System.out.println(seconds < MIN_SECOND); System.out.println(seconds > MAX_SECOND); System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); System.out.println("Create " + seconds); System.out.println(MIN_SECOND); System.out.println(MAX_SECOND); System.out.println(seconds); System.out.println(seconds < MIN_SECOND); System.out.println(seconds > MAX_SECOND); System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); throw new DateTimeException("Instant exceeds minimum or maximum instant"); } return new Instant(seconds, nanoOfSecond); } the output is (when it actually fails): true // the if statement randomly returned true -31557014167219200 31556889864403199 1384128000 false // the two parts of the if statement return false false // the two parts of the if statement return false true // the if statement still returns true Create 1384128000 // system out resets it -31557014167219200 31556889864403199 1384128000 false false false // the if statement returns false Exception in thread "main" java.time.DateTimeException: Instant exceeds minimum or maximum instant at java.time.Instant.create(Instant.java:422) at java.time.Instant.ofEpochSecond(Instant.java:327) at java.time.Instant.plus(Instant.java:940) at java.time.Instant.plusNanos(Instant.java:918) at java.time.Instant.truncatedTo(Instant.java:773) at TestInstantBug.main(TestInstantBug.java:13) 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:483) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Hope you can squash this bug. b114 needs a big warning sign on it. Stephen From Alan.Bateman at oracle.com Mon Nov 11 05:33:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Nov 2013 13:33:43 +0000 Subject: Apparant bug in the JVM In-Reply-To: References: Message-ID: <5280DCB7.3080805@oracle.com> I assume this is it: https://bugs.openjdk.java.net/browse/JDK-8027622 You need to use -XX:- XX:-UseMathExactIntrinsics until hs25-b58 makes it into a build. -Alan. On 11/11/2013 13:23, Stephen Colebourne wrote: > I was sent this piece of test code by Dirk Lemmermann. It fails > randomly on JDK8 b114 > > import static java.time.temporal.ChronoUnit.DAYS; > import java.time.Instant; > > public class TestInstantBug { > public static void main(String[] args) { > Instant now = Instant.now(); > System.out.println("now = " + now); > for (int i = 0; i< 100000; i++) { > System.out.println(i); > Instant truncated = now.truncatedTo(DAYS); > System.out.println(truncated); > } > } > } > > The code does not change any variables during the loop. Instant is > immutable and well written to my knowledge. > > My debugging shows some horrible behaviour. > > I copied Instant.java and edited it, adding it to the bootclasspath. > This is the original code in Instant.java: > private static Instant create(long seconds, int nanoOfSecond) { > if ((seconds | nanoOfSecond) == 0) { > return EPOCH; > } > if (seconds< MIN_SECOND || seconds> MAX_SECOND) { > throw new DateTimeException("Instant exceeds minimum or > maximum instant"); > } > return new Instant(seconds, nanoOfSecond); > } > > The second if statement randomly fails. > Worse, the use of a System.out.println() on the "seconds" variable > causes the if statement to reset. > > Given this test code: > > private static Instant create(long seconds, int nanoOfSecond) { > if ((seconds | nanoOfSecond) == 0) { > return EPOCH; > } > System.out.println(seconds< MIN_SECOND || seconds> MAX_SECOND); > if (seconds< MIN_SECOND || seconds> MAX_SECOND) { > System.out.println(MIN_SECOND); > System.out.println(MAX_SECOND); > System.out.println(seconds); > System.out.println(seconds< MIN_SECOND); > System.out.println(seconds> MAX_SECOND); > System.out.println(seconds< MIN_SECOND || seconds> MAX_SECOND); > System.out.println("Create " + seconds); > System.out.println(MIN_SECOND); > System.out.println(MAX_SECOND); > System.out.println(seconds); > System.out.println(seconds< MIN_SECOND); > System.out.println(seconds> MAX_SECOND); > System.out.println(seconds< MIN_SECOND || seconds> MAX_SECOND); > throw new DateTimeException("Instant exceeds minimum or > maximum instant"); > } > return new Instant(seconds, nanoOfSecond); > } > > the output is (when it actually fails): > true // the if statement randomly returned true > -31557014167219200 > 31556889864403199 > 1384128000 > false // the two parts of the if statement return false > false // the two parts of the if statement return false > true // the if statement still returns true > Create 1384128000 // system out resets it > -31557014167219200 > 31556889864403199 > 1384128000 > false > false > false // the if statement returns false > Exception in thread "main" java.time.DateTimeException: Instant > exceeds minimum or maximum instant > at java.time.Instant.create(Instant.java:422) > at java.time.Instant.ofEpochSecond(Instant.java:327) > at java.time.Instant.plus(Instant.java:940) > at java.time.Instant.plusNanos(Instant.java:918) > at java.time.Instant.truncatedTo(Instant.java:773) > at TestInstantBug.main(TestInstantBug.java:13) > 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:483) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > > Hope you can squash this bug. b114 needs a big warning sign on it. > > Stephen From rickard.backman at oracle.com Mon Nov 11 05:32:14 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 11 Nov 2013 14:32:14 +0100 Subject: Apparant bug in the JVM In-Reply-To: References: Message-ID: <20131111133214.GC28348@rbackman> Stephen, it's been fixed in b115. Bug: JDK-8027622 Thanks /R On 11/11, Stephen Colebourne wrote: > I was sent this piece of test code by Dirk Lemmermann. It fails > randomly on JDK8 b114 > > import static java.time.temporal.ChronoUnit.DAYS; > import java.time.Instant; > > public class TestInstantBug { > public static void main(String[] args) { > Instant now = Instant.now(); > System.out.println("now = " + now); > for (int i = 0; i < 100000; i++) { > System.out.println(i); > Instant truncated = now.truncatedTo(DAYS); > System.out.println(truncated); > } > } > } > > The code does not change any variables during the loop. Instant is > immutable and well written to my knowledge. > > My debugging shows some horrible behaviour. > > I copied Instant.java and edited it, adding it to the bootclasspath. > This is the original code in Instant.java: > private static Instant create(long seconds, int nanoOfSecond) { > if ((seconds | nanoOfSecond) == 0) { > return EPOCH; > } > if (seconds < MIN_SECOND || seconds > MAX_SECOND) { > throw new DateTimeException("Instant exceeds minimum or > maximum instant"); > } > return new Instant(seconds, nanoOfSecond); > } > > The second if statement randomly fails. > Worse, the use of a System.out.println() on the "seconds" variable > causes the if statement to reset. > > Given this test code: > > private static Instant create(long seconds, int nanoOfSecond) { > if ((seconds | nanoOfSecond) == 0) { > return EPOCH; > } > System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); > if (seconds < MIN_SECOND || seconds > MAX_SECOND) { > System.out.println(MIN_SECOND); > System.out.println(MAX_SECOND); > System.out.println(seconds); > System.out.println(seconds < MIN_SECOND); > System.out.println(seconds > MAX_SECOND); > System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); > System.out.println("Create " + seconds); > System.out.println(MIN_SECOND); > System.out.println(MAX_SECOND); > System.out.println(seconds); > System.out.println(seconds < MIN_SECOND); > System.out.println(seconds > MAX_SECOND); > System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); > throw new DateTimeException("Instant exceeds minimum or > maximum instant"); > } > return new Instant(seconds, nanoOfSecond); > } > > the output is (when it actually fails): > true // the if statement randomly returned true > -31557014167219200 > 31556889864403199 > 1384128000 > false // the two parts of the if statement return false > false // the two parts of the if statement return false > true // the if statement still returns true > Create 1384128000 // system out resets it > -31557014167219200 > 31556889864403199 > 1384128000 > false > false > false // the if statement returns false > Exception in thread "main" java.time.DateTimeException: Instant > exceeds minimum or maximum instant > at java.time.Instant.create(Instant.java:422) > at java.time.Instant.ofEpochSecond(Instant.java:327) > at java.time.Instant.plus(Instant.java:940) > at java.time.Instant.plusNanos(Instant.java:918) > at java.time.Instant.truncatedTo(Instant.java:773) > at TestInstantBug.main(TestInstantBug.java:13) > 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:483) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > > Hope you can squash this bug. b114 needs a big warning sign on it. > > Stephen From scolebourne at joda.org Mon Nov 11 05:42:48 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 11 Nov 2013 13:42:48 +0000 Subject: Apparant bug in the JVM In-Reply-To: <20131111133214.GC28348@rbackman> References: <20131111133214.GC28348@rbackman> Message-ID: Cool, must have missed the linked threads. Stephen On 11 November 2013 13:32, Rickard B?ckman wrote: > Stephen, > > it's been fixed in b115. > Bug: JDK-8027622 > > Thanks > /R > > On 11/11, Stephen Colebourne wrote: >> I was sent this piece of test code by Dirk Lemmermann. It fails >> randomly on JDK8 b114 >> >> import static java.time.temporal.ChronoUnit.DAYS; >> import java.time.Instant; >> >> public class TestInstantBug { >> public static void main(String[] args) { >> Instant now = Instant.now(); >> System.out.println("now = " + now); >> for (int i = 0; i < 100000; i++) { >> System.out.println(i); >> Instant truncated = now.truncatedTo(DAYS); >> System.out.println(truncated); >> } >> } >> } >> >> The code does not change any variables during the loop. Instant is >> immutable and well written to my knowledge. >> >> My debugging shows some horrible behaviour. >> >> I copied Instant.java and edited it, adding it to the bootclasspath. >> This is the original code in Instant.java: >> private static Instant create(long seconds, int nanoOfSecond) { >> if ((seconds | nanoOfSecond) == 0) { >> return EPOCH; >> } >> if (seconds < MIN_SECOND || seconds > MAX_SECOND) { >> throw new DateTimeException("Instant exceeds minimum or >> maximum instant"); >> } >> return new Instant(seconds, nanoOfSecond); >> } >> >> The second if statement randomly fails. >> Worse, the use of a System.out.println() on the "seconds" variable >> causes the if statement to reset. >> >> Given this test code: >> >> private static Instant create(long seconds, int nanoOfSecond) { >> if ((seconds | nanoOfSecond) == 0) { >> return EPOCH; >> } >> System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); >> if (seconds < MIN_SECOND || seconds > MAX_SECOND) { >> System.out.println(MIN_SECOND); >> System.out.println(MAX_SECOND); >> System.out.println(seconds); >> System.out.println(seconds < MIN_SECOND); >> System.out.println(seconds > MAX_SECOND); >> System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); >> System.out.println("Create " + seconds); >> System.out.println(MIN_SECOND); >> System.out.println(MAX_SECOND); >> System.out.println(seconds); >> System.out.println(seconds < MIN_SECOND); >> System.out.println(seconds > MAX_SECOND); >> System.out.println(seconds < MIN_SECOND || seconds > MAX_SECOND); >> throw new DateTimeException("Instant exceeds minimum or >> maximum instant"); >> } >> return new Instant(seconds, nanoOfSecond); >> } >> >> the output is (when it actually fails): >> true // the if statement randomly returned true >> -31557014167219200 >> 31556889864403199 >> 1384128000 >> false // the two parts of the if statement return false >> false // the two parts of the if statement return false >> true // the if statement still returns true >> Create 1384128000 // system out resets it >> -31557014167219200 >> 31556889864403199 >> 1384128000 >> false >> false >> false // the if statement returns false >> Exception in thread "main" java.time.DateTimeException: Instant >> exceeds minimum or maximum instant >> at java.time.Instant.create(Instant.java:422) >> at java.time.Instant.ofEpochSecond(Instant.java:327) >> at java.time.Instant.plus(Instant.java:940) >> at java.time.Instant.plusNanos(Instant.java:918) >> at java.time.Instant.truncatedTo(Instant.java:773) >> at TestInstantBug.main(TestInstantBug.java:13) >> 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:483) >> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >> >> Hope you can squash this bug. b114 needs a big warning sign on it. >> >> Stephen From keithgchapman at gmail.com Mon Nov 11 12:29:38 2013 From: keithgchapman at gmail.com (Keith Chapman) Date: Mon, 11 Nov 2013 15:29:38 -0500 Subject: Is it possible to stop a specific application thread? Message-ID: Hi, I'm playing around with some research ideas on hotspot. One of my runtime services of the VM needs to stop a specific application thread (I have a handle to the pthread of the application thread). How can the VM stop such a thread? Is there any mechanism in place to do this? Thanks, Keith. -- Keith Chapman blog: http://www.keith-chapman.org From david.holmes at oracle.com Mon Nov 11 16:26:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Nov 2013 10:26:00 +1000 Subject: Is it possible to stop a specific application thread? In-Reply-To: References: Message-ID: <52817598.1050703@oracle.com> Hi Keith, On 12/11/2013 6:29 AM, Keith Chapman wrote: > Hi, > > I'm playing around with some research ideas on hotspot. > > One of my runtime services of the VM needs to stop a specific application > thread (I have a handle to the pthread of the application thread). How can > the VM stop such a thread? Is there any mechanism in place to do this? There is no general purpose mechanism currently in place. You could use the deprecated and inherently dangerous Thread.suspend mechanism (either directly or via the JVMTI suspension interface). Or if you are more adventurous with your VM hacking you could introduce a per-thread safepoint operation to cause it to stop. Or you could hack in a special "magic exception" type the processing of which simply blocks the thread until "resumed" somehow (not sure how ??). Or ... Cheers, David > Thanks, > Keith. > From keithgchapman at gmail.com Mon Nov 11 17:16:09 2013 From: keithgchapman at gmail.com (Keith Chapman) Date: Mon, 11 Nov 2013 20:16:09 -0500 Subject: Is it possible to stop a specific application thread? In-Reply-To: <52817598.1050703@oracle.com> References: <52817598.1050703@oracle.com> Message-ID: Hi David, On Mon, Nov 11, 2013 at 7:26 PM, David Holmes wrote: > Hi Keith, > > > On 12/11/2013 6:29 AM, Keith Chapman wrote: > >> Hi, >> >> I'm playing around with some research ideas on hotspot. >> >> One of my runtime services of the VM needs to stop a specific application >> thread (I have a handle to the pthread of the application thread). How can >> the VM stop such a thread? Is there any mechanism in place to do this? >> > > There is no general purpose mechanism currently in place. > Thats a bummer, having such a mechanism would have been useful for numerous VM services like biased locking revocation, concurrent GC. > > You could use the deprecated and inherently dangerous Thread.suspend > mechanism (either directly or via the JVMTI suspension interface). > > Or if you are more adventurous with your VM hacking you could introduce a > per-thread safepoint operation to cause it to stop. I actually thought about that and explored the way safepoints are implemented. The place that I had most trouble was getting threads running compiled code to stop. The way it currently works is by allocating a polling page (at startup) and drilling in that address into the compiled code. Hence i I am to do it per thread I would have to make a call to the runtime to get the address of the polling page for that particular thread. I presume this would be too expensive (Making a VM call at the end of each method and through some loop iterations). Is there any insight you could offer on how this could be done? Thanks, Keith. > Or you could hack in a special "magic exception" type the processing of > which simply blocks the thread until "resumed" somehow (not sure how ??). > Or ... > > Cheers, > David > > Thanks, >> Keith. >> >> -- Keith Chapman blog: http://www.keith-chapman.org From david.holmes at oracle.com Mon Nov 11 17:25:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Nov 2013 11:25:04 +1000 Subject: Is it possible to stop a specific application thread? In-Reply-To: References: <52817598.1050703@oracle.com> Message-ID: <52818370.4050004@oracle.com> On 12/11/2013 11:16 AM, Keith Chapman wrote: > Hi David, > > On Mon, Nov 11, 2013 at 7:26 PM, David Holmes > wrote: > > Hi Keith, > > > On 12/11/2013 6:29 AM, Keith Chapman wrote: > > Hi, > > I'm playing around with some research ideas on hotspot. > > One of my runtime services of the VM needs to stop a specific > application > thread (I have a handle to the pthread of the application > thread). How can > the VM stop such a thread? Is there any mechanism in place to do > this? > > > There is no general purpose mechanism currently in place. > > > Thats a bummer, having such a mechanism would have been useful for > numerous VM services like biased locking revocation, concurrent GC. For which safepoints are generally used so a per-thread safepoint mechanism is what you are looking for. > > You could use the deprecated and inherently dangerous Thread.suspend > mechanism (either directly or via the JVMTI suspension interface). > > Or if you are more adventurous with your VM hacking you could > introduce a per-thread safepoint operation to cause it to stop. > > > I actually thought about that and explored the way safepoints are > implemented. The place that I had most trouble was getting threads > running compiled code to stop. The way it currently works is by > allocating a polling page (at startup) and drilling in that address into > the compiled code. Hence i I am to do it per thread I would have to make > a call to the runtime to get the address of the polling page for that > particular thread. I presume this would be too expensive (Making a VM > call at the end of each method and through some loop iterations). > > Is there any insight you could offer on how this could be done? Two basic options I can think of: 1. Use a single shared page and have other threads simply ignore the safepoint request. This might incur some overhead as not-wanted threads could hit this multiple times. 2. Use a per-thread page accessed via the current thread. There would be a little overhead for the indirection but the compiler knows how to access the current JavaThread object. No need for runtime calls that I can see. Good luck. David > Thanks, > Keith. > > Or you could hack in a special "magic exception" type the processing > of which simply blocks the thread until "resumed" somehow (not sure > how ??). Or ... > > Cheers, > David > > Thanks, > Keith. > > > > > -- > > Keith Chapman > blog: http://www.keith-chapman.org From keithgchapman at gmail.com Mon Nov 11 17:50:11 2013 From: keithgchapman at gmail.com (Keith Chapman) Date: Mon, 11 Nov 2013 20:50:11 -0500 Subject: Is it possible to stop a specific application thread? In-Reply-To: <52818370.4050004@oracle.com> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> Message-ID: Hi David, On Mon, Nov 11, 2013 at 8:25 PM, David Holmes wrote: > On 12/11/2013 11:16 AM, Keith Chapman wrote: > >> Hi David, >> >> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes > > wrote: >> >> Hi Keith, >> >> >> On 12/11/2013 6:29 AM, Keith Chapman wrote: >> >> Hi, >> >> I'm playing around with some research ideas on hotspot. >> >> One of my runtime services of the VM needs to stop a specific >> application >> thread (I have a handle to the pthread of the application >> thread). How can >> the VM stop such a thread? Is there any mechanism in place to do >> this? >> >> >> There is no general purpose mechanism currently in place. >> >> >> Thats a bummer, having such a mechanism would have been useful for >> numerous VM services like biased locking revocation, concurrent GC. >> > > For which safepoints are generally used so a per-thread safepoint > mechanism is what you are looking for. > > > >> You could use the deprecated and inherently dangerous Thread.suspend >> mechanism (either directly or via the JVMTI suspension interface). >> >> Or if you are more adventurous with your VM hacking you could >> introduce a per-thread safepoint operation to cause it to stop. >> >> >> I actually thought about that and explored the way safepoints are >> implemented. The place that I had most trouble was getting threads >> running compiled code to stop. The way it currently works is by >> allocating a polling page (at startup) and drilling in that address into >> the compiled code. Hence i I am to do it per thread I would have to make >> a call to the runtime to get the address of the polling page for that >> particular thread. I presume this would be too expensive (Making a VM >> call at the end of each method and through some loop iterations). >> >> Is there any insight you could offer on how this could be done? >> > > Two basic options I can think of: > > 1. Use a single shared page and have other threads simply ignore the > safepoint request. This might incur some overhead as not-wanted threads > could hit this multiple times. > > 2. Use a per-thread page accessed via the current thread. There would be a > little overhead for the indirection but the compiler knows how to access > the current JavaThread object. No need for runtime calls that I can see. > This seems to be the most viable option. Cold you point me to an example in the codebase where something similar is done (Accessing the a field via the current thread) in the compiler. I have already figured out how to do this for the other cases, its just the compiled code (Accessing a thread local safepoint page) that I haven't figured out yet. Thanks, Keith. > > Good luck. > > David > > > Thanks, >> Keith. >> >> Or you could hack in a special "magic exception" type the processing >> of which simply blocks the thread until "resumed" somehow (not sure >> how ??). Or ... >> >> Cheers, >> David >> >> Thanks, >> Keith. >> >> >> >> >> -- >> >> Keith Chapman >> blog: http://www.keith-chapman.org >> > -- Keith Chapman blog: http://www.keith-chapman.org From david.holmes at oracle.com Mon Nov 11 18:06:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Nov 2013 12:06:37 +1000 Subject: Is it possible to stop a specific application thread? In-Reply-To: References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> Message-ID: <52818D2D.6010707@oracle.com> On 12/11/2013 11:50 AM, Keith Chapman wrote: > On Mon, Nov 11, 2013 at 8:25 PM, David Holmes > wrote: > On 12/11/2013 11:16 AM, Keith Chapman wrote: > On Mon, Nov 11, 2013 at 7:26 PM, David Holmes > > >> wrote: > On 12/11/2013 6:29 AM, Keith Chapman wrote: > I'm playing around with some research ideas on hotspot. > > One of my runtime services of the VM needs to stop a > specific > application > thread (I have a handle to the pthread of the application > thread). How can > the VM stop such a thread? Is there any mechanism in > place to do > this? > > > There is no general purpose mechanism currently in place. > > > Thats a bummer, having such a mechanism would have been useful for > numerous VM services like biased locking revocation, concurrent GC. > > > For which safepoints are generally used so a per-thread safepoint > mechanism is what you are looking for. > > > > You could use the deprecated and inherently dangerous > Thread.suspend > mechanism (either directly or via the JVMTI suspension > interface). > > Or if you are more adventurous with your VM hacking you could > introduce a per-thread safepoint operation to cause it to stop. > > > I actually thought about that and explored the way safepoints are > implemented. The place that I had most trouble was getting threads > running compiled code to stop. The way it currently works is by > allocating a polling page (at startup) and drilling in that > address into > the compiled code. Hence i I am to do it per thread I would have > to make > a call to the runtime to get the address of the polling page for > that > particular thread. I presume this would be too expensive (Making > a VM > call at the end of each method and through some loop iterations). > > Is there any insight you could offer on how this could be done? > > > Two basic options I can think of: > > 1. Use a single shared page and have other threads simply ignore the > safepoint request. This might incur some overhead as not-wanted > threads could hit this multiple times. > > 2. Use a per-thread page accessed via the current thread. There > would be a little overhead for the indirection but the compiler > knows how to access the current JavaThread object. No need for > runtime calls that I can see. > > > This seems to be the most viable option. Cold you point me to an example > in the codebase where something similar is done (Accessing the a field > via the current thread) in the compiler. I have already figured out how > to do this for the other cases, its just the compiled code (Accessing a > thread local safepoint page) that I haven't figured out yet. I'm not a compiler person but the intrinsic for Thread.currentThread does just that: accesses the JavaThread field of the current thread that points to the java.lang.Thread object: From share/vm/c1/c1_LIRGenerator.cpp // Example: Thread.currentThread() void LIRGenerator::do_currentThread(Intrinsic* x) { assert(x->number_of_arguments() == 0, "wrong type"); LIR_Opr reg = rlock_result(x); __ move_wide(new LIR_Address(getThreadPointer(), in_bytes(JavaThread::threadObj_offset()), T_OBJECT), reg); } From ./share/vm/opto/library_call.cpp //--------------------------generate_current_thread-------------------- Node* LibraryCallKit::generate_current_thread(Node* &tls_output) { ciKlass* thread_klass = env()->Thread_klass(); const Type* thread_type = TypeOopPtr::make_from_klass(thread_klass)->cast_to_ptr_type(TypePtr::NotNull); Node* thread = _gvn.transform(new (C) ThreadLocalNode()); Node* p = basic_plus_adr(top()/*!oop*/, thread, in_bytes(JavaThread::threadObj_offset())); Node* threadObj = make_load(NULL, p, thread_type, T_OBJECT); tls_output = thread; return threadObj; } But please don't ask me how these work :) PS. Be very careful changing what would normally be global safepoint ops into per-thread ones. There are a lot of safepoint assumptions strewn throughout the VM code. David ----- > Thanks, > Keith. > > > Good luck. > > David > > > Thanks, > Keith. > > Or you could hack in a special "magic exception" type the > processing > of which simply blocks the thread until "resumed" somehow > (not sure > how ??). Or ... > > Cheers, > David > > Thanks, > Keith. > > > > > -- > > Keith Chapman > blog: http://www.keith-chapman.org > > > > > -- > > Keith Chapman > blog: http://www.keith-chapman.org From kmcguigan at twitter.com Mon Nov 11 21:46:20 2013 From: kmcguigan at twitter.com (Keith McGuigan) Date: Tue, 12 Nov 2013 00:46:20 -0500 Subject: Is it possible to stop a specific application thread? In-Reply-To: <52818370.4050004@oracle.com> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> Message-ID: I had a prototype at one point that did #2, but I don't have the source for it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they can reply with the diffs to give someone a leg up in doing this again. -- - Keith (McGuigan) On Monday, November 11, 2013, David Holmes wrote: > On 12/11/2013 11:16 AM, Keith Chapman wrote: > >> Hi David, >> >> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes > > wrote: >> >> Hi Keith, >> >> >> On 12/11/2013 6:29 AM, Keith Chapman wrote: >> >> Hi, >> >> I'm playing around with some research ideas on hotspot. >> >> One of my runtime services of the VM needs to stop a specific >> application >> thread (I have a handle to the pthread of the application >> thread). How can >> the VM stop such a thread? Is there any mechanism in place to do >> this? >> >> >> There is no general purpose mechanism currently in place. >> >> >> Thats a bummer, having such a mechanism would have been useful for >> numerous VM services like biased locking revocation, concurrent GC. >> > > For which safepoints are generally used so a per-thread safepoint > mechanism is what you are looking for. > > >> You could use the deprecated and inherently dangerous Thread.suspend >> mechanism (either directly or via the JVMTI suspension interface). >> >> Or if you are more adventurous with your VM hacking you could >> introduce a per-thread safepoint operation to cause it to stop. >> >> >> I actually thought about that and explored the way safepoints are >> implemented. The place that I had most trouble was getting threads >> running compiled code to stop. The way it currently works is by >> allocating a polling page (at startup) and drilling in that address into >> the compiled code. Hence i I am to do it per thread I would have to make >> a call to the runtime to get the address of the polling page for that >> particular thread. I presume this would be too expensive (Making a VM >> call at the end of each method and through some loop iterations). >> >> Is there any insight you could offer on how this could be done? >> > > Two basic options I can think of: > > 1. Use a single shared page and have other threads simply ignore the > safepoint request. This might incur some overhead as not-wanted threads > could hit this multiple times. > > 2. Use a per-thread page accessed via the current thread. There would be a > little overhead for the indirection but the compiler knows how to access > the current JavaThread object. No need for runtime calls that I can see. > > Good luck. > > David > > Thanks, >> Keith. >> >> Or you could hack in a special "magic exception" type the processing >> of which simply blocks the thread until "resumed" somehow (not sure >> how ??). Or ... >> >> Cheers, >> David >> >> Thanks, >> Keith. >> >> >> >> >> -- >> >> Keith Chapman >> blog: http://www.keith-chapman.org >> > From goetz.lindenmaier at sap.com Tue Nov 12 00:24:52 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Nov 2013 08:24:52 +0000 Subject: Is it possible to stop a specific application thread? In-Reply-To: References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> Hi, our VM is running with what we call PerThreadSafepoints for a long time. We implement this by loading the page from the thread as you propose. But we don't have a page per thread, as poisoning them seems to costly if there are many threads and all threads must be stopped. Instead, we adapt the field in the thread: usually it points to some valid address. If a safepoint is required, the polling page is written into that field. We implemented this when we tried to improve BiasedLocking, but as we could not gain anything, we don't really use it any more. If you really have interest in this feature, I can prepare a webrev for it. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan Sent: Dienstag, 12. November 2013 06:46 To: David Holmes Cc: hotspot-dev at openjdk.java.net Subject: Re: Is it possible to stop a specific application thread? I had a prototype at one point that did #2, but I don't have the source for it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they can reply with the diffs to give someone a leg up in doing this again. -- - Keith (McGuigan) On Monday, November 11, 2013, David Holmes wrote: > On 12/11/2013 11:16 AM, Keith Chapman wrote: > >> Hi David, >> >> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes > > wrote: >> >> Hi Keith, >> >> >> On 12/11/2013 6:29 AM, Keith Chapman wrote: >> >> Hi, >> >> I'm playing around with some research ideas on hotspot. >> >> One of my runtime services of the VM needs to stop a specific >> application >> thread (I have a handle to the pthread of the application >> thread). How can >> the VM stop such a thread? Is there any mechanism in place to do >> this? >> >> >> There is no general purpose mechanism currently in place. >> >> >> Thats a bummer, having such a mechanism would have been useful for >> numerous VM services like biased locking revocation, concurrent GC. >> > > For which safepoints are generally used so a per-thread safepoint > mechanism is what you are looking for. > > >> You could use the deprecated and inherently dangerous Thread.suspend >> mechanism (either directly or via the JVMTI suspension interface). >> >> Or if you are more adventurous with your VM hacking you could >> introduce a per-thread safepoint operation to cause it to stop. >> >> >> I actually thought about that and explored the way safepoints are >> implemented. The place that I had most trouble was getting threads >> running compiled code to stop. The way it currently works is by >> allocating a polling page (at startup) and drilling in that address into >> the compiled code. Hence i I am to do it per thread I would have to make >> a call to the runtime to get the address of the polling page for that >> particular thread. I presume this would be too expensive (Making a VM >> call at the end of each method and through some loop iterations). >> >> Is there any insight you could offer on how this could be done? >> > > Two basic options I can think of: > > 1. Use a single shared page and have other threads simply ignore the > safepoint request. This might incur some overhead as not-wanted threads > could hit this multiple times. > > 2. Use a per-thread page accessed via the current thread. There would be a > little overhead for the indirection but the compiler knows how to access > the current JavaThread object. No need for runtime calls that I can see. > > Good luck. > > David > > Thanks, >> Keith. >> >> Or you could hack in a special "magic exception" type the processing >> of which simply blocks the thread until "resumed" somehow (not sure >> how ??). Or ... >> >> Cheers, >> David >> >> Thanks, >> Keith. >> >> >> >> >> -- >> >> Keith Chapman >> blog: http://www.keith-chapman.org >> > From david.holmes at oracle.com Tue Nov 12 01:39:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Nov 2013 19:39:03 +1000 Subject: Is it possible to stop a specific application thread? In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> Message-ID: <5281F737.8070505@oracle.com> On 12/11/2013 6:24 PM, Lindenmaier, Goetz wrote: > Hi, > > our VM is running with what we call PerThreadSafepoints for a long time. > > We implement this by loading the page from the thread as you propose. > But we don't have a page per thread, as poisoning them seems to costly > if there are many threads and all threads must be stopped. Good point. You don't want a global safepoint to be implemented as a set of per-thread safepoints. > Instead, we adapt the field in the thread: usually it points to some > valid address. If a safepoint is required, the polling page is written > into that field. So a global safepoint still has to iterate the Threads list to update every individual field? I wonder if two polls (one per-thread and one global) would be too detrimental to normal performance .... Cheers, David > We implemented this when we tried to improve BiasedLocking, > but as we could not gain anything, we don't really use it any more. > If you really have interest in this feature, I can prepare a webrev > for it. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan > Sent: Dienstag, 12. November 2013 06:46 > To: David Holmes > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > I had a prototype at one point that did #2, but I don't have the source for > it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they > can reply with the diffs to give someone a leg up in doing this again. > > -- > - Keith (McGuigan) > > On Monday, November 11, 2013, David Holmes wrote: > >> On 12/11/2013 11:16 AM, Keith Chapman wrote: >> >>> Hi David, >>> >>> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >> > wrote: >>> >>> Hi Keith, >>> >>> >>> On 12/11/2013 6:29 AM, Keith Chapman wrote: >>> >>> Hi, >>> >>> I'm playing around with some research ideas on hotspot. >>> >>> One of my runtime services of the VM needs to stop a specific >>> application >>> thread (I have a handle to the pthread of the application >>> thread). How can >>> the VM stop such a thread? Is there any mechanism in place to do >>> this? >>> >>> >>> There is no general purpose mechanism currently in place. >>> >>> >>> Thats a bummer, having such a mechanism would have been useful for >>> numerous VM services like biased locking revocation, concurrent GC. >>> >> >> For which safepoints are generally used so a per-thread safepoint >> mechanism is what you are looking for. >> >> >>> You could use the deprecated and inherently dangerous Thread.suspend >>> mechanism (either directly or via the JVMTI suspension interface). >>> >>> Or if you are more adventurous with your VM hacking you could >>> introduce a per-thread safepoint operation to cause it to stop. >>> >>> >>> I actually thought about that and explored the way safepoints are >>> implemented. The place that I had most trouble was getting threads >>> running compiled code to stop. The way it currently works is by >>> allocating a polling page (at startup) and drilling in that address into >>> the compiled code. Hence i I am to do it per thread I would have to make >>> a call to the runtime to get the address of the polling page for that >>> particular thread. I presume this would be too expensive (Making a VM >>> call at the end of each method and through some loop iterations). >>> >>> Is there any insight you could offer on how this could be done? >>> >> >> Two basic options I can think of: >> >> 1. Use a single shared page and have other threads simply ignore the >> safepoint request. This might incur some overhead as not-wanted threads >> could hit this multiple times. >> >> 2. Use a per-thread page accessed via the current thread. There would be a >> little overhead for the indirection but the compiler knows how to access >> the current JavaThread object. No need for runtime calls that I can see. >> >> Good luck. >> >> David >> >> Thanks, >>> Keith. >>> >>> Or you could hack in a special "magic exception" type the processing >>> of which simply blocks the thread until "resumed" somehow (not sure >>> how ??). Or ... >>> >>> Cheers, >>> David >>> >>> Thanks, >>> Keith. >>> >>> >>> >>> >>> -- >>> >>> Keith Chapman >>> blog: http://www.keith-chapman.org >>> >> From goetz.lindenmaier at sap.com Tue Nov 12 02:26:39 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Nov 2013 10:26:39 +0000 Subject: Is it possible to stop a specific application thread? In-Reply-To: <5281F737.8070505@oracle.com> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> <5281F737.8070505@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE644DD@DEWDFEMB12A.global.corp.sap> Hi David, > So a global safepoint still has to iterate the Threads list to update > every individual field? Yes, but that can be done in parallel. It does not do measurable harm In our VM. If you really want to improve on this, you could use two pages: one for the normal safepoints that is in the thread's field per default. Here you change the poisoning of the page. The second is always unaccessible, and you write it's address into the threads field if you want to stop a single thread. I think the biggest effect on performance is that the poll address has to be reread on every safepoint, i.e., the node loading the address can not be moved out of loops. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 12. November 2013 10:39 To: Lindenmaier, Goetz Cc: Keith McGuigan; hotspot-dev at openjdk.java.net Subject: Re: Is it possible to stop a specific application thread? On 12/11/2013 6:24 PM, Lindenmaier, Goetz wrote: > Hi, > > our VM is running with what we call PerThreadSafepoints for a long time. > > We implement this by loading the page from the thread as you propose. > But we don't have a page per thread, as poisoning them seems to costly > if there are many threads and all threads must be stopped. Good point. You don't want a global safepoint to be implemented as a set of per-thread safepoints. > Instead, we adapt the field in the thread: usually it points to some > valid address. If a safepoint is required, the polling page is written > into that field. So a global safepoint still has to iterate the Threads list to update every individual field? I wonder if two polls (one per-thread and one global) would be too detrimental to normal performance .... Cheers, David > We implemented this when we tried to improve BiasedLocking, > but as we could not gain anything, we don't really use it any more. > If you really have interest in this feature, I can prepare a webrev > for it. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan > Sent: Dienstag, 12. November 2013 06:46 > To: David Holmes > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > I had a prototype at one point that did #2, but I don't have the source for > it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they > can reply with the diffs to give someone a leg up in doing this again. > > -- > - Keith (McGuigan) > > On Monday, November 11, 2013, David Holmes wrote: > >> On 12/11/2013 11:16 AM, Keith Chapman wrote: >> >>> Hi David, >>> >>> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >> > wrote: >>> >>> Hi Keith, >>> >>> >>> On 12/11/2013 6:29 AM, Keith Chapman wrote: >>> >>> Hi, >>> >>> I'm playing around with some research ideas on hotspot. >>> >>> One of my runtime services of the VM needs to stop a specific >>> application >>> thread (I have a handle to the pthread of the application >>> thread). How can >>> the VM stop such a thread? Is there any mechanism in place to do >>> this? >>> >>> >>> There is no general purpose mechanism currently in place. >>> >>> >>> Thats a bummer, having such a mechanism would have been useful for >>> numerous VM services like biased locking revocation, concurrent GC. >>> >> >> For which safepoints are generally used so a per-thread safepoint >> mechanism is what you are looking for. >> >> >>> You could use the deprecated and inherently dangerous Thread.suspend >>> mechanism (either directly or via the JVMTI suspension interface). >>> >>> Or if you are more adventurous with your VM hacking you could >>> introduce a per-thread safepoint operation to cause it to stop. >>> >>> >>> I actually thought about that and explored the way safepoints are >>> implemented. The place that I had most trouble was getting threads >>> running compiled code to stop. The way it currently works is by >>> allocating a polling page (at startup) and drilling in that address into >>> the compiled code. Hence i I am to do it per thread I would have to make >>> a call to the runtime to get the address of the polling page for that >>> particular thread. I presume this would be too expensive (Making a VM >>> call at the end of each method and through some loop iterations). >>> >>> Is there any insight you could offer on how this could be done? >>> >> >> Two basic options I can think of: >> >> 1. Use a single shared page and have other threads simply ignore the >> safepoint request. This might incur some overhead as not-wanted threads >> could hit this multiple times. >> >> 2. Use a per-thread page accessed via the current thread. There would be a >> little overhead for the indirection but the compiler knows how to access >> the current JavaThread object. No need for runtime calls that I can see. >> >> Good luck. >> >> David >> >> Thanks, >>> Keith. >>> >>> Or you could hack in a special "magic exception" type the processing >>> of which simply blocks the thread until "resumed" somehow (not sure >>> how ??). Or ... >>> >>> Cheers, >>> David >>> >>> Thanks, >>> Keith. >>> >>> >>> >>> >>> -- >>> >>> Keith Chapman >>> blog: http://www.keith-chapman.org >>> >> From jesper.wilhelmsson at oracle.com Tue Nov 12 04:56:48 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 12 Nov 2013 13:56:48 +0100 Subject: RFR: 8028162 - Update Netbeans / Solaris Studio project files on Mac Message-ID: <52822590.6000704@oracle.com> Hi, Could I have a couple of reviews of the updated project files for NetBeans / Solaris Studio. This change updates the Mac part of the project files. I intend to do the same change on linux as well but that will be a separate change. Then maybe someone who has a Solaris box can update the Solaris part? Bug: https://bugs.openjdk.java.net/browse/JDK-8028162 Webrev: http://cr.openjdk.java.net/~jwilhelm/8028162/webrev/ Looking at the diff you will see that all $SRC have been replaced by 0. This was done automatically by Solaris Studio. I asked in the support forum if this was correct, and apparently it was :-) Forum: http://myforums.oracle.com/jive3/thread.jspa?threadID=1350319&tstart=0 Thanks, /Jesper From keithgchapman at gmail.com Tue Nov 12 05:27:26 2013 From: keithgchapman at gmail.com (Keith Chapman) Date: Tue, 12 Nov 2013 08:27:26 -0500 Subject: Is it possible to stop a specific application thread? In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> Message-ID: On Tue, Nov 12, 2013 at 3:24 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > our VM is running with what we call PerThreadSafepoints for a long time. > > We implement this by loading the page from the thread as you propose. > But we don't have a page per thread, as poisoning them seems to costly > if there are many threads and all threads must be stopped. > > Instead, we adapt the field in the thread: usually it points to some > valid address. If a safepoint is required, the polling page is written > into that field. > > We implemented this when we tried to improve BiasedLocking, > but as we could not gain anything, we don't really use it any more. > > If you really have interest in this feature, I can prepare a webrev > for it. > That would be awesome. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto: > hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan > Sent: Dienstag, 12. November 2013 06:46 > To: David Holmes > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > I had a prototype at one point that did #2, but I don't have the source for > it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they > can reply with the diffs to give someone a leg up in doing this again. > > -- > - Keith (McGuigan) > > On Monday, November 11, 2013, David Holmes wrote: > > > On 12/11/2013 11:16 AM, Keith Chapman wrote: > > > >> Hi David, > >> > >> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >> > wrote: > >> > >> Hi Keith, > >> > >> > >> On 12/11/2013 6:29 AM, Keith Chapman wrote: > >> > >> Hi, > >> > >> I'm playing around with some research ideas on hotspot. > >> > >> One of my runtime services of the VM needs to stop a specific > >> application > >> thread (I have a handle to the pthread of the application > >> thread). How can > >> the VM stop such a thread? Is there any mechanism in place to do > >> this? > >> > >> > >> There is no general purpose mechanism currently in place. > >> > >> > >> Thats a bummer, having such a mechanism would have been useful for > >> numerous VM services like biased locking revocation, concurrent GC. > >> > > > > For which safepoints are generally used so a per-thread safepoint > > mechanism is what you are looking for. > > > > > >> You could use the deprecated and inherently dangerous Thread.suspend > >> mechanism (either directly or via the JVMTI suspension interface). > >> > >> Or if you are more adventurous with your VM hacking you could > >> introduce a per-thread safepoint operation to cause it to stop. > >> > >> > >> I actually thought about that and explored the way safepoints are > >> implemented. The place that I had most trouble was getting threads > >> running compiled code to stop. The way it currently works is by > >> allocating a polling page (at startup) and drilling in that address into > >> the compiled code. Hence i I am to do it per thread I would have to make > >> a call to the runtime to get the address of the polling page for that > >> particular thread. I presume this would be too expensive (Making a VM > >> call at the end of each method and through some loop iterations). > >> > >> Is there any insight you could offer on how this could be done? > >> > > > > Two basic options I can think of: > > > > 1. Use a single shared page and have other threads simply ignore the > > safepoint request. This might incur some overhead as not-wanted threads > > could hit this multiple times. > > > > 2. Use a per-thread page accessed via the current thread. There would be > a > > little overhead for the indirection but the compiler knows how to access > > the current JavaThread object. No need for runtime calls that I can see. > > > > Good luck. > > > > David > > > > Thanks, > >> Keith. > >> > >> Or you could hack in a special "magic exception" type the processing > >> of which simply blocks the thread until "resumed" somehow (not sure > >> how ??). Or ... > >> > >> Cheers, > >> David > >> > >> Thanks, > >> Keith. > >> > >> > >> > >> > >> -- > >> > >> Keith Chapman > >> blog: http://www.keith-chapman.org > >> > > > -- Keith Chapman blog: http://www.keith-chapman.org From vitalyd at gmail.com Tue Nov 12 06:22:57 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 12 Nov 2013 09:22:57 -0500 Subject: Is it possible to stop a specific application thread? In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE644DD@DEWDFEMB12A.global.corp.sap> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> <5281F737.8070505@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE644DD@DEWDFEMB12A.global.corp.sap> Message-ID: Rereading poll address inside loop shouldn't be too bad since it should stay in cache, maybe even L1 (depends on what else loop body does)? Sent from my phone On Nov 12, 2013 5:28 AM, "Lindenmaier, Goetz" wrote: > Hi David, > > > So a global safepoint still has to iterate the Threads list to update > > every individual field? > Yes, but that can be done in parallel. It does not do measurable harm > In our VM. > If you really want to improve on this, you could use two pages: > one for the normal safepoints that is in the thread's field per default. > Here you change the poisoning of the page. > The second is always unaccessible, and you write it's address into the > threads field if you want to stop a single thread. > > I think the biggest effect on performance is that the poll address has > to be reread on every safepoint, i.e., the node loading the address > can not be moved out of loops. > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 12. November 2013 10:39 > To: Lindenmaier, Goetz > Cc: Keith McGuigan; hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > On 12/11/2013 6:24 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > our VM is running with what we call PerThreadSafepoints for a long time. > > > > We implement this by loading the page from the thread as you propose. > > But we don't have a page per thread, as poisoning them seems to costly > > if there are many threads and all threads must be stopped. > > Good point. You don't want a global safepoint to be implemented as a set > of per-thread safepoints. > > > Instead, we adapt the field in the thread: usually it points to some > > valid address. If a safepoint is required, the polling page is written > > into that field. > > So a global safepoint still has to iterate the Threads list to update > every individual field? > > I wonder if two polls (one per-thread and one global) would be too > detrimental to normal performance .... > > Cheers, > David > > > We implemented this when we tried to improve BiasedLocking, > > but as we could not gain anything, we don't really use it any more. > > > If you really have interest in this feature, I can prepare a webrev > > for it. > > > > Best regards, > > Goetz. > > > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net [mailto: > hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan > > Sent: Dienstag, 12. November 2013 06:46 > > To: David Holmes > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: Is it possible to stop a specific application thread? > > > > I had a prototype at one point that did #2, but I don't have the source > for > > it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they > > can reply with the diffs to give someone a leg up in doing this again. > > > > -- > > - Keith (McGuigan) > > > > On Monday, November 11, 2013, David Holmes wrote: > > > >> On 12/11/2013 11:16 AM, Keith Chapman wrote: > >> > >>> Hi David, > >>> > >>> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >>> > wrote: > >>> > >>> Hi Keith, > >>> > >>> > >>> On 12/11/2013 6:29 AM, Keith Chapman wrote: > >>> > >>> Hi, > >>> > >>> I'm playing around with some research ideas on hotspot. > >>> > >>> One of my runtime services of the VM needs to stop a specific > >>> application > >>> thread (I have a handle to the pthread of the application > >>> thread). How can > >>> the VM stop such a thread? Is there any mechanism in place to > do > >>> this? > >>> > >>> > >>> There is no general purpose mechanism currently in place. > >>> > >>> > >>> Thats a bummer, having such a mechanism would have been useful for > >>> numerous VM services like biased locking revocation, concurrent GC. > >>> > >> > >> For which safepoints are generally used so a per-thread safepoint > >> mechanism is what you are looking for. > >> > >> > >>> You could use the deprecated and inherently dangerous > Thread.suspend > >>> mechanism (either directly or via the JVMTI suspension interface). > >>> > >>> Or if you are more adventurous with your VM hacking you could > >>> introduce a per-thread safepoint operation to cause it to stop. > >>> > >>> > >>> I actually thought about that and explored the way safepoints are > >>> implemented. The place that I had most trouble was getting threads > >>> running compiled code to stop. The way it currently works is by > >>> allocating a polling page (at startup) and drilling in that address > into > >>> the compiled code. Hence i I am to do it per thread I would have to > make > >>> a call to the runtime to get the address of the polling page for that > >>> particular thread. I presume this would be too expensive (Making a VM > >>> call at the end of each method and through some loop iterations). > >>> > >>> Is there any insight you could offer on how this could be done? > >>> > >> > >> Two basic options I can think of: > >> > >> 1. Use a single shared page and have other threads simply ignore the > >> safepoint request. This might incur some overhead as not-wanted threads > >> could hit this multiple times. > >> > >> 2. Use a per-thread page accessed via the current thread. There would > be a > >> little overhead for the indirection but the compiler knows how to access > >> the current JavaThread object. No need for runtime calls that I can see. > >> > >> Good luck. > >> > >> David > >> > >> Thanks, > >>> Keith. > >>> > >>> Or you could hack in a special "magic exception" type the > processing > >>> of which simply blocks the thread until "resumed" somehow (not > sure > >>> how ??). Or ... > >>> > >>> Cheers, > >>> David > >>> > >>> Thanks, > >>> Keith. > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Keith Chapman > >>> blog: http://www.keith-chapman.org > >>> > >> > From goetz.lindenmaier at sap.com Tue Nov 12 08:30:17 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Nov 2013 16:30:17 +0000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> Hi, I updated this webrev to work with the latest version of the staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ Best regards, Goetz. From: goetz.lindenmaier at sap.com Sent: Freitag, 11. Oktober 2013 15:34 To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Hi, I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. This is part of the PPC port. http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ For a detailed description see the text in the webrev and bug description. All this basically does is add a field to load and store nodes and change all constructor calls to set this field. So the effect on existing platforms should be very small. Therefore I marked this 'M', although quite some lines of code are touched. Please review and test this change. I'm happy to incorporate your comments and any improvements you propose. Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Nov 12 08:32:08 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 12 Nov 2013 16:32:08 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> Hi, I also updated this webrev to work with the latest staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ Best regards, Goetz. From: goetz.lindenmaier at sap.com Sent: Mittwoch, 2. Oktober 2013 15:49 To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. Hi, we extended C2 by what we call lateExpand. LateExpand expands nodes after register allocation. http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ Some nodes can not be expanded during matching. E.g., register allocation might not be able to deal with the resulting pattern. To allow better scheduling in such cases, we introduce lateExpand which runs after register allocation. Whether and how nodes are expanded is specified in the ad-file. See block.cpp for a detailed documentation. We use this for some nodes on ppc, and extensively on ia64. For an example, see the webrev. We added some utility functions in node.hpp and block.hpp used by PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, MachConstantBaseNode gets the two new functions, as we need to late expand it. To skip the walk over the IR if no lateExpand is needed, we use Matcher::require_late_expand set in the ad file. This ends up in ad_.cpp, thus can not be evaluated by the C++ compiler. If you agree, I would use a "const bool EnableLateExpand" in globalDefinitions_.hpp. (There is no suitable c2__.hpp file). We allready mailed a webrev with this change after last year's JavaOne, but there was no discussion on it. Again, this change is 'L', but the code is not used on other platforms than PPC64 (so far). So the impact on those platforms should be minimal. Please review and test this change. Thanks and best regards, Goetz. From coleen.phillimore at oracle.com Tue Nov 12 12:48:53 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Nov 2013 15:48:53 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> Message-ID: <52829435.9070205@oracle.com> Karen, I think I finally understand these changes and they look good. Thanks for the explanations. Coleen On 10/31/2013 01:53 PM, Karen Kinnear wrote: > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util, java.lang, jdk.lambda > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. nashorn > 7. invoke tests > 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 9. intfbug > 10. defmeth with -Xshare:on (for 0 length method array) > > thanks, > Karen > > matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html > From harold.seigel at oracle.com Tue Nov 12 12:49:23 2013 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 12 Nov 2013 15:49:23 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> Message-ID: <52829453.2010203@oracle.com> Hi Karen, Your changes look good. Thanks! Harold On 10/31/2013 1:53 PM, Karen Kinnear wrote: > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util, java.lang, jdk.lambda > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. nashorn > 7. invoke tests > 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 9. intfbug > 10. defmeth with -Xshare:on (for 0 length method array) > > thanks, > Karen > > matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html > From vladimir.kozlov at oracle.com Tue Nov 12 12:53:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Nov 2013 12:53:28 -0800 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> Message-ID: <52829548.6060604@oracle.com> Hi Goetz, It is good feature. Can you name it postaloc_expand to be clear when we do it? Names. I know it is picking but for methods and .ad statements names we use low case and underscore. Camel style is used for class names. I know this was written long time ago but we are trying now to not use separate enc_class unless it is used by several instructions. Can you also implement ability to write postaloc_expand inside mach instruction (As we do now for ins_encode)? You can do it as separate changes later if it a lot of work. instruct divI_reg_reg_Ex(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ match(Set dst (DivI src1 src2)); predicate(UseNewCode); ins_cost((2+71)*DEFAULT_COST); format %{ "SRA $src2,0,$src2\n\t" "SRA $src1,0,$src1\n\t" "SDIVX $src1,$src2,$dst" %} postaloc_expand %{ MachNode *m1 = new (C) divI_reg_reg_SRANode(); MachNode *m2 = new (C) divI_reg_reg_SRANode(); MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); ... %} %} Are you allow branches in late expand? I assume not because you don't have separate graph's blocks for that. It would be nice to have some verification code which enforces restrictions. Also it would be nice if in lateExpand rule you need only define nodes and connect them and the rest (opnds clonning, RA info patching and pushing result nodes) be done by adlc. But it will require more code in adlc so it may be for the future. I am worried that current code requires very careful coding: which operand to clone and to which assign it, which RA methods to use for resetting (set1(), set2(), set_pair()). It is very bugs prone. adlparse.cpp: // No pipe required for expands. + // No pipe required for late expand. + if (instr->expands() || instr->lateExpands()) { Will it be difficult to totally separate lateExpands from ins_encode? Your current code use _insencode + _is_lateExpand. Can you do one InsEncode* _lateExpand? Or it will be too intrusive? block.cpp: Node_List already has method contains(Node* n), use it in Block::contains() (you can define it in header file then). PhaseCFG::LateExpand(): TraceLateExpand is develop flag so it will be true only for #ifdef ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT in this method. "These kills are not required any more after expanding" - what about flags kill Proj nodes? Disconnecting input nodes worries me. Do you clean graph after that to remove unused nodes? I need to look more on LateExpand() in next round. compile.cpp: Can you add TracePhase/TraceTime to get time spent in LateExpand. Why you need lateExpand() method in Node class? Generated mach nodes are based on MachNode so this method could be declared only in MachNode. (Putting new virtual method into top Node class will increase virtual tables for all ideal and mach nodes). Thanks, Vladimir On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: > Hi, > > I also updated this webrev to work with the latest staging repository. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Mittwoch, 2. Oktober 2013 15:49 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' > Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Hi, > > we extended C2 by what we call lateExpand. LateExpand expands nodes > after register allocation. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Some nodes can not be expanded during matching. E.g., register > allocation might not be able to deal with the resulting pattern. To > allow better scheduling in such cases, we introduce lateExpand which > runs after register allocation. Whether and how nodes are expanded is > specified in the ad-file. See block.cpp for a detailed > documentation. We use this for some nodes on ppc, and extensively on > ia64. > For an example, see the webrev. > > We added some utility functions in node.hpp and block.hpp used by > PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, > MachConstantBaseNode gets the two new functions, as we need to > late expand it. > > To skip the walk over the IR if no lateExpand is needed, we use > Matcher::require_late_expand set in the ad file. This ends up in > ad_.cpp, thus can not be evaluated by the C++ compiler. If you > agree, I would use a "const bool EnableLateExpand" in > globalDefinitions_.hpp. (There is no suitable c2__.hpp > file). > > We allready mailed a webrev with this change after last year's > JavaOne, but there was no discussion on it. > Again, this change is 'L', but the code is not used on other > platforms than PPC64 (so far). So the impact on those platforms > should be minimal. > > Please review and test this change. > > Thanks and best regards, > Goetz. > From lois.foltan at oracle.com Tue Nov 12 13:52:02 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 12 Nov 2013 16:52:02 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> Message-ID: <5282A302.3070304@oracle.com> Hi Karen, Thank you for your many explanations concerning my questions about this code change. I have reviewed and it looks good! Lois On 10/31/2013 1:53 PM, Karen Kinnear wrote: > Please review: > > webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util, java.lang, jdk.lambda > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. nashorn > 7. invoke tests > 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 9. intfbug > 10. defmeth with -Xshare:on (for 0 length method array) > > thanks, > Karen > > matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html > From john.r.rose at oracle.com Tue Nov 12 14:17:15 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Nov 2013 14:17:15 -0800 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> Message-ID: <326B746E-54FD-4984-9D7F-A130BA6E1D08@oracle.com> Reviewed. This is an improvement. Good comments and trace output, and the logic is cleaner. ? Joh P.S. There's a stray newline in this change: + // the search could find a miranda or a default method + if (is_miranda(m, ik()->methods(), ik()->default_methods(), ik()->super())) +{ + return true; + } ...and also a stray space here before the arrow: + if (original_methods ->length() > 0) { + MetadataFactory::free_array(cld, original_methods); + } On Oct 31, 2013, at 10:53 AM, Karen Kinnear wrote: > webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. From vitalyd at gmail.com Tue Nov 12 17:30:43 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 12 Nov 2013 20:30:43 -0500 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, Just curious - why an enum for both versions (load, store) and not a simple bool? You expecting more values? You wouldn't need those asserts in the accessors if this was a bool. Also what does "Sem" stand for? Semantic? Seems like an odd abbreviation. Thanks Sent from my phone On Nov 12, 2013 11:31 AM, "Lindenmaier, Goetz" wrote: > Hi, > > I updated this webrev to work with the latest version of the staging > repository. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > Best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Freitag, 11. Oktober 2013 15:34 > To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir > Kozlov > Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to > know about memory ordering. > > Hi, > > I prepared a webrev for 8024921< > https://bugs.openjdk.java.net/browse/JDK-8024921>Extend Load and Store > nodes to know about memory ordering. > This is part of the PPC port. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > For a detailed description see the text in the webrev and bug description. > > All this basically does is add a field to load and store nodes and > change all constructor calls to set this field. So the effect on > existing platforms should be very small. Therefore I marked this > 'M', although quite some lines of code are touched. > > Please review and test this change. > I'm happy to incorporate your comments and any improvements > you propose. > > Best regards, > Goetz. > > > > > From karen.kinnear at oracle.com Tue Nov 12 18:34:44 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Nov 2013 21:34:44 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <326B746E-54FD-4984-9D7F-A130BA6E1D08@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> <326B746E-54FD-4984-9D7F-A130BA6E1D08@oracle.com> Message-ID: Many thanks. Applied both fixes. thanks, Karen On Nov 12, 2013, at 5:17 PM, John Rose wrote: > Reviewed. This is an improvement. Good comments and trace output, and the logic is cleaner. ? Joh > > P.S. There's a stray newline in this change: > + // the search could find a miranda or a default method > + if (is_miranda(m, ik()->methods(), ik()->default_methods(), ik()->super())) > +{ > + return true; > + } > > ...and also a stray space here before the arrow: > + if (original_methods ->length() > 0) { > + MetadataFactory::free_array(cld, original_methods); > + } > > > On Oct 31, 2013, at 10:53 AM, Karen Kinnear wrote: > >> webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. > From vladimir.kozlov at oracle.com Tue Nov 12 18:57:33 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Nov 2013 18:57:33 -0800 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> Message-ID: <5282EA9D.8060609@oracle.com> Goetz, Too much changes due to explicit params which are not used on our platforms. Can you leave current make_load()/store_to_memory() for unordered case and add new make_load_ordered() and store_to_memory_ordered() for which you pass all parameters (and they call make_load()/store_to_memory()) ? Can you explain why?: "Maintaining this change has shown very error prone if the defaults for the new field are ::unordered." Did you tried what I suggested above? Changes to memory nodes (and LoadNode::make()/ StoreNode::make()) are fine since we need to record ordering case and there is no other way. And it is less cases than make_load()/store_to_memory(). Regarding David's concern about memory barriers I think changes are fine because MemBar are preserved in IR graph. Some of them are different kind but it is fine for C2 - it just needs some barriers to preserve order of loads and stores. As Vitaly I also don't know what is 'Sem'. Please, translate :) Thanks, Vladimir On 11/12/13 8:30 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated this webrev to work with the latest version of the staging repository. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > Best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Freitag, 11. Oktober 2013 15:34 > To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov > Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. > > Hi, > > I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. > This is part of the PPC port. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > For a detailed description see the text in the webrev and bug description. > > All this basically does is add a field to load and store nodes and > change all constructor calls to set this field. So the effect on > existing platforms should be very small. Therefore I marked this > 'M', although quite some lines of code are touched. > > Please review and test this change. > I'm happy to incorporate your comments and any improvements > you propose. > > Best regards, > Goetz. > > > > From karen.kinnear at oracle.com Tue Nov 12 19:06:23 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Nov 2013 22:06:23 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <52829435.9070205@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> <52829435.9070205@oracle.com> Message-ID: <9E4DA31F-62AB-4902-9803-0BDE353805D1@oracle.com> Coleen, Thank you for the code review. Many thanks for all the great questions. thanks, Karen On Nov 12, 2013, at 3:48 PM, Coleen Phillimore wrote: > > Karen, I think I finally understand these changes and they look good. > Thanks for the explanations. > Coleen > > On 10/31/2013 01:53 PM, Karen Kinnear wrote: >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util, java.lang, jdk.lambda >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. nashorn >> 7. invoke tests >> 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 9. intfbug >> 10. defmeth with -Xshare:on (for 0 length method array) >> >> thanks, >> Karen >> >> matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html >> > From karen.kinnear at oracle.com Tue Nov 12 19:06:50 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Nov 2013 22:06:50 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <52829453.2010203@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> <52829453.2010203@oracle.com> Message-ID: Harold, Thank you for the code review and great suggestions for next steps in bugfixland. thanks, Karen On Nov 12, 2013, at 3:49 PM, harold seigel wrote: > Hi Karen, > > Your changes look good. > > Thanks! Harold > > On 10/31/2013 1:53 PM, Karen Kinnear wrote: >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util, java.lang, jdk.lambda >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. nashorn >> 7. invoke tests >> 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 9. intfbug >> 10. defmeth with -Xshare:on (for 0 length method array) >> >> thanks, >> Karen >> >> matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html >> > From karen.kinnear at oracle.com Tue Nov 12 19:07:08 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Nov 2013 22:07:08 -0500 Subject: RFR: 8027229: Lambda: ICCE for 2 or more maximally specific methods for interfaces In-Reply-To: <5282A302.3070304@oracle.com> References: <196F72A7-D411-46E8-8C52-D3554730D7E1@oracle.com> <5282A302.3070304@oracle.com> Message-ID: Lois, I really appreciate your code review and thoughtful questions. thanks, Karen On Nov 12, 2013, at 4:52 PM, Lois Foltan wrote: > Hi Karen, > > Thank you for your many explanations concerning my questions about this code change. I have reviewed and it looks good! > > Lois > > On 10/31/2013 1:53 PM, Karen Kinnear wrote: >> Please review: >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util, java.lang, jdk.lambda >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. nashorn >> 7. invoke tests >> 8. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 9. intfbug >> 10. defmeth with -Xshare:on (for 0 length method array) >> >> thanks, >> Karen >> >> matches JVMS: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html >> > From karen.kinnear at oracle.com Tue Nov 12 19:27:46 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Nov 2013 22:27:46 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <5282B005.8040202@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> Message-ID: <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> Bharadwaj et al, One more very short round of code reviews please folks. Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are still valid. I did add the fix for this to the updated webrev below. The only changes relative to the initial webrev are: 1. klassVtable.cpp - I removed the extra before the { 2. defaultMethods.cpp - added the suggested comments, and removed extra space - code fix in lines: 403, 408, 411 All small tests have passed, and the longer ones are in progress. Goal is to check this in tomorrow please. thanks, Karen webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ bug: http://bugs.openjdk.java.net/browse/JDK-8027229 Added support for default method inheritance logic for interfaces. Removed interface methods from interface vtables. Better cleanup of 8027304 as well. specific tests: 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest including: testSuperConflict (fixed to match specification) 2. vmtestbase defmeth including: SuperCallTest:testSuperConflict (fixed to match specification) 3. jtreg java.util.streams 4. jck lang, vm 5. nsk vm.quick, vm.mlvm 6. invoke tests 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 8. Bharadwaj's new test example On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: > Hi Karen, > > I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows > > interface L { > > //default int m() { return 101; } > abstract public int m(); > } > > and ran sh run.sh to get > > Exception in thread "main" java.lang.AbstractMethodError: J.m()I > at I.m(I.java:3) > at IV_C.m(IV_C.java:3) > at IV_C.main(IV_C.java:6) > > Just to verify, here is the info about L.class > > $ javap cpath/L.class > Compiled from "L.java" > interface L { > public abstract int m(); > } > > I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. > > Apologies if this (rightly or wrongly) delays your checkin. > > Bharadwaj > From john.r.rose at oracle.com Tue Nov 12 22:10:52 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Nov 2013 22:10:52 -0800 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> Message-ID: <132548F1-8B9A-45E4-B367-D0707BD851D6@oracle.com> Re-reviewed. But I didn't catch the bug on first review... ? John On Nov 12, 2013, at 7:27 PM, Karen Kinnear wrote: > Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are > still valid. > > I did add the fix for this to the updated webrev below. > The only changes relative to the initial webrev are: > 1. klassVtable.cpp - I removed the extra before the { > > 2. defaultMethods.cpp > - added the suggested comments, and removed extra space > - code fix in lines: 403, 408, 411 From john.coomes at oracle.com Tue Nov 12 22:16:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 13 Nov 2013 06:16:34 +0000 Subject: hg: hsx/jdk7u/corba: 8021257: com.sun.corba.se.** should be on restricted package list Message-ID: <20131113061636.D03E962561@hg.openjdk.java.net> Changeset: f15d0e49b1d8 Author: alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/f15d0e49b1d8 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java From john.coomes at oracle.com Tue Nov 12 22:16:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 13 Nov 2013 06:16:46 +0000 Subject: hg: hsx/jdk7u/jaxp: 6 new changesets Message-ID: <20131113061657.9911362562@hg.openjdk.java.net> Changeset: 5ea5b94af7d7 Author: joehw Date: 2013-10-14 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/5ea5b94af7d7 8003262: reverse translation required changes in xalan resource bundles Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java Changeset: fa4bc4681f57 Author: joehw Date: 2013-10-15 12:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/fa4bc4681f57 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb ! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java Changeset: 0115f26bcecd Author: aefimov Date: 2013-10-15 14:48 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0115f26bcecd 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Reviewed-by: alanb, shade ! src/com/sun/org/apache/xpath/internal/XPathContext.java Changeset: e200ce7cc24b Author: joehw Date: 2013-10-17 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/e200ce7cc24b 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/util/URI.java Changeset: c0727f8c3ea8 Author: joehw Date: 2013-10-19 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/c0727f8c3ea8 8016500: Unlocalized warnings. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: 036cf3985427 Author: lana Date: 2013-10-21 14:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/036cf3985427 Merge ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java From john.coomes at oracle.com Tue Nov 12 22:17:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 13 Nov 2013 06:17:55 +0000 Subject: hg: hsx/jdk7u/jdk: 19 new changesets Message-ID: <20131113062209.0842362563@hg.openjdk.java.net> Changeset: 3f9d91c59d8c Author: igerasim Date: 2013-10-10 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3f9d91c59d8c 7147084: (process) appA hangs when read output stream of appB which starts appC that runs forever Reviewed-by: alanb ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c + test/java/lang/ProcessBuilder/InheritIOEHandle.java + test/java/lang/ProcessBuilder/SiblingIOEHandle.java Changeset: 7d28d2947ce4 Author: kshefov Date: 2013-10-11 18:35 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7d28d2947ce4 7124338: [macosx] Selection lost if a selected item removed from a java.awt.List Reviewed-by: serb, anthony + test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html + test/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java Changeset: baf197bacdba Author: sjiang Date: 2013-10-14 09:43 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/baf197bacdba 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/monitor/NullAttributeValueTest.java Changeset: ba069f9e8b50 Author: sjiang Date: 2013-10-10 09:01 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ba069f9e8b50 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java Changeset: a75689a260dd Author: sjiang Date: 2013-10-10 08:37 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a75689a260dd 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Reviewed-by: dfuchs, dholmes ! test/javax/management/monitor/CounterMonitorThresholdTest.java Changeset: 8667b1db10e0 Author: sjiang Date: 2013-10-10 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8667b1db10e0 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Reviewed-by: dholmes, jbachorik ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java Changeset: cfd96c6d47c6 Author: joehw Date: 2013-10-15 12:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cfd96c6d47c6 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb + test/javax/xml/jaxp/validation/8015092/XPathWhiteSpaceTest.java + test/javax/xml/jaxp/validation/8015092/idIxpns.xsd + test/javax/xml/jaxp/validation/8015092/idIxpns1.xsd + test/javax/xml/jaxp/validation/8015092/idJ029.xsd + test/javax/xml/jaxp/validation/8015092/idJimp.xsd Changeset: 6126a0662727 Author: coffeys Date: 2013-10-16 05:49 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6126a0662727 8012326: Deadlock occurs when Charset.availableCharsets() is called by several threads at the same time Summary: removed the race condition risk from ExtendedCharset access code Reviewed-by: sherman ! make/sun/nio/cs/Makefile ! src/share/classes/java/nio/charset/Charset.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider Changeset: c421ade4c566 Author: jchen Date: 2013-10-16 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c421ade4c566 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test Reviewed-by: prr, vadim, serb ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c Changeset: e0e3b791ec9d Author: joehw Date: 2013-10-17 17:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e0e3b791ec9d 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea + test/javax/xml/jaxp/validation/8015243/AnyURITest.java + test/javax/xml/jaxp/validation/8015243/anyURI_b006.xsd Changeset: 621fc6e8c7e8 Author: igerasim Date: 2013-10-19 02:13 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/621fc6e8c7e8 8023130: (process) ProcessBuilder#inheritIO does not work on Windows Reviewed-by: alanb, martin ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh Changeset: ffe251aaae42 Author: lana Date: 2013-10-21 14:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ffe251aaae42 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/windows/classes/java/lang/ProcessImpl.java Changeset: c5fbbced812e Author: igerasim Date: 2013-10-24 22:03 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c5fbbced812e 8022584: Memory leak in some NetworkInterface methods Reviewed-by: alanb, dholmes, chegar, michaelm ! src/solaris/native/java/net/NetworkInterface.c Changeset: 694ad155b344 Author: alanb Date: 2013-10-24 19:21 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/694ad155b344 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oracle.com, mark.sheppard at oracle.com ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 01f4ed4d889b Author: coffeys Date: 2013-10-25 18:51 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/01f4ed4d889b Merge Changeset: 0ce67c8129f9 Author: alitvinov Date: 2013-10-29 13:23 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0ce67c8129f9 8027066: XMLDecoder in java 7 cannot properly deserialize object arrays Reviewed-by: alexsch, malenkov Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + test/java/beans/XMLEncoder/Test8027066.java Changeset: fd7850833158 Author: igerasim Date: 2013-10-28 20:26 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/fd7850833158 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions Reviewed-by: alanb, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 3d28326a9e5d Author: aefimov Date: 2013-10-24 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3d28326a9e5d 8025255: (tz) Support tzdata2013g 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! test/ProblemList.txt ! test/sun/util/resources/TimeZone/Bug6317929.java Changeset: b10113081c39 Author: peytoia Date: 2013-10-30 17:25 +0900 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b10113081c39 8027426: String.toLowerCase incorrectly increases length, if string contains \u0130 char Reviewed-by: okutsu ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/String.java ! test/java/lang/String/ToLowerCase.java From john.coomes at oracle.com Tue Nov 12 22:16:28 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 13 Nov 2013 06:16:28 +0000 Subject: hg: hsx/jdk7u: 2 new changesets Message-ID: <20131113061629.2E7906255F@hg.openjdk.java.net> Changeset: 104c02d9c423 Author: thurka Date: 2013-10-07 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/104c02d9c423 8025920: webrev.ksh does not provide any details about changes in zip files Summary: Add support for diffs for zip files Reviewed-by: ksrini, chegar ! make/scripts/webrev.ksh Changeset: 88113cabda38 Author: lana Date: 2013-10-21 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/88113cabda38 Merge From staffan.larsen at oracle.com Wed Nov 13 02:23:43 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Nov 2013 11:23:43 +0100 Subject: RFR (S): 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary In-Reply-To: <527BB658.4000208@oracle.com> References: <527B9F28.3060303@oracle.com> <527BB658.4000208@oracle.com> Message-ID: Assuming that you have verified the changes by running relevant tests this looks good. Reviewed. Thanks, /Staffan On 07 Nov 2013, at 16:48, Yekaterina Kantserova wrote: > Adding hotspot-dev group. > > -------- Original Message -------- > Subject: RFR (S): 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary > Date: Thu, 07 Nov 2013 15:09:44 +0100 > From: Yekaterina Kantserova > To: Serviceability Dev > > > > Hi, > > Could I please have a review of this fix. > > The following has been done: > - updated OutputAnalyzer and ProcessTool with changes from hotspot/testlibrary; > - added test classes AssertsTest and OutputAnalyzerReportingTest from hotspot/testlibrary; > - added InputArguments class from hotspot/testlibrary (provides access to the input arguments to the VM); > - removed JdkFinder (it's replaced with JDKToolLauncher); > - re-wrote JcmdBase to use JDKToolLauncher instead of JdkFinder. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8015497 > > Webrev: > http://cr.openjdk.java.net/~ykantser/8015497/webrev.00/ > > Thanks, > Katja > From yekaterina.kantserova at oracle.com Wed Nov 13 02:34:51 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 13 Nov 2013 11:34:51 +0100 Subject: RFR (S): 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary In-Reply-To: References: <527B9F28.3060303@oracle.com> <527BB658.4000208@oracle.com> Message-ID: <528355CB.4060604@oracle.com> On 11/13/2013 11:23 AM, Staffan Larsen wrote: > Assuming that you have verified the changes by running relevant tests this looks good. Yes, I did. Thanks! > > Reviewed. > > Thanks, > /Staffan > > On 07 Nov 2013, at 16:48, Yekaterina Kantserova wrote: > >> Adding hotspot-dev group. >> >> -------- Original Message -------- >> Subject: RFR (S): 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary >> Date: Thu, 07 Nov 2013 15:09:44 +0100 >> From: Yekaterina Kantserova >> To: Serviceability Dev >> >> >> >> Hi, >> >> Could I please have a review of this fix. >> >> The following has been done: >> - updated OutputAnalyzer and ProcessTool with changes from hotspot/testlibrary; >> - added test classes AssertsTest and OutputAnalyzerReportingTest from hotspot/testlibrary; >> - added InputArguments class from hotspot/testlibrary (provides access to the input arguments to the VM); >> - removed JdkFinder (it's replaced with JDKToolLauncher); >> - re-wrote JcmdBase to use JDKToolLauncher instead of JdkFinder. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8015497 >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8015497/webrev.00/ >> >> Thanks, >> Katja >> From harold.seigel at oracle.com Wed Nov 13 04:50:10 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 13 Nov 2013 07:50:10 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> Message-ID: <52837582.2040403@oracle.com> Hi Karen, Your new change looks good. Harold On 11/12/2013 10:27 PM, Karen Kinnear wrote: > Bharadwaj et al, > > One more very short round of code reviews please folks. > > Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are > still valid. > > I did add the fix for this to the updated webrev below. > The only changes relative to the initial webrev are: > 1. klassVtable.cpp - I removed the extra before the { > > 2. defaultMethods.cpp > - added the suggested comments, and removed extra space > - code fix in lines: 403, 408, 411 > > All small tests have passed, and the longer ones are in progress. > Goal is to check this in tomorrow please. > > thanks, > Karen > > webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util.streams > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. invoke tests > 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 8. Bharadwaj's new test example > > > On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: > >> Hi Karen, >> >> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >> >> interface L { >> >> //default int m() { return 101; } >> abstract public int m(); >> } >> >> and ran sh run.sh to get >> >> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >> at I.m(I.java:3) >> at IV_C.m(IV_C.java:3) >> at IV_C.main(IV_C.java:6) >> >> Just to verify, here is the info about L.class >> >> $ javap cpath/L.class >> Compiled from "L.java" >> interface L { >> public abstract int m(); >> } >> >> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >> >> Apologies if this (rightly or wrongly) delays your checkin. >> >> Bharadwaj >> From karen.kinnear at oracle.com Wed Nov 13 05:06:50 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 13 Nov 2013 08:06:50 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <52837582.2040403@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> <52837582.2040403@oracle.com> Message-ID: Many thanks Harold. thanks, Karen On Nov 13, 2013, at 7:50 AM, harold seigel wrote: > Hi Karen, > > Your new change looks good. > > Harold > > On 11/12/2013 10:27 PM, Karen Kinnear wrote: >> Bharadwaj et al, >> >> One more very short round of code reviews please folks. >> >> Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are >> still valid. >> >> I did add the fix for this to the updated webrev below. >> The only changes relative to the initial webrev are: >> 1. klassVtable.cpp - I removed the extra before the { >> >> 2. defaultMethods.cpp >> - added the suggested comments, and removed extra space >> - code fix in lines: 403, 408, 411 >> >> All small tests have passed, and the longer ones are in progress. >> Goal is to check this in tomorrow please. >> >> thanks, >> Karen >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util.streams >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. invoke tests >> 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 8. Bharadwaj's new test example >> >> >> On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: >> >>> Hi Karen, >>> >>> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >>> >>> interface L { >>> >>> //default int m() { return 101; } >>> abstract public int m(); >>> } >>> >>> and ran sh run.sh to get >>> >>> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >>> at I.m(I.java:3) >>> at IV_C.m(IV_C.java:3) >>> at IV_C.main(IV_C.java:6) >>> >>> Just to verify, here is the info about L.class >>> >>> $ javap cpath/L.class >>> Compiled from "L.java" >>> interface L { >>> public abstract int m(); >>> } >>> >>> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >>> >>> Apologies if this (rightly or wrongly) delays your checkin. >>> >>> Bharadwaj >>> > From lois.foltan at oracle.com Wed Nov 13 05:11:45 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 13 Nov 2013 08:11:45 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> Message-ID: <52837A91.10809@oracle.com> Hi Karen, Changes look good. Lois On 11/12/2013 10:27 PM, Karen Kinnear wrote: > Bharadwaj et al, > > One more very short round of code reviews please folks. > > Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are > still valid. > > I did add the fix for this to the updated webrev below. > The only changes relative to the initial webrev are: > 1. klassVtable.cpp - I removed the extra before the { > > 2. defaultMethods.cpp > - added the suggested comments, and removed extra space > - code fix in lines: 403, 408, 411 > > All small tests have passed, and the longer ones are in progress. > Goal is to check this in tomorrow please. > > thanks, > Karen > > webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util.streams > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. invoke tests > 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 8. Bharadwaj's new test example > > > On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: > >> Hi Karen, >> >> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >> >> interface L { >> >> //default int m() { return 101; } >> abstract public int m(); >> } >> >> and ran sh run.sh to get >> >> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >> at I.m(I.java:3) >> at IV_C.m(IV_C.java:3) >> at IV_C.main(IV_C.java:6) >> >> Just to verify, here is the info about L.class >> >> $ javap cpath/L.class >> Compiled from "L.java" >> interface L { >> public abstract int m(); >> } >> >> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >> >> Apologies if this (rightly or wrongly) delays your checkin. >> >> Bharadwaj >> From goetz.lindenmaier at sap.com Wed Nov 13 05:20:56 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Nov 2013 13:20:56 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <52829548.6060604@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE648F9@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for the review! I'm already working on your comments, more some later in a comprehensive mail. For now: would postalloc_expand be fine, too (two ls)? Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 12. November 2013 21:53 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. Hi Goetz, It is good feature. Can you name it postaloc_expand to be clear when we do it? Names. I know it is picking but for methods and .ad statements names we use low case and underscore. Camel style is used for class names. I know this was written long time ago but we are trying now to not use separate enc_class unless it is used by several instructions. Can you also implement ability to write postaloc_expand inside mach instruction (As we do now for ins_encode)? You can do it as separate changes later if it a lot of work. instruct divI_reg_reg_Ex(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ match(Set dst (DivI src1 src2)); predicate(UseNewCode); ins_cost((2+71)*DEFAULT_COST); format %{ "SRA $src2,0,$src2\n\t" "SRA $src1,0,$src1\n\t" "SDIVX $src1,$src2,$dst" %} postaloc_expand %{ MachNode *m1 = new (C) divI_reg_reg_SRANode(); MachNode *m2 = new (C) divI_reg_reg_SRANode(); MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); ... %} %} Are you allow branches in late expand? I assume not because you don't have separate graph's blocks for that. It would be nice to have some verification code which enforces restrictions. Also it would be nice if in lateExpand rule you need only define nodes and connect them and the rest (opnds clonning, RA info patching and pushing result nodes) be done by adlc. But it will require more code in adlc so it may be for the future. I am worried that current code requires very careful coding: which operand to clone and to which assign it, which RA methods to use for resetting (set1(), set2(), set_pair()). It is very bugs prone. adlparse.cpp: // No pipe required for expands. + // No pipe required for late expand. + if (instr->expands() || instr->lateExpands()) { Will it be difficult to totally separate lateExpands from ins_encode? Your current code use _insencode + _is_lateExpand. Can you do one InsEncode* _lateExpand? Or it will be too intrusive? block.cpp: Node_List already has method contains(Node* n), use it in Block::contains() (you can define it in header file then). PhaseCFG::LateExpand(): TraceLateExpand is develop flag so it will be true only for #ifdef ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT in this method. "These kills are not required any more after expanding" - what about flags kill Proj nodes? Disconnecting input nodes worries me. Do you clean graph after that to remove unused nodes? I need to look more on LateExpand() in next round. compile.cpp: Can you add TracePhase/TraceTime to get time spent in LateExpand. Why you need lateExpand() method in Node class? Generated mach nodes are based on MachNode so this method could be declared only in MachNode. (Putting new virtual method into top Node class will increase virtual tables for all ideal and mach nodes). Thanks, Vladimir On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: > Hi, > > I also updated this webrev to work with the latest staging repository. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Mittwoch, 2. Oktober 2013 15:49 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' > Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Hi, > > we extended C2 by what we call lateExpand. LateExpand expands nodes > after register allocation. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Some nodes can not be expanded during matching. E.g., register > allocation might not be able to deal with the resulting pattern. To > allow better scheduling in such cases, we introduce lateExpand which > runs after register allocation. Whether and how nodes are expanded is > specified in the ad-file. See block.cpp for a detailed > documentation. We use this for some nodes on ppc, and extensively on > ia64. > For an example, see the webrev. > > We added some utility functions in node.hpp and block.hpp used by > PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, > MachConstantBaseNode gets the two new functions, as we need to > late expand it. > > To skip the walk over the IR if no lateExpand is needed, we use > Matcher::require_late_expand set in the ad file. This ends up in > ad_.cpp, thus can not be evaluated by the C++ compiler. If you > agree, I would use a "const bool EnableLateExpand" in > globalDefinitions_.hpp. (There is no suitable c2__.hpp > file). > > We allready mailed a webrev with this change after last year's > JavaOne, but there was no discussion on it. > Again, this change is 'L', but the code is not used on other > platforms than PPC64 (so far). So the impact on those platforms > should be minimal. > > Please review and test this change. > > Thanks and best regards, > Goetz. > From karen.kinnear at oracle.com Wed Nov 13 06:06:28 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 13 Nov 2013 09:06:28 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <52837A91.10809@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> <52837A91.10809@oracle.com> Message-ID: Thank you very much Lois. Karen On Nov 13, 2013, at 8:11 AM, Lois Foltan wrote: > Hi Karen, > > Changes look good. > > Lois > > On 11/12/2013 10:27 PM, Karen Kinnear wrote: >> Bharadwaj et al, >> >> One more very short round of code reviews please folks. >> >> Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are >> still valid. >> >> I did add the fix for this to the updated webrev below. >> The only changes relative to the initial webrev are: >> 1. klassVtable.cpp - I removed the extra before the { >> >> 2. defaultMethods.cpp >> - added the suggested comments, and removed extra space >> - code fix in lines: 403, 408, 411 >> >> All small tests have passed, and the longer ones are in progress. >> Goal is to check this in tomorrow please. >> >> thanks, >> Karen >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util.streams >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. invoke tests >> 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 8. Bharadwaj's new test example >> >> >> On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: >> >>> Hi Karen, >>> >>> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >>> >>> interface L { >>> >>> //default int m() { return 101; } >>> abstract public int m(); >>> } >>> >>> and ran sh run.sh to get >>> >>> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >>> at I.m(I.java:3) >>> at IV_C.m(IV_C.java:3) >>> at IV_C.main(IV_C.java:6) >>> >>> Just to verify, here is the info about L.class >>> >>> $ javap cpath/L.class >>> Compiled from "L.java" >>> interface L { >>> public abstract int m(); >>> } >>> >>> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >>> >>> Apologies if this (rightly or wrongly) delays your checkin. >>> >>> Bharadwaj >>> > From coleen.phillimore at oracle.com Wed Nov 13 06:34:24 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Nov 2013 09:34:24 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> Message-ID: <52838DF0.1040108@oracle.com> Yes, this looks good, Karen. Coleen On 11/12/2013 10:27 PM, Karen Kinnear wrote: > Bharadwaj et al, > > One more very short round of code reviews please folks. > > Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are > still valid. > > I did add the fix for this to the updated webrev below. > The only changes relative to the initial webrev are: > 1. klassVtable.cpp - I removed the extra before the { > > 2. defaultMethods.cpp > - added the suggested comments, and removed extra space > - code fix in lines: 403, 408, 411 > > All small tests have passed, and the longer ones are in progress. > Goal is to check this in tomorrow please. > > thanks, > Karen > > webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match specification) > 3. jtreg java.util.streams > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. invoke tests > 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 8. Bharadwaj's new test example > > > On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: > >> Hi Karen, >> >> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >> >> interface L { >> >> //default int m() { return 101; } >> abstract public int m(); >> } >> >> and ran sh run.sh to get >> >> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >> at I.m(I.java:3) >> at IV_C.m(IV_C.java:3) >> at IV_C.main(IV_C.java:6) >> >> Just to verify, here is the info about L.class >> >> $ javap cpath/L.class >> Compiled from "L.java" >> interface L { >> public abstract int m(); >> } >> >> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >> >> Apologies if this (rightly or wrongly) delays your checkin. >> >> Bharadwaj >> From karen.kinnear at oracle.com Wed Nov 13 06:42:37 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 13 Nov 2013 09:42:37 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <52838DF0.1040108@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> <52838DF0.1040108@oracle.com> Message-ID: Thank you very much Coleen. thanks, Karen On Nov 13, 2013, at 9:34 AM, Coleen Phillimore wrote: > > Yes, this looks good, Karen. > > Coleen > > On 11/12/2013 10:27 PM, Karen Kinnear wrote: >> Bharadwaj et al, >> >> One more very short round of code reviews please folks. >> >> Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are >> still valid. >> >> I did add the fix for this to the updated webrev below. >> The only changes relative to the initial webrev are: >> 1. klassVtable.cpp - I removed the extra before the { >> >> 2. defaultMethods.cpp >> - added the suggested comments, and removed extra space >> - code fix in lines: 403, 408, 411 >> >> All small tests have passed, and the longer ones are in progress. >> Goal is to check this in tomorrow please. >> >> thanks, >> Karen >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util.streams >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. invoke tests >> 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 8. Bharadwaj's new test example >> >> >> On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: >> >>> Hi Karen, >>> >>> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >>> >>> interface L { >>> >>> //default int m() { return 101; } >>> abstract public int m(); >>> } >>> >>> and ran sh run.sh to get >>> >>> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >>> at I.m(I.java:3) >>> at IV_C.m(IV_C.java:3) >>> at IV_C.main(IV_C.java:6) >>> >>> Just to verify, here is the info about L.class >>> >>> $ javap cpath/L.class >>> Compiled from "L.java" >>> interface L { >>> public abstract int m(); >>> } >>> >>> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >>> >>> Apologies if this (rightly or wrongly) delays your checkin. >>> >>> Bharadwaj >>> > From roland.westrelin at oracle.com Wed Nov 13 06:48:48 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Nov 2013 15:48:48 +0100 Subject: CFV: New HSX Committer: Albert Noll Message-ID: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. Votes are due by Nov. 27, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Roland Westrelin. [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From vladimir.x.ivanov at oracle.com Wed Nov 13 07:03:26 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Nov 2013 19:03:26 +0400 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <528394BE.1020609@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 11/13/13 6:48 PM, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 > From bharadwaj.yadavalli at oracle.com Wed Nov 13 07:32:42 2013 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Wed, 13 Nov 2013 10:32:42 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> Message-ID: <52839B9A.9040009@oracle.com> Thanks for considering the test case and addressing it, Karen. Changes look good to me. You may want to consider removing the additional space between original_methods and -> in the hunk of defaultMethods.cpp patch. @@ -1074,11 +1081,13 @@ // Replace klass methods with new merged lists klass->set_methods(merged_methods); klass->set_initial_method_idnum(new_size); ClassLoaderData* cld = klass->class_loader_data(); + if (original_methods ->length() > 0) { MetadataFactory::free_array(cld, original_methods); + } Sorry to be picky :-) Thanks, Bharadwaj On 11/12/2013 10:27 PM, Karen Kinnear wrote: > Bharadwaj et al, > > One more very short round of code reviews please folks. > > Thank you for the testcase. I broke this with the fix for 8027304, so > the code reviews for 8027229 are > still valid. > > I did add the fix for this to the updated webrev below. > The only changes relative to the initial webrev are: > 1. klassVtable.cpp - I removed the extra before the { > > 2. defaultMethods.cpp > - added the suggested comments, and removed extra space > - code fix in lines: 403, 408, 411 > > All small tests have passed, and the longer ones are in progress. > Goal is to check this in tomorrow please. > > thanks, > Karen > > webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ > > bug: http://bugs.openjdk.java.net/browse/JDK-8027229 > > Added support for default method inheritance logic for interfaces. > Removed interface methods from interface vtables. > Better cleanup of 8027304 as well. > > specific tests: > 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest > including: testSuperConflict (fixed to match specification) > 2. vmtestbase defmeth > including: SuperCallTest:testSuperConflict (fixed to match > specification) > 3. jtreg java.util.streams > 4. jck lang, vm > 5. nsk vm.quick, vm.mlvm > 6. invoke tests > 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 > 8. Bharadwaj's new test example > > > On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: > >> Hi Karen, >> >> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >> >> interface L { >> >> //default int m() { return 101; } >> abstract public int m(); >> } >> >> and ran sh run.sh to get >> >> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >> at I.m(I.java:3) >> at IV_C.m(IV_C.java:3) >> at IV_C.main(IV_C.java:6) >> >> Just to verify, here is the info about L.class >> >> $ javap cpath/L.class >> Compiled from "L.java" >> interface L { >> public abstract int m(); >> } >> >> I believe the change I made to L.java reflects the case where one of >> the methods is abstract and the other default. >> >> Apologies if this (rightly or wrongly) delays your checkin. >> >> Bharadwaj >> > From karen.kinnear at oracle.com Wed Nov 13 07:36:08 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 13 Nov 2013 10:36:08 -0500 Subject: Please re-review 1 file: Re: 8027229 code review In-Reply-To: <52839B9A.9040009@oracle.com> References: <10A1AAB3-875E-47D1-A42C-67107FC4C2CD@oracle.com> <5281036F.1020801@oracle.com> <5E809433-907C-4ADC-A346-D50DE0591F4A@oracle.com> <5282B005.8040202@oracle.com> <93157D6B-8400-4B8A-8EFD-A1A705D07FEF@oracle.com> <52839B9A.9040009@oracle.com> Message-ID: Bharadwaj, Great suggestion - sorry I just pushed the change, so I will fix the extra space next time I am in there - or one of us will. Thank you for the review and for the test case. thanks, Karen On Nov 13, 2013, at 10:32 AM, S. Bharadwaj Yadavalli wrote: > Thanks for considering the test case and addressing it, Karen. > > Changes look good to me. > > You may want to consider removing the additional space between original_methods and -> in the hunk of defaultMethods.cpp patch. > @@ -1074,11 +1081,13 @@ > // Replace klass methods with new merged lists > klass->set_methods(merged_methods); > klass->set_initial_method_idnum(new_size); > > ClassLoaderData* cld = klass->class_loader_data(); > + if (original_methods ->length() > 0) { > MetadataFactory::free_array(cld, original_methods); > + } > > Sorry to be picky :-) > > Thanks, > > Bharadwaj > > On 11/12/2013 10:27 PM, Karen Kinnear wrote: >> Bharadwaj et al, >> >> One more very short round of code reviews please folks. >> >> Thank you for the testcase. I broke this with the fix for 8027304, so the code reviews for 8027229 are >> still valid. >> >> I did add the fix for this to the updated webrev below. >> The only changes relative to the initial webrev are: >> 1. klassVtable.cpp - I removed the extra before the { >> >> 2. defaultMethods.cpp >> - added the suggested comments, and removed extra space >> - code fix in lines: 403, 408, 411 >> >> All small tests have passed, and the longer ones are in progress. >> Goal is to check this in tomorrow please. >> >> thanks, >> Karen >> >> webrev: http://cr.openjdk.java.net/~acorn/8027229.2/webrev/ >> bug: http://bugs.openjdk.java.net/browse/JDK-8027229 >> >> Added support for default method inheritance logic for interfaces. >> Removed interface methods from interface vtables. >> Better cleanup of 8027304 as well. >> >> specific tests: >> 1. jdk jtreg: FDSeparateCompilation, DefaultMethodsTest >> including: testSuperConflict (fixed to match specification) >> 2. vmtestbase defmeth >> including: SuperCallTest:testSuperConflict (fixed to match specification) >> 3. jtreg java.util.streams >> 4. jck lang, vm >> 5. nsk vm.quick, vm.mlvm >> 6. invoke tests >> 7. jtreg hotspot/test/runtime, hotspot/test/compiler/jsr292 >> 8. Bharadwaj's new test example >> >> >> On Nov 12, 2013, at 5:47 PM, S. Bharadwaj Yadavalli wrote: >> >>> Hi Karen, >>> >>> I changed testSuperConflict_ICCE_or_AME_or_none/L/L.java as follows >>> >>> interface L { >>> >>> //default int m() { return 101; } >>> abstract public int m(); >>> } >>> >>> and ran sh run.sh to get >>> >>> Exception in thread "main" java.lang.AbstractMethodError: J.m()I >>> at I.m(I.java:3) >>> at IV_C.m(IV_C.java:3) >>> at IV_C.main(IV_C.java:6) >>> >>> Just to verify, here is the info about L.class >>> >>> $ javap cpath/L.class >>> Compiled from "L.java" >>> interface L { >>> public abstract int m(); >>> } >>> >>> I believe the change I made to L.java reflects the case where one of the methods is abstract and the other default. >>> >>> Apologies if this (rightly or wrongly) delays your checkin. >>> >>> Bharadwaj >>> >> > From coleen.phillimore at oracle.com Wed Nov 13 08:22:05 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Nov 2013 11:22:05 -0500 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <5283A72D.1070408@oracle.com> Vote: yes On 11/13/2013 9:48 AM, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From goetz.lindenmaier at sap.com Wed Nov 13 08:54:21 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Nov 2013 16:54:21 +0000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE64A2B@DEWDFEMB12A.global.corp.sap> Hi Vitaly, we use an enum so that we have a speaking name for the value. Sure we could use a 'final bool unordered = false' but enum seems the proper way. Propose a better name for Sem, I don't like it too much either! I just used the name in our code (done by one of my former colleagues A few years ago). I will change it if there is a better (and please short) one. Best regards, Goetz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Mittwoch, 13. November 2013 02:31 To: Lindenmaier, Goetz Cc: Vladimir Kozlov; hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Hi Goetz, Just curious - why an enum for both versions (load, store) and not a simple bool? You expecting more values? You wouldn't need those asserts in the accessors if this was a bool. Also what does "Sem" stand for? Semantic? Seems like an odd abbreviation. Thanks Sent from my phone On Nov 12, 2013 11:31 AM, "Lindenmaier, Goetz" > wrote: Hi, I updated this webrev to work with the latest version of the staging repository. http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ Best regards, Goetz. From: goetz.lindenmaier at sap.com Sent: Freitag, 11. Oktober 2013 15:34 To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Hi, I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. This is part of the PPC port. http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ For a detailed description see the text in the webrev and bug description. All this basically does is add a field to load and store nodes and change all constructor calls to set this field. So the effect on existing platforms should be very small. Therefore I marked this 'M', although quite some lines of code are touched. Please review and test this change. I'm happy to incorporate your comments and any improvements you propose. Best regards, Goetz. From john.r.rose at oracle.com Wed Nov 13 09:01:20 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 13 Nov 2013 09:01:20 -0800 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <74C321A6-5D41-44F0-B8CC-CAC4BEA1853D@oracle.com> Vote: yes From coleen.phillimore at oracle.com Wed Nov 13 09:04:31 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Nov 2013 12:04:31 -0500 Subject: RFR 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field,change In-Reply-To: <52805BE2.4040204@oracle.com> References: <52805BE2.4040204@oracle.com> Message-ID: <5283B11F.6000501@oracle.com> I added code to so we don't create duplicate invokespecial/InterfaceMethodref cpCache entries (suggested by John R), renamed _cp_cache_index_limit to _first_iteration_cp_cache_limit which is a bit clearer, and fixed formatting in test. Also added duplicate invokespecial/InterfaceMethodref case to test. Reran jck, java/lang/invoke and defmeth tests. open webrev at http://cr.openjdk.java.net/~coleenp/8025937_2/ Thanks, Coleen On 11/10/2013 11:24 PM, Coleen Phillmore wrote: > Summary: Create extra constant pool cache entries for > invokespecial/InterfaceMethodref to hold the alternate resolution. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025937/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025937 > > Tested with testcase in time api, java/lang/invoke jtreg tests, NSK > mlvm, quick and defmeth tests, jck lang/vm tests, and testcase in > changeset. > > Thanks, > Coleen > > > From serguei.spitsyn at oracle.com Wed Nov 13 09:06:09 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Nov 2013 09:06:09 -0800 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <5283B181.4080702@oracle.com> Vote: yes From vitalyd at gmail.com Wed Nov 13 09:20:07 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 13 Nov 2013 12:20:07 -0500 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE64A2B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64A2B@DEWDFEMB12A.global.corp.sap> Message-ID: Personally, I'd just use bool - you don't have a naming decision then :). You also won't need the asserts in accessor. If you stick with enum, how about MemOrder? Is that too long? You're only going to use that name in a few places so I think clarity trumps super short name. Sent from my phone On Nov 13, 2013 11:54 AM, "Lindenmaier, Goetz" wrote: > Hi Vitaly, > > > > we use an enum so that we have a speaking name for the value. > > Sure we could use a ?final bool unordered = false? but enum seems > > the proper way. > > > > Propose a better name for Sem, I don?t like it too much either! > > I just used the name in our code (done by one of my former colleagues > > A few years ago). I will change it if there is a better (and please > short) one. > > > > Best regards, > > Goetz. > > > > > > > > *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com] > *Sent:* Mittwoch, 13. November 2013 02:31 > *To:* Lindenmaier, Goetz > *Cc:* Vladimir Kozlov; hotspot-dev developers; > ppc-aix-port-dev at openjdk.java.net > *Subject:* RE: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store > nodes to know about memory ordering. > > > > Hi Goetz, > > Just curious - why an enum for both versions (load, store) and not a > simple bool? You expecting more values? You wouldn't need those asserts in > the accessors if this was a bool. > > Also what does "Sem" stand for? Semantic? Seems like an odd abbreviation. > > Thanks > > Sent from my phone > > On Nov 12, 2013 11:31 AM, "Lindenmaier, Goetz" > wrote: > > Hi, > > I updated this webrev to work with the latest version of the staging > repository. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > Best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Freitag, 11. Oktober 2013 15:34 > To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir > Kozlov > Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to > know about memory ordering. > > Hi, > > I prepared a webrev for 8024921< > https://bugs.openjdk.java.net/browse/JDK-8024921>Extend Load and Store > nodes to know about memory ordering. > This is part of the PPC port. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ > > For a detailed description see the text in the webrev and bug description. > > All this basically does is add a field to load and store nodes and > change all constructor calls to set this field. So the effect on > existing platforms should be very small. Therefore I marked this > 'M', although quite some lines of code are touched. > > Please review and test this change. > I'm happy to incorporate your comments and any improvements > you propose. > > Best regards, > Goetz. > > > > From vladimir.kozlov at oracle.com Wed Nov 13 10:02:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 10:02:40 -0800 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE648F9@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE648F9@DEWDFEMB12A.global.corp.sap> Message-ID: <5283BEC0.6090201@oracle.com> On 11/13/13 5:20 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for the review! > I'm already working on your comments, more some later in a > comprehensive mail. For now: would postalloc_expand be fine, > too (two ls)? Yes, definitely. Thanks, Vladimir > > Best regards, > Goetz > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 12. November 2013 21:53 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Hi Goetz, > > It is good feature. Can you name it postaloc_expand to be clear when we > do it? > > Names. I know it is picking but for methods and .ad statements names we > use low case and underscore. Camel style is used for class names. > > I know this was written long time ago but we are trying now to not use > separate enc_class unless it is used by several instructions. Can you > also implement ability to write postaloc_expand inside mach instruction > (As we do now for ins_encode)? You can do it as separate changes later > if it a lot of work. > > instruct divI_reg_reg_Ex(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ > match(Set dst (DivI src1 src2)); > predicate(UseNewCode); > ins_cost((2+71)*DEFAULT_COST); > format %{ "SRA $src2,0,$src2\n\t" > "SRA $src1,0,$src1\n\t" > "SDIVX $src1,$src2,$dst" %} > postaloc_expand %{ > MachNode *m1 = new (C) divI_reg_reg_SRANode(); > MachNode *m2 = new (C) divI_reg_reg_SRANode(); > MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); > ... > %} > %} > > Are you allow branches in late expand? I assume not because you don't > have separate graph's blocks for that. It would be nice to have some > verification code which enforces restrictions. > > Also it would be nice if in lateExpand rule you need only define nodes > and connect them and the rest (opnds clonning, RA info patching and > pushing result nodes) be done by adlc. But it will require more code in > adlc so it may be for the future. I am worried that current code > requires very careful coding: which operand to clone and to which assign > it, which RA methods to use for resetting (set1(), set2(), set_pair()). > It is very bugs prone. > > > adlparse.cpp: // No pipe required for expands. > > + // No pipe required for late expand. > + if (instr->expands() || instr->lateExpands()) { > > Will it be difficult to totally separate lateExpands from ins_encode? > Your current code use _insencode + _is_lateExpand. Can you do one > InsEncode* _lateExpand? Or it will be too intrusive? > > > block.cpp: > Node_List already has method contains(Node* n), use it in > Block::contains() (you can define it in header file then). > > PhaseCFG::LateExpand(): > > TraceLateExpand is develop flag so it will be true only for #ifdef > ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT > in this method. > > "These kills are not required any more after expanding" - what about > flags kill Proj nodes? Disconnecting input nodes worries me. Do you > clean graph after that to remove unused nodes? > > I need to look more on LateExpand() in next round. > > compile.cpp: Can you add TracePhase/TraceTime to get time spent in > LateExpand. > > Why you need lateExpand() method in Node class? Generated mach nodes are > based on MachNode so this method could be declared only in MachNode. > (Putting new virtual method into top Node class will increase virtual > tables for all ideal and mach nodes). > > Thanks, > Vladimir > > On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I also updated this webrev to work with the latest staging repository. >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >> >> Best regards, >> Goetz. >> >> From: goetz.lindenmaier at sap.com >> Sent: Mittwoch, 2. Oktober 2013 15:49 >> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' >> Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. >> >> Hi, >> >> we extended C2 by what we call lateExpand. LateExpand expands nodes >> after register allocation. >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >> >> Some nodes can not be expanded during matching. E.g., register >> allocation might not be able to deal with the resulting pattern. To >> allow better scheduling in such cases, we introduce lateExpand which >> runs after register allocation. Whether and how nodes are expanded is >> specified in the ad-file. See block.cpp for a detailed >> documentation. We use this for some nodes on ppc, and extensively on >> ia64. >> For an example, see the webrev. >> >> We added some utility functions in node.hpp and block.hpp used by >> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >> MachConstantBaseNode gets the two new functions, as we need to >> late expand it. >> >> To skip the walk over the IR if no lateExpand is needed, we use >> Matcher::require_late_expand set in the ad file. This ends up in >> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >> agree, I would use a "const bool EnableLateExpand" in >> globalDefinitions_.hpp. (There is no suitable c2__.hpp >> file). >> >> We allready mailed a webrev with this change after last year's >> JavaOne, but there was no discussion on it. >> Again, this change is 'L', but the code is not used on other >> platforms than PPC64 (so far). So the impact on those platforms >> should be minimal. >> >> Please review and test this change. >> >> Thanks and best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Wed Nov 13 10:18:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 10:18:22 -0800 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <528394BE.1020609@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> <528394BE.1020609@oracle.com> Message-ID: <5283C26E.9030807@oracle.com> Vote: yes Regards, Vladimir On 11/13/13 7:03 AM, Vladimir Ivanov wrote: > Vote: yes > > Best regards, > Vladimir Ivanov > > On 11/13/13 6:48 PM, Roland Westrelin wrote: >> I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. >> >> Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified >> to be committer [1]. See the end of this email for a list of 8 significant changes. >> >> Votes are due by Nov. 27, 2013. >> >> Only current HSX Committers [2] are eligible to vote on this nomination. >> Votes must be cast in the open by replying to to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Roland Westrelin. >> >> [1] http://openjdk.java.net/projects/#project-committer >> [2] http://openjdk.java.net/census#hsx >> [3] http://openjdk.java.net/projects#committer-vote >> >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 >> From vladimir.kozlov at oracle.com Wed Nov 13 10:32:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 10:32:26 -0800 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64A2B@DEWDFEMB12A.global.corp.sap> Message-ID: <5283C5BA.1050307@oracle.com> On 11/13/13 9:20 AM, Vitaly Davidovich wrote: > Personally, I'd just use bool - you don't have a naming decision then :). > You also won't need the asserts in accessor. C2 usually uses enum for such cases. I would also prefer move enum to MemNode class (additional field should stay in subclasses) and list all values: typedef enum { unordered = 0, acquire, release } MemOrder; > > If you stick with enum, how about MemOrder? Is that too long? You're only > going to use that name in a few places so I think clarity trumps super > short name. +1 Thanks, Vladimir > > Sent from my phone > On Nov 13, 2013 11:54 AM, "Lindenmaier, Goetz" > wrote: > >> Hi Vitaly, >> >> >> >> we use an enum so that we have a speaking name for the value. >> >> Sure we could use a ?final bool unordered = false? but enum seems >> >> the proper way. >> >> >> >> Propose a better name for Sem, I don?t like it too much either! >> >> I just used the name in our code (done by one of my former colleagues >> >> A few years ago). I will change it if there is a better (and please >> short) one. >> >> >> >> Best regards, >> >> Goetz. >> >> >> >> >> >> >> >> *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com] >> *Sent:* Mittwoch, 13. November 2013 02:31 >> *To:* Lindenmaier, Goetz >> *Cc:* Vladimir Kozlov; hotspot-dev developers; >> ppc-aix-port-dev at openjdk.java.net >> *Subject:* RE: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >> nodes to know about memory ordering. >> >> >> >> Hi Goetz, >> >> Just curious - why an enum for both versions (load, store) and not a >> simple bool? You expecting more values? You wouldn't need those asserts in >> the accessors if this was a bool. >> >> Also what does "Sem" stand for? Semantic? Seems like an odd abbreviation. >> >> Thanks >> >> Sent from my phone >> >> On Nov 12, 2013 11:31 AM, "Lindenmaier, Goetz" >> wrote: >> >> Hi, >> >> I updated this webrev to work with the latest version of the staging >> repository. >> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >> >> Best regards, >> Goetz. >> >> From: goetz.lindenmaier at sap.com >> Sent: Freitag, 11. Oktober 2013 15:34 >> To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir >> Kozlov >> Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to >> know about memory ordering. >> >> Hi, >> >> I prepared a webrev for 8024921< >> https://bugs.openjdk.java.net/browse/JDK-8024921>Extend Load and Store >> nodes to know about memory ordering. >> This is part of the PPC port. >> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >> >> For a detailed description see the text in the webrev and bug description. >> >> All this basically does is add a field to load and store nodes and >> change all constructor calls to set this field. So the effect on >> existing platforms should be very small. Therefore I marked this >> 'M', although quite some lines of code are touched. >> >> Please review and test this change. >> I'm happy to incorporate your comments and any improvements >> you propose. >> >> Best regards, >> Goetz. >> >> >> >> From john.r.rose at oracle.com Wed Nov 13 11:35:53 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 13 Nov 2013 11:35:53 -0800 Subject: RFR 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field, change In-Reply-To: <5283B11F.6000501@oracle.com> References: <52805BE2.4040204@oracle.com> <5283B11F.6000501@oracle.com> Message-ID: <0CEB7A4C-703F-4B92-916B-2072EDE399C5@oracle.com> That looks good. The linear search is a fine choice for this corner case. BTW, I suggest adding an assert to cp_cache_delta() that _first_iteration_cp_cache_limit >= 0. (Nit: The "!!!" in the comment is a trifle loud.) You can count me as reviewer in any case. ? John On Nov 13, 2013, at 9:04 AM, Coleen Phillimore wrote: > > I added code to so we don't create duplicate invokespecial/InterfaceMethodref cpCache entries (suggested by John R), renamed _cp_cache_index_limit to _first_iteration_cp_cache_limit which is a bit clearer, and fixed formatting in test. Also added duplicate invokespecial/InterfaceMethodref case to test. Reran jck, java/lang/invoke and defmeth tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025937_2/ > > Thanks, > Coleen > > On 11/10/2013 11:24 PM, Coleen Phillmore wrote: >> Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025937/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025937 >> >> Tested with testcase in time api, java/lang/invoke jtreg tests, NSK mlvm, quick and defmeth tests, jck lang/vm tests, and testcase in changeset. >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Nov 13 11:43:58 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Nov 2013 14:43:58 -0500 Subject: RFR 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field,change In-Reply-To: <0CEB7A4C-703F-4B92-916B-2072EDE399C5@oracle.com> References: <52805BE2.4040204@oracle.com> <5283B11F.6000501@oracle.com> <0CEB7A4C-703F-4B92-916B-2072EDE399C5@oracle.com> Message-ID: <5283D67E.1060403@oracle.com> On 11/13/2013 2:35 PM, John Rose wrote: > That looks good. The linear search is a fine choice for this corner case. Yeah, there are few and not worth adding a ton of code and/or allocating another cp_map table for. > > BTW, I suggest adding an assert to cp_cache_delta() that _first_iteration_cp_cache_limit >= 0. Thanks, that is a good suggestion. I will add it. > > (Nit: The "!!!" in the comment is a trifle loud.) Ok. I'll take out two of the !.. :) Thanks! Coleen > > You can count me as reviewer in any case. > > ? John > > On Nov 13, 2013, at 9:04 AM, Coleen Phillimore wrote: > >> I added code to so we don't create duplicate invokespecial/InterfaceMethodref cpCache entries (suggested by John R), renamed _cp_cache_index_limit to _first_iteration_cp_cache_limit which is a bit clearer, and fixed formatting in test. Also added duplicate invokespecial/InterfaceMethodref case to test. Reran jck, java/lang/invoke and defmeth tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025937_2/ >> >> Thanks, >> Coleen >> >> On 11/10/2013 11:24 PM, Coleen Phillmore wrote: >>> Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025937/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025937 >>> >>> Tested with testcase in time api, java/lang/invoke jtreg tests, NSK mlvm, quick and defmeth tests, jck lang/vm tests, and testcase in changeset. >>> >>> Thanks, >>> Coleen From lois.foltan at oracle.com Wed Nov 13 12:16:49 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 13 Nov 2013 15:16:49 -0500 Subject: RFR 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field,change In-Reply-To: <5283B11F.6000501@oracle.com> References: <52805BE2.4040204@oracle.com> <5283B11F.6000501@oracle.com> Message-ID: <5283DE31.6000601@oracle.com> Looks good Coleen, I have reviewed. Lois On 11/13/2013 12:04 PM, Coleen Phillimore wrote: > > I added code to so we don't create duplicate > invokespecial/InterfaceMethodref cpCache entries (suggested by John > R), renamed _cp_cache_index_limit to _first_iteration_cp_cache_limit > which is a bit clearer, and fixed formatting in test. Also added > duplicate invokespecial/InterfaceMethodref case to test. Reran jck, > java/lang/invoke and defmeth tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025937_2/ > > Thanks, > Coleen > > On 11/10/2013 11:24 PM, Coleen Phillmore wrote: >> Summary: Create extra constant pool cache entries for >> invokespecial/InterfaceMethodref to hold the alternate resolution. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025937/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025937 >> >> Tested with testcase in time api, java/lang/invoke jtreg tests, NSK >> mlvm, quick and defmeth tests, jck lang/vm tests, and testcase in >> changeset. >> >> Thanks, >> Coleen >> >> >> > From harold.seigel at oracle.com Wed Nov 13 12:21:54 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 13 Nov 2013 15:21:54 -0500 Subject: RFR 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field,change In-Reply-To: <5283D67E.1060403@oracle.com> References: <52805BE2.4040204@oracle.com> <5283B11F.6000501@oracle.com> <0CEB7A4C-703F-4B92-916B-2072EDE399C5@oracle.com> <5283D67E.1060403@oracle.com> Message-ID: <5283DF62.1000500@oracle.com> Hi Coleen, Your changes look good. Harold On 11/13/2013 2:43 PM, Coleen Phillimore wrote: > On 11/13/2013 2:35 PM, John Rose wrote: >> That looks good. The linear search is a fine choice for this corner >> case. > > Yeah, there are few and not worth adding a ton of code and/or > allocating another cp_map table for. >> >> BTW, I suggest adding an assert to cp_cache_delta() that >> _first_iteration_cp_cache_limit >= 0. > > Thanks, that is a good suggestion. I will add it. >> >> (Nit: The "!!!" in the comment is a trifle loud.) > > Ok. I'll take out two of the !.. :) > > Thanks! > Coleen >> >> You can count me as reviewer in any case. >> >> ? John >> >> On Nov 13, 2013, at 9:04 AM, Coleen Phillimore >> wrote: >> >>> I added code to so we don't create duplicate >>> invokespecial/InterfaceMethodref cpCache entries (suggested by John >>> R), renamed _cp_cache_index_limit to _first_iteration_cp_cache_limit >>> which is a bit clearer, and fixed formatting in test. Also added >>> duplicate invokespecial/InterfaceMethodref case to test. Reran >>> jck, java/lang/invoke and defmeth tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025937_2/ >>> >>> Thanks, >>> Coleen >>> >>> On 11/10/2013 11:24 PM, Coleen Phillmore wrote: >>>> Summary: Create extra constant pool cache entries for >>>> invokespecial/InterfaceMethodref to hold the alternate resolution. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025937/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8025937 >>>> >>>> Tested with testcase in time api, java/lang/invoke jtreg tests, NSK >>>> mlvm, quick and defmeth tests, jck lang/vm tests, and testcase in >>>> changeset. >>>> >>>> Thanks, >>>> Coleen > From goetz.lindenmaier at sap.com Wed Nov 13 15:37:48 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Nov 2013 23:37:48 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <52829548.6060604@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE64B96@DEWDFEMB12A.global.corp.sap> Hi Vladimir, Thanks for the thorough review!! I made a new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp-2/ > It is good feature. Thanks :) > Can you name it postaloc_expand to be clear when we do it? Fixed. > Names. I know it is picking but for methods and .ad statements names we > use low case and underscore. Camel style is used for class names. No matter, changing names isn't a big deal. I hope I've got all. > I know this was written long time ago but we are trying now to not use > separate enc_class unless it is used by several instructions. Can you > also implement ability to write postaloc_expand inside mach instruction > (As we do now for ins_encode)? You can do it as separate changes later > if it a lot of work. Done. Was really simple ;) I'll adapt our ad file eventually, but that contains 370 ins_encode and 460 instruct declarations, so it will take some time. > Are you allow branches in late expand? I assume not because you don't > have separate graph's blocks for that. It would be nice to have some > verification code which enforces restrictions. No, no branches. That would need a very different approach, as the cfg would have to be changed. We have some conditional moves with branches that would be much better represented if blocks were possible. But we did not implement that as it seems far too much effort. Anyways, on ia64 we have predicated instructions, so there we don't need branches. On Power, starting with Power7, there is a conditional move. > Also it would be nice if in lateExpand rule you need only define nodes > and connect them and the rest (opnds clonning, RA info patching and > pushing result nodes) be done by adlc. But it will require more code in > adlc so it may be for the future. I am worried that current code > requires very careful coding: which operand to clone and to which assign > it, which RA methods to use for resetting (set1(), set2(), set_pair()). > It is very bugs prone. Yes, it is a bit complicated. Basically, adlc could generate constructors for nodes that generate the operands. At least if the node clearly specifies it's operands. If there are operand classes that's ambiguous. I would at least like some checker code like machNode->check_operands that checks that all operands are there and that they have the proper type. The advantage is that it's more flexible than the expand mechanism. For example there are no C-if's possible in expands. Many other things are restricted, like generating nodes that require TEMPs. All these features could be added to expand, but that's always a lot of overhead if you just want to generate some instructions. > Will it be difficult to totally separate lateExpands from ins_encode? > Your current code use _insencode + _is_lateExpand. Can you do one > InsEncode* _lateExpand? Or it will be too intrusive? I will just have to copy lots of code. Also, for the postaloc_expand %{ %} support I just had to call the proper ins_encode function. I don't think replicating all that code makes sense. > block.cpp: > Node_List already has method contains(Node* n), use it in > Block::contains() (you can define it in header file then). Done. Also added const to Node_List::contains(). PhaseCFG::LateExpand(): > TraceLateExpand is develop flag so it will be true only for #ifdef > ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT > in this method. Done. > "These kills are not required any more after expanding" - what about > flags kill Proj nodes? Disconnecting input nodes worries me. Do you > clean graph after that to remove unused nodes? Yes, the graph is clean afterwards. Many kills/temps are explicit register deps after expanding. Those that should be kept have to be added in the postaloc_expand method of the node. If that method wants to reuse a Proj, it can add it to the node list returned. Then it will be first removed, and then added again. This is necessary, as the position in the blocks node list must be correct. > I need to look more on LateExpand() in next round. > compile.cpp: Can you add TracePhase/TraceTime to get time spent in > LateExpand. Done. I used TracePhase. > Why you need lateExpand() method in Node class? Generated mach nodes are > based on MachNode so this method could be declared only in MachNode. > (Putting new virtual method into top Node class will increase virtual > tables for all ideal and mach nodes). We put it just right next to format() and emit(). Moved to machnode. Best regards, Goetz. Thanks, Vladimir On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: > Hi, > > I also updated this webrev to work with the latest staging repository. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Best regards, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Mittwoch, 2. Oktober 2013 15:49 > To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' > Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > Hi, > > we extended C2 by what we call lateExpand. LateExpand expands nodes > after register allocation. > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ > > Some nodes can not be expanded during matching. E.g., register > allocation might not be able to deal with the resulting pattern. To > allow better scheduling in such cases, we introduce lateExpand which > runs after register allocation. Whether and how nodes are expanded is > specified in the ad-file. See block.cpp for a detailed > documentation. We use this for some nodes on ppc, and extensively on > ia64. > For an example, see the webrev. > > We added some utility functions in node.hpp and block.hpp used by > PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, > MachConstantBaseNode gets the two new functions, as we need to > late expand it. > > To skip the walk over the IR if no lateExpand is needed, we use > Matcher::require_late_expand set in the ad file. This ends up in > ad_.cpp, thus can not be evaluated by the C++ compiler. If you > agree, I would use a "const bool EnableLateExpand" in > globalDefinitions_.hpp. (There is no suitable c2__.hpp > file). > > We allready mailed a webrev with this change after last year's > JavaOne, but there was no discussion on it. > Again, this change is 'L', but the code is not used on other > platforms than PPC64 (so far). So the impact on those platforms > should be minimal. > > Please review and test this change. > > Thanks and best regards, > Goetz. > From vladimir.kozlov at oracle.com Wed Nov 13 19:39:46 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 19:39:46 -0800 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE64B96@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64B96@DEWDFEMB12A.global.corp.sap> Message-ID: <52844602.9020105@oracle.com> This webrev contains other changes in src/cpu/ppc/vm. Was it intentional? Thanks, Vladimir On 11/13/13 3:37 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > Thanks for the thorough review!! > I made a new webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp-2/ > >> It is good feature. > Thanks :) >> Can you name it postaloc_expand to be clear when we do it? > Fixed. > >> Names. I know it is picking but for methods and .ad statements names we >> use low case and underscore. Camel style is used for class names. > No matter, changing names isn't a big deal. I hope I've got all. > >> I know this was written long time ago but we are trying now to not use >> separate enc_class unless it is used by several instructions. Can you >> also implement ability to write postaloc_expand inside mach instruction >> (As we do now for ins_encode)? You can do it as separate changes later >> if it a lot of work. > Done. Was really simple ;) I'll adapt our ad file eventually, but that contains > 370 ins_encode and 460 instruct declarations, so it will take some time. > >> Are you allow branches in late expand? I assume not because you don't >> have separate graph's blocks for that. It would be nice to have some >> verification code which enforces restrictions. > No, no branches. That would need a very different approach, as the cfg > would have to be changed. We have some conditional moves with branches > that would be much better represented if blocks were possible. But we did not implement > that as it seems far too much effort. Anyways, on ia64 we have predicated > instructions, so there we don't need branches. On Power, starting with > Power7, there is a conditional move. > >> Also it would be nice if in lateExpand rule you need only define nodes >> and connect them and the rest (opnds clonning, RA info patching and >> pushing result nodes) be done by adlc. But it will require more code in >> adlc so it may be for the future. I am worried that current code >> requires very careful coding: which operand to clone and to which assign >> it, which RA methods to use for resetting (set1(), set2(), set_pair()). >> It is very bugs prone. > Yes, it is a bit complicated. Basically, adlc could generate constructors > for nodes that generate the operands. At least if the node clearly specifies > it's operands. If there are operand classes that's ambiguous. > I would at least like some checker code like machNode->check_operands > that checks that all operands are there and that they have the proper > type. > The advantage is that it's more flexible than the expand mechanism. > For example there are no C-if's possible in expands. Many other things > are restricted, like generating nodes that require TEMPs. All these > features could be added to expand, but that's always a lot of overhead > if you just want to generate some instructions. > >> Will it be difficult to totally separate lateExpands from ins_encode? >> Your current code use _insencode + _is_lateExpand. Can you do one >> InsEncode* _lateExpand? Or it will be too intrusive? > I will just have to copy lots of code. Also, for the postaloc_expand %{ %} > support I just had to call the proper ins_encode function. I don't think > replicating all that code makes sense. > >> block.cpp: >> Node_List already has method contains(Node* n), use it in >> Block::contains() (you can define it in header file then). > Done. Also added const to Node_List::contains(). > > PhaseCFG::LateExpand(): > >> TraceLateExpand is develop flag so it will be true only for #ifdef >> ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT >> in this method. > Done. > >> "These kills are not required any more after expanding" - what about >> flags kill Proj nodes? Disconnecting input nodes worries me. Do you >> clean graph after that to remove unused nodes? > Yes, the graph is clean afterwards. Many kills/temps are explicit register > deps after expanding. Those that should be kept have to be added in the > postaloc_expand method of the node. If that method wants to reuse a Proj, it can > add it to the node list returned. Then it will be first removed, and > then added again. This is necessary, as the position in the blocks > node list must be correct. > >> I need to look more on LateExpand() in next round. > >> compile.cpp: Can you add TracePhase/TraceTime to get time spent in >> LateExpand. > Done. I used TracePhase. > >> Why you need lateExpand() method in Node class? Generated mach nodes are >> based on MachNode so this method could be declared only in MachNode. >> (Putting new virtual method into top Node class will increase virtual >> tables for all ideal and mach nodes). > We put it just right next to format() and emit(). Moved to machnode. > > Best regards, > Goetz. > > > Thanks, > Vladimir > > On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I also updated this webrev to work with the latest staging repository. >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >> >> Best regards, >> Goetz. >> >> From: goetz.lindenmaier at sap.com >> Sent: Mittwoch, 2. Oktober 2013 15:49 >> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' >> Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. >> >> Hi, >> >> we extended C2 by what we call lateExpand. LateExpand expands nodes >> after register allocation. >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >> >> Some nodes can not be expanded during matching. E.g., register >> allocation might not be able to deal with the resulting pattern. To >> allow better scheduling in such cases, we introduce lateExpand which >> runs after register allocation. Whether and how nodes are expanded is >> specified in the ad-file. See block.cpp for a detailed >> documentation. We use this for some nodes on ppc, and extensively on >> ia64. >> For an example, see the webrev. >> >> We added some utility functions in node.hpp and block.hpp used by >> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >> MachConstantBaseNode gets the two new functions, as we need to >> late expand it. >> >> To skip the walk over the IR if no lateExpand is needed, we use >> Matcher::require_late_expand set in the ad file. This ends up in >> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >> agree, I would use a "const bool EnableLateExpand" in >> globalDefinitions_.hpp. (There is no suitable c2__.hpp >> file). >> >> We allready mailed a webrev with this change after last year's >> JavaOne, but there was no discussion on it. >> Again, this change is 'L', but the code is not used on other >> platforms than PPC64 (so far). So the impact on those platforms >> should be minimal. >> >> Please review and test this change. >> >> Thanks and best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Wed Nov 13 21:26:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Nov 2013 21:26:53 -0800 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <52844602.9020105@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64B96@DEWDFEMB12A.global.corp.sap> <52844602.9020105@oracle.com> Message-ID: <52845F1D.8080809@oracle.com> I looked on files from previous webrev and you addressed all my comments. But I need clean webrev to approve it. Thanks, Vladimir On 11/13/13 7:39 PM, Vladimir Kozlov wrote: > This webrev contains other changes in src/cpu/ppc/vm. Was it intentional? > > Thanks, > Vladimir > > On 11/13/13 3:37 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> Thanks for the thorough review!! >> I made a new webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp-2/ >> >>> It is good feature. >> Thanks :) >>> Can you name it postaloc_expand to be clear when we do it? >> Fixed. >> >>> Names. I know it is picking but for methods and .ad statements names we >>> use low case and underscore. Camel style is used for class names. >> No matter, changing names isn't a big deal. I hope I've got all. >> >>> I know this was written long time ago but we are trying now to not use >>> separate enc_class unless it is used by several instructions. Can you >>> also implement ability to write postaloc_expand inside mach instruction >>> (As we do now for ins_encode)? You can do it as separate changes later >>> if it a lot of work. >> Done. Was really simple ;) I'll adapt our ad file eventually, but that contains >> 370 ins_encode and 460 instruct declarations, so it will take some time. >> >>> Are you allow branches in late expand? I assume not because you don't >>> have separate graph's blocks for that. It would be nice to have some >>> verification code which enforces restrictions. >> No, no branches. That would need a very different approach, as the cfg >> would have to be changed. We have some conditional moves with branches >> that would be much better represented if blocks were possible. But we did not implement >> that as it seems far too much effort. Anyways, on ia64 we have predicated >> instructions, so there we don't need branches. On Power, starting with >> Power7, there is a conditional move. >> >>> Also it would be nice if in lateExpand rule you need only define nodes >>> and connect them and the rest (opnds clonning, RA info patching and >>> pushing result nodes) be done by adlc. But it will require more code in >>> adlc so it may be for the future. I am worried that current code >>> requires very careful coding: which operand to clone and to which assign >>> it, which RA methods to use for resetting (set1(), set2(), set_pair()). >>> It is very bugs prone. >> Yes, it is a bit complicated. Basically, adlc could generate constructors >> for nodes that generate the operands. At least if the node clearly specifies >> it's operands. If there are operand classes that's ambiguous. >> I would at least like some checker code like machNode->check_operands >> that checks that all operands are there and that they have the proper >> type. >> The advantage is that it's more flexible than the expand mechanism. >> For example there are no C-if's possible in expands. Many other things >> are restricted, like generating nodes that require TEMPs. All these >> features could be added to expand, but that's always a lot of overhead >> if you just want to generate some instructions. >> >>> Will it be difficult to totally separate lateExpands from ins_encode? >>> Your current code use _insencode + _is_lateExpand. Can you do one >>> InsEncode* _lateExpand? Or it will be too intrusive? >> I will just have to copy lots of code. Also, for the postaloc_expand %{ %} >> support I just had to call the proper ins_encode function. I don't think >> replicating all that code makes sense. >> >>> block.cpp: >>> Node_List already has method contains(Node* n), use it in >>> Block::contains() (you can define it in header file then). >> Done. Also added const to Node_List::contains(). >> >> PhaseCFG::LateExpand(): >> >>> TraceLateExpand is develop flag so it will be true only for #ifdef >>> ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT >>> in this method. >> Done. >> >>> "These kills are not required any more after expanding" - what about >>> flags kill Proj nodes? Disconnecting input nodes worries me. Do you >>> clean graph after that to remove unused nodes? >> Yes, the graph is clean afterwards. Many kills/temps are explicit register >> deps after expanding. Those that should be kept have to be added in the >> postaloc_expand method of the node. If that method wants to reuse a Proj, it can >> add it to the node list returned. Then it will be first removed, and >> then added again. This is necessary, as the position in the blocks >> node list must be correct. >> >>> I need to look more on LateExpand() in next round. >> >>> compile.cpp: Can you add TracePhase/TraceTime to get time spent in >>> LateExpand. >> Done. I used TracePhase. >> >>> Why you need lateExpand() method in Node class? Generated mach nodes are >>> based on MachNode so this method could be declared only in MachNode. >>> (Putting new virtual method into top Node class will increase virtual >>> tables for all ideal and mach nodes). >> We put it just right next to format() and emit(). Moved to machnode. >> >> Best regards, >> Goetz. >> >> >> Thanks, >> Vladimir >> >> On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I also updated this webrev to work with the latest staging repository. >>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >>> >>> Best regards, >>> Goetz. >>> >>> From: goetz.lindenmaier at sap.com >>> Sent: Mittwoch, 2. Oktober 2013 15:49 >>> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' >>> Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. >>> >>> Hi, >>> >>> we extended C2 by what we call lateExpand. LateExpand expands nodes >>> after register allocation. >>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >>> >>> Some nodes can not be expanded during matching. E.g., register >>> allocation might not be able to deal with the resulting pattern. To >>> allow better scheduling in such cases, we introduce lateExpand which >>> runs after register allocation. Whether and how nodes are expanded is >>> specified in the ad-file. See block.cpp for a detailed >>> documentation. We use this for some nodes on ppc, and extensively on >>> ia64. >>> For an example, see the webrev. >>> >>> We added some utility functions in node.hpp and block.hpp used by >>> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >>> MachConstantBaseNode gets the two new functions, as we need to >>> late expand it. >>> >>> To skip the walk over the IR if no lateExpand is needed, we use >>> Matcher::require_late_expand set in the ad file. This ends up in >>> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >>> agree, I would use a "const bool EnableLateExpand" in >>> globalDefinitions_.hpp. (There is no suitable c2__.hpp >>> file). >>> >>> We allready mailed a webrev with this change after last year's >>> JavaOne, but there was no discussion on it. >>> Again, this change is 'L', but the code is not used on other >>> platforms than PPC64 (so far). So the impact on those platforms >>> should be minimal. >>> >>> Please review and test this change. >>> >>> Thanks and best regards, >>> Goetz. >>> From bengt.rutisson at oracle.com Wed Nov 13 23:38:28 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 14 Nov 2013 08:38:28 +0100 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <52847DF4.3060809@oracle.com> Vote: yes Bengt On 11/13/13 3:48 PM, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From staffan.larsen at oracle.com Wed Nov 13 23:54:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Nov 2013 08:54:07 +0100 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: Vote: yes. /Staffan On 13 Nov 2013, at 15:48, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From goetz.lindenmaier at sap.com Thu Nov 14 00:15:45 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Nov 2013 08:15:45 +0000 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <52845F1D.8080809@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64B96@DEWDFEMB12A.global.corp.sap> <52844602.9020105@oracle.com> <52845F1D.8080809@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE64C82@DEWDFEMB12A.global.corp.sap> Hi Vladimir, sorry for that, I fixed it. Looks like I didn't pop all my ppc changes. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 14. November 2013 06:27 To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. I looked on files from previous webrev and you addressed all my comments. But I need clean webrev to approve it. Thanks, Vladimir On 11/13/13 7:39 PM, Vladimir Kozlov wrote: > This webrev contains other changes in src/cpu/ppc/vm. Was it intentional? > > Thanks, > Vladimir > > On 11/13/13 3:37 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> Thanks for the thorough review!! >> I made a new webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp-2/ >> >>> It is good feature. >> Thanks :) >>> Can you name it postaloc_expand to be clear when we do it? >> Fixed. >> >>> Names. I know it is picking but for methods and .ad statements names we >>> use low case and underscore. Camel style is used for class names. >> No matter, changing names isn't a big deal. I hope I've got all. >> >>> I know this was written long time ago but we are trying now to not use >>> separate enc_class unless it is used by several instructions. Can you >>> also implement ability to write postaloc_expand inside mach instruction >>> (As we do now for ins_encode)? You can do it as separate changes later >>> if it a lot of work. >> Done. Was really simple ;) I'll adapt our ad file eventually, but that contains >> 370 ins_encode and 460 instruct declarations, so it will take some time. >> >>> Are you allow branches in late expand? I assume not because you don't >>> have separate graph's blocks for that. It would be nice to have some >>> verification code which enforces restrictions. >> No, no branches. That would need a very different approach, as the cfg >> would have to be changed. We have some conditional moves with branches >> that would be much better represented if blocks were possible. But we did not implement >> that as it seems far too much effort. Anyways, on ia64 we have predicated >> instructions, so there we don't need branches. On Power, starting with >> Power7, there is a conditional move. >> >>> Also it would be nice if in lateExpand rule you need only define nodes >>> and connect them and the rest (opnds clonning, RA info patching and >>> pushing result nodes) be done by adlc. But it will require more code in >>> adlc so it may be for the future. I am worried that current code >>> requires very careful coding: which operand to clone and to which assign >>> it, which RA methods to use for resetting (set1(), set2(), set_pair()). >>> It is very bugs prone. >> Yes, it is a bit complicated. Basically, adlc could generate constructors >> for nodes that generate the operands. At least if the node clearly specifies >> it's operands. If there are operand classes that's ambiguous. >> I would at least like some checker code like machNode->check_operands >> that checks that all operands are there and that they have the proper >> type. >> The advantage is that it's more flexible than the expand mechanism. >> For example there are no C-if's possible in expands. Many other things >> are restricted, like generating nodes that require TEMPs. All these >> features could be added to expand, but that's always a lot of overhead >> if you just want to generate some instructions. >> >>> Will it be difficult to totally separate lateExpands from ins_encode? >>> Your current code use _insencode + _is_lateExpand. Can you do one >>> InsEncode* _lateExpand? Or it will be too intrusive? >> I will just have to copy lots of code. Also, for the postaloc_expand %{ %} >> support I just had to call the proper ins_encode function. I don't think >> replicating all that code makes sense. >> >>> block.cpp: >>> Node_List already has method contains(Node* n), use it in >>> Block::contains() (you can define it in header file then). >> Done. Also added const to Node_List::contains(). >> >> PhaseCFG::LateExpand(): >> >>> TraceLateExpand is develop flag so it will be true only for #ifdef >>> ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT >>> in this method. >> Done. >> >>> "These kills are not required any more after expanding" - what about >>> flags kill Proj nodes? Disconnecting input nodes worries me. Do you >>> clean graph after that to remove unused nodes? >> Yes, the graph is clean afterwards. Many kills/temps are explicit register >> deps after expanding. Those that should be kept have to be added in the >> postaloc_expand method of the node. If that method wants to reuse a Proj, it can >> add it to the node list returned. Then it will be first removed, and >> then added again. This is necessary, as the position in the blocks >> node list must be correct. >> >>> I need to look more on LateExpand() in next round. >> >>> compile.cpp: Can you add TracePhase/TraceTime to get time spent in >>> LateExpand. >> Done. I used TracePhase. >> >>> Why you need lateExpand() method in Node class? Generated mach nodes are >>> based on MachNode so this method could be declared only in MachNode. >>> (Putting new virtual method into top Node class will increase virtual >>> tables for all ideal and mach nodes). >> We put it just right next to format() and emit(). Moved to machnode. >> >> Best regards, >> Goetz. >> >> >> Thanks, >> Vladimir >> >> On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I also updated this webrev to work with the latest staging repository. >>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >>> >>> Best regards, >>> Goetz. >>> >>> From: goetz.lindenmaier at sap.com >>> Sent: Mittwoch, 2. Oktober 2013 15:49 >>> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' >>> Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. >>> >>> Hi, >>> >>> we extended C2 by what we call lateExpand. LateExpand expands nodes >>> after register allocation. >>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >>> >>> Some nodes can not be expanded during matching. E.g., register >>> allocation might not be able to deal with the resulting pattern. To >>> allow better scheduling in such cases, we introduce lateExpand which >>> runs after register allocation. Whether and how nodes are expanded is >>> specified in the ad-file. See block.cpp for a detailed >>> documentation. We use this for some nodes on ppc, and extensively on >>> ia64. >>> For an example, see the webrev. >>> >>> We added some utility functions in node.hpp and block.hpp used by >>> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >>> MachConstantBaseNode gets the two new functions, as we need to >>> late expand it. >>> >>> To skip the walk over the IR if no lateExpand is needed, we use >>> Matcher::require_late_expand set in the ad file. This ends up in >>> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >>> agree, I would use a "const bool EnableLateExpand" in >>> globalDefinitions_.hpp. (There is no suitable c2__.hpp >>> file). >>> >>> We allready mailed a webrev with this change after last year's >>> JavaOne, but there was no discussion on it. >>> Again, this change is 'L', but the code is not used on other >>> platforms than PPC64 (so far). So the impact on those platforms >>> should be minimal. >>> >>> Please review and test this change. >>> >>> Thanks and best regards, >>> Goetz. >>> From volker.simonis at gmail.com Thu Nov 14 00:24:15 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Nov 2013 09:24:15 +0100 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: Vote: yes On Wed, Nov 13, 2013 at 3:48 PM, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From thomas.schatzl at oracle.com Thu Nov 14 01:50:02 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Nov 2013 10:50:02 +0100 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <1384422602.2822.2.camel@cirrus> Vote: On Wed, 2013-11-13 at 15:48 +0100, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From thomas.schatzl at oracle.com Thu Nov 14 01:55:30 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Nov 2013 10:55:30 +0100 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <1384422930.2822.3.camel@cirrus> Vote: yes :) From niclas.adlertz at oracle.com Thu Nov 14 02:02:03 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 14 Nov 2013 11:02:03 +0100 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <52849F9B.8070300@oracle.com> Vote: Yes On 2013-11-13 15:48, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 > From jesper.wilhelmsson at oracle.com Thu Nov 14 03:24:16 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 14 Nov 2013 12:24:16 +0100 Subject: RFR: 8028162 - Update Netbeans / Solaris Studio project files on Mac In-Reply-To: <52848F0D.9080300@oracle.com> References: <52822590.6000704@oracle.com> <52848F0D.9080300@oracle.com> Message-ID: <5284B2E0.5070809@oracle.com> Hi Magnus, Magnus Ihse Bursie skrev 14/11/13 9:51 AM: > Hi Jesper, > > I assume you wanted to post this to the build-dev list -- the build-infra-dev > was a project-based list used during active development of the new build system. OK, thanks for forwarding. > > As far as I can tell, the changes looks good. (But I'm not a formal reviewer) Thanks! Do you know which repository is the most suitable to push this change? I can't go through hsx/hotspot-gc ;-) > > Thinking long term, this file should probably be generated on the fly instead of > updated manually like this. It is fairly automatic since Solaris Studio generates the files, but if it could be done by the make files it would of course be even better. /Jesper > > /Magnus > > On 2013-11-12 13:56, Jesper Wilhelmsson wrote: >> Hi, >> >> Could I have a couple of reviews of the updated project files for NetBeans / >> Solaris Studio. >> >> This change updates the Mac part of the project files. I intend to do the same >> change on linux as well but that will be a separate change. Then maybe someone >> who has a Solaris box can update the Solaris part? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028162 >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8028162/webrev/ >> >> Looking at the diff you will see that all $SRC have been replaced by 0. This >> was done automatically by Solaris Studio. I asked in the support forum if this >> was correct, and apparently it was :-) >> >> Forum: http://myforums.oracle.com/jive3/thread.jspa?threadID=1350319&tstart=0 >> >> Thanks, >> /Jesper > From david.r.chase at oracle.com Thu Nov 14 09:11:15 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 14 Nov 2013 12:11:15 -0500 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <6F03E393-7D34-40A1-B812-755CD3FF8446@oracle.com> Vote: yes From vladimir.kozlov at oracle.com Thu Nov 14 10:29:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Nov 2013 10:29:52 -0800 Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE64C82@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D036C09@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE64608@DEWDFEMB12A.global.corp.sap> <52829548.6060604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64B96@DEWDFEMB12A.global.corp.sap> <52844602.9020105@oracle.com> <52845F1D.8080809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64C82@DEWDFEMB12A.global.corp.sap> Message-ID: <528516A0.2030802@oracle.com> Looks good. I need to make changes in our closed .ad files and get reviews. I will push after that. Thanks, Vladimir On 11/14/13 12:15 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > sorry for that, I fixed it. Looks like I didn't pop all my ppc changes. > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Donnerstag, 14. November 2013 06:27 > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. > > I looked on files from previous webrev and you addressed all my comments. But I need clean webrev to approve it. > > Thanks, > Vladimir > > On 11/13/13 7:39 PM, Vladimir Kozlov wrote: >> This webrev contains other changes in src/cpu/ppc/vm. Was it intentional? >> >> Thanks, >> Vladimir >> >> On 11/13/13 3:37 PM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> Thanks for the thorough review!! >>> I made a new webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp-2/ >>> >>>> It is good feature. >>> Thanks :) >>>> Can you name it postaloc_expand to be clear when we do it? >>> Fixed. >>> >>>> Names. I know it is picking but for methods and .ad statements names we >>>> use low case and underscore. Camel style is used for class names. >>> No matter, changing names isn't a big deal. I hope I've got all. >>> >>>> I know this was written long time ago but we are trying now to not use >>>> separate enc_class unless it is used by several instructions. Can you >>>> also implement ability to write postaloc_expand inside mach instruction >>>> (As we do now for ins_encode)? You can do it as separate changes later >>>> if it a lot of work. >>> Done. Was really simple ;) I'll adapt our ad file eventually, but that contains >>> 370 ins_encode and 460 instruct declarations, so it will take some time. >>> >>>> Are you allow branches in late expand? I assume not because you don't >>>> have separate graph's blocks for that. It would be nice to have some >>>> verification code which enforces restrictions. >>> No, no branches. That would need a very different approach, as the cfg >>> would have to be changed. We have some conditional moves with branches >>> that would be much better represented if blocks were possible. But we did not implement >>> that as it seems far too much effort. Anyways, on ia64 we have predicated >>> instructions, so there we don't need branches. On Power, starting with >>> Power7, there is a conditional move. >>> >>>> Also it would be nice if in lateExpand rule you need only define nodes >>>> and connect them and the rest (opnds clonning, RA info patching and >>>> pushing result nodes) be done by adlc. But it will require more code in >>>> adlc so it may be for the future. I am worried that current code >>>> requires very careful coding: which operand to clone and to which assign >>>> it, which RA methods to use for resetting (set1(), set2(), set_pair()). >>>> It is very bugs prone. >>> Yes, it is a bit complicated. Basically, adlc could generate constructors >>> for nodes that generate the operands. At least if the node clearly specifies >>> it's operands. If there are operand classes that's ambiguous. >>> I would at least like some checker code like machNode->check_operands >>> that checks that all operands are there and that they have the proper >>> type. >>> The advantage is that it's more flexible than the expand mechanism. >>> For example there are no C-if's possible in expands. Many other things >>> are restricted, like generating nodes that require TEMPs. All these >>> features could be added to expand, but that's always a lot of overhead >>> if you just want to generate some instructions. >>> >>>> Will it be difficult to totally separate lateExpands from ins_encode? >>>> Your current code use _insencode + _is_lateExpand. Can you do one >>>> InsEncode* _lateExpand? Or it will be too intrusive? >>> I will just have to copy lots of code. Also, for the postaloc_expand %{ %} >>> support I just had to call the proper ins_encode function. I don't think >>> replicating all that code makes sense. >>> >>>> block.cpp: >>>> Node_List already has method contains(Node* n), use it in >>>> Block::contains() (you can define it in header file then). >>> Done. Also added const to Node_List::contains(). >>> >>> PhaseCFG::LateExpand(): >>> >>>> TraceLateExpand is develop flag so it will be true only for #ifdef >>>> ASSERT. It seems all #ifndef PRODUCT should be replaced by #ifdef ASSERT >>>> in this method. >>> Done. >>> >>>> "These kills are not required any more after expanding" - what about >>>> flags kill Proj nodes? Disconnecting input nodes worries me. Do you >>>> clean graph after that to remove unused nodes? >>> Yes, the graph is clean afterwards. Many kills/temps are explicit register >>> deps after expanding. Those that should be kept have to be added in the >>> postaloc_expand method of the node. If that method wants to reuse a Proj, it can >>> add it to the node list returned. Then it will be first removed, and >>> then added again. This is necessary, as the position in the blocks >>> node list must be correct. >>> >>>> I need to look more on LateExpand() in next round. >>> >>>> compile.cpp: Can you add TracePhase/TraceTime to get time spent in >>>> LateExpand. >>> Done. I used TracePhase. >>> >>>> Why you need lateExpand() method in Node class? Generated mach nodes are >>>> based on MachNode so this method could be declared only in MachNode. >>>> (Putting new virtual method into top Node class will increase virtual >>>> tables for all ideal and mach nodes). >>> We put it just right next to format() and emit(). Moved to machnode. >>> >>> Best regards, >>> Goetz. >>> >>> >>> Thanks, >>> Vladimir >>> >>> On 11/12/13 8:32 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I also updated this webrev to work with the latest staging repository. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> From: goetz.lindenmaier at sap.com >>>> Sent: Mittwoch, 2. Oktober 2013 15:49 >>>> To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; 'Vladimir Kozlov' >>>> Subject: RFR(L): 8003854: PPC64 (part 115): Introduce lateExpand that expands nodes after register allocation. >>>> >>>> Hi, >>>> >>>> we extended C2 by what we call lateExpand. LateExpand expands nodes >>>> after register allocation. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8003854-lateExp/ >>>> >>>> Some nodes can not be expanded during matching. E.g., register >>>> allocation might not be able to deal with the resulting pattern. To >>>> allow better scheduling in such cases, we introduce lateExpand which >>>> runs after register allocation. Whether and how nodes are expanded is >>>> specified in the ad-file. See block.cpp for a detailed >>>> documentation. We use this for some nodes on ppc, and extensively on >>>> ia64. >>>> For an example, see the webrev. >>>> >>>> We added some utility functions in node.hpp and block.hpp used by >>>> PhaseCFG::LateExpand() or the Node::lateExpand functions. Also, >>>> MachConstantBaseNode gets the two new functions, as we need to >>>> late expand it. >>>> >>>> To skip the walk over the IR if no lateExpand is needed, we use >>>> Matcher::require_late_expand set in the ad file. This ends up in >>>> ad_.cpp, thus can not be evaluated by the C++ compiler. If you >>>> agree, I would use a "const bool EnableLateExpand" in >>>> globalDefinitions_.hpp. (There is no suitable c2__.hpp >>>> file). >>>> >>>> We allready mailed a webrev with this change after last year's >>>> JavaOne, but there was no discussion on it. >>>> Again, this change is 'L', but the code is not used on other >>>> platforms than PPC64 (so far). So the impact on those platforms >>>> should be minimal. >>>> >>>> Please review and test this change. >>>> >>>> Thanks and best regards, >>>> Goetz. >>>> From john.coomes at oracle.com Thu Nov 14 10:31:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:31:24 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b116 for changeset 5fdc44652089 Message-ID: <20131114183127.C8928625CA@hg.openjdk.java.net> Changeset: 7299367c8aa4 Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/7299367c8aa4 Added tag jdk8-b116 for changeset 5fdc44652089 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:31:31 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:31:31 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b116 for changeset e757eb9aee3d Message-ID: <20131114183141.C0EEA625CB@hg.openjdk.java.net> Changeset: c1d234d4f164 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/c1d234d4f164 Added tag jdk8-b116 for changeset e757eb9aee3d ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:31:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:31:21 +0000 Subject: hg: hsx/hotspot-main: 3 new changesets Message-ID: <20131114183121.96001625C9@hg.openjdk.java.net> Changeset: c1029b02ca87 Author: ihse Date: 2013-11-08 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c1029b02ca87 8027836: Webrev should handle files that has been moved from a directory which now is removed. Reviewed-by: mduigou, tbell ! make/scripts/webrev.ksh Changeset: cbfe5da942c6 Author: katleman Date: 2013-11-11 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/cbfe5da942c6 Merge Changeset: a4afb0a8d55e Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/a4afb0a8d55e Added tag jdk8-b116 for changeset cbfe5da942c6 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:31:45 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:31:45 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b116 for changeset 587560c222a2 Message-ID: <20131114183152.57D27625CC@hg.openjdk.java.net> Changeset: fe56ba456fd3 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/fe56ba456fd3 Added tag jdk8-b116 for changeset 587560c222a2 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:32:02 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:32:02 +0000 Subject: hg: hsx/hotspot-main/jdk: 5 new changesets Message-ID: <20131114183353.51809625CD@hg.openjdk.java.net> Changeset: bdcba4854576 Author: erikj Date: 2013-11-07 10:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bdcba4854576 8027698: Platform specific jars are not being signed by the sign-jars target Reviewed-by: ihse, tbell, wetmore ! makefiles/SignJars.gmk Changeset: 295a641fc86b Author: erikj Date: 2013-11-07 14:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/295a641fc86b 8027406: JDK demos are missing source files Reviewed-by: alexsch, ihse ! makefiles/CompileDemos.gmk Changeset: 43168d403243 Author: anthony Date: 2013-11-08 20:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/43168d403243 8027912: [macosx] Provide means to force the headful mode on OS X when running via ssh Summary: Bypass AquaSession check if AWT_FORCE_HEADFUL env. variable is set to TRUE Reviewed-by: anthony, art Contributed-by: David Dehaven ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 0dc0067f3b8e Author: katleman Date: 2013-11-11 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0dc0067f3b8e Merge Changeset: 483148bf625e Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/483148bf625e Added tag jdk8-b116 for changeset 0dc0067f3b8e ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:34:52 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:34:52 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b116 for changeset 3c040b04af05 Message-ID: <20131114183501.E531D625CF@hg.openjdk.java.net> Changeset: 64d119680f0a Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/64d119680f0a Added tag jdk8-b116 for changeset 3c040b04af05 ! .hgtags From john.coomes at oracle.com Thu Nov 14 10:35:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 14 Nov 2013 18:35:08 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b116 for changeset 0fb1a427fbf6 Message-ID: <20131114183513.26D91625D0@hg.openjdk.java.net> Changeset: 774c63629870 Author: cl Date: 2013-11-14 09:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/774c63629870 Added tag jdk8-b116 for changeset 0fb1a427fbf6 ! .hgtags From markus.gronlund at oracle.com Thu Nov 14 10:53:44 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Thu, 14 Nov 2013 18:53:44 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131114185353.1988F625DE@hg.openjdk.java.net> Changeset: 9d8b29a0548c Author: mgerdin Date: 2013-11-08 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9d8b29a0548c 8027237: New tests on ReservedSpace/VirtualSpace classes Summary: Three tests added: 1) test stressing VirtualSpace by resizing it constantly 2) test running unit tests in several threads 3) test checking protected area in ReservedHeapSpace class Reviewed-by: stefank, zgu Contributed-by: aleksey.timofeev at oracle.com ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReadFromNoaccessArea.java + test/runtime/memory/RunUnitTestsConcurrently.java + test/runtime/memory/StressVirtualSpaceResize.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 19f8a5d7600b Author: mgerdin Date: 2013-11-08 23:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19f8a5d7600b Merge Changeset: fce21ac5968d Author: acorn Date: 2013-11-13 07:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fce21ac5968d 8027229: ICCE expected for >=2 maximally specific default methods. Summary: Need to process defaults for interfaces for invokespecial Reviewed-by: lfoltan, hseigel, coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 41cb10cbfb3c Author: coleenp Date: 2013-11-13 16:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41cb10cbfb3c 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field change Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. Reviewed-by: jrose, lfoltan, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp From vladimir.kozlov at oracle.com Thu Nov 14 12:07:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Nov 2013 12:07:52 -0800 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE64E28@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <5282EA9D.8060609@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64A58@DEWDFEMB12A.global.corp.sap> <5283DABE.6090503@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64E28@DEWDFEMB12A.global.corp.sap> Message-ID: <52852D98.80506@oracle.com> On 11/14/13 6:55 AM, Lindenmaier, Goetz wrote: > Hi, > > I renamed the enum MemOrd, almost as Vitaly proposed. > I also changed the order of arguments, and added default > argument for require_atomic_access. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-1-ldst/ This looks good. Is it final version which I can push (need to go throught JPRT)? Or you want to add code from your question below. > > I also found a way to work around on of the PPC64 defines. > For the others in inline_unsafe_fence I actually would like to have > some way to distinguish them in the matcher. Then I would not need > the defines here. > They also differ in their meaning from the other Acquire/Release > operations, as they all refer to a certain memory operation, but these do not. > I would propose to either introduce MemBarAcquire/ReleaseWide > or setting a flag in the node that indicates that the membar is > not intended for a certain memory operation. > What do you think? Add new one. We already did that for MemBarAcquire/ReleaseLock. It simplified matcher. Thanks, Vladimir > > Best regards, > Goetz. > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 13. November 2013 21:02 > To: Lindenmaier, Goetz > Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. > > On 11/13/13 9:13 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Too much changes due to explicit params which are not used on our >>> platforms. Can you leave current make_load()/store_to_memory() for >>> unordered case and add new make_load_ordered() and >>> store_to_memory_ordered() for which you pass all parameters (and they >>> call make_load()/store_to_memory()) ? >>> >>> Can you explain why?: >>> "Maintaining this change has shown very error prone if the defaults for >>> the new field are ::unordered." >>> Did you tried what I suggested above? >> What happened in our code is that you add a new call to the function, we >> integrate the change and it just compiles as the default argument is used. >> Thus we oversaw that we had to add 'release'. >> Also, I found errors where our 'release' was cast to Boolean and passed >> to the newly added argument 'require_atomic_access'. >> In all these cases you will get a compile time error without default parameters. >> Having extra functions causes similar problems. >> If I use default parameter 'release' and 'acquire', the generated code will >> be correct if the parameter is left out, but I have to pass the argument in >> the most places, anyways. > > Okay, can you swap it with require_atomic_access argument to keep it > with default value? > > Thanks, > Vladimir > >> >>> Changes to memory nodes (and LoadNode::make()/ StoreNode::make()) are >>> fine since we need to record ordering case and there is no other way. >>> And it is less cases than make_load()/store_to_memory(). >> Thanks! >> >>> Regarding David's concern about memory barriers I think changes are fine >>> because MemBar are preserved in IR graph. Some of them are different >>> kind but it is fine for C2 - it just needs some barriers to preserve >>> order of loads and stores. >> >>> As Vitaly I also don't know what is 'Sem'. Please, translate :) >> As Vitaly guessed, it's short for semantic. >> >> Best regards and thanks for the review! >> Goetz. >> >> Thanks, >> Vladimir >> >> On 11/12/13 8:30 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated this webrev to work with the latest version of the staging repository. >>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>> >>> Best regards, >>> Goetz. >>> >>> From: goetz.lindenmaier at sap.com >>> Sent: Freitag, 11. Oktober 2013 15:34 >>> To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov >>> Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. >>> >>> Hi, >>> >>> I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. >>> This is part of the PPC port. >>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>> >>> For a detailed description see the text in the webrev and bug description. >>> >>> All this basically does is add a field to load and store nodes and >>> change all constructor calls to set this field. So the effect on >>> existing platforms should be very small. Therefore I marked this >>> 'M', although quite some lines of code are touched. >>> >>> Please review and test this change. >>> I'm happy to incorporate your comments and any improvements >>> you propose. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> From goetz.lindenmaier at sap.com Thu Nov 14 12:12:18 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Nov 2013 20:12:18 +0000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <52852D98.80506@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <5282EA9D.8060609@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64A58@DEWDFEMB12A.global.corp.sap> <5283DABE.6090503@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64E28@DEWDFEMB12A.global.corp.sap> <52852D98.80506@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE65027@DEWDFEMB12A.global.corp.sap> What do you prefer? Two or one changes? I can take out the #defines in this one, and make a separate one for the new node. I think this are two different issues, so there should be two changes. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, November 14, 2013 9:08 PM To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. On 11/14/13 6:55 AM, Lindenmaier, Goetz wrote: > Hi, > > I renamed the enum MemOrd, almost as Vitaly proposed. > I also changed the order of arguments, and added default > argument for require_atomic_access. > http://cr.openjdk.java.net/~goetz/webrevs/8024921-1-ldst/ This looks good. Is it final version which I can push (need to go throught JPRT)? Or you want to add code from your question below. > > I also found a way to work around on of the PPC64 defines. > For the others in inline_unsafe_fence I actually would like to have > some way to distinguish them in the matcher. Then I would not need > the defines here. > They also differ in their meaning from the other Acquire/Release > operations, as they all refer to a certain memory operation, but these do not. > I would propose to either introduce MemBarAcquire/ReleaseWide > or setting a flag in the node that indicates that the membar is > not intended for a certain memory operation. > What do you think? Add new one. We already did that for MemBarAcquire/ReleaseLock. It simplified matcher. Thanks, Vladimir > > Best regards, > Goetz. > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 13. November 2013 21:02 > To: Lindenmaier, Goetz > Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. > > On 11/13/13 9:13 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Too much changes due to explicit params which are not used on our >>> platforms. Can you leave current make_load()/store_to_memory() for >>> unordered case and add new make_load_ordered() and >>> store_to_memory_ordered() for which you pass all parameters (and they >>> call make_load()/store_to_memory()) ? >>> >>> Can you explain why?: >>> "Maintaining this change has shown very error prone if the defaults for >>> the new field are ::unordered." >>> Did you tried what I suggested above? >> What happened in our code is that you add a new call to the function, we >> integrate the change and it just compiles as the default argument is used. >> Thus we oversaw that we had to add 'release'. >> Also, I found errors where our 'release' was cast to Boolean and passed >> to the newly added argument 'require_atomic_access'. >> In all these cases you will get a compile time error without default parameters. >> Having extra functions causes similar problems. >> If I use default parameter 'release' and 'acquire', the generated code will >> be correct if the parameter is left out, but I have to pass the argument in >> the most places, anyways. > > Okay, can you swap it with require_atomic_access argument to keep it > with default value? > > Thanks, > Vladimir > >> >>> Changes to memory nodes (and LoadNode::make()/ StoreNode::make()) are >>> fine since we need to record ordering case and there is no other way. >>> And it is less cases than make_load()/store_to_memory(). >> Thanks! >> >>> Regarding David's concern about memory barriers I think changes are fine >>> because MemBar are preserved in IR graph. Some of them are different >>> kind but it is fine for C2 - it just needs some barriers to preserve >>> order of loads and stores. >> >>> As Vitaly I also don't know what is 'Sem'. Please, translate :) >> As Vitaly guessed, it's short for semantic. >> >> Best regards and thanks for the review! >> Goetz. >> >> Thanks, >> Vladimir >> >> On 11/12/13 8:30 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I updated this webrev to work with the latest version of the staging repository. >>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>> >>> Best regards, >>> Goetz. >>> >>> From: goetz.lindenmaier at sap.com >>> Sent: Freitag, 11. Oktober 2013 15:34 >>> To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov >>> Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. >>> >>> Hi, >>> >>> I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. >>> This is part of the PPC port. >>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>> >>> For a detailed description see the text in the webrev and bug description. >>> >>> All this basically does is add a field to load and store nodes and >>> change all constructor calls to set this field. So the effect on >>> existing platforms should be very small. Therefore I marked this >>> 'M', although quite some lines of code are touched. >>> >>> Please review and test this change. >>> I'm happy to incorporate your comments and any improvements >>> you propose. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> From vladimir.kozlov at oracle.com Thu Nov 14 12:18:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Nov 2013 12:18:47 -0800 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE65027@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <5282EA9D.8060609@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64A58@DEWDFEMB12A.global.corp.sap> <5283DABE.6090503@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64E28@DEWDFEMB12A.global.corp.sap> <52852D98.80506@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE65027@DEWDFEMB12A.global.corp.sap> Message-ID: <52853027.8040607@oracle.com> On 11/14/13 12:12 PM, Lindenmaier, Goetz wrote: > What do you prefer? Two or one changes? Two different changes. > I can take out the #defines in this one, and make a separate one > for the new node. I think this are two different issues, so there > should be two changes. Can you leave current changes as they are and refactor code in second changes? We have free cycles in JPRT now so I want to push current version if it is okay with you. thanks, Vladimir > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, November 14, 2013 9:08 PM > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. > > On 11/14/13 6:55 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I renamed the enum MemOrd, almost as Vitaly proposed. >> I also changed the order of arguments, and added default >> argument for require_atomic_access. >> http://cr.openjdk.java.net/~goetz/webrevs/8024921-1-ldst/ > > This looks good. Is it final version which I can push (need to go > throught JPRT)? Or you want to add code from your question below. > >> >> I also found a way to work around on of the PPC64 defines. >> For the others in inline_unsafe_fence I actually would like to have >> some way to distinguish them in the matcher. Then I would not need >> the defines here. >> They also differ in their meaning from the other Acquire/Release >> operations, as they all refer to a certain memory operation, but these do not. >> I would propose to either introduce MemBarAcquire/ReleaseWide >> or setting a flag in the node that indicates that the membar is >> not intended for a certain memory operation. >> What do you think? > > Add new one. We already did that for MemBarAcquire/ReleaseLock. It > simplified matcher. > > Thanks, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Mittwoch, 13. November 2013 21:02 >> To: Lindenmaier, Goetz >> Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. >> >> On 11/13/13 9:13 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>>> Too much changes due to explicit params which are not used on our >>>> platforms. Can you leave current make_load()/store_to_memory() for >>>> unordered case and add new make_load_ordered() and >>>> store_to_memory_ordered() for which you pass all parameters (and they >>>> call make_load()/store_to_memory()) ? >>>> >>>> Can you explain why?: >>>> "Maintaining this change has shown very error prone if the defaults for >>>> the new field are ::unordered." >>>> Did you tried what I suggested above? >>> What happened in our code is that you add a new call to the function, we >>> integrate the change and it just compiles as the default argument is used. >>> Thus we oversaw that we had to add 'release'. >>> Also, I found errors where our 'release' was cast to Boolean and passed >>> to the newly added argument 'require_atomic_access'. >>> In all these cases you will get a compile time error without default parameters. >>> Having extra functions causes similar problems. >>> If I use default parameter 'release' and 'acquire', the generated code will >>> be correct if the parameter is left out, but I have to pass the argument in >>> the most places, anyways. >> >> Okay, can you swap it with require_atomic_access argument to keep it >> with default value? >> >> Thanks, >> Vladimir >> >>> >>>> Changes to memory nodes (and LoadNode::make()/ StoreNode::make()) are >>>> fine since we need to record ordering case and there is no other way. >>>> And it is less cases than make_load()/store_to_memory(). >>> Thanks! >>> >>>> Regarding David's concern about memory barriers I think changes are fine >>>> because MemBar are preserved in IR graph. Some of them are different >>>> kind but it is fine for C2 - it just needs some barriers to preserve >>>> order of loads and stores. >>> >>>> As Vitaly I also don't know what is 'Sem'. Please, translate :) >>> As Vitaly guessed, it's short for semantic. >>> >>> Best regards and thanks for the review! >>> Goetz. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/12/13 8:30 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I updated this webrev to work with the latest version of the staging repository. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> From: goetz.lindenmaier at sap.com >>>> Sent: Freitag, 11. Oktober 2013 15:34 >>>> To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Vladimir Kozlov >>>> Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. >>>> >>>> Hi, >>>> >>>> I prepared a webrev for 8024921Extend Load and Store nodes to know about memory ordering. >>>> This is part of the PPC port. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>>> >>>> For a detailed description see the text in the webrev and bug description. >>>> >>>> All this basically does is add a field to load and store nodes and >>>> change all constructor calls to set this field. So the effect on >>>> existing platforms should be very small. Therefore I marked this >>>> 'M', although quite some lines of code are touched. >>>> >>>> Please review and test this change. >>>> I'm happy to incorporate your comments and any improvements >>>> you propose. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> From joseph.provino at oracle.com Thu Nov 14 12:35:47 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 14 Nov 2013 15:35:47 -0500 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE Message-ID: <52853423.5050603@oracle.com> webrev is here: http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ thanks. joe From erik.helin at oracle.com Thu Nov 14 13:33:29 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 14 Nov 2013 21:33:29 +0000 Subject: hg: hsx/hotspot-main/hotspot: 14 new changesets Message-ID: <20131114213357.742E8625F8@hg.openjdk.java.net> Changeset: 4288e54fd145 Author: jwilhelm Date: 2013-10-21 18:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4288e54fd145 8026851: Remove unnecessary code in GenRemSet Summary: Removed the GenRemSet::rem_set_name() since we only have one remset. Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 3aee6bc29547 Author: jwilhelm Date: 2013-10-21 18:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3aee6bc29547 8026852: Use restricted_align_down in collector policy code Summary: Moved restricted_align_down to globalDefinitions and renamed it align_size_down_bounded Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 46d7652b223c Author: jwilhelm Date: 2013-10-21 18:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/46d7652b223c 8026853: Prepare GC code for collector policy regression fix Summary: Cleanup related to the NewSize and MaxNewSize bugs Reviewed-by: tschatzl, jcoomes, ehelin ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8f07aa079343 Author: jwilhelm Date: 2013-11-01 17:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f07aa079343 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking 7057939: jmap shows MaxNewSize=4GB when Java is using parallel collector Summary: Major cleanup of the collectorpolicy classes Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp + src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMaxNewSize.java Changeset: 610be0309a79 Author: amurillo Date: 2013-11-02 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/610be0309a79 Merge ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 28674af341ac Author: tschatzl Date: 2013-11-07 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/28674af341ac 8027756: assert(!hr->isHumongous()) failed: code root in humongous region? Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts. Reviewed-by: jmasa, tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestHumongousCodeCacheRoots.java Changeset: 40b8c6bad703 Author: jmasa Date: 2013-10-16 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/40b8c6bad703 8024954: CMS: CMSClassUnloadingMaxInterval is not implemented correctly. This change is also part of the fix for 8024483. Reviewed-by: mgerdin, brutisso, tschatzl Contributed-by: jwha at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 592d8b01fedd Author: jmasa Date: 2013-11-08 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/592d8b01fedd 8024483: assertion failure: (!mirror_alive || loader_alive) failed: Reviewed-by: brutisso, tschatzl, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 3ad2b68d107e Author: jwilhelm Date: 2013-11-10 00:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3ad2b68d107e 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java Summary: Update NewSize when _initial_gen0_size is changed Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp Changeset: 236cecd9ec97 Author: jwilhelm Date: 2013-11-11 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/236cecd9ec97 8028093: Initial young size is smaller than minimum young size Summary: Remove min_gen1_size argument from adjust_gen0_sizes() Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: bde526e3667e Author: jwilhelm Date: 2013-11-11 05:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bde526e3667e Merge Changeset: 11b116661830 Author: mgerdin Date: 2013-11-11 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11b116661830 Merge ! src/share/vm/memory/metaspace.cpp Changeset: ee527493b36d Author: sjohanss Date: 2013-11-08 17:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ee527493b36d 8027960: Assertion assert(end >= start) failed during nightly testing on solaris Summary: Needed to update _space_alignment in generation sizer to ensure correct sizing of spaces. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp Changeset: 755c423791ab Author: ehelin Date: 2013-11-14 21:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/755c423791ab Merge ! src/share/vm/prims/whitebox.cpp From goetz.lindenmaier at sap.com Thu Nov 14 14:04:24 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Nov 2013 22:04:24 +0000 Subject: RFR (S): 8028401: PPC (part 117): Improve usability of adlc and format() functionality. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6513E@DEWDFEMB12A.global.corp.sap> Hi, This change contains some smaller additions to adlc and the format() routine, that improve their usability: http://cr.openjdk.java.net/~goetz/webrevs/8028401-0-adlc/ Improve usability of adlc: So far, expands can only use instructs that are specified further up in the .ad file. This is because the check whether nodes used in the expand are also defined is done during parsing. Move this check to a later point to relax ordering constraints. Add a row of additional, more verbose syntax checks. Improve format(): If MachNode::format() is called before constants are written to the constants section, it can fail. Add a safer version of constant_offset to avoid this. Please review and test this change. Best regards, Goetz. From alejandro.murillo at oracle.com Thu Nov 14 15:51:47 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 14 Nov 2013 16:51:47 -0700 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <52856213.1010802@oracle.com> vote: yes -- Alejandro From vladimir.kozlov at oracle.com Thu Nov 14 17:52:26 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 15 Nov 2013 01:52:26 +0000 Subject: hg: hsx/jdk7u/hotspot: 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Message-ID: <20131115015233.32F6E62600@hg.openjdk.java.net> Changeset: ecd0bdbc9635 Author: kvn Date: 2013-11-11 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ecd0bdbc9635 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Summary: Exclude last input argument's stack slots from vector's spilling masks. Reviewed-by: iveresov ! src/share/vm/opto/matcher.cpp From vladimir.kozlov at oracle.com Thu Nov 14 19:15:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Nov 2013 19:15:39 -0800 Subject: RFR (S): 8028401: PPC (part 117): Improve usability of adlc and format() functionality. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6513E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6513E@DEWDFEMB12A.global.corp.sap> Message-ID: <528591DB.80003@oracle.com> Do we really need 2 version of constant_offset_unchecked()? It is used only in format() const. Vladimir On 11/14/13 2:04 PM, Lindenmaier, Goetz wrote: > Hi, > > This change contains some smaller additions to adlc and the format() routine, > that improve their usability: > http://cr.openjdk.java.net/~goetz/webrevs/8028401-0-adlc/ > > Improve usability of adlc: > So far, expands can only use instructs that are specified further up in the .ad file. > This is because the check whether nodes used in the expand are also defined > is done during parsing. > Move this check to a later point to relax ordering constraints. > > Add a row of additional, more verbose syntax checks. > > Improve format(): > If MachNode::format() is called before constants are written to the > constants section, it can fail. Add a safer version of constant_offset > to avoid this. > > Please review and test this change. > > Best regards, > Goetz. > From david.holmes at oracle.com Thu Nov 14 20:45:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Nov 2013 14:45:33 +1000 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE In-Reply-To: <52853423.5050603@oracle.com> References: <52853423.5050603@oracle.com> Message-ID: <5285A6ED.3000807@oracle.com> Hi Joe, On 15/11/2013 6:35 AM, Joseph Provino wrote: > > webrev is here: > > http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ > As per other email I think the more appropriate fix here is to guard the callsite in MetadataOnStackMark as JVMTI_ONLY: JVMTI_ONLY(JvmtiCurrentBreakpoints::metadata_do(Metadata::mark_on_stack)); Any code that uses an optional facility, like JVMTI or other GC or tracing etc, has to guard that use. It would probably be better if there was also guards in the jvmtiImpl.hpp file so that this issue would have been detected at build time. I know this isn't necessarily trivial because we have to retain sufficient parts of JVMTI to provide the base API that can report that JVMTI functionality is not available - but I don't think JvmtiCurrentBreakPoints falls into that category. Thanks, David > thanks. > > joe From igor.veresov at oracle.com Thu Nov 14 20:57:31 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Fri, 15 Nov 2013 04:57:31 +0000 Subject: hg: hsx/jdk7u/hotspot: 4 new changesets Message-ID: <20131115045740.43C4862603@hg.openjdk.java.net> Changeset: 9d2ec5befb5c Author: iveresov Date: 2013-10-31 04:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/9d2ec5befb5c 8027997: G1: SPECjbb2013 crashes due to a broken object reference Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: f35a0cfb0f5d Author: iveresov Date: 2013-11-05 00:59 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/f35a0cfb0f5d 8027839: C1 crashes in Weblogic with G1 enabled Summary: Keep T_OBJECT operands in registers for logical operations on x64 Reviewed-by: kvn, roland ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 2a667d6ef59e Author: iveresov Date: 2013-11-05 01:57 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2a667d6ef59e 8027840: C2 allows safepoint checks to leak into G1 pre-barriers Summary: Make all raw loads strictly respect control dependencies, make sure RCE doesn't move raw loads, add verification of G1 pre-barriers. Reviewed-by: kvn, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.hpp Changeset: 90cfd4ad3c92 Author: iveresov Date: 2013-11-14 17:59 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/90cfd4ad3c92 Merge From david.r.chase at oracle.com Thu Nov 14 21:59:41 2013 From: david.r.chase at oracle.com (david.r.chase at oracle.com) Date: Fri, 15 Nov 2013 05:59:41 +0000 Subject: hg: hsx/hotspot-main/hotspot: 13 new changesets Message-ID: <20131115060013.1DA7862608@hg.openjdk.java.net> Changeset: e2509677809c Author: vlivanov Date: 2013-11-08 01:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e2509677809c 8023037: Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp Changeset: 83c8f6f4ab09 Author: drchase Date: 2013-11-08 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/83c8f6f4ab09 Merge Changeset: 1dcea64e9f00 Author: kvn Date: 2013-11-11 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1dcea64e9f00 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Summary: Exclude last input argument's stack slots from vector's spilling masks. Reviewed-by: iveresov ! src/share/vm/opto/matcher.cpp Changeset: 78da3894b86f Author: anoll Date: 2013-11-12 09:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/78da3894b86f 8027593: performance drop with constrained codecache starting with hs25 b111 Summary: Fixed proper sweeping of small code cache sizes Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: 144b23411b51 Author: roland Date: 2013-11-12 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/144b23411b51 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp Summary: receiver type collected by profiling for default method may be interface Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f675976a61e7 Author: rbackman Date: 2013-11-12 13:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f675976a61e7 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post Reviewed-by: iveresov, kvn ! src/share/vm/opto/loopopts.cpp + test/compiler/intrinsics/mathexact/SplitThruPhiTest.java Changeset: b957c650babb Author: rbackman Date: 2013-11-12 14:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b957c650babb 8028207: assert(_outcnt==1) failed: not unique in compile.cpp Reviewed-by: iveresov, kvn ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/GVNTest.java Changeset: e6ba215af802 Author: roland Date: 2013-11-13 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e6ba215af802 8027631: "unexpected profiling mismatch" error with new type profiling Summary: inlined method handle calls can call methods with different signatures Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp + test/compiler/profiling/TestUnexpectedProfilingMismatch.java Changeset: 924c32982a12 Author: roland Date: 2013-11-13 01:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/924c32982a12 Merge Changeset: 6e1826d5c23e Author: roland Date: 2013-11-13 13:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6e1826d5c23e 8027572: assert(r != 0) failed: invalid Summary: null classes should be expected in profiles with conflicts Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp + test/compiler/profiling/unloadingconflict/B.java + test/compiler/profiling/unloadingconflict/TestProfileConflictClassUnloading.java Changeset: e74074c34312 Author: vlivanov Date: 2013-11-14 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e74074c34312 8028159: C2: compiler stack overflow during inlining of @ForceInline methods Reviewed-by: roland, kvn ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: df0df745224c Author: drchase Date: 2013-11-14 15:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df0df745224c Merge Changeset: 6f206b5d258f Author: drchase Date: 2013-11-14 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6f206b5d258f Merge ! src/share/vm/runtime/arguments.cpp From goetz.lindenmaier at sap.com Fri Nov 15 01:38:48 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Nov 2013 09:38:48 +0000 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <528593D0.2010806@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <5282EA9D.8060609@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64A58@DEWDFEMB12A.global.corp.sap> <5283DABE.6090503@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64E28@DEWDFEMB12A.global.corp.sap> <52852D98.80506@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE65027@DEWDFEMB12A.global.corp.sap> <52853027.8040607@oracle.com> <528530D8.2060800@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE65109@DEWDFEMB12A.global.corp.sap> <528593D0.2010806@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE65371@DEWDFEMB12A.global.corp.sap> Hi Vladimir, sorry for that, but that's some code not included in the builds I do. It's guarded by TRACE_HAVE_INTRINSICS, and there is no switch to turn that on in the makefiles. If I force it on, I get lots of other errors: vm/c1/c1_GraphBuilder.cpp: In member function 'bool GraphBuilder::try_inline_intrinsics(ciMethod*)': vm/c1/c1_GraphBuilder.cpp:3363: error: '_classID' is not a member of 'vmIntrinsics' vm/c1/c1_GraphBuilder.cpp:3364: error: '_threadID' is not a member of 'vmIntrinsics' vm/c1/c1_GraphBuilder.cpp:3369: error: '_counterTime' is not a member of 'vmIntrinsics' vm/c1/c1_LIRGenerator.cpp: In member function 'virtual void LIRGenerator::do_Intrinsic(Intrinsic*)': vm/c1/c1_LIRGenerator.cpp:3049: error: '_threadID' is not a member of 'vmIntrinsics' vm/c1/c1_LIRGenerator.cpp:3050: error: '_classID' is not a member of 'vmIntrinsics' vm/c1/c1_LIRGenerator.cpp:3051: error: '_counterTime' is not a member of 'vmIntrinsics' vm/c1/c1_LIRGenerator.cpp:3052: error: 'TRACE_TIME_METHOD' was not declared in this scope I would need access to your closed sources and JPRT to fully test this, I guess. I checked all the calls once more, but I can not test it, so I can not assure I got all. I updated the webrev http://cr.openjdk.java.net/~goetz/webrevs/8024921-2-ldst/ Best regards and thanks for pushing 115, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 15. November 2013 04:24 To: Lindenmaier, Goetz Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. Goetz, I have build problem in library_call.cpp. Looks like you missed several make_load(), store_to_memory() calls: src/share/vm/opto/library_call.cpp: In member function 'bool LibraryCallKit::inline_native_classID()': src/share/vm/opto/library_call.cpp:3180: error: no matching function for call to 'LibraryCallKit::make_load(NULL, Node*&, const TypeLong*&, BasicType)' src/share/vm/opto/library_call.cpp:3187: error: no matching function for call to 'LibraryCallKit::store_to_memory(Node*, Node*&, Node*&, BasicType, const TypePtr*&)' and several other places. Vladimir On 11/14/13 1:21 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > The defines are in > library_call.cpp:3117, in inline_unsafe_allocate(). > > here goes the webrev without the changes in inline_unsafe_allocate: > http://cr.openjdk.java.net/~goetz/webrevs/8024921-2-ldst/ > > And here a first draft for MemBarAcquire/ReleaseWide: > http://cr.openjdk.java.net/~goetz/webrevs/MemBarWide/ > But I definitely still need to test this, I'll add it into our VM > to get the full tests before calling for a real review. > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, November 14, 2013 9:22 PM > To: Lindenmaier, Goetz > Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. > > Actually what defines you are talking about? I don't see them in these > changes. > > Vladimir > > On 11/14/13 12:18 PM, Vladimir Kozlov wrote: >> On 11/14/13 12:12 PM, Lindenmaier, Goetz wrote: >>> What do you prefer? Two or one changes? >> >> Two different changes. >> >>> I can take out the #defines in this one, and make a separate one >>> for the new node. I think this are two different issues, so there >>> should be two changes. >> >> Can you leave current changes as they are and refactor code in second >> changes? We have free cycles in JPRT now so I want to push current >> version if it is okay with you. >> >> thanks, >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, November 14, 2013 9:08 PM >>> To: Lindenmaier, Goetz >>> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >>> nodes to know about memory ordering. >>> >>> On 11/14/13 6:55 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I renamed the enum MemOrd, almost as Vitaly proposed. >>>> I also changed the order of arguments, and added default >>>> argument for require_atomic_access. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-1-ldst/ >>> >>> This looks good. Is it final version which I can push (need to go >>> throught JPRT)? Or you want to add code from your question below. >>> >>>> >>>> I also found a way to work around on of the PPC64 defines. >>>> For the others in inline_unsafe_fence I actually would like to have >>>> some way to distinguish them in the matcher. Then I would not need >>>> the defines here. >>>> They also differ in their meaning from the other Acquire/Release >>>> operations, as they all refer to a certain memory operation, but >>>> these do not. >>>> I would propose to either introduce MemBarAcquire/ReleaseWide >>>> or setting a flag in the node that indicates that the membar is >>>> not intended for a certain memory operation. >>>> What do you think? >>> >>> Add new one. We already did that for MemBarAcquire/ReleaseLock. It >>> simplified matcher. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Mittwoch, 13. November 2013 21:02 >>>> To: Lindenmaier, Goetz >>>> Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >>>> nodes to know about memory ordering. >>>> >>>> On 11/13/13 9:13 AM, Lindenmaier, Goetz wrote: >>>>> Hi Vladimir, >>>>> >>>>>> Too much changes due to explicit params which are not used on our >>>>>> platforms. Can you leave current make_load()/store_to_memory() for >>>>>> unordered case and add new make_load_ordered() and >>>>>> store_to_memory_ordered() for which you pass all parameters (and they >>>>>> call make_load()/store_to_memory()) ? >>>>>> >>>>>> Can you explain why?: >>>>>> "Maintaining this change has shown very error prone if the defaults >>>>>> for >>>>>> the new field are ::unordered." >>>>>> Did you tried what I suggested above? >>>>> What happened in our code is that you add a new call to the >>>>> function, we >>>>> integrate the change and it just compiles as the default argument is >>>>> used. >>>>> Thus we oversaw that we had to add 'release'. >>>>> Also, I found errors where our 'release' was cast to Boolean and passed >>>>> to the newly added argument 'require_atomic_access'. >>>>> In all these cases you will get a compile time error without default >>>>> parameters. >>>>> Having extra functions causes similar problems. >>>>> If I use default parameter 'release' and 'acquire', the generated >>>>> code will >>>>> be correct if the parameter is left out, but I have to pass the >>>>> argument in >>>>> the most places, anyways. >>>> >>>> Okay, can you swap it with require_atomic_access argument to keep it >>>> with default value? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>>> Changes to memory nodes (and LoadNode::make()/ StoreNode::make()) are >>>>>> fine since we need to record ordering case and there is no other way. >>>>>> And it is less cases than make_load()/store_to_memory(). >>>>> Thanks! >>>>> >>>>>> Regarding David's concern about memory barriers I think changes are >>>>>> fine >>>>>> because MemBar are preserved in IR graph. Some of them are different >>>>>> kind but it is fine for C2 - it just needs some barriers to preserve >>>>>> order of loads and stores. >>>>> >>>>>> As Vitaly I also don't know what is 'Sem'. Please, translate :) >>>>> As Vitaly guessed, it's short for semantic. >>>>> >>>>> Best regards and thanks for the review! >>>>> Goetz. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/12/13 8:30 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I updated this webrev to work with the latest version of the >>>>>> staging repository. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> From: goetz.lindenmaier at sap.com >>>>>> Sent: Freitag, 11. Oktober 2013 15:34 >>>>>> To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; >>>>>> Vladimir Kozlov >>>>>> Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >>>>>> nodes to know about memory ordering. >>>>>> >>>>>> Hi, >>>>>> >>>>>> I prepared a webrev for >>>>>> 8024921Extend >>>>>> Load and Store nodes to know about memory ordering. >>>>>> This is part of the PPC port. >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>>>>> >>>>>> For a detailed description see the text in the webrev and bug >>>>>> description. >>>>>> >>>>>> All this basically does is add a field to load and store nodes and >>>>>> change all constructor calls to set this field. So the effect on >>>>>> existing platforms should be very small. Therefore I marked this >>>>>> 'M', although quite some lines of code are touched. >>>>>> >>>>>> Please review and test this change. >>>>>> I'm happy to incorporate your comments and any improvements >>>>>> you propose. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> From goetz.lindenmaier at sap.com Fri Nov 15 01:58:50 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Nov 2013 09:58:50 +0000 Subject: RFR (S): 8028401: PPC (part 117): Improve usability of adlc and format() functionality. In-Reply-To: <528591DB.80003@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6513E@DEWDFEMB12A.global.corp.sap> <528591DB.80003@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE653F1@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I removed the version without const. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Freitag, 15. November 2013 04:16 To: hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8028401: PPC (part 117): Improve usability of adlc and format() functionality. Do we really need 2 version of constant_offset_unchecked()? It is used only in format() const. Vladimir On 11/14/13 2:04 PM, Lindenmaier, Goetz wrote: > Hi, > > This change contains some smaller additions to adlc and the format() routine, > that improve their usability: > http://cr.openjdk.java.net/~goetz/webrevs/8028401-0-adlc/ > > Improve usability of adlc: > So far, expands can only use instructs that are specified further up in the .ad file. > This is because the check whether nodes used in the expand are also defined > is done during parsing. > Move this check to a later point to relax ordering constraints. > > Add a row of additional, more verbose syntax checks. > > Improve format(): > If MachNode::format() is called before constants are written to the > constants section, it can fail. Add a safer version of constant_offset > to avoid this. > > Please review and test this change. > > Best regards, > Goetz. > From coleen.phillimore at oracle.com Fri Nov 15 08:56:59 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Nov 2013 11:56:59 -0500 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE In-Reply-To: <5285A6ED.3000807@oracle.com> References: <52853423.5050603@oracle.com> <5285A6ED.3000807@oracle.com> Message-ID: <5286525B.4030705@oracle.com> Joe, I don't mind whichever way you fix it but there's another similar instance coming in bug, that you might want to wait for. RFR: 8027630 SIGSEGV in const char*Klass::external_name() http://cr.openjdk.java.net/~sla/8027630/webrev.00/ Coleen On 11/14/2013 11:45 PM, David Holmes wrote: > Hi Joe, > > On 15/11/2013 6:35 AM, Joseph Provino wrote: >> >> webrev is here: >> >> http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ >> > > As per other email I think the more appropriate fix here is to guard > the callsite in MetadataOnStackMark as JVMTI_ONLY: > > JVMTI_ONLY(JvmtiCurrentBreakpoints::metadata_do(Metadata::mark_on_stack)); > > > Any code that uses an optional facility, like JVMTI or other GC or > tracing etc, has to guard that use. It would probably be better if > there was also guards in the jvmtiImpl.hpp file so that this issue > would have been detected at build time. I know this isn't necessarily > trivial because we have to retain sufficient parts of JVMTI to provide > the base API that can report that JVMTI functionality is not available > - but I don't think JvmtiCurrentBreakPoints falls into that category. > > Thanks, > David > >> thanks. >> >> joe From joseph.provino at oracle.com Fri Nov 15 09:11:30 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 15 Nov 2013 12:11:30 -0500 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE In-Reply-To: <5286525B.4030705@oracle.com> References: <52853423.5050603@oracle.com> <5285A6ED.3000807@oracle.com> <5286525B.4030705@oracle.com> Message-ID: <528655C2.2000008@oracle.com> On 11/15/2013 11:56 AM, Coleen Phillimore wrote: > > Joe, > > I don't mind whichever way you fix Coleen, I'm happy to fix it whichever way is determined to be best. > it but there's another similar instance coming in bug, that you might > want to wait for. > > RFR: 8027630 SIGSEGV in const char*Klass::external_name() > http://cr.openjdk.java.net/~sla/8027630/webrev.00/ > I don't mind waiting but does this change need a "guard". It's in threadServices.* which is always included (I think). joe > > Coleen > > On 11/14/2013 11:45 PM, David Holmes wrote: >> Hi Joe, >> >> On 15/11/2013 6:35 AM, Joseph Provino wrote: >>> >>> webrev is here: >>> >>> http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ >>> >> >> As per other email I think the more appropriate fix here is to guard >> the callsite in MetadataOnStackMark as JVMTI_ONLY: >> >> JVMTI_ONLY(JvmtiCurrentBreakpoints::metadata_do(Metadata::mark_on_stack)); >> >> >> Any code that uses an optional facility, like JVMTI or other GC or >> tracing etc, has to guard that use. It would probably be better if >> there was also guards in the jvmtiImpl.hpp file so that this issue >> would have been detected at build time. I know this isn't necessarily >> trivial because we have to retain sufficient parts of JVMTI to >> provide the base API that can report that JVMTI functionality is not >> available - but I don't think JvmtiCurrentBreakPoints falls into that >> category. >> >> Thanks, >> David >> >>> thanks. >>> >>> joe > From serguei.spitsyn at oracle.com Fri Nov 15 09:42:03 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 15 Nov 2013 09:42:03 -0800 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE In-Reply-To: <52853423.5050603@oracle.com> References: <52853423.5050603@oracle.com> Message-ID: <52865CEB.9070805@oracle.com> Joe, The fix looks good. Thanks, Serguei On 11/14/13 12:35 PM, Joseph Provino wrote: > > webrev is here: > > http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ > > > thanks. > > joe From david.holmes at oracle.com Fri Nov 15 09:55:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Nov 2013 03:55:53 +1000 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE In-Reply-To: <528655C2.2000008@oracle.com> References: <52853423.5050603@oracle.com> <5285A6ED.3000807@oracle.com> <5286525B.4030705@oracle.com> <528655C2.2000008@oracle.com> Message-ID: <52866029.1050402@oracle.com> Hi Joe, On 16/11/2013 3:11 AM, Joseph Provino wrote: > > On 11/15/2013 11:56 AM, Coleen Phillimore wrote: >> >> Joe, >> >> I don't mind whichever way you fix > > Coleen, I'm happy to fix it whichever way is determined to be best. Given this has to get special approval at this stage lets go with your JVMTI_RETURN proposal. We can look at how to make this generally more robust for 8u or 9. Thanks, David >> it but there's another similar instance coming in bug, that you might >> want to wait for. >> >> RFR: 8027630 SIGSEGV in const char*Klass::external_name() >> http://cr.openjdk.java.net/~sla/8027630/webrev.00/ >> > > I don't mind waiting but does this change need a "guard". It's in > threadServices.* which is always included (I think). > > joe > >> >> Coleen >> >> On 11/14/2013 11:45 PM, David Holmes wrote: >>> Hi Joe, >>> >>> On 15/11/2013 6:35 AM, Joseph Provino wrote: >>>> >>>> webrev is here: >>>> >>>> http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ >>>> >>> >>> As per other email I think the more appropriate fix here is to guard >>> the callsite in MetadataOnStackMark as JVMTI_ONLY: >>> >>> JVMTI_ONLY(JvmtiCurrentBreakpoints::metadata_do(Metadata::mark_on_stack)); >>> >>> >>> Any code that uses an optional facility, like JVMTI or other GC or >>> tracing etc, has to guard that use. It would probably be better if >>> there was also guards in the jvmtiImpl.hpp file so that this issue >>> would have been detected at build time. I know this isn't necessarily >>> trivial because we have to retain sufficient parts of JVMTI to >>> provide the base API that can report that JVMTI functionality is not >>> available - but I don't think JvmtiCurrentBreakPoints falls into that >>> category. >>> >>> Thanks, >>> David >>> >>>> thanks. >>>> >>>> joe >> > From coleen.phillimore at oracle.com Fri Nov 15 10:14:15 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Nov 2013 13:14:15 -0500 Subject: Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE In-Reply-To: <52866029.1050402@oracle.com> References: <52853423.5050603@oracle.com> <5285A6ED.3000807@oracle.com> <5286525B.4030705@oracle.com> <528655C2.2000008@oracle.com> <52866029.1050402@oracle.com> Message-ID: <52866477.30408@oracle.com> On 11/15/2013 12:55 PM, David Holmes wrote: > Hi Joe, > > On 16/11/2013 3:11 AM, Joseph Provino wrote: >> >> On 11/15/2013 11:56 AM, Coleen Phillimore wrote: >>> >>> Joe, >>> >>> I don't mind whichever way you fix >> >> Coleen, I'm happy to fix it whichever way is determined to be best. > > Given this has to get special approval at this stage lets go with your > JVMTI_RETURN proposal. We can look at how to make this generally more > robust for 8u or 9. This is fine, I reviewed it too. Coleen > > Thanks, > David > >>> it but there's another similar instance coming in bug, that you might >>> want to wait for. >>> >>> RFR: 8027630 SIGSEGV in const char*Klass::external_name() >>> http://cr.openjdk.java.net/~sla/8027630/webrev.00/ >>> >> >> I don't mind waiting but does this change need a "guard". It's in >> threadServices.* which is always included (I think). >> >> joe >> >>> >>> Coleen >>> >>> On 11/14/2013 11:45 PM, David Holmes wrote: >>>> Hi Joe, >>>> >>>> On 15/11/2013 6:35 AM, Joseph Provino wrote: >>>>> >>>>> webrev is here: >>>>> >>>>> http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/ >>>>> >>>> >>>> As per other email I think the more appropriate fix here is to guard >>>> the callsite in MetadataOnStackMark as JVMTI_ONLY: >>>> >>>> JVMTI_ONLY(JvmtiCurrentBreakpoints::metadata_do(Metadata::mark_on_stack)); >>>> >>>> >>>> >>>> Any code that uses an optional facility, like JVMTI or other GC or >>>> tracing etc, has to guard that use. It would probably be better if >>>> there was also guards in the jvmtiImpl.hpp file so that this issue >>>> would have been detected at build time. I know this isn't necessarily >>>> trivial because we have to retain sufficient parts of JVMTI to >>>> provide the base API that can report that JVMTI functionality is not >>>> available - but I don't think JvmtiCurrentBreakPoints falls into that >>>> category. >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks. >>>>> >>>>> joe >>> >> From alejandro.murillo at oracle.com Fri Nov 15 10:49:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Nov 2013 18:49:36 +0000 Subject: hg: hsx/hsx25/hotspot: 35 new changesets Message-ID: <20131115185051.5A19162620@hg.openjdk.java.net> Changeset: aec3226be72d Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aec3226be72d Added tag jdk8-b116 for changeset 52b076e6ffae ! .hgtags Changeset: 20c72bec2707 Author: amurillo Date: 2013-11-08 07:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/20c72bec2707 8028061: new hotspot build - hs25-b59 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9d8b29a0548c Author: mgerdin Date: 2013-11-08 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9d8b29a0548c 8027237: New tests on ReservedSpace/VirtualSpace classes Summary: Three tests added: 1) test stressing VirtualSpace by resizing it constantly 2) test running unit tests in several threads 3) test checking protected area in ReservedHeapSpace class Reviewed-by: stefank, zgu Contributed-by: aleksey.timofeev at oracle.com ! src/share/vm/prims/whitebox.cpp + test/runtime/memory/ReadFromNoaccessArea.java + test/runtime/memory/RunUnitTestsConcurrently.java + test/runtime/memory/StressVirtualSpaceResize.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 19f8a5d7600b Author: mgerdin Date: 2013-11-08 23:49 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/19f8a5d7600b Merge Changeset: fce21ac5968d Author: acorn Date: 2013-11-13 07:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fce21ac5968d 8027229: ICCE expected for >=2 maximally specific default methods. Summary: Need to process defaults for interfaces for invokespecial Reviewed-by: lfoltan, hseigel, coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: 41cb10cbfb3c Author: coleenp Date: 2013-11-13 16:42 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/41cb10cbfb3c 8025937: assert(existing_f1 == NULL || existing_f1 == f1) failed: illegal field change Summary: Create extra constant pool cache entries for invokespecial/InterfaceMethodref to hold the alternate resolution. Reviewed-by: jrose, lfoltan, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: 4288e54fd145 Author: jwilhelm Date: 2013-10-21 18:51 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4288e54fd145 8026851: Remove unnecessary code in GenRemSet Summary: Removed the GenRemSet::rem_set_name() since we only have one remset. Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 3aee6bc29547 Author: jwilhelm Date: 2013-10-21 18:52 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3aee6bc29547 8026852: Use restricted_align_down in collector policy code Summary: Moved restricted_align_down to globalDefinitions and renamed it align_size_down_bounded Reviewed-by: stefank, mgerdin, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 46d7652b223c Author: jwilhelm Date: 2013-10-21 18:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/46d7652b223c 8026853: Prepare GC code for collector policy regression fix Summary: Cleanup related to the NewSize and MaxNewSize bugs Reviewed-by: tschatzl, jcoomes, ehelin ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 8f07aa079343 Author: jwilhelm Date: 2013-11-01 17:09 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8f07aa079343 8016309: assert(eden_size > 0 && survivor_size > 0) failed: just checking 7057939: jmap shows MaxNewSize=4GB when Java is using parallel collector Summary: Major cleanup of the collectorpolicy classes Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp + src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! test/gc/arguments/TestMaxHeapSizeTools.java + test/gc/arguments/TestMaxNewSize.java Changeset: 610be0309a79 Author: amurillo Date: 2013-11-02 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/610be0309a79 Merge ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 28674af341ac Author: tschatzl Date: 2013-11-07 15:17 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/28674af341ac 8027756: assert(!hr->isHumongous()) failed: code root in humongous region? Summary: Change checks for isHumongous() to continuesHumongous() as installing a code root for a humongous object is valid, but not for continuations of humongous objects. Cleaned up asserts. Reviewed-by: jmasa, tamao ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp + test/gc/g1/TestHumongousCodeCacheRoots.java Changeset: 40b8c6bad703 Author: jmasa Date: 2013-10-16 15:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/40b8c6bad703 8024954: CMS: CMSClassUnloadingMaxInterval is not implemented correctly. This change is also part of the fix for 8024483. Reviewed-by: mgerdin, brutisso, tschatzl Contributed-by: jwha at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 592d8b01fedd Author: jmasa Date: 2013-11-08 06:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/592d8b01fedd 8024483: assertion failure: (!mirror_alive || loader_alive) failed: Reviewed-by: brutisso, tschatzl, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 3ad2b68d107e Author: jwilhelm Date: 2013-11-10 00:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3ad2b68d107e 8027911: Assertion in the collector policy when running gc/arguments/TestMaxNewSize.java Summary: Update NewSize when _initial_gen0_size is changed Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp Changeset: 236cecd9ec97 Author: jwilhelm Date: 2013-11-11 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/236cecd9ec97 8028093: Initial young size is smaller than minimum young size Summary: Remove min_gen1_size argument from adjust_gen0_sizes() Reviewed-by: tschatzl, brutisso ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: bde526e3667e Author: jwilhelm Date: 2013-11-11 05:05 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bde526e3667e Merge Changeset: 11b116661830 Author: mgerdin Date: 2013-11-11 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/11b116661830 Merge ! src/share/vm/memory/metaspace.cpp Changeset: ee527493b36d Author: sjohanss Date: 2013-11-08 17:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ee527493b36d 8027960: Assertion assert(end >= start) failed during nightly testing on solaris Summary: Needed to update _space_alignment in generation sizer to ensure correct sizing of spaces. Reviewed-by: jmasa, tschatzl ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp Changeset: 755c423791ab Author: ehelin Date: 2013-11-14 21:05 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/755c423791ab Merge ! src/share/vm/prims/whitebox.cpp Changeset: e2509677809c Author: vlivanov Date: 2013-11-08 01:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e2509677809c 8023037: Race between ciEnv::register_method and nmethod::make_not_entrant_or_zombie Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/globals.hpp Changeset: 83c8f6f4ab09 Author: drchase Date: 2013-11-08 14:19 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/83c8f6f4ab09 Merge Changeset: 1dcea64e9f00 Author: kvn Date: 2013-11-11 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1dcea64e9f00 8024830: SEGV in org.apache.lucene.codecs.compressing.CompressingTermVectorsReader.get Summary: Exclude last input argument's stack slots from vector's spilling masks. Reviewed-by: iveresov ! src/share/vm/opto/matcher.cpp Changeset: 78da3894b86f Author: anoll Date: 2013-11-12 09:32 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/78da3894b86f 8027593: performance drop with constrained codecache starting with hs25 b111 Summary: Fixed proper sweeping of small code cache sizes Reviewed-by: kvn, iveresov ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: 144b23411b51 Author: roland Date: 2013-11-12 13:58 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/144b23411b51 8027632: assert(xtype->klass_is_exact()) failed: Should be exact at graphKit.cpp Summary: receiver type collected by profiling for default method may be interface Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f675976a61e7 Author: rbackman Date: 2013-11-12 13:47 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f675976a61e7 8028198: SIGSEGV in PhaseIdealLoop::build_loop_late_post Reviewed-by: iveresov, kvn ! src/share/vm/opto/loopopts.cpp + test/compiler/intrinsics/mathexact/SplitThruPhiTest.java Changeset: b957c650babb Author: rbackman Date: 2013-11-12 14:52 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b957c650babb 8028207: assert(_outcnt==1) failed: not unique in compile.cpp Reviewed-by: iveresov, kvn ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/GVNTest.java Changeset: e6ba215af802 Author: roland Date: 2013-11-13 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e6ba215af802 8027631: "unexpected profiling mismatch" error with new type profiling Summary: inlined method handle calls can call methods with different signatures Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp + test/compiler/profiling/TestUnexpectedProfilingMismatch.java Changeset: 924c32982a12 Author: roland Date: 2013-11-13 01:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/924c32982a12 Merge Changeset: 6e1826d5c23e Author: roland Date: 2013-11-13 13:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6e1826d5c23e 8027572: assert(r != 0) failed: invalid Summary: null classes should be expected in profiles with conflicts Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp + test/compiler/profiling/unloadingconflict/B.java + test/compiler/profiling/unloadingconflict/TestProfileConflictClassUnloading.java Changeset: e74074c34312 Author: vlivanov Date: 2013-11-14 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e74074c34312 8028159: C2: compiler stack overflow during inlining of @ForceInline methods Reviewed-by: roland, kvn ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/runtime/globals.hpp Changeset: df0df745224c Author: drchase Date: 2013-11-14 15:58 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df0df745224c Merge Changeset: 6f206b5d258f Author: drchase Date: 2013-11-14 13:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6f206b5d258f Merge ! src/share/vm/runtime/arguments.cpp Changeset: c78d517c7ea4 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c78d517c7ea4 Merge Changeset: f573d00213b7 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f573d00213b7 Added tag hs25-b59 for changeset c78d517c7ea4 ! .hgtags From vladimir.kozlov at oracle.com Fri Nov 15 11:40:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Nov 2013 11:40:35 -0800 Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE65371@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE645F5@DEWDFEMB12A.global.corp.sap> <5282EA9D.8060609@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64A58@DEWDFEMB12A.global.corp.sap> <5283DABE.6090503@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE64E28@DEWDFEMB12A.global.corp.sap> <52852D98.80506@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE65027@DEWDFEMB12A.global.corp.sap> <52853027.8040607@oracle.com> <528530D8.2060800@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE65109@DEWDFEMB12A.global.corp.sap> <528593D0.2010806@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE65371@DEWDFEMB12A.global.corp.sap> Message-ID: <528678B3.3050202@oracle.com> Thank you, Goetz this version works. It is in JPRT queue. Vladimir On 11/15/13 1:38 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > sorry for that, but that's some code not included in the builds I do. > It's guarded by TRACE_HAVE_INTRINSICS, and there is no switch > to turn that on in the makefiles. If I force it on, I get lots of other errors: > > vm/c1/c1_GraphBuilder.cpp: In member function 'bool GraphBuilder::try_inline_intrinsics(ciMethod*)': > vm/c1/c1_GraphBuilder.cpp:3363: error: '_classID' is not a member of 'vmIntrinsics' > vm/c1/c1_GraphBuilder.cpp:3364: error: '_threadID' is not a member of 'vmIntrinsics' > vm/c1/c1_GraphBuilder.cpp:3369: error: '_counterTime' is not a member of 'vmIntrinsics' > > vm/c1/c1_LIRGenerator.cpp: In member function 'virtual void LIRGenerator::do_Intrinsic(Intrinsic*)': > vm/c1/c1_LIRGenerator.cpp:3049: error: '_threadID' is not a member of 'vmIntrinsics' > vm/c1/c1_LIRGenerator.cpp:3050: error: '_classID' is not a member of 'vmIntrinsics' > vm/c1/c1_LIRGenerator.cpp:3051: error: '_counterTime' is not a member of 'vmIntrinsics' > vm/c1/c1_LIRGenerator.cpp:3052: error: 'TRACE_TIME_METHOD' was not declared in this scope > > I would need access to your closed sources and JPRT to fully test this, I guess. > I checked all the calls once more, but I can not test it, so I can not assure I got all. > I updated the webrev > http://cr.openjdk.java.net/~goetz/webrevs/8024921-2-ldst/ > > Best regards and thanks for pushing 115, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Freitag, 15. November 2013 04:24 > To: Lindenmaier, Goetz > Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. > > Goetz, > > I have build problem in library_call.cpp. > > Looks like you missed several make_load(), store_to_memory() calls: > > src/share/vm/opto/library_call.cpp: In member function 'bool > LibraryCallKit::inline_native_classID()': > src/share/vm/opto/library_call.cpp:3180: error: no matching function for > call to 'LibraryCallKit::make_load(NULL, Node*&, const TypeLong*&, > BasicType)' > src/share/vm/opto/library_call.cpp:3187: error: no matching function for > call to 'LibraryCallKit::store_to_memory(Node*, Node*&, Node*&, > BasicType, const TypePtr*&)' > > and several other places. > > Vladimir > > On 11/14/13 1:21 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> The defines are in >> library_call.cpp:3117, in inline_unsafe_allocate(). >> >> here goes the webrev without the changes in inline_unsafe_allocate: >> http://cr.openjdk.java.net/~goetz/webrevs/8024921-2-ldst/ >> >> And here a first draft for MemBarAcquire/ReleaseWide: >> http://cr.openjdk.java.net/~goetz/webrevs/MemBarWide/ >> But I definitely still need to test this, I'll add it into our VM >> to get the full tests before calling for a real review. >> >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, November 14, 2013 9:22 PM >> To: Lindenmaier, Goetz >> Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store nodes to know about memory ordering. >> >> Actually what defines you are talking about? I don't see them in these >> changes. >> >> Vladimir >> >> On 11/14/13 12:18 PM, Vladimir Kozlov wrote: >>> On 11/14/13 12:12 PM, Lindenmaier, Goetz wrote: >>>> What do you prefer? Two or one changes? >>> >>> Two different changes. >>> >>>> I can take out the #defines in this one, and make a separate one >>>> for the new node. I think this are two different issues, so there >>>> should be two changes. >>> >>> Can you leave current changes as they are and refactor code in second >>> changes? We have free cycles in JPRT now so I want to push current >>> version if it is okay with you. >>> >>> thanks, >>> Vladimir >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Thursday, November 14, 2013 9:08 PM >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >>>> nodes to know about memory ordering. >>>> >>>> On 11/14/13 6:55 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I renamed the enum MemOrd, almost as Vitaly proposed. >>>>> I also changed the order of arguments, and added default >>>>> argument for require_atomic_access. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-1-ldst/ >>>> >>>> This looks good. Is it final version which I can push (need to go >>>> throught JPRT)? Or you want to add code from your question below. >>>> >>>>> >>>>> I also found a way to work around on of the PPC64 defines. >>>>> For the others in inline_unsafe_fence I actually would like to have >>>>> some way to distinguish them in the matcher. Then I would not need >>>>> the defines here. >>>>> They also differ in their meaning from the other Acquire/Release >>>>> operations, as they all refer to a certain memory operation, but >>>>> these do not. >>>>> I would propose to either introduce MemBarAcquire/ReleaseWide >>>>> or setting a flag in the node that indicates that the membar is >>>>> not intended for a certain memory operation. >>>>> What do you think? >>>> >>>> Add new one. We already did that for MemBarAcquire/ReleaseLock. It >>>> simplified matcher. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Mittwoch, 13. November 2013 21:02 >>>>> To: Lindenmaier, Goetz >>>>> Subject: Re: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >>>>> nodes to know about memory ordering. >>>>> >>>>> On 11/13/13 9:13 AM, Lindenmaier, Goetz wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>>> Too much changes due to explicit params which are not used on our >>>>>>> platforms. Can you leave current make_load()/store_to_memory() for >>>>>>> unordered case and add new make_load_ordered() and >>>>>>> store_to_memory_ordered() for which you pass all parameters (and they >>>>>>> call make_load()/store_to_memory()) ? >>>>>>> >>>>>>> Can you explain why?: >>>>>>> "Maintaining this change has shown very error prone if the defaults >>>>>>> for >>>>>>> the new field are ::unordered." >>>>>>> Did you tried what I suggested above? >>>>>> What happened in our code is that you add a new call to the >>>>>> function, we >>>>>> integrate the change and it just compiles as the default argument is >>>>>> used. >>>>>> Thus we oversaw that we had to add 'release'. >>>>>> Also, I found errors where our 'release' was cast to Boolean and passed >>>>>> to the newly added argument 'require_atomic_access'. >>>>>> In all these cases you will get a compile time error without default >>>>>> parameters. >>>>>> Having extra functions causes similar problems. >>>>>> If I use default parameter 'release' and 'acquire', the generated >>>>>> code will >>>>>> be correct if the parameter is left out, but I have to pass the >>>>>> argument in >>>>>> the most places, anyways. >>>>> >>>>> Okay, can you swap it with require_atomic_access argument to keep it >>>>> with default value? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>>> Changes to memory nodes (and LoadNode::make()/ StoreNode::make()) are >>>>>>> fine since we need to record ordering case and there is no other way. >>>>>>> And it is less cases than make_load()/store_to_memory(). >>>>>> Thanks! >>>>>> >>>>>>> Regarding David's concern about memory barriers I think changes are >>>>>>> fine >>>>>>> because MemBar are preserved in IR graph. Some of them are different >>>>>>> kind but it is fine for C2 - it just needs some barriers to preserve >>>>>>> order of loads and stores. >>>>>> >>>>>>> As Vitaly I also don't know what is 'Sem'. Please, translate :) >>>>>> As Vitaly guessed, it's short for semantic. >>>>>> >>>>>> Best regards and thanks for the review! >>>>>> Goetz. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/12/13 8:30 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I updated this webrev to work with the latest version of the >>>>>>> staging repository. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> From: goetz.lindenmaier at sap.com >>>>>>> Sent: Freitag, 11. Oktober 2013 15:34 >>>>>>> To: hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; >>>>>>> Vladimir Kozlov >>>>>>> Subject: RFR(M): 8024921: PPC64 (part 113): Extend Load and Store >>>>>>> nodes to know about memory ordering. >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I prepared a webrev for >>>>>>> 8024921Extend >>>>>>> Load and Store nodes to know about memory ordering. >>>>>>> This is part of the PPC port. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8024921-0-ldst/ >>>>>>> >>>>>>> For a detailed description see the text in the webrev and bug >>>>>>> description. >>>>>>> >>>>>>> All this basically does is add a field to load and store nodes and >>>>>>> change all constructor calls to set this field. So the effect on >>>>>>> existing platforms should be very small. Therefore I marked this >>>>>>> 'M', although quite some lines of code are touched. >>>>>>> >>>>>>> Please review and test this change. >>>>>>> I'm happy to incorporate your comments and any improvements >>>>>>> you propose. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> From vladimir.kozlov at oracle.com Fri Nov 15 11:41:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Nov 2013 11:41:17 -0800 Subject: RFR (S): 8028401: PPC (part 117): Improve usability of adlc and format() functionality. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE653F1@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6513E@DEWDFEMB12A.global.corp.sap> <528591DB.80003@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE653F1@DEWDFEMB12A.global.corp.sap> Message-ID: <528678DD.7080501@oracle.com> Good. I will push it after 8024921. Thanks, Vladimir On 11/15/13 1:58 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed the version without const. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Freitag, 15. November 2013 04:16 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8028401: PPC (part 117): Improve usability of adlc and format() functionality. > > Do we really need 2 version of constant_offset_unchecked()? It is used > only in format() const. > > Vladimir > > On 11/14/13 2:04 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> This change contains some smaller additions to adlc and the format() routine, >> that improve their usability: >> http://cr.openjdk.java.net/~goetz/webrevs/8028401-0-adlc/ >> >> Improve usability of adlc: >> So far, expands can only use instructs that are specified further up in the .ad file. >> This is because the check whether nodes used in the expand are also defined >> is done during parsing. >> Move this check to a later point to relax ordering constraints. >> >> Add a row of additional, more verbose syntax checks. >> >> Improve format(): >> If MachNode::format() is called before constants are written to the >> constants section, it can fail. Add a safer version of constant_offset >> to avoid this. >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> From alejandro.murillo at oracle.com Fri Nov 15 12:25:22 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Nov 2013 20:25:22 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131115202531.52C1A62621@hg.openjdk.java.net> Changeset: aec3226be72d Author: cl Date: 2013-11-14 09:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aec3226be72d Added tag jdk8-b116 for changeset 52b076e6ffae ! .hgtags Changeset: c78d517c7ea4 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c78d517c7ea4 Merge Changeset: f573d00213b7 Author: amurillo Date: 2013-11-15 07:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f573d00213b7 Added tag hs25-b59 for changeset c78d517c7ea4 ! .hgtags Changeset: 854a42db7069 Author: amurillo Date: 2013-11-15 07:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/854a42db7069 8028444: new hotspot build - hs25-b60 Reviewed-by: jcoomes ! make/hotspot_version From goetz.lindenmaier at sap.com Fri Nov 15 16:56:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 16 Nov 2013 00:56:12 +0000 Subject: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE65CC0@DEWDFEMB12A.global.corp.sap> Hi, PPC has a compare-and-trap instruction that is used for NullChecks and RangeChecks. If a check fails, SIGTRAP is raised and must be handled by the signal handler of the VM. Add support for handling SIGTRAP on PPC64 to linux. http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ Please review and test this change. Best regards, Goetz. From vladimir.kozlov at oracle.com Fri Nov 15 17:33:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Nov 2013 17:33:57 -0800 Subject: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE65CC0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE65CC0@DEWDFEMB12A.global.corp.sap> Message-ID: <5286CB85.40207@oracle.com> Whi print_signal_handler() is called for SIGTRAP if handler is not installed (on not PPC64)? Thanks, Vladimir On 11/15/13 4:56 PM, Lindenmaier, Goetz wrote: > Hi, > > PPC has a compare-and-trap instruction that is used for NullChecks and RangeChecks. > If a check fails, SIGTRAP is raised and must be handled by the signal handler of the VM. > Add support for handling SIGTRAP on PPC64 to linux. > > http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ > > Please review and test this change. > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Mon Nov 18 00:39:50 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Nov 2013 08:39:50 +0000 Subject: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. In-Reply-To: <5286CB85.40207@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE65CC0@DEWDFEMB12A.global.corp.sap> <5286CB85.40207@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE668B5@DEWDFEMB12A.global.corp.sap> Hi Vladimir, that's because in our VM, we always print all handlers. I added the #define in the print routine. http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Samstag, 16. November 2013 02:34 To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. Whi print_signal_handler() is called for SIGTRAP if handler is not installed (on not PPC64)? Thanks, Vladimir On 11/15/13 4:56 PM, Lindenmaier, Goetz wrote: > Hi, > > PPC has a compare-and-trap instruction that is used for NullChecks and RangeChecks. > If a check fails, SIGTRAP is raised and must be handled by the signal handler of the VM. > Add support for handling SIGTRAP on PPC64 to linux. > > http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ > > Please review and test this change. > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Mon Nov 18 06:18:34 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Nov 2013 14:18:34 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> Hi, The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory ordering in various places. Some order a certain load/store with other operations. Inline_unsafe_fence() inserts MemBars that do not correspont to a memory operation. So far, the same nodes were used. This change introduces MemBarAcquire/ReleaseWide to use where no dedicated load/store is ordered. With this change, these nodes can be matched differently, what is needed on PPC64. When reviewing 8024921 (part 113) we decided to avoid #defines in inline_unsafe_fence() and to introduce new MemBar operations. Please review and test this change. http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Nov 18 08:19:17 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Nov 2013 16:19:17 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> Hi David, as reply to your comment on the bug: Well, I sitll would need 2 different nodes, as on PPC we do MemBarAcquireWide --> lwsync MemBarReleaseWide --> lwsync MemBarVolatile --> sync. On Sparc, you even do 3 different operations. Or should I name them MemBarFenceAcquire and MemBarFenceRelease? This all depends a lot on the available instructions of the processors. Therefore I think a really clean representation that, at the same time, allows to find the cheapest set of instructions to express it on all processors, is impossible. Best regards, Goetz PS: Should I respond to comments in the bug right in the bug or on the mailing lists? From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Montag, 18. November 2013 15:19 To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. Hi, The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory ordering in various places. Some order a certain load/store with other operations. Inline_unsafe_fence() inserts MemBars that do not correspont to a memory operation. So far, the same nodes were used. This change introduces MemBarAcquire/ReleaseWide to use where no dedicated load/store is ordered. With this change, these nodes can be matched differently, what is needed on PPC64. When reviewing 8024921 (part 113) we decided to avoid #defines in inline_unsafe_fence() and to introduce new MemBar operations. Please review and test this change. http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ Best regards, Goetz. From volker.simonis at gmail.com Mon Nov 18 08:45:04 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Nov 2013 17:45:04 +0100 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' Message-ID: Hi, could you please review the following small webrev which fixes the CPP-interpreter after "CheckUnhandledOops" was re-enabled in the fastdebug build: http://cr.openjdk.java.net/~simonis/webrevs/8028514/ All the changes are in CPP-interpreter specific files or in code which is protected by "#ifdef CC_INTERP". Most changes just switch old-style "(oop)"casts to new-style "cast_to_oop()" conversions. Thank you and best regards, Volker From magnus.ihse.bursie at oracle.com Thu Nov 14 00:51:25 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Nov 2013 09:51:25 +0100 Subject: RFR: 8028162 - Update Netbeans / Solaris Studio project files on Mac In-Reply-To: <52822590.6000704@oracle.com> References: <52822590.6000704@oracle.com> Message-ID: <52848F0D.9080300@oracle.com> Hi Jesper, I assume you wanted to post this to the build-dev list -- the build-infra-dev was a project-based list used during active development of the new build system. As far as I can tell, the changes looks good. (But I'm not a formal reviewer) Thinking long term, this file should probably be generated on the fly instead of updated manually like this. /Magnus On 2013-11-12 13:56, Jesper Wilhelmsson wrote: > Hi, > > Could I have a couple of reviews of the updated project files for > NetBeans / Solaris Studio. > > This change updates the Mac part of the project files. I intend to do > the same change on linux as well but that will be a separate change. > Then maybe someone who has a Solaris box can update the Solaris part? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028162 > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8028162/webrev/ > > Looking at the diff you will see that all $SRC have been replaced by > 0. This was done automatically by Solaris Studio. I asked in the > support forum if this was correct, and apparently it was :-) > > Forum: > http://myforums.oracle.com/jive3/thread.jspa?threadID=1350319&tstart=0 > > Thanks, > /Jesper From magnus.ihse.bursie at oracle.com Mon Nov 18 04:44:13 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Nov 2013 13:44:13 +0100 Subject: RFR: 8028162 - Update Netbeans / Solaris Studio project files on Mac In-Reply-To: <5284B2E0.5070809@oracle.com> References: <52822590.6000704@oracle.com> <52848F0D.9080300@oracle.com> <5284B2E0.5070809@oracle.com> Message-ID: <528A0B9D.50305@oracle.com> On 2013-11-14 12:24, Jesper Wilhelmsson wrote: > >> >> As far as I can tell, the changes looks good. (But I'm not a formal >> reviewer) > > Thanks! Do you know which repository is the most suitable to push this > change? I can't go through hsx/hotspot-gc ;-) Maybe the build forest? /Magnus From henry.jen at oracle.com Fri Nov 1 20:36:37 2013 From: henry.jen at oracle.com (Henry Jen) Date: Sat, 02 Nov 2013 03:36:37 -0000 Subject: Build failure with gnu make 4.0 on Arch Linux Message-ID: <52747344.8080807@oracle.com> Hi, I am trying to setup build environment on a new installation, and encounter following build error. I suspect this is because of missing some required tools and software, however, the error message is not helpful. Tried to echo the make commang used, but as you can see the output seems to be scrambled. Is there a way to find out what exact command causing problem? I tried to configure --with-jobs=1, that doesn't help. The Gnu make version is 4.0, let me know what else information I can collect to help diagnosis the problem. Cheers, Henry > > INFO: ZIP_DEBUGINFO_FILES=1 > /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles > /usr/bin/make: invalid option -- '/' > /usr/bin/make: invalid option -- '/' > Usage: make [options] [target] ... > Options: > -b, -m Ignored for compatibility. > -B, --always-make Unconditionally make all targets. > -C DIRECTORY, --directory=DIRECTORY > Change to DIRECTORY before doing anything. > -d Print lots of debugging information. > --debug[=FLAGS] Print various types of debugging information. > -e, --environment-overrides > Environment variables override makefiles. > --eval=STRING Evaluate STRING as a makefile statement. > -f FILE, --file=FILE, --makefile=FILE > Read FILE as a makefile. > -h, --help Print this message and exit. > -i, --ignore-errors Ignore errors from recipes. > -I DIRECTORY, --include-dir=DIRECTORY > Search DIRECTORY for included makefiles. > -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg. > -k, --keep-going Keep going when some targets can't be made. > -l [N], --load-average[=N], --max-load[=N] > Don't start multiple jobs unless load is below N. > -L, --check-symlink-times Use the latest mtime between symlinks and target. > -n, --just-print, --dry-run, --recon > Don't actually run any recipe; just print them. > -o FILE, --old-file=FILE, --assume-old=FILE > Consider FILE to be very old and don't remake it. > -O[TYPE], --output-sync[=TYPE] > Synchronize output of parallel jobs by TYPE. > -p, --print-data-base Print make's internal database. > -q, --question Run no recipe; exit status says if up to date. > -r, --no-builtin-rules Disable the built-in implicit rules. > -R, --no-builtin-variables Disable the built-in variable settings. > -s, --silent, --quiet Don't echo recipes. > -S, --no-keep-going, --stop > Turns off -k. > -t, --touch Touch targets instead of remaking them. > --trace Print tracing information. > -v, --version Print the version number of make and exit. > -w, --print-directory Print the current directory. > --no-print-directory Turn off -w, even if it was turned on implicitly. > -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE > Consider FILE to be infinitely new. > --warn-undefined-variables Warn when an undefined variable is referenced. > > This program built for x86_64-unknown-linux-gnu > Report bugs to > make[5]: *** [ad_stuff] Error 2 > /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for target 'ad_stuff' failed > make[4]: *** [product] Error 2 > /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target 'product' failed > make[3]: *** [generic_build2] Error 2 > Makefile:216: recipe for target 'generic_build2' failed > make[2]: *** [product] Error 2 > Makefile:167: recipe for target 'product' failed > make[1]: *** [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 > HotspotWrapper.gmk:44: recipe for target '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' failed > /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for target 'hotspot-only' failed > make: *** [hotspot-only] Error 2 From henry.jen at oracle.com Sat Nov 2 00:27:46 2013 From: henry.jen at oracle.com (Henry Jen) Date: Sat, 02 Nov 2013 07:27:46 -0000 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <5274A891.3020105@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> Message-ID: <5274A96E.8060707@oracle.com> Yes, I just verified that's the result of sed. Following patch fix it. I don't quite understand why we need that line. Cheers, Henry diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 -0700 +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 -0700 @@ -64,7 +64,6 @@ echo "$MFLAGS" \ | sed ' s/^-/ -/ - s/ -\([^ ][^ ]*\)j/ -\1 -j/ s/ -j[0-9][0-9]*/ -j/ s/ -j\([^ ]\)/ -j -\1/ s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ On 11/02/2013 12:24 AM, David Holmes wrote: > Hi Henry, > > Looks to me like the script that tries to hack the -j option has messed up: > > -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 > -en/ws/tl/common/makefiles > > Note the -j3 which seems to have been inserted into the middle of > /hjen/ws ... > > David > > On 2/11/2013 1:36 PM, Henry Jen wrote: >> Hi, >> >> I am trying to setup build environment on a new installation, and >> encounter following build error. >> >> I suspect this is because of missing some required tools and software, >> however, the error message is not helpful. >> >> Tried to echo the make commang used, but as you can see the output seems >> to be scrambled. Is there a way to find out what exact command causing >> problem? I tried to configure --with-jobs=1, that doesn't help. >> >> The Gnu make version is 4.0, let me know what else information I can >> collect to help diagnosis the problem. >> >> Cheers, >> Henry >> >> >>> >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>> -I/home/hjen/ws/tl/common/makefiles >>> -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>> /usr/bin/make: invalid option -- '/' >>> /usr/bin/make: invalid option -- '/' >>> Usage: make [options] [target] ... >>> Options: >>> -b, -m Ignored for compatibility. >>> -B, --always-make Unconditionally make all targets. >>> -C DIRECTORY, --directory=DIRECTORY >>> Change to DIRECTORY before doing anything. >>> -d Print lots of debugging information. >>> --debug[=FLAGS] Print various types of debugging >>> information. >>> -e, --environment-overrides >>> Environment variables override makefiles. >>> --eval=STRING Evaluate STRING as a makefile statement. >>> -f FILE, --file=FILE, --makefile=FILE >>> Read FILE as a makefile. >>> -h, --help Print this message and exit. >>> -i, --ignore-errors Ignore errors from recipes. >>> -I DIRECTORY, --include-dir=DIRECTORY >>> Search DIRECTORY for included makefiles. >>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with >>> no arg. >>> -k, --keep-going Keep going when some targets can't be >>> made. >>> -l [N], --load-average[=N], --max-load[=N] >>> Don't start multiple jobs unless load is >>> below N. >>> -L, --check-symlink-times Use the latest mtime between symlinks >>> and target. >>> -n, --just-print, --dry-run, --recon >>> Don't actually run any recipe; just >>> print them. >>> -o FILE, --old-file=FILE, --assume-old=FILE >>> Consider FILE to be very old and don't >>> remake it. >>> -O[TYPE], --output-sync[=TYPE] >>> Synchronize output of parallel jobs by >>> TYPE. >>> -p, --print-data-base Print make's internal database. >>> -q, --question Run no recipe; exit status says if up to >>> date. >>> -r, --no-builtin-rules Disable the built-in implicit rules. >>> -R, --no-builtin-variables Disable the built-in variable settings. >>> -s, --silent, --quiet Don't echo recipes. >>> -S, --no-keep-going, --stop >>> Turns off -k. >>> -t, --touch Touch targets instead of remaking them. >>> --trace Print tracing information. >>> -v, --version Print the version number of make and exit. >>> -w, --print-directory Print the current directory. >>> --no-print-directory Turn off -w, even if it was turned on >>> implicitly. >>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>> Consider FILE to be infinitely new. >>> --warn-undefined-variables Warn when an undefined variable is >>> referenced. >>> >>> This program built for x86_64-unknown-linux-gnu >>> Report bugs to >>> make[5]: *** [ad_stuff] Error 2 >>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>> target 'ad_stuff' failed >>> make[4]: *** [product] Error 2 >>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>> 'product' failed >>> make[3]: *** [generic_build2] Error 2 >>> Makefile:216: recipe for target 'generic_build2' failed >>> make[2]: *** [product] Error 2 >>> Makefile:167: recipe for target 'product' failed >>> make[1]: *** >>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>> >>> Error 2 >>> HotspotWrapper.gmk:44: recipe for target >>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>> >>> failed >>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>> target 'hotspot-only' failed >>> make: *** [hotspot-only] Error 2 From henry.jen at oracle.com Sat Nov 2 00:30:56 2013 From: henry.jen at oracle.com (Henry Jen) Date: Sat, 02 Nov 2013 07:30:56 -0000 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <5274A96E.8060707@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> Message-ID: <5274AA2C.2070901@oracle.com> What I don't understand(misleading me) is that my previous Ubuntu setup has same directory structure, but not seeing this problem. Cheers, Henry On 11/02/2013 12:27 AM, Henry Jen wrote: > Yes, I just verified that's the result of sed. Following patch fix it. > I don't quite understand why we need that line. > > Cheers, > Henry > > diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh > --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 > -0700 > +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 > -0700 > @@ -64,7 +64,6 @@ > echo "$MFLAGS" \ > | sed ' > s/^-/ -/ > - s/ -\([^ ][^ ]*\)j/ -\1 -j/ > s/ -j[0-9][0-9]*/ -j/ > s/ -j\([^ ]\)/ -j -\1/ > s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ > > > On 11/02/2013 12:24 AM, David Holmes wrote: >> Hi Henry, >> >> Looks to me like the script that tries to hack the -j option has >> messed up: >> >> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >> -en/ws/tl/common/makefiles >> >> Note the -j3 which seems to have been inserted into the middle of >> /hjen/ws ... >> >> David >> >> On 2/11/2013 1:36 PM, Henry Jen wrote: >>> Hi, >>> >>> I am trying to setup build environment on a new installation, and >>> encounter following build error. >>> >>> I suspect this is because of missing some required tools and software, >>> however, the error message is not helpful. >>> >>> Tried to echo the make commang used, but as you can see the output seems >>> to be scrambled. Is there a way to find out what exact command causing >>> problem? I tried to configure --with-jobs=1, that doesn't help. >>> >>> The Gnu make version is 4.0, let me know what else information I can >>> collect to help diagnosis the problem. >>> >>> Cheers, >>> Henry >>> >>> >>>> >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>> -I/home/hjen/ws/tl/common/makefiles >>>> -I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>> /usr/bin/make: invalid option -- '/' >>>> /usr/bin/make: invalid option -- '/' >>>> Usage: make [options] [target] ... >>>> Options: >>>> -b, -m Ignored for compatibility. >>>> -B, --always-make Unconditionally make all targets. >>>> -C DIRECTORY, --directory=DIRECTORY >>>> Change to DIRECTORY before doing >>>> anything. >>>> -d Print lots of debugging information. >>>> --debug[=FLAGS] Print various types of debugging >>>> information. >>>> -e, --environment-overrides >>>> Environment variables override makefiles. >>>> --eval=STRING Evaluate STRING as a makefile statement. >>>> -f FILE, --file=FILE, --makefile=FILE >>>> Read FILE as a makefile. >>>> -h, --help Print this message and exit. >>>> -i, --ignore-errors Ignore errors from recipes. >>>> -I DIRECTORY, --include-dir=DIRECTORY >>>> Search DIRECTORY for included makefiles. >>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with >>>> no arg. >>>> -k, --keep-going Keep going when some targets can't be >>>> made. >>>> -l [N], --load-average[=N], --max-load[=N] >>>> Don't start multiple jobs unless load is >>>> below N. >>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>> and target. >>>> -n, --just-print, --dry-run, --recon >>>> Don't actually run any recipe; just >>>> print them. >>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>> Consider FILE to be very old and don't >>>> remake it. >>>> -O[TYPE], --output-sync[=TYPE] >>>> Synchronize output of parallel jobs by >>>> TYPE. >>>> -p, --print-data-base Print make's internal database. >>>> -q, --question Run no recipe; exit status says if up to >>>> date. >>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>> -s, --silent, --quiet Don't echo recipes. >>>> -S, --no-keep-going, --stop >>>> Turns off -k. >>>> -t, --touch Touch targets instead of remaking them. >>>> --trace Print tracing information. >>>> -v, --version Print the version number of make and >>>> exit. >>>> -w, --print-directory Print the current directory. >>>> --no-print-directory Turn off -w, even if it was turned on >>>> implicitly. >>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>> Consider FILE to be infinitely new. >>>> --warn-undefined-variables Warn when an undefined variable is >>>> referenced. >>>> >>>> This program built for x86_64-unknown-linux-gnu >>>> Report bugs to >>>> make[5]: *** [ad_stuff] Error 2 >>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>> target 'ad_stuff' failed >>>> make[4]: *** [product] Error 2 >>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>> 'product' failed >>>> make[3]: *** [generic_build2] Error 2 >>>> Makefile:216: recipe for target 'generic_build2' failed >>>> make[2]: *** [product] Error 2 >>>> Makefile:167: recipe for target 'product' failed >>>> make[1]: *** >>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>> >>>> >>>> Error 2 >>>> HotspotWrapper.gmk:44: recipe for target >>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>> >>>> >>>> failed >>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>> target 'hotspot-only' failed >>>> make: *** [hotspot-only] Error 2 From henry.jen at oracle.com Mon Nov 4 22:18:25 2013 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 04 Nov 2013 22:18:25 -0800 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <52776B0D.7050308@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> <5274AA2C.2070901@oracle.com> <52776B0D.7050308@oracle.com> Message-ID: <52788DB1.1070300@oracle.com> Yes, GNU make 4.0 change the format of MFLAGS so that there is no longer space between -I and folder. Cheers, Henry On 11/04/2013 01:38 AM, Erik Joelsson wrote: > This seems to be make 4.0 specific. I saw the same error when trying a > home built make 4.0 on Solaris the other day (for a completely different > reason so I didn't pursue the problem). > > We will investigate. > > /Erik > > On 2013-11-02 08:30, Henry Jen wrote: >> What I don't understand(misleading me) is that my previous Ubuntu >> setup has same directory structure, but not seeing this problem. >> >> Cheers, >> Henry >> >> On 11/02/2013 12:27 AM, Henry Jen wrote: >>> Yes, I just verified that's the result of sed. Following patch fix it. >>> I don't quite understand why we need that line. >>> >>> Cheers, >>> Henry >>> >>> diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh >>> --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 >>> -0700 >>> +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 >>> -0700 >>> @@ -64,7 +64,6 @@ >>> echo "$MFLAGS" \ >>> | sed ' >>> s/^-/ -/ >>> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >>> s/ -j[0-9][0-9]*/ -j/ >>> s/ -j\([^ ]\)/ -j -\1/ >>> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >>> >>> >>> On 11/02/2013 12:24 AM, David Holmes wrote: >>>> Hi Henry, >>>> >>>> Looks to me like the script that tries to hack the -j option has >>>> messed up: >>>> >>>> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>>> -j3 >>>> -en/ws/tl/common/makefiles >>>> >>>> Note the -j3 which seems to have been inserted into the middle of >>>> /hjen/ws ... >>>> >>>> David >>>> >>>> On 2/11/2013 1:36 PM, Henry Jen wrote: >>>>> Hi, >>>>> >>>>> I am trying to setup build environment on a new installation, and >>>>> encounter following build error. >>>>> >>>>> I suspect this is because of missing some required tools and software, >>>>> however, the error message is not helpful. >>>>> >>>>> Tried to echo the make commang used, but as you can see the output >>>>> seems >>>>> to be scrambled. Is there a way to find out what exact command causing >>>>> problem? I tried to configure --with-jobs=1, that doesn't help. >>>>> >>>>> The Gnu make version is 4.0, let me know what else information I can >>>>> collect to help diagnosis the problem. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> >>>>>> >>>>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>> /usr/bin/make: invalid option -- '/' >>>>>> /usr/bin/make: invalid option -- '/' >>>>>> Usage: make [options] [target] ... >>>>>> Options: >>>>>> -b, -m Ignored for compatibility. >>>>>> -B, --always-make Unconditionally make all targets. >>>>>> -C DIRECTORY, --directory=DIRECTORY >>>>>> Change to DIRECTORY before doing >>>>>> anything. >>>>>> -d Print lots of debugging information. >>>>>> --debug[=FLAGS] Print various types of debugging >>>>>> information. >>>>>> -e, --environment-overrides >>>>>> Environment variables override >>>>>> makefiles. >>>>>> --eval=STRING Evaluate STRING as a makefile >>>>>> statement. >>>>>> -f FILE, --file=FILE, --makefile=FILE >>>>>> Read FILE as a makefile. >>>>>> -h, --help Print this message and exit. >>>>>> -i, --ignore-errors Ignore errors from recipes. >>>>>> -I DIRECTORY, --include-dir=DIRECTORY >>>>>> Search DIRECTORY for included >>>>>> makefiles. >>>>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs >>>>>> with >>>>>> no arg. >>>>>> -k, --keep-going Keep going when some targets can't be >>>>>> made. >>>>>> -l [N], --load-average[=N], --max-load[=N] >>>>>> Don't start multiple jobs unless >>>>>> load is >>>>>> below N. >>>>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>>>> and target. >>>>>> -n, --just-print, --dry-run, --recon >>>>>> Don't actually run any recipe; just >>>>>> print them. >>>>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>>>> Consider FILE to be very old and don't >>>>>> remake it. >>>>>> -O[TYPE], --output-sync[=TYPE] >>>>>> Synchronize output of parallel jobs by >>>>>> TYPE. >>>>>> -p, --print-data-base Print make's internal database. >>>>>> -q, --question Run no recipe; exit status says if >>>>>> up to >>>>>> date. >>>>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>>>> -s, --silent, --quiet Don't echo recipes. >>>>>> -S, --no-keep-going, --stop >>>>>> Turns off -k. >>>>>> -t, --touch Touch targets instead of remaking them. >>>>>> --trace Print tracing information. >>>>>> -v, --version Print the version number of make and >>>>>> exit. >>>>>> -w, --print-directory Print the current directory. >>>>>> --no-print-directory Turn off -w, even if it was turned on >>>>>> implicitly. >>>>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>>>> Consider FILE to be infinitely new. >>>>>> --warn-undefined-variables Warn when an undefined variable is >>>>>> referenced. >>>>>> >>>>>> This program built for x86_64-unknown-linux-gnu >>>>>> Report bugs to >>>>>> make[5]: *** [ad_stuff] Error 2 >>>>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>>>> target 'ad_stuff' failed >>>>>> make[4]: *** [product] Error 2 >>>>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>>>> 'product' failed >>>>>> make[3]: *** [generic_build2] Error 2 >>>>>> Makefile:216: recipe for target 'generic_build2' failed >>>>>> make[2]: *** [product] Error 2 >>>>>> Makefile:167: recipe for target 'product' failed >>>>>> make[1]: *** >>>>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>>>> >>>>>> >>>>>> >>>>>> Error 2 >>>>>> HotspotWrapper.gmk:44: recipe for target >>>>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>>>> >>>>>> >>>>>> >>>>>> failed >>>>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>>>> target 'hotspot-only' failed >>>>>> make: *** [hotspot-only] Error 2 > From henry.jen at oracle.com Tue Nov 5 08:13:09 2013 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 5 Nov 2013 08:13:09 -0800 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <5278E42F.9030108@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> <5274AA2C.2070901@oracle.com> <52776B0D.7050308@oracle.com> <52788DB1.1070300@oracle.com> <5278E42F.9030108@oracle.com> Message-ID: <8E86C732-FADF-4938-B83E-91123AB4BA6F@oracle.com> +1, that would work. I just wondering if it?s better to have I in both bracket to be tolerant to case like -RsI, although it?s not a problem now, but that seems legal options to me. Cheers, Henry On Nov 5, 2013, at 4:27 AM, Erik Joelsson wrote: > So this only happens in hotspot because of make/linux/makefiles/adjust-mflags.sh. I would suggest this change to fix it. It adds -I to a set of options that cannot be combined with -j sharing the same dash (since -I requires an argument). > > diff -r ddc3758f68db make/linux/makefiles/adjust-mflags.sh > --- a/make/linux/makefiles/adjust-mflags.sh > +++ b/make/linux/makefiles/adjust-mflags.sh > @@ -64,7 +64,7 @@ > echo "$MFLAGS" \ > | sed ' > s/^-/ -/ > - s/ -\([^ ][^ ]*\)j/ -\1 -j/ > + s/ -\([^ I][^ ]*\)j/ -\1 -j/ > s/ -j[0-9][0-9]*/ -j/ > s/ -j\([^ ]\)/ -j -\1/ > s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ > > /Erik > > On 2013-11-05 07:18, Henry Jen wrote: >> Yes, GNU make 4.0 change the format of MFLAGS so that there is no longer space between -I and folder. >> >> Cheers, >> Henry >> >> >> On 11/04/2013 01:38 AM, Erik Joelsson wrote: >>> This seems to be make 4.0 specific. I saw the same error when trying a >>> home built make 4.0 on Solaris the other day (for a completely different >>> reason so I didn't pursue the problem). >>> >>> We will investigate. >>> >>> /Erik >>> >>> On 2013-11-02 08:30, Henry Jen wrote: >>>> What I don't understand(misleading me) is that my previous Ubuntu >>>> setup has same directory structure, but not seeing this problem. >>>> >>>> Cheers, >>>> Henry >>>> >>>> On 11/02/2013 12:27 AM, Henry Jen wrote: >>>>> Yes, I just verified that's the result of sed. Following patch fix it. >>>>> I don't quite understand why we need that line. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh >>>>> --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 >>>>> -0700 >>>>> +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 >>>>> -0700 >>>>> @@ -64,7 +64,6 @@ >>>>> echo "$MFLAGS" \ >>>>> | sed ' >>>>> s/^-/ -/ >>>>> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >>>>> s/ -j[0-9][0-9]*/ -j/ >>>>> s/ -j\([^ ]\)/ -j -\1/ >>>>> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >>>>> >>>>> >>>>> On 11/02/2013 12:24 AM, David Holmes wrote: >>>>>> Hi Henry, >>>>>> >>>>>> Looks to me like the script that tries to hack the -j option has >>>>>> messed up: >>>>>> >>>>>> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>>>>> -j3 >>>>>> -en/ws/tl/common/makefiles >>>>>> >>>>>> Note the -j3 which seems to have been inserted into the middle of >>>>>> /hjen/ws ... >>>>>> >>>>>> David >>>>>> >>>>>> On 2/11/2013 1:36 PM, Henry Jen wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am trying to setup build environment on a new installation, and >>>>>>> encounter following build error. >>>>>>> >>>>>>> I suspect this is because of missing some required tools and software, >>>>>>> however, the error message is not helpful. >>>>>>> >>>>>>> Tried to echo the make commang used, but as you can see the output >>>>>>> seems >>>>>>> to be scrambled. Is there a way to find out what exact command causing >>>>>>> problem? I tried to configure --with-jobs=1, that doesn't help. >>>>>>> >>>>>>> The Gnu make version is 4.0, let me know what else information I can >>>>>>> collect to help diagnosis the problem. >>>>>>> >>>>>>> Cheers, >>>>>>> Henry >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>>>>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>>>>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>>>>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>>> Usage: make [options] [target] ... >>>>>>>> Options: >>>>>>>> -b, -m Ignored for compatibility. >>>>>>>> -B, --always-make Unconditionally make all targets. >>>>>>>> -C DIRECTORY, --directory=DIRECTORY >>>>>>>> Change to DIRECTORY before doing >>>>>>>> anything. >>>>>>>> -d Print lots of debugging information. >>>>>>>> --debug[=FLAGS] Print various types of debugging >>>>>>>> information. >>>>>>>> -e, --environment-overrides >>>>>>>> Environment variables override >>>>>>>> makefiles. >>>>>>>> --eval=STRING Evaluate STRING as a makefile >>>>>>>> statement. >>>>>>>> -f FILE, --file=FILE, --makefile=FILE >>>>>>>> Read FILE as a makefile. >>>>>>>> -h, --help Print this message and exit. >>>>>>>> -i, --ignore-errors Ignore errors from recipes. >>>>>>>> -I DIRECTORY, --include-dir=DIRECTORY >>>>>>>> Search DIRECTORY for included >>>>>>>> makefiles. >>>>>>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs >>>>>>>> with >>>>>>>> no arg. >>>>>>>> -k, --keep-going Keep going when some targets can't be >>>>>>>> made. >>>>>>>> -l [N], --load-average[=N], --max-load[=N] >>>>>>>> Don't start multiple jobs unless >>>>>>>> load is >>>>>>>> below N. >>>>>>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>>>>>> and target. >>>>>>>> -n, --just-print, --dry-run, --recon >>>>>>>> Don't actually run any recipe; just >>>>>>>> print them. >>>>>>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>>>>>> Consider FILE to be very old and don't >>>>>>>> remake it. >>>>>>>> -O[TYPE], --output-sync[=TYPE] >>>>>>>> Synchronize output of parallel jobs by >>>>>>>> TYPE. >>>>>>>> -p, --print-data-base Print make's internal database. >>>>>>>> -q, --question Run no recipe; exit status says if >>>>>>>> up to >>>>>>>> date. >>>>>>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>>>>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>>>>>> -s, --silent, --quiet Don't echo recipes. >>>>>>>> -S, --no-keep-going, --stop >>>>>>>> Turns off -k. >>>>>>>> -t, --touch Touch targets instead of remaking them. >>>>>>>> --trace Print tracing information. >>>>>>>> -v, --version Print the version number of make and >>>>>>>> exit. >>>>>>>> -w, --print-directory Print the current directory. >>>>>>>> --no-print-directory Turn off -w, even if it was turned on >>>>>>>> implicitly. >>>>>>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>>>>>> Consider FILE to be infinitely new. >>>>>>>> --warn-undefined-variables Warn when an undefined variable is >>>>>>>> referenced. >>>>>>>> >>>>>>>> This program built for x86_64-unknown-linux-gnu >>>>>>>> Report bugs to >>>>>>>> make[5]: *** [ad_stuff] Error 2 >>>>>>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>>>>>> target 'ad_stuff' failed >>>>>>>> make[4]: *** [product] Error 2 >>>>>>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>>>>>> 'product' failed >>>>>>>> make[3]: *** [generic_build2] Error 2 >>>>>>>> Makefile:216: recipe for target 'generic_build2' failed >>>>>>>> make[2]: *** [product] Error 2 >>>>>>>> Makefile:167: recipe for target 'product' failed >>>>>>>> make[1]: *** >>>>>>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Error 2 >>>>>>>> HotspotWrapper.gmk:44: recipe for target >>>>>>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> failed >>>>>>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>>>>>> target 'hotspot-only' failed >>>>>>>> make: *** [hotspot-only] Error 2 >>> > From henry.jen at oracle.com Thu Nov 14 15:40:40 2013 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 14 Nov 2013 15:40:40 -0800 Subject: Build failure with gnu make 4.0 on Arch Linux In-Reply-To: <52791D7A.3070908@oracle.com> References: <52747344.8080807@oracle.com> <5274A891.3020105@oracle.com> <5274A96E.8060707@oracle.com> <5274AA2C.2070901@oracle.com> <52776B0D.7050308@oracle.com> <52788DB1.1070300@oracle.com> <5278E42F.9030108@oracle.com> <8E86C732-FADF-4938-B83E-91123AB4BA6F@oracle.com> <52791D7A.3070908@oracle.com> Message-ID: I filed?JDK-8028407 with this proposed patch attached, not sure which repo is proper channel to review/commit. Cheers, Henry On November 5, 2013 at 8:31:57 AM, Erik Joelsson (erik.joelsson at oracle.com) wrote: You are right, that would be more correct. /Erik On 2013-11-05 17:13, Henry Jen wrote: > +1, that would work. > > I just wondering if it?s better to have I in both bracket to be tolerant to case like -RsI, although it?s not a problem now, but that seems legal options to me. > > Cheers, > Henry > > On Nov 5, 2013, at 4:27 AM, Erik Joelsson wrote: > >> So this only happens in hotspot because of make/linux/makefiles/adjust-mflags.sh. I would suggest this change to fix it. It adds -I to a set of options that cannot be combined with -j sharing the same dash (since -I requires an argument). >> >> diff -r ddc3758f68db make/linux/makefiles/adjust-mflags.sh >> --- a/make/linux/makefiles/adjust-mflags.sh >> +++ b/make/linux/makefiles/adjust-mflags.sh >> @@ -64,7 +64,7 @@ >> echo "$MFLAGS" \ >> | sed ' >> s/^-/ -/ >> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >> + s/ -\([^ I][^ ]*\)j/ -\1 -j/ >> s/ -j[0-9][0-9]*/ -j/ >> s/ -j\([^ ]\)/ -j -\1/ >> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >> >> /Erik >> >> On 2013-11-05 07:18, Henry Jen wrote: >>> Yes, GNU make 4.0 change the format of MFLAGS so that there is no longer space between -I and folder. >>> >>> Cheers, >>> Henry >>> >>> >>> On 11/04/2013 01:38 AM, Erik Joelsson wrote: >>>> This seems to be make 4.0 specific. I saw the same error when trying a >>>> home built make 4.0 on Solaris the other day (for a completely different >>>> reason so I didn't pursue the problem). >>>> >>>> We will investigate. >>>> >>>> /Erik >>>> >>>> On 2013-11-02 08:30, Henry Jen wrote: >>>>> What I don't understand(misleading me) is that my previous Ubuntu >>>>> setup has same directory structure, but not seeing this problem. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> On 11/02/2013 12:27 AM, Henry Jen wrote: >>>>>> Yes, I just verified that's the result of sed. Following patch fix it. >>>>>> I don't quite understand why we need that line. >>>>>> >>>>>> Cheers, >>>>>> Henry >>>>>> >>>>>> diff -r ea1b8c643fc8 make/linux/makefiles/adjust-mflags.sh >>>>>> --- a/make/linux/makefiles/adjust-mflags.sh Wed Oct 30 13:43:16 2013 >>>>>> -0700 >>>>>> +++ b/make/linux/makefiles/adjust-mflags.sh Sat Nov 02 00:26:42 2013 >>>>>> -0700 >>>>>> @@ -64,7 +64,6 @@ >>>>>> echo "$MFLAGS" \ >>>>>> | sed ' >>>>>> s/^-/ -/ >>>>>> - s/ -\([^ ][^ ]*\)j/ -\1 -j/ >>>>>> s/ -j[0-9][0-9]*/ -j/ >>>>>> s/ -j\([^ ]\)/ -j -\1/ >>>>>> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/ >>>>>> >>>>>> >>>>>> On 11/02/2013 12:24 AM, David Holmes wrote: >>>>>>> Hi Henry, >>>>>>> >>>>>>> Looks to me like the script that tries to hack the -j option has >>>>>>> messed up: >>>>>>> >>>>>>> -I /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h >>>>>>> -j3 >>>>>>> -en/ws/tl/common/makefiles >>>>>>> >>>>>>> Note the -j3 which seems to have been inserted into the middle of >>>>>>> /hjen/ws ... >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 2/11/2013 1:36 PM, Henry Jen wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am trying to setup build environment on a new installation, and >>>>>>>> encounter following build error. >>>>>>>> >>>>>>>> I suspect this is because of missing some required tools and software, >>>>>>>> however, the error message is not helpful. >>>>>>>> >>>>>>>> Tried to echo the make commang used, but as you can see the output >>>>>>>> seems >>>>>>>> to be scrambled. Is there a way to find out what exact command causing >>>>>>>> problem? I tried to configure --with-jobs=1, that doesn't help. >>>>>>>> >>>>>>>> The Gnu make version is 4.0, let me know what else information I can >>>>>>>> collect to help diagnosis the problem. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Henry >>>>>>>> >>>>>>>> >>>>>>>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>>>>>>> /usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I >>>>>>>>> /home/hjen/ws/tl/common/makefiles -f adlc.make -r -rRs -I/home/h -j3 >>>>>>>>> -en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> -I/home/hjen/ws/tl/common/makefiles >>>>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>>>> /usr/bin/make: invalid option -- '/' >>>>>>>>> Usage: make [options] [target] ... >>>>>>>>> Options: >>>>>>>>> -b, -m Ignored for compatibility. >>>>>>>>> -B, --always-make Unconditionally make all targets. >>>>>>>>> -C DIRECTORY, --directory=DIRECTORY >>>>>>>>> Change to DIRECTORY before doing >>>>>>>>> anything. >>>>>>>>> -d Print lots of debugging information. >>>>>>>>> --debug[=FLAGS] Print various types of debugging >>>>>>>>> information. >>>>>>>>> -e, --environment-overrides >>>>>>>>> Environment variables override >>>>>>>>> makefiles. >>>>>>>>> --eval=STRING Evaluate STRING as a makefile >>>>>>>>> statement. >>>>>>>>> -f FILE, --file=FILE, --makefile=FILE >>>>>>>>> Read FILE as a makefile. >>>>>>>>> -h, --help Print this message and exit. >>>>>>>>> -i, --ignore-errors Ignore errors from recipes. >>>>>>>>> -I DIRECTORY, --include-dir=DIRECTORY >>>>>>>>> Search DIRECTORY for included >>>>>>>>> makefiles. >>>>>>>>> -j [N], --jobs[=N] Allow N jobs at once; infinite jobs >>>>>>>>> with >>>>>>>>> no arg. >>>>>>>>> -k, --keep-going Keep going when some targets can't be >>>>>>>>> made. >>>>>>>>> -l [N], --load-average[=N], --max-load[=N] >>>>>>>>> Don't start multiple jobs unless >>>>>>>>> load is >>>>>>>>> below N. >>>>>>>>> -L, --check-symlink-times Use the latest mtime between symlinks >>>>>>>>> and target. >>>>>>>>> -n, --just-print, --dry-run, --recon >>>>>>>>> Don't actually run any recipe; just >>>>>>>>> print them. >>>>>>>>> -o FILE, --old-file=FILE, --assume-old=FILE >>>>>>>>> Consider FILE to be very old and don't >>>>>>>>> remake it. >>>>>>>>> -O[TYPE], --output-sync[=TYPE] >>>>>>>>> Synchronize output of parallel jobs by >>>>>>>>> TYPE. >>>>>>>>> -p, --print-data-base Print make's internal database. >>>>>>>>> -q, --question Run no recipe; exit status says if >>>>>>>>> up to >>>>>>>>> date. >>>>>>>>> -r, --no-builtin-rules Disable the built-in implicit rules. >>>>>>>>> -R, --no-builtin-variables Disable the built-in variable settings. >>>>>>>>> -s, --silent, --quiet Don't echo recipes. >>>>>>>>> -S, --no-keep-going, --stop >>>>>>>>> Turns off -k. >>>>>>>>> -t, --touch Touch targets instead of remaking them. >>>>>>>>> --trace Print tracing information. >>>>>>>>> -v, --version Print the version number of make and >>>>>>>>> exit. >>>>>>>>> -w, --print-directory Print the current directory. >>>>>>>>> --no-print-directory Turn off -w, even if it was turned on >>>>>>>>> implicitly. >>>>>>>>> -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE >>>>>>>>> Consider FILE to be infinitely new. >>>>>>>>> --warn-undefined-variables Warn when an undefined variable is >>>>>>>>> referenced. >>>>>>>>> >>>>>>>>> This program built for x86_64-unknown-linux-gnu >>>>>>>>> Report bugs to >>>>>>>>> make[5]: *** [ad_stuff] Error 2 >>>>>>>>> /home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for >>>>>>>>> target 'ad_stuff' failed >>>>>>>>> make[4]: *** [product] Error 2 >>>>>>>>> /home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target >>>>>>>>> 'product' failed >>>>>>>>> make[3]: *** [generic_build2] Error 2 >>>>>>>>> Makefile:216: recipe for target 'generic_build2' failed >>>>>>>>> make[2]: *** [product] Error 2 >>>>>>>>> Makefile:167: recipe for target 'product' failed >>>>>>>>> make[1]: *** >>>>>>>>> [/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Error 2 >>>>>>>>> HotspotWrapper.gmk:44: recipe for target >>>>>>>>> '/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp' >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> failed >>>>>>>>> /export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for >>>>>>>>> target 'hotspot-only' failed >>>>>>>>> make: *** [hotspot-only] Error 2 From vladimir.kozlov at oracle.com Mon Nov 18 11:17:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 11:17:26 -0800 Subject: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE668B5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE65CC0@DEWDFEMB12A.global.corp.sap> <5286CB85.40207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE668B5@DEWDFEMB12A.global.corp.sap> Message-ID: <528A67C6.6070302@oracle.com> Good. You can push it yourself (don't forget Reviewed-by:) since everything under #ifdef. thanks, Vladimir On 11/18/13 12:39 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > that's because in our VM, we always print all handlers. > > I added the #define in the print routine. > http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ > > Best regards, > Goetz > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Samstag, 16. November 2013 02:34 > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. > > Whi print_signal_handler() is called for SIGTRAP if handler is not > installed (on not PPC64)? > > Thanks, > Vladimir > > On 11/15/13 4:56 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> PPC has a compare-and-trap instruction that is used for NullChecks and RangeChecks. >> If a check fails, SIGTRAP is raised and must be handled by the signal handler of the VM. >> Add support for handling SIGTRAP on PPC64 to linux. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Mon Nov 18 11:36:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 11:36:08 -0800 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> Message-ID: <528A6C28.7080306@oracle.com> I think David asked for different nodes not just one. We can have new membar nodes with names matching Unsafe methods names: LoadFence, StoreFence, FullFence. I am fine with it. MemBar and Fence have similar meaning so lets don't mix them in node names. Thanks, Vladimir On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: > Hi David, > > as reply to your comment on the bug: > > Well, I sitll would need 2 different nodes, as on PPC we do > MemBarAcquireWide --> lwsync > MemBarReleaseWide --> lwsync > MemBarVolatile --> sync. > On Sparc, you even do 3 different operations. > > Or should I name them MemBarFenceAcquire and MemBarFenceRelease? > This all depends a lot on the available instructions of the processors. > Therefore I think a really clean representation that, at the same time, allows > to find the cheapest set of instructions to express it on all > processors, is impossible. > > Best regards, > Goetz > > PS: Should I respond to comments in the bug right in the bug > or on the mailing lists? > > > > > > > > > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Montag, 18. November 2013 15:19 > To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov > Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi, > > The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory ordering in various places. Some order a certain load/store with other operations. Inline_unsafe_fence() inserts MemBars that do not correspont to a memory operation. So far, the same nodes were used. > > This change introduces MemBarAcquire/ReleaseWide to use where no dedicated load/store is ordered. With this change, these nodes can be matched differently, what is needed on PPC64. > > When reviewing 8024921 (part 113) we decided to avoid #defines in inline_unsafe_fence() and to introduce new MemBar operations. > > Please review and test this change. > http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Mon Nov 18 11:54:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 11:54:23 -0800 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: References: Message-ID: <528A706F.5090606@oracle.com> Looks fine to me. We need to make similar changes in closed src, I will prepare them. Thanks, Vladimir On 11/18/13 8:45 AM, Volker Simonis wrote: > Hi, > > could you please review the following small webrev which fixes the > CPP-interpreter after "CheckUnhandledOops" was re-enabled in the > fastdebug build: > > http://cr.openjdk.java.net/~simonis/webrevs/8028514/ > > All the changes are in CPP-interpreter specific files or in code which > is protected by "#ifdef CC_INTERP". Most changes just switch > old-style "(oop)"casts to new-style "cast_to_oop()" conversions. > > Thank you and best regards, > Volker > From goetz.lindenmaier at sap.com Mon Nov 18 13:17:30 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Nov 2013 21:17:30 +0000 Subject: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. In-Reply-To: <528A67C6.6070302@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE65CC0@DEWDFEMB12A.global.corp.sap> <5286CB85.40207@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE668B5@DEWDFEMB12A.global.corp.sap> <528A67C6.6070302@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66BF1@DEWDFEMB12A.global.corp.sap> Thanks a lot, it's in there. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, November 18, 2013 8:17 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. Good. You can push it yourself (don't forget Reviewed-by:) since everything under #ifdef. thanks, Vladimir On 11/18/13 12:39 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > that's because in our VM, we always print all handlers. > > I added the #define in the print routine. > http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ > > Best regards, > Goetz > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Samstag, 16. November 2013 02:34 > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR (S): 8028470: PPC64 (part 214): linux: extend signal handler to catch SIGTRAP on ppc64. > > Whi print_signal_handler() is called for SIGTRAP if handler is not > installed (on not PPC64)? > > Thanks, > Vladimir > > On 11/15/13 4:56 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> PPC has a compare-and-trap instruction that is used for NullChecks and RangeChecks. >> If a check fails, SIGTRAP is raised and must be handled by the signal handler of the VM. >> Add support for handling SIGTRAP on PPC64 to linux. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8028470-0-trap/ >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> From david.holmes at oracle.com Mon Nov 18 13:44:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Nov 2013 07:44:59 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> Message-ID: <528A8A5B.1000404@oracle.com> On 19/11/2013 2:19 AM, Lindenmaier, Goetz wrote: > Hi David, > > as reply to your comment on the bug: > > Well, I sitll would need 2 different nodes, as on PPC we do > MemBarAcquireWide --> lwsync > MemBarReleaseWide --> lwsync > MemBarVolatile --> sync. > On Sparc, you even do 3 different operations. > > Or should I name them MemBarFenceAcquire and MemBarFenceRelease? > This all depends a lot on the available instructions of the processors. > Therefore I think a really clean representation that, at the same time, allows > to find the cheapest set of instructions to express it on all > processors, is impossible. Without a doubt the terminology as presently used throughout the VM is somewhat muddled. I was tending to think of acquire in the load.acquire sense (loadStore|loadLoad barrier) and similarly of release as a store.release (storeSore|storeLoad). But I was overlooking the more general acquire/release semantics that we sometimes use when describing, for example the memory semantics of entering and leaving a synchronized block. So I prefer your FenceAcquire/FenceRelease suggestion over the "wide" name. Thanks, David > Best regards, > Goetz > > PS: Should I respond to comments in the bug right in the bug > or on the mailing lists? > > > > > > > > > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Montag, 18. November 2013 15:19 > To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov > Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi, > > The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory ordering in various places. Some order a certain load/store with other operations. Inline_unsafe_fence() inserts MemBars that do not correspont to a memory operation. So far, the same nodes were used. > > This change introduces MemBarAcquire/ReleaseWide to use where no dedicated load/store is ordered. With this change, these nodes can be matched differently, what is needed on PPC64. > > When reviewing 8024921 (part 113) we decided to avoid #defines in inline_unsafe_fence() and to introduce new MemBar operations. > > Please review and test this change. > http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ > > Best regards, > Goetz. > From david.holmes at oracle.com Mon Nov 18 13:49:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Nov 2013 07:49:23 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528A6C28.7080306@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> Message-ID: <528A8B63.9090605@oracle.com> Vladimir, On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: > I think David asked for different nodes not just one. > We can have new membar nodes with names matching Unsafe methods names: > LoadFence, StoreFence, FullFence. I am fine with it. But I don't think that actually describes them - they don't distinguish between loads and stores only the direction in which the barrier operates. "acquire" only allows accesses to move below it; "release" only allows accesses to move above it ie: load a store b, c acquire(); load d store e,f release(); load g store h, i allows the loads of 'a' and 'g' to move into the region between acquire and release; similarly for the stores to b and h. But the load of d nor the store to e can not move in relation to either acquire or release. Thanks, David > MemBar and Fence have similar meaning so lets don't mix them in node names. > > Thanks, > Vladimir > > On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> as reply to your comment on the bug: >> >> Well, I sitll would need 2 different nodes, as on PPC we do >> MemBarAcquireWide --> lwsync >> MemBarReleaseWide --> lwsync >> MemBarVolatile --> sync. >> On Sparc, you even do 3 different operations. >> >> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >> This all depends a lot on the available instructions of the processors. >> Therefore I think a really clean representation that, at the same >> time, allows >> to find the cheapest set of instructions to express it on all >> processors, is impossible. >> >> Best regards, >> Goetz >> >> PS: Should I respond to comments in the bug right in the bug >> or on the mailing lists? >> >> >> >> >> >> >> >> >> From: ppc-aix-port-dev-bounces at openjdk.java.net >> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >> Lindenmaier, Goetz >> Sent: Montag, 18. November 2013 15:19 >> To: 'hotspot-dev at openjdk.java.net'; >> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >> MemBarAcquire/ReleaseWide. >> >> Hi, >> >> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >> ordering in various places. Some order a certain load/store with other >> operations. Inline_unsafe_fence() inserts MemBars that do not >> correspont to a memory operation. So far, the same nodes were used. >> >> This change introduces MemBarAcquire/ReleaseWide to use where no >> dedicated load/store is ordered. With this change, these nodes can be >> matched differently, what is needed on PPC64. >> >> When reviewing 8024921 (part 113) we decided to avoid #defines in >> inline_unsafe_fence() and to introduce new MemBar operations. >> >> Please review and test this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Mon Nov 18 14:19:06 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Nov 2013 22:19:06 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528A8B63.9090605@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> Hi David, Vladimir, I also would prefer MemBarFenceAquire/Release, for two reasons - the same prefix shows they are all similar nodes. - I don't have to change MemBarVolatile to FullFence, which I didn't change yet and which is used in more places. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Monday, November 18, 2013 10:49 PM To: Vladimir Kozlov Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. Vladimir, On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: > I think David asked for different nodes not just one. > We can have new membar nodes with names matching Unsafe methods names: > LoadFence, StoreFence, FullFence. I am fine with it. But I don't think that actually describes them - they don't distinguish between loads and stores only the direction in which the barrier operates. "acquire" only allows accesses to move below it; "release" only allows accesses to move above it ie: load a store b, c acquire(); load d store e,f release(); load g store h, i allows the loads of 'a' and 'g' to move into the region between acquire and release; similarly for the stores to b and h. But the load of d nor the store to e can not move in relation to either acquire or release. Thanks, David > MemBar and Fence have similar meaning so lets don't mix them in node names. > > Thanks, > Vladimir > > On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> as reply to your comment on the bug: >> >> Well, I sitll would need 2 different nodes, as on PPC we do >> MemBarAcquireWide --> lwsync >> MemBarReleaseWide --> lwsync >> MemBarVolatile --> sync. >> On Sparc, you even do 3 different operations. >> >> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >> This all depends a lot on the available instructions of the processors. >> Therefore I think a really clean representation that, at the same >> time, allows >> to find the cheapest set of instructions to express it on all >> processors, is impossible. >> >> Best regards, >> Goetz >> >> PS: Should I respond to comments in the bug right in the bug >> or on the mailing lists? >> >> >> >> >> >> >> >> >> From: ppc-aix-port-dev-bounces at openjdk.java.net >> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >> Lindenmaier, Goetz >> Sent: Montag, 18. November 2013 15:19 >> To: 'hotspot-dev at openjdk.java.net'; >> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >> MemBarAcquire/ReleaseWide. >> >> Hi, >> >> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >> ordering in various places. Some order a certain load/store with other >> operations. Inline_unsafe_fence() inserts MemBars that do not >> correspont to a memory operation. So far, the same nodes were used. >> >> This change introduces MemBarAcquire/ReleaseWide to use where no >> dedicated load/store is ordered. With this change, these nodes can be >> matched differently, what is needed on PPC64. >> >> When reviewing 8024921 (part 113) we decided to avoid #defines in >> inline_unsafe_fence() and to introduce new MemBar operations. >> >> Please review and test this change. >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >> >> Best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Mon Nov 18 14:28:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Nov 2013 14:28:26 -0800 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> Message-ID: <528A948A.20002@oracle.com> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: > Hi David, Vladimir, > > I also would prefer MemBarFenceAquire/Release, for two reasons > - the same prefix shows they are all similar nodes. > - I don't have to change MemBarVolatile to FullFence, which I didn't > change yet and which is used in more places. Okay. Vladimir > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Monday, November 18, 2013 10:49 PM > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Vladimir, > > On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >> I think David asked for different nodes not just one. >> We can have new membar nodes with names matching Unsafe methods names: >> LoadFence, StoreFence, FullFence. I am fine with it. > > But I don't think that actually describes them - they don't distinguish > between loads and stores only the direction in which the barrier > operates. "acquire" only allows accesses to move below it; "release" > only allows accesses to move above it ie: > > load a > store b, c > acquire(); > load d > store e,f > release(); > load g > store h, i > > allows the loads of 'a' and 'g' to move into the region between acquire > and release; similarly for the stores to b and h. But the load of d nor > the store to e can not move in relation to either acquire or release. > > Thanks, > David > >> MemBar and Fence have similar meaning so lets don't mix them in node names. >> >> Thanks, >> Vladimir >> >> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> as reply to your comment on the bug: >>> >>> Well, I sitll would need 2 different nodes, as on PPC we do >>> MemBarAcquireWide --> lwsync >>> MemBarReleaseWide --> lwsync >>> MemBarVolatile --> sync. >>> On Sparc, you even do 3 different operations. >>> >>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>> This all depends a lot on the available instructions of the processors. >>> Therefore I think a really clean representation that, at the same >>> time, allows >>> to find the cheapest set of instructions to express it on all >>> processors, is impossible. >>> >>> Best regards, >>> Goetz >>> >>> PS: Should I respond to comments in the bug right in the bug >>> or on the mailing lists? >>> >>> >>> >>> >>> >>> >>> >>> >>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>> Lindenmaier, Goetz >>> Sent: Montag, 18. November 2013 15:19 >>> To: 'hotspot-dev at openjdk.java.net'; >>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>> MemBarAcquire/ReleaseWide. >>> >>> Hi, >>> >>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>> ordering in various places. Some order a certain load/store with other >>> operations. Inline_unsafe_fence() inserts MemBars that do not >>> correspont to a memory operation. So far, the same nodes were used. >>> >>> This change introduces MemBarAcquire/ReleaseWide to use where no >>> dedicated load/store is ordered. With this change, these nodes can be >>> matched differently, what is needed on PPC64. >>> >>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>> inline_unsafe_fence() and to introduce new MemBar operations. >>> >>> Please review and test this change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>> >>> Best regards, >>> Goetz. >>> From david.holmes at oracle.com Mon Nov 18 17:32:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Nov 2013 11:32:26 +1000 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: References: Message-ID: <528ABFAA.90904@oracle.com> On 19/11/2013 2:45 AM, Volker Simonis wrote: > Hi, > > could you please review the following small webrev which fixes the > CPP-interpreter after "CheckUnhandledOops" was re-enabled in the > fastdebug build: > > http://cr.openjdk.java.net/~simonis/webrevs/8028514/ > > All the changes are in CPP-interpreter specific files or in code which > is protected by "#ifdef CC_INTERP". Most changes just switch > old-style "(oop)"casts to new-style "cast_to_oop()" conversions. Why do we have use of INTPTR_FORMAT but a cast_from_oop ? ie mixing signed with unsigned. Otherwise looks ok. Thanks, David > Thank you and best regards, > Volker > From christian.thalinger at oracle.com Mon Nov 18 18:08:22 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Nov 2013 18:08:22 -0800 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_hotspot_Group_Member=3A_Rickard_?= =?iso-8859-1?Q?B=E4ckman?= In-Reply-To: <5278E859.4070906@oracle.com> References: <5278E859.4070906@oracle.com> Message-ID: <5A1B3D43-4EDC-4608-AA69-1FF00E65D7A3@oracle.com> Vote: yes On Nov 5, 2013, at 4:45 AM, Niclas Adlertz wrote: > I hereby nominate Rickard B?ckman (OpenJDK user name: rbackman) to Membership in the hotspot Group. > > Rickard is an Oracle engineer, working for the compiler team. He has been working in the HotSpot team since 2010. Rickard is a Committer in the HotSpot project and has currently contributed 32 changes. > > Votes are due by Tuesday, November 19, 2013. > > Only current Members of the hotspot Group [1] 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 [2]. > > Kind Regards, > Niclas Adlertz > > [1] http://openjdk.java.net/census/#hotspot > [2] http://openjdk.java.net/groups/#member-vote From lois.foltan at oracle.com Mon Nov 18 18:35:54 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 18 Nov 2013 21:35:54 -0500 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: References: Message-ID: <528ACE8A.1080505@oracle.com> Hi Volker, I do have a few review comments: src/cpu/ppc/vm/frame_ppc.cpp - The "cast_to_oop(NULL)" I believe could be simplified to "(oop)NULL" see similar code in src/cpu/x86/vm/frame_x86.cpp. src/share/vm/interpreter/bytecodeInterpreter.cpp - I have attached the recent RFR for supporting CHECK_UNHANDLED_OOPS across the platforms. It contains the summary outlining the changes. Please change your "cast_from_oop" within tty->print_cr() to "(void *)" as described in summary note item #3. Thank you, Lois On 11/18/2013 11:45 AM, Volker Simonis wrote: > Hi, > > could you please review the following small webrev which fixes the > CPP-interpreter after "CheckUnhandledOops" was re-enabled in the > fastdebug build: > > http://cr.openjdk.java.net/~simonis/webrevs/8028514/ > > All the changes are in CPP-interpreter specific files or in code which > is protected by "#ifdef CC_INTERP". Most changes just switch > old-style "(oop)"casts to new-style "cast_to_oop()" conversions. > > Thank you and best regards, > Volker -------------- next part -------------- An embedded message was scrubbed... From: Lois Foltan Subject: FR (L) JDK-7195622 (round 2): CheckUnhandledOops has limited usefulness now Date: Mon, 23 Sep 2013 17:17:05 -0400 Size: 6676 Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20131118/3c3712da/FRLJDK-7195622round2CheckUnhandledOopshaslimitedusefulnessnow.eml From christian.thalinger at oracle.com Mon Nov 18 20:44:47 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Nov 2013 20:44:47 -0800 Subject: CFV: New HSX Committer: Albert Noll In-Reply-To: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> References: <99CF71D8-79B5-4CAB-9E63-A86494B22D89@oracle.com> Message-ID: <87931545-4906-4469-9867-ABDD1132324F@oracle.com> Vote: yes On Nov 13, 2013, at 6:48 AM, Roland Westrelin wrote: > I hereby nominate Albert Noll (OpenJDK user name: anoll) to HSX Committer. > > Albert is a member of the Hotspot Compiler group. He contributed 26 changesets to the HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. > > Votes are due by Nov. 27, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91eba9f82325 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01e51113b4f5 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/813f26e34135 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/891687731b59 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/510fbd28919c > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/78da3894b86f > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 From goetz.lindenmaier at sap.com Tue Nov 19 00:34:32 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Nov 2013 08:34:32 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528A948A.20002@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> Hi, I made a new webrev, using the new names: http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ Thanks, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Montag, 18. November 2013 23:28 To: Lindenmaier, Goetz; 'David Holmes' Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: > Hi David, Vladimir, > > I also would prefer MemBarFenceAquire/Release, for two reasons > - the same prefix shows they are all similar nodes. > - I don't have to change MemBarVolatile to FullFence, which I didn't > change yet and which is used in more places. Okay. Vladimir > > Best regards, > Goetz. > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Monday, November 18, 2013 10:49 PM > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Vladimir, > > On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >> I think David asked for different nodes not just one. >> We can have new membar nodes with names matching Unsafe methods names: >> LoadFence, StoreFence, FullFence. I am fine with it. > > But I don't think that actually describes them - they don't distinguish > between loads and stores only the direction in which the barrier > operates. "acquire" only allows accesses to move below it; "release" > only allows accesses to move above it ie: > > load a > store b, c > acquire(); > load d > store e,f > release(); > load g > store h, i > > allows the loads of 'a' and 'g' to move into the region between acquire > and release; similarly for the stores to b and h. But the load of d nor > the store to e can not move in relation to either acquire or release. > > Thanks, > David > >> MemBar and Fence have similar meaning so lets don't mix them in node names. >> >> Thanks, >> Vladimir >> >> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> as reply to your comment on the bug: >>> >>> Well, I sitll would need 2 different nodes, as on PPC we do >>> MemBarAcquireWide --> lwsync >>> MemBarReleaseWide --> lwsync >>> MemBarVolatile --> sync. >>> On Sparc, you even do 3 different operations. >>> >>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>> This all depends a lot on the available instructions of the processors. >>> Therefore I think a really clean representation that, at the same >>> time, allows >>> to find the cheapest set of instructions to express it on all >>> processors, is impossible. >>> >>> Best regards, >>> Goetz >>> >>> PS: Should I respond to comments in the bug right in the bug >>> or on the mailing lists? >>> >>> >>> >>> >>> >>> >>> >>> >>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>> Lindenmaier, Goetz >>> Sent: Montag, 18. November 2013 15:19 >>> To: 'hotspot-dev at openjdk.java.net'; >>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>> MemBarAcquire/ReleaseWide. >>> >>> Hi, >>> >>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>> ordering in various places. Some order a certain load/store with other >>> operations. Inline_unsafe_fence() inserts MemBars that do not >>> correspont to a memory operation. So far, the same nodes were used. >>> >>> This change introduces MemBarAcquire/ReleaseWide to use where no >>> dedicated load/store is ordered. With this change, these nodes can be >>> matched differently, what is needed on PPC64. >>> >>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>> inline_unsafe_fence() and to introduce new MemBar operations. >>> >>> Please review and test this change. >>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>> >>> Best regards, >>> Goetz. >>> From volker.simonis at gmail.com Tue Nov 19 02:08:39 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Nov 2013 11:08:39 +0100 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: <528ACE8A.1080505@oracle.com> References: <528ACE8A.1080505@oracle.com> Message-ID: Hi Lois, thanks for your review. Here's the new webrev: http://cr.openjdk.java.net/~simonis/webrevs/8028514.v2/ Please find my comments inline: On Tue, Nov 19, 2013 at 3:35 AM, Lois Foltan wrote: > Hi Volker, > > I do have a few review comments: > > src/cpu/ppc/vm/frame_ppc.cpp > - The "cast_to_oop(NULL)" I believe could be simplified to > "(oop)NULL" see similar code in > src/cpu/x86/vm/frame_x86.cpp. > I was not sure here and wanted to make the conversion explicit, because NULL is actually the integer constant 'zero' and there's no special oop constructor for integers. But if the compiler doesn't complain and if it works on x86 I can change it as you suggested. > src/share/vm/interpreter/bytecodeInterpreter.cpp > - I have attached the recent RFR for supporting CHECK_UNHANDLED_OOPS > across the platforms. > It contains the summary outlining the changes. Please change your > "cast_from_oop" > within tty->print_cr() to "(void *)" as described in summary note item > #3. You're right, I missed the (void*)operator in the oop class. I changed it the way you suggested. Thanks, Volker > > Thank you, > Lois > > > On 11/18/2013 11:45 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following small webrev which fixes the >> CPP-interpreter after "CheckUnhandledOops" was re-enabled in the >> fastdebug build: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8028514/ >> >> All the changes are in CPP-interpreter specific files or in code which >> is protected by "#ifdef CC_INTERP". Most changes just switch >> old-style "(oop)"casts to new-style "cast_to_oop()" conversions. >> >> Thank you and best regards, >> Volker > > From volker.simonis at gmail.com Tue Nov 19 02:09:22 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Nov 2013 11:09:22 +0100 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: <528ABFAA.90904@oracle.com> References: <528ABFAA.90904@oracle.com> Message-ID: Hi David, I've changed the cast to (void*) as suggested by Lois. Thanks, Volker On Tue, Nov 19, 2013 at 2:32 AM, David Holmes wrote: > On 19/11/2013 2:45 AM, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following small webrev which fixes the >> CPP-interpreter after "CheckUnhandledOops" was re-enabled in the >> fastdebug build: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8028514/ >> >> All the changes are in CPP-interpreter specific files or in code which >> is protected by "#ifdef CC_INTERP". Most changes just switch >> old-style "(oop)"casts to new-style "cast_to_oop()" conversions. > > > Why do we have use of INTPTR_FORMAT but a cast_from_oop ? ie > mixing signed with unsigned. > > Otherwise looks ok. > > Thanks, > David > > >> Thank you and best regards, >> Volker >> > From lois.foltan at oracle.com Tue Nov 19 03:54:42 2013 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 19 Nov 2013 06:54:42 -0500 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: References: <528ACE8A.1080505@oracle.com> Message-ID: <528B5182.7010106@oracle.com> On 11/19/2013 5:08 AM, Volker Simonis wrote: > Hi Lois, > > thanks for your review. Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8028514.v2/ > > Please find my comments inline: > > On Tue, Nov 19, 2013 at 3:35 AM, Lois Foltan wrote: >> Hi Volker, >> >> I do have a few review comments: >> >> src/cpu/ppc/vm/frame_ppc.cpp >> - The "cast_to_oop(NULL)" I believe could be simplified to >> "(oop)NULL" see similar code in >> src/cpu/x86/vm/frame_x86.cpp. >> > I was not sure here and wanted to make the conversion explicit, > because NULL is actually the integer constant 'zero' and there's no > special oop constructor for integers. But if the compiler doesn't > complain and if it works on x86 I can change it as you suggested. HI Volker, Exactly, it is dependent upon how NULL is defined. If the simplification is not compilable, than I am okay with the original change. > >> src/share/vm/interpreter/bytecodeInterpreter.cpp >> - I have attached the recent RFR for supporting CHECK_UNHANDLED_OOPS >> across the platforms. >> It contains the summary outlining the changes. Please change your >> "cast_from_oop" >> within tty->print_cr() to "(void *)" as described in summary note item >> #3. > You're right, I missed the (void*)operator in the oop class. I changed > it the way you suggested. Thank you, I have reviewed. Looks good. Lois > > Thanks, > Volker > >> Thank you, >> Lois >> >> >> On 11/18/2013 11:45 AM, Volker Simonis wrote: >>> Hi, >>> >>> could you please review the following small webrev which fixes the >>> CPP-interpreter after "CheckUnhandledOops" was re-enabled in the >>> fastdebug build: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8028514/ >>> >>> All the changes are in CPP-interpreter specific files or in code which >>> is protected by "#ifdef CC_INTERP". Most changes just switch >>> old-style "(oop)"casts to new-style "cast_to_oop()" conversions. >>> >>> Thank you and best regards, >>> Volker >> From goetz.lindenmaier at sap.com Tue Nov 19 03:58:14 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Nov 2013 11:58:14 +0000 Subject: RFR(M): 8028580: PPC64 (part 114/120): Support for Call nodes with constants. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66E4C@DEWDFEMB12A.global.corp.sap> Hi, C2 Call nodes use several constant values. So far C2 does not support placing these values in the constant table of the nmethod. Among others, these constants are - the called address - the inline cache - values required by the C-calling convention (on PPC, env pointer and toc from function descriptor) This change extends Call nodes so that they can issue constants to the constant table. http://cr.openjdk.java.net/~goetz/webrevs/8028580-0-call/ - Extend adlc to add edge to MachConstantBaseNode if $constanttablebase is used in the specification. - Extend Call nodes to deliver proper register mask to register allocation for this new input. - Add method ins_num_consts() so that number of required constants can be specified in the call node. - Extend output() so that it reserves space for the constants in the Calls, using ins_num_consts(). Please review and test this change. Thanks and best regards, Goetz. From goetz.lindenmaier at sap.com Tue Nov 19 04:00:03 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Nov 2013 12:00:03 +0000 Subject: opto: How to use MachConstantBase with Call nodes -- needed for ppc port References: <4295855A5C1DE049A61835A1887419CC0D039EEA@DEWDFEMB12A.global.corp.sap> <527C2487.4020800@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66E5B@DEWDFEMB12A.global.corp.sap> Hi, I started a new thread to review 8028580, which I implemented based on the discussion in this thread. Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 8. November 2013 15:54 To: 'Vladimir Kozlov'; hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Christian Thalinger Subject: RE: opto: How to use MachConstantBase with Call nodes -- needed for ppc port Hi Vladimir, > Yes, it would be nice to avoid graph walk. Well, the graph walk would only be there on PPC, but it's a lot of overhead. > Can you extend what we already do for safepoints on sparc?: Yes, I think that would be a way to do it. I could add MachCallNode::needs_constant_base_input() on all platforms. If set, matcher adds MachConstantBaseNode to the call nodes behind the arguments, before jvms inputs and adapts the jvms offsets. For register allocation, I would have to pimp _in_rms/in_RegMask() in some way. Probably I need to add something to the ad file that gives the register mask to use. This solution does not allow to add TEMP operands to Call nodes, which would be nice, too. But that's not necessary, just a nice-to-have. I'll implement it and come back to you if I have to do something I consider ugly ;) Best regards and thanks for your tips, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Freitag, 8. November 2013 00:39 To: Lindenmaier, Goetz; hotspot-dev developers; ppc-aix-port-dev at openjdk.java.net; Christian Thalinger Subject: Re: opto: How to use MachConstantBase with Call nodes -- needed for ppc port Goetz, Yes, it would be nice to avoid graph walk. Can you extend what we already do for safepoints on sparc?: void Parse::add_safepoint() { // See if we can avoid this safepoint. No need for a SafePoint immediately // after a Call (except Leaf Call) or another SafePoint. Node *proj = control(); bool add_poll_param = SafePointNode::needs_polling_address_input(); uint parms = add_poll_param ? TypeFunc::Parms+1 : TypeFunc::Parms; It looks like we handle similar situation with simple Safepoint node adding an edge before debug info as you suggested but it will be normal ideal graph edge with input Con node. I am fine if you do it in C2 code directly (but with a lot of testing) because on our platforms we will not use it. Regards, Vladimir On 10/7/13 2:54 AM, Lindenmaier, Goetz wrote: > Hi, > > This is part of the ppc port, but I would like some advice before I open a > bug and prepare a webrev. > > The next change I would like to prepare will be based on this patch: > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/ppc_patches/0114_opto-hook_to_postprocess_matcher_output_platform_dependent.patch > The method introduced there is later filled with code on ppc: > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/e6d09cebf92d/src/cpu/ppc/vm/compile_ppc.cpp > > This introduces a walk over the IR after matching, before gcm. In that walk > we add MachConstantBaseNode to the call nodes (CallDynamicJava, CallLeaf and > CallLeafNoFP). > There are two problems why we need this: > > - The functionality to automatically generate an input of MachConstantBaseNode > only works with subclasses of MachConstantNode. > > - Call nodes can not have ordinary operands with ins. > > We decided to implement this additional walk over the IR because it was the solution > with the least change to shared code. > > Actually I would prefer a solution that gets along without this walk. > This would be possible by adding support for ordinary ins/operands in Call nodes. > The ins could be: > [[The 5 basic operands] [the params] [new: the ordinary ins as specified by operands] [the jvms ins] [oop_map ins]] > > oper_input_base() would have to return something like 'TypeFunc::Parms + tf()->_domain->_cnt', > and we would have to add oper_input_end() which does a loop over the opers > and counts the ins required: > oper_input_end() { > int end = oper_input_base() > for (uint i = 1; i < num_opnds(); ++i) { end += _opnds[i]->num_edges(); } > return end; > } > Also, jvms->locoff() etc would have to depend on oper_input_end() in some way. > > Alternatively, one could put the ordinary ins behind jvms, then > oper_input_base() would have to return jvms->endoff(), > and oop_maps would have to use oper_input_end() to locate their first in. > > Further, I would have to add a new MachOperand that represents the > ConstantBase > > What do you think? Would you rather prefer the existing solution, > or should I try to implement what I described? Do you have a better > idea how to add the ConstantBase to Calls? > > Best regards, > Goetz. > From david.holmes at oracle.com Tue Nov 19 11:07:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Nov 2013 05:07:57 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> Message-ID: <528BB70D.70007@oracle.com> So I like the rename but I am concerned there are semantic issues here: switch(id) { case vmIntrinsics::_loadFence: - insert_mem_bar(Op_MemBarAcquire); + insert_mem_bar(Op_MemBarFenceAcquire); return true; case vmIntrinsics::_storeFence: - insert_mem_bar(Op_MemBarRelease); + insert_mem_bar(Op_MemBarFenceRelease); return true; What is a _loadFence operation? Does it really map to MembarFenceAcquire? Ditto for the _storeFence. These sound like bi-directional fences - are they? Are they really only concerned with loads or stores ? David On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: > Hi, > > I made a new webrev, using the new names: > http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ > > Thanks, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Montag, 18. November 2013 23:28 > To: Lindenmaier, Goetz; 'David Holmes' > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >> Hi David, Vladimir, >> >> I also would prefer MemBarFenceAquire/Release, for two reasons >> - the same prefix shows they are all similar nodes. >> - I don't have to change MemBarVolatile to FullFence, which I didn't >> change yet and which is used in more places. > > Okay. > > Vladimir > >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Monday, November 18, 2013 10:49 PM >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> Vladimir, >> >> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>> I think David asked for different nodes not just one. >>> We can have new membar nodes with names matching Unsafe methods names: >>> LoadFence, StoreFence, FullFence. I am fine with it. >> >> But I don't think that actually describes them - they don't distinguish >> between loads and stores only the direction in which the barrier >> operates. "acquire" only allows accesses to move below it; "release" >> only allows accesses to move above it ie: >> >> load a >> store b, c >> acquire(); >> load d >> store e,f >> release(); >> load g >> store h, i >> >> allows the loads of 'a' and 'g' to move into the region between acquire >> and release; similarly for the stores to b and h. But the load of d nor >> the store to e can not move in relation to either acquire or release. >> >> Thanks, >> David >> >>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> as reply to your comment on the bug: >>>> >>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>> MemBarAcquireWide --> lwsync >>>> MemBarReleaseWide --> lwsync >>>> MemBarVolatile --> sync. >>>> On Sparc, you even do 3 different operations. >>>> >>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>> This all depends a lot on the available instructions of the processors. >>>> Therefore I think a really clean representation that, at the same >>>> time, allows >>>> to find the cheapest set of instructions to express it on all >>>> processors, is impossible. >>>> >>>> Best regards, >>>> Goetz >>>> >>>> PS: Should I respond to comments in the bug right in the bug >>>> or on the mailing lists? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>> Lindenmaier, Goetz >>>> Sent: Montag, 18. November 2013 15:19 >>>> To: 'hotspot-dev at openjdk.java.net'; >>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>> MemBarAcquire/ReleaseWide. >>>> >>>> Hi, >>>> >>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>> ordering in various places. Some order a certain load/store with other >>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>> correspont to a memory operation. So far, the same nodes were used. >>>> >>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>> dedicated load/store is ordered. With this change, these nodes can be >>>> matched differently, what is needed on PPC64. >>>> >>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>> >>>> Please review and test this change. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>> >>>> Best regards, >>>> Goetz. >>>> From david.holmes at oracle.com Tue Nov 19 11:11:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Nov 2013 05:11:44 +1000 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: References: <528ACE8A.1080505@oracle.com> Message-ID: <528BB7F0.8010307@oracle.com> Thanks Volker - nothing further from me. David On 19/11/2013 8:08 PM, Volker Simonis wrote: > Hi Lois, > > thanks for your review. Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8028514.v2/ > > Please find my comments inline: > > On Tue, Nov 19, 2013 at 3:35 AM, Lois Foltan wrote: >> Hi Volker, >> >> I do have a few review comments: >> >> src/cpu/ppc/vm/frame_ppc.cpp >> - The "cast_to_oop(NULL)" I believe could be simplified to >> "(oop)NULL" see similar code in >> src/cpu/x86/vm/frame_x86.cpp. >> > > I was not sure here and wanted to make the conversion explicit, > because NULL is actually the integer constant 'zero' and there's no > special oop constructor for integers. But if the compiler doesn't > complain and if it works on x86 I can change it as you suggested. > >> src/share/vm/interpreter/bytecodeInterpreter.cpp >> - I have attached the recent RFR for supporting CHECK_UNHANDLED_OOPS >> across the platforms. >> It contains the summary outlining the changes. Please change your >> "cast_from_oop" >> within tty->print_cr() to "(void *)" as described in summary note item >> #3. > > You're right, I missed the (void*)operator in the oop class. I changed > it the way you suggested. > > Thanks, > Volker > >> >> Thank you, >> Lois >> >> >> On 11/18/2013 11:45 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following small webrev which fixes the >>> CPP-interpreter after "CheckUnhandledOops" was re-enabled in the >>> fastdebug build: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8028514/ >>> >>> All the changes are in CPP-interpreter specific files or in code which >>> is protected by "#ifdef CC_INTERP". Most changes just switch >>> old-style "(oop)"casts to new-style "cast_to_oop()" conversions. >>> >>> Thank you and best regards, >>> Volker >> >> From balchandra.vaidya at oracle.com Tue Nov 19 08:35:44 2013 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Tue, 19 Nov 2013 16:35:44 +0000 Subject: Testing Groovy against JDK 8 EA builds In-Reply-To: <528B83D2.6020802@gmx.org> References: <528B5CD2.9010606@oracle.com> <528B83D2.6020802@gmx.org> Message-ID: <528B9360.1010601@oracle.com> Hi Jochen, There could be multiple issues here and will require further information. I am copying hotspot-dev mailing list for further guidance. Thanks Balchandra On 11/19/13 03:29 PM, Jochen Theodorou wrote: > > Hi all, > > Dalibor and Rory suggested I comment on how well Groovy works with > jdk8-ea. I thought I write directly to the mailing list here to share > the problems. > > So I used 1.8.0-ea-b115 and run our test suite to give a short > overview. Of course we have to look into those issues in detail at > some point. Anyway, we get 31 (out of 6107) failing tests. > > All failures seem to be related to default methods. > > We have some helper methods we add to our classes and for example a > class extending LinkedList gets a helper method stream() and tries to > call it with invokeSpecial. The result is a VerifyError. The majority > of problems are like that. Of course that means tests involving these > classes have not been executed. > > We get also several null pointer exceptions, which seem to be related > to List#sort. We ourselves provide a sort(Comparable) method on > Iterable, but that method returns a List. The default method > List#sort(Comparable) is void and hides the Iterable one, thus the > method will return null and subsequent calls on the result fail with > NPEs. > > Those name clashes are a bit problem here I must say. Sure, we can > rename our method, but numerous examples out there use it. And worse, > our method is not mutating, the jdk one is. I am not yet sure what we > will do about that in general. > > bye Jochen > From benjamin.john.evans at gmail.com Tue Nov 19 08:40:38 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 19 Nov 2013 16:40:38 +0000 Subject: Testing Groovy against JDK 8 EA builds In-Reply-To: <528B9360.1010601@oracle.com> References: <528B5CD2.9010606@oracle.com> <528B83D2.6020802@gmx.org> <528B9360.1010601@oracle.com> Message-ID: I would recommend also talking to Brian & the Lambdas EG. Ben On Tue, Nov 19, 2013 at 4:35 PM, Balchandra Vaidya < balchandra.vaidya at oracle.com> wrote: > > Hi Jochen, > > There could be multiple issues here and will require further > information. I am copying hotspot-dev mailing list for further > guidance. > > > Thanks > Balchandra > > > > > On 11/19/13 03:29 PM, Jochen Theodorou wrote: > >> >> Hi all, >> >> Dalibor and Rory suggested I comment on how well Groovy works with >> jdk8-ea. I thought I write directly to the mailing list here to share the >> problems. >> >> So I used 1.8.0-ea-b115 and run our test suite to give a short overview. >> Of course we have to look into those issues in detail at some point. >> Anyway, we get 31 (out of 6107) failing tests. >> >> All failures seem to be related to default methods. >> >> We have some helper methods we add to our classes and for example a class >> extending LinkedList gets a helper method stream() and tries to call it >> with invokeSpecial. The result is a VerifyError. The majority of problems >> are like that. Of course that means tests involving these classes have not >> been executed. >> >> We get also several null pointer exceptions, which seem to be related to >> List#sort. We ourselves provide a sort(Comparable) method on Iterable, but >> that method returns a List. The default method List#sort(Comparable) is >> void and hides the Iterable one, thus the method will return null and >> subsequent calls on the result fail with NPEs. >> >> Those name clashes are a bit problem here I must say. Sure, we can rename >> our method, but numerous examples out there use it. And worse, our method >> is not mutating, the jdk one is. I am not yet sure what we will do about >> that in general. >> >> bye Jochen >> >> > From karen.kinnear at oracle.com Tue Nov 19 11:28:10 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 19 Nov 2013 14:28:10 -0500 Subject: CFV: New hsx Committer: Eric McCorkle Message-ID: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx [0] Committer [1]. Eric McCorkle joined the langtools team over a year ago and in addition to the work he has contributed to the jdk, has been a significant contributor to the hotspot team. Specifically, he added the Method Parameter Annotations, including reflection, serviceability agent and redefineclasses support. He also has done some work in jni and jvm interfaces. In addition, Eric has been extremely helpful with the lambda default methods effort. Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). Only current hsx Committers [0] 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 [2] Regards, Karen Kinnear [0]http://openjdk.java.net/census/#hsx [1]http://openjdk.java.net/bylaws#committer [2]http://openjdk.java.net/projects/#committer-vote [3] list here: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 Eric also contributed the majority of the code changes to the following serviceability patch: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From david.holmes at oracle.com Tue Nov 19 11:30:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Nov 2013 05:30:33 +1000 Subject: Testing Groovy against JDK 8 EA builds In-Reply-To: <528B9360.1010601@oracle.com> References: <528B5CD2.9010606@oracle.com> <528B83D2.6020802@gmx.org> <528B9360.1010601@oracle.com> Message-ID: <528BBC59.5030705@oracle.com> The VerifyError is VM related and there are still ongoing changes as the spec settles and the implementation catches up. The List issue is something to discuss on lambda-dev. We know there are some source incompatabilities with default methods in Java 8. This is an accepted price to pay for moving the Java libraries forward. David On 20/11/2013 2:35 AM, Balchandra Vaidya wrote: > > Hi Jochen, > > There could be multiple issues here and will require further > information. I am copying hotspot-dev mailing list for further > guidance. > > > Thanks > Balchandra > > > > On 11/19/13 03:29 PM, Jochen Theodorou wrote: >> >> Hi all, >> >> Dalibor and Rory suggested I comment on how well Groovy works with >> jdk8-ea. I thought I write directly to the mailing list here to share >> the problems. >> >> So I used 1.8.0-ea-b115 and run our test suite to give a short >> overview. Of course we have to look into those issues in detail at >> some point. Anyway, we get 31 (out of 6107) failing tests. >> >> All failures seem to be related to default methods. >> >> We have some helper methods we add to our classes and for example a >> class extending LinkedList gets a helper method stream() and tries to >> call it with invokeSpecial. The result is a VerifyError. The majority >> of problems are like that. Of course that means tests involving these >> classes have not been executed. >> >> We get also several null pointer exceptions, which seem to be related >> to List#sort. We ourselves provide a sort(Comparable) method on >> Iterable, but that method returns a List. The default method >> List#sort(Comparable) is void and hides the Iterable one, thus the >> method will return null and subsequent calls on the result fail with >> NPEs. >> >> Those name clashes are a bit problem here I must say. Sure, we can >> rename our method, but numerous examples out there use it. And worse, >> our method is not mutating, the jdk one is. I am not yet sure what we >> will do about that in general. >> >> bye Jochen >> > From david.holmes at oracle.com Tue Nov 19 11:33:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Nov 2013 05:33:09 +1000 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BBCF5.3090809@oracle.com> Vote: yes David On 20/11/2013 5:28 AM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca > From goetz.lindenmaier at sap.com Tue Nov 19 11:34:37 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Nov 2013 19:34:37 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528BB70D.70007@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> Hi David, this are the instrinsics for sun/misc/Unsafe, which are documented as shown below. So I guess that's just what is desired. Best regards, Goetz. /** * Ensures lack of reordering of loads before the fence * with loads or stores after the fence. * @since 1.8 */ public native void loadFence(); /** * Ensures lack of reordering of stores before the fence * with loads or stores after the fence. * @since 1.8 */ public native void storeFence(); /** * Ensures lack of reordering of loads or stores before the fence * with loads or stores after the fence. * @since 1.8 */ public native void fullFence(); -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, November 19, 2013 8:08 PM To: Lindenmaier, Goetz Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. So I like the rename but I am concerned there are semantic issues here: switch(id) { case vmIntrinsics::_loadFence: - insert_mem_bar(Op_MemBarAcquire); + insert_mem_bar(Op_MemBarFenceAcquire); return true; case vmIntrinsics::_storeFence: - insert_mem_bar(Op_MemBarRelease); + insert_mem_bar(Op_MemBarFenceRelease); return true; What is a _loadFence operation? Does it really map to MembarFenceAcquire? Ditto for the _storeFence. These sound like bi-directional fences - are they? Are they really only concerned with loads or stores ? David On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: > Hi, > > I made a new webrev, using the new names: > http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ > > Thanks, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Montag, 18. November 2013 23:28 > To: Lindenmaier, Goetz; 'David Holmes' > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >> Hi David, Vladimir, >> >> I also would prefer MemBarFenceAquire/Release, for two reasons >> - the same prefix shows they are all similar nodes. >> - I don't have to change MemBarVolatile to FullFence, which I didn't >> change yet and which is used in more places. > > Okay. > > Vladimir > >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Monday, November 18, 2013 10:49 PM >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> Vladimir, >> >> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>> I think David asked for different nodes not just one. >>> We can have new membar nodes with names matching Unsafe methods names: >>> LoadFence, StoreFence, FullFence. I am fine with it. >> >> But I don't think that actually describes them - they don't distinguish >> between loads and stores only the direction in which the barrier >> operates. "acquire" only allows accesses to move below it; "release" >> only allows accesses to move above it ie: >> >> load a >> store b, c >> acquire(); >> load d >> store e,f >> release(); >> load g >> store h, i >> >> allows the loads of 'a' and 'g' to move into the region between acquire >> and release; similarly for the stores to b and h. But the load of d nor >> the store to e can not move in relation to either acquire or release. >> >> Thanks, >> David >> >>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> as reply to your comment on the bug: >>>> >>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>> MemBarAcquireWide --> lwsync >>>> MemBarReleaseWide --> lwsync >>>> MemBarVolatile --> sync. >>>> On Sparc, you even do 3 different operations. >>>> >>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>> This all depends a lot on the available instructions of the processors. >>>> Therefore I think a really clean representation that, at the same >>>> time, allows >>>> to find the cheapest set of instructions to express it on all >>>> processors, is impossible. >>>> >>>> Best regards, >>>> Goetz >>>> >>>> PS: Should I respond to comments in the bug right in the bug >>>> or on the mailing lists? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>> Lindenmaier, Goetz >>>> Sent: Montag, 18. November 2013 15:19 >>>> To: 'hotspot-dev at openjdk.java.net'; >>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>> MemBarAcquire/ReleaseWide. >>>> >>>> Hi, >>>> >>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>> ordering in various places. Some order a certain load/store with other >>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>> correspont to a memory operation. So far, the same nodes were used. >>>> >>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>> dedicated load/store is ordered. With this change, these nodes can be >>>> matched differently, what is needed on PPC64. >>>> >>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>> >>>> Please review and test this change. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>> >>>> Best regards, >>>> Goetz. >>>> From christian.tornqvist at oracle.com Tue Nov 19 11:35:29 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 19 Nov 2013 14:35:29 -0500 Subject: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <003a01cee55e$81ab8070$85028150$@oracle.com> Vote: yes -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Karen Kinnear Sent: Tuesday, November 19, 2013 2:28 PM To: hotspot-dev at openjdk.java.net developers Subject: CFV: New hsx Committer: Eric McCorkle I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx [0] Committer [1]. Eric McCorkle joined the langtools team over a year ago and in addition to the work he has contributed to the jdk, has been a significant contributor to the hotspot team. Specifically, he added the Method Parameter Annotations, including reflection, serviceability agent and redefineclasses support. He also has done some work in jni and jvm interfaces. In addition, Eric has been extremely helpful with the lambda default methods effort. Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). Only current hsx Committers [0] 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 [2] Regards, Karen Kinnear [0]http://openjdk.java.net/census/#hsx [1]http://openjdk.java.net/bylaws#committer [2]http://openjdk.java.net/projects/#committer-vote [3] list here: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 Eric also contributed the majority of the code changes to the following serviceability patch: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From vladimir.kozlov at oracle.com Tue Nov 19 11:44:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 11:44:14 -0800 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BBF8E.6080303@oracle.com> Vote: yes On 11/19/13 11:28 AM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca > From staffan.larsen at oracle.com Tue Nov 19 11:45:25 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 19 Nov 2013 20:45:25 +0100 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <3E6307F7-BC21-4B25-BA1A-9588BC169BC6@oracle.com> Vote: yes /Staffan On 19 nov 2013, at 20:28, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From david.holmes at oracle.com Tue Nov 19 11:50:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Nov 2013 05:50:38 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> Message-ID: <528BC10E.3030802@oracle.com> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: > Hi David, > > this are the instrinsics for sun/misc/Unsafe, which are documented > as shown below. So I guess that's just what is desired. I don't think so! What is described for Unsafe are full bi-directional fences and "acquire" and "release" are only uni-directional fences! David ----- > Best regards, > Goetz. > > /** > * Ensures lack of reordering of loads before the fence > * with loads or stores after the fence. > * @since 1.8 > */ > public native void loadFence(); > > /** > * Ensures lack of reordering of stores before the fence > * with loads or stores after the fence. > * @since 1.8 > */ > public native void storeFence(); > > /** > * Ensures lack of reordering of loads or stores before the fence > * with loads or stores after the fence. > * @since 1.8 > */ > public native void fullFence(); > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 19, 2013 8:08 PM > To: Lindenmaier, Goetz > Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > So I like the rename but I am concerned there are semantic issues here: > > switch(id) { > case vmIntrinsics::_loadFence: > - insert_mem_bar(Op_MemBarAcquire); > + insert_mem_bar(Op_MemBarFenceAcquire); > return true; > case vmIntrinsics::_storeFence: > - insert_mem_bar(Op_MemBarRelease); > + insert_mem_bar(Op_MemBarFenceRelease); > return true; > > What is a _loadFence operation? Does it really map to > MembarFenceAcquire? Ditto for the _storeFence. These sound like > bi-directional fences - are they? Are they really only concerned with > loads or stores ? > > David > > On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I made a new webrev, using the new names: >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >> >> Thanks, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Montag, 18. November 2013 23:28 >> To: Lindenmaier, Goetz; 'David Holmes' >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>> Hi David, Vladimir, >>> >>> I also would prefer MemBarFenceAquire/Release, for two reasons >>> - the same prefix shows they are all similar nodes. >>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>> change yet and which is used in more places. >> >> Okay. >> >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Monday, November 18, 2013 10:49 PM >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> Vladimir, >>> >>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>> I think David asked for different nodes not just one. >>>> We can have new membar nodes with names matching Unsafe methods names: >>>> LoadFence, StoreFence, FullFence. I am fine with it. >>> >>> But I don't think that actually describes them - they don't distinguish >>> between loads and stores only the direction in which the barrier >>> operates. "acquire" only allows accesses to move below it; "release" >>> only allows accesses to move above it ie: >>> >>> load a >>> store b, c >>> acquire(); >>> load d >>> store e,f >>> release(); >>> load g >>> store h, i >>> >>> allows the loads of 'a' and 'g' to move into the region between acquire >>> and release; similarly for the stores to b and h. But the load of d nor >>> the store to e can not move in relation to either acquire or release. >>> >>> Thanks, >>> David >>> >>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> as reply to your comment on the bug: >>>>> >>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>> MemBarAcquireWide --> lwsync >>>>> MemBarReleaseWide --> lwsync >>>>> MemBarVolatile --> sync. >>>>> On Sparc, you even do 3 different operations. >>>>> >>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>> This all depends a lot on the available instructions of the processors. >>>>> Therefore I think a really clean representation that, at the same >>>>> time, allows >>>>> to find the cheapest set of instructions to express it on all >>>>> processors, is impossible. >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>> PS: Should I respond to comments in the bug right in the bug >>>>> or on the mailing lists? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>> Lindenmaier, Goetz >>>>> Sent: Montag, 18. November 2013 15:19 >>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>> MemBarAcquire/ReleaseWide. >>>>> >>>>> Hi, >>>>> >>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>> ordering in various places. Some order a certain load/store with other >>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>> correspont to a memory operation. So far, the same nodes were used. >>>>> >>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>> matched differently, what is needed on PPC64. >>>>> >>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>> >>>>> Please review and test this change. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From coleen.phillimore at oracle.com Tue Nov 19 11:51:10 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Nov 2013 14:51:10 -0500 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BC12E.2060602@oracle.com> Vote: yes On 11/19/2013 02:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From serguei.spitsyn at oracle.com Tue Nov 19 11:56:12 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Nov 2013 11:56:12 -0800 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BC25C.1090001@oracle.com> Vote: yes From harold.seigel at oracle.com Tue Nov 19 12:12:28 2013 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 19 Nov 2013 15:12:28 -0500 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BC62C.4000500@oracle.com> Vote: yes On 11/19/2013 2:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From vladimir.kozlov at oracle.com Tue Nov 19 12:29:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 12:29:22 -0800 Subject: RFR(S): 8028514: PPC64: Fix C++ Interpreter after '7195622: CheckUnhandledOops has limited usefulness now' In-Reply-To: <528BB7F0.8010307@oracle.com> References: <528ACE8A.1080505@oracle.com> <528BB7F0.8010307@oracle.com> Message-ID: <528BCA22.8040203@oracle.com> I submitted JPRT job to push the fix. Thanks, Vladimir On 11/19/13 11:11 AM, David Holmes wrote: > Thanks Volker - nothing further from me. > > David > > On 19/11/2013 8:08 PM, Volker Simonis wrote: >> Hi Lois, >> >> thanks for your review. Here's the new webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8028514.v2/ >> >> Please find my comments inline: >> >> On Tue, Nov 19, 2013 at 3:35 AM, Lois Foltan >> wrote: >>> Hi Volker, >>> >>> I do have a few review comments: >>> >>> src/cpu/ppc/vm/frame_ppc.cpp >>> - The "cast_to_oop(NULL)" I believe could be simplified to >>> "(oop)NULL" see similar code in >>> src/cpu/x86/vm/frame_x86.cpp. >>> >> >> I was not sure here and wanted to make the conversion explicit, >> because NULL is actually the integer constant 'zero' and there's no >> special oop constructor for integers. But if the compiler doesn't >> complain and if it works on x86 I can change it as you suggested. >> >>> src/share/vm/interpreter/bytecodeInterpreter.cpp >>> - I have attached the recent RFR for supporting >>> CHECK_UNHANDLED_OOPS >>> across the platforms. >>> It contains the summary outlining the changes. Please change >>> your >>> "cast_from_oop" >>> within tty->print_cr() to "(void *)" as described in summary >>> note item >>> #3. >> >> You're right, I missed the (void*)operator in the oop class. I changed >> it the way you suggested. >> >> Thanks, >> Volker >> >>> >>> Thank you, >>> Lois >>> >>> >>> On 11/18/2013 11:45 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> could you please review the following small webrev which fixes the >>>> CPP-interpreter after "CheckUnhandledOops" was re-enabled in the >>>> fastdebug build: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/8028514/ >>>> >>>> All the changes are in CPP-interpreter specific files or in code which >>>> is protected by "#ifdef CC_INTERP". Most changes just switch >>>> old-style "(oop)"casts to new-style "cast_to_oop()" conversions. >>>> >>>> Thank you and best regards, >>>> Volker >>> >>> From daniel.daugherty at oracle.com Tue Nov 19 12:33:58 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Nov 2013 13:33:58 -0700 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BCB36.7080407@oracle.com> Vote: yes Dan On 11/19/13 12:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca > From john.r.rose at oracle.com Tue Nov 19 13:23:23 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Nov 2013 13:23:23 -0800 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <9FE9F082-3480-4012-B4B5-C9F5F163AFDF@oracle.com> Vote: yes! Changes are of the required raw bulk, *worse* than typical internal cancellation (code churn), and much better than average system-facing complexity. I would consider vetoing a similar committer proposal that was (a) minimally sized and (b) had a significant degree of internal cancellation (code churn) and (c) had no other claim to significance. Point (c) is *not* the case here. Detailed comments: The changesets presented, in physical size, are average representatives of what is already in the repository. The size of "hg diff -c $rev" can be expected (as a rule of thumb) to be about 300 lines, or about 10k-12k bytes. Eric's 8 changes match this almost exactly. (I just rechecked those numbers on 100 recent non-merge changesets in hotspot-main, dates 9/18 - 10/18, with and without outer quartiles.) There is a potential significance problem in Eric's changes, however, because they represent a certain amount of "code churn": Some of the change sets cancel out previous changes in the same group of 8. This is decisively counteracted by the fact that Eric's changes are very deep, with linkage to JDK changes and classfile spec. changes, and by other supporting comments Karen made in her call for votes. In this case some (not all) of the churn was driven by external changes (the size of the flags field in the new attribute). I point this out because, based on my reading of the bylaws, I expect a candidate committer's "portfolio" of eight or more changes to be at least of average significance relative to the existing repository. For me, that starts with an expected bulk on the order of 8 changes averaging 300 LOC and 10kb. The bulk can be reduced by significant internal cancellations (code churn). The result will always be adjusted by ad hoc measures of significance, such as difficulty or architectural interconnectedness of changes. From vladimir.kozlov at oracle.com Tue Nov 19 14:04:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 14:04:16 -0800 Subject: RFR(M): 8028580: PPC64 (part 114/120): Support for Call nodes with constants. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE66E4C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66E4C@DEWDFEMB12A.global.corp.sap> Message-ID: <528BE060.60401@oracle.com> It is much better than I expected! This is too good to be true :) Are you sure it is complete changes? Few small notes: Could you, please, change code (new and old) in in_RegMask() methods you touched in machnode.cpp to put 'return' on separate line after condition and use {} ? I think the next code should be more general where you loop over all const inputs and ask each one for size: add_size += (n->as_Mach()->ins_num_consts() * 8); In ConstantTable::calculate_offsets_and_size() we have: int typesize = type_to_size_in_bytes(con->type()); offset = align_size_up(offset, typesize); Thanks, Vladimir On 11/19/13 3:58 AM, Lindenmaier, Goetz wrote: > Hi, > > C2 Call nodes use several constant values. So far C2 does not > support placing these values in the constant table of the nmethod. > > Among others, these constants are > - the called address > - the inline cache > - values required by the C-calling convention (on PPC, env pointer > and toc from function descriptor) > > This change extends Call nodes so that they can issue constants > to the constant table. > http://cr.openjdk.java.net/~goetz/webrevs/8028580-0-call/ > > - Extend adlc to add edge to MachConstantBaseNode if > $constanttablebase is used in the specification. > - Extend Call nodes to deliver proper register mask to > register allocation for this new input. > - Add method ins_num_consts() so that number of required > constants can be specified in the call node. > - Extend output() so that it reserves space for the > constants in the Calls, using ins_num_consts(). > > Please review and test this change. > > Thanks and best regards, > Goetz. > From christian.thalinger at oracle.com Tue Nov 19 14:13:01 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Nov 2013 14:13:01 -0800 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: Vote: yes On Nov 19, 2013, at 11:28 AM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From alejandro.murillo at oracle.com Tue Nov 19 14:53:03 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 19 Nov 2013 15:53:03 -0700 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528BEBCF.30200@oracle.com> vote: yes -- Alejandro From goetz.lindenmaier at sap.com Tue Nov 19 15:24:51 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 19 Nov 2013 23:24:51 +0000 Subject: RFR(M): 8028580: PPC64 (part 114/120): Support for Call nodes with constants. In-Reply-To: <528BE060.60401@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66E4C@DEWDFEMB12A.global.corp.sap> <528BE060.60401@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE670DF@DEWDFEMB12A.global.corp.sap> Hi Vladimir, > I think the next code should be more general I know what you mean. But I have no way to find out what kind of constant the nodes will put into the table. So I can not check for their size in this loop. That's all hidden in the emitters, which are platform dependent. So I must assume 8 bytes of size. Therefore I proposed to move the functionality from MachConstantNode to operands, and add operands to calls (similar to TEMP operands). Then I could check the operands in this loop and find out about the constants But I guess that's far more change, out of scope for the PPC port. I updated the webrev with the improved formatting. Thanks a lot for the review! Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, November 19, 2013 11:04 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8028580: PPC64 (part 114/120): Support for Call nodes with constants. It is much better than I expected! This is too good to be true :) Are you sure it is complete changes? Few small notes: Could you, please, change code (new and old) in in_RegMask() methods you touched in machnode.cpp to put 'return' on separate line after condition and use {} ? I think the next code should be more general where you loop over all const inputs and ask each one for size: add_size += (n->as_Mach()->ins_num_consts() * 8); In ConstantTable::calculate_offsets_and_size() we have: int typesize = type_to_size_in_bytes(con->type()); offset = align_size_up(offset, typesize); Thanks, Vladimir On 11/19/13 3:58 AM, Lindenmaier, Goetz wrote: > Hi, > > C2 Call nodes use several constant values. So far C2 does not > support placing these values in the constant table of the nmethod. > > Among others, these constants are > - the called address > - the inline cache > - values required by the C-calling convention (on PPC, env pointer > and toc from function descriptor) > > This change extends Call nodes so that they can issue constants > to the constant table. > http://cr.openjdk.java.net/~goetz/webrevs/8028580-0-call/ > > - Extend adlc to add edge to MachConstantBaseNode if > $constanttablebase is used in the specification. > - Extend Call nodes to deliver proper register mask to > register allocation for this new input. > - Add method ins_num_consts() so that number of required > constants can be specified in the call node. > - Extend output() so that it reserves space for the > constants in the Calls, using ins_num_consts(). > > Please review and test this change. > > Thanks and best regards, > Goetz. > From vladimir.kozlov at oracle.com Tue Nov 19 15:35:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Nov 2013 15:35:39 -0800 Subject: RFR(M): 8028580: PPC64 (part 114/120): Support for Call nodes with constants. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE670DF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66E4C@DEWDFEMB12A.global.corp.sap> <528BE060.60401@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE670DF@DEWDFEMB12A.global.corp.sap> Message-ID: <528BF5CB.2060505@oracle.com> On 11/19/13 3:24 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> I think the next code should be more general > I know what you mean. But I have no way to find out what kind of constant the > nodes will put into the table. So I can not check for their size in this loop. > That's all hidden in the emitters, which are platform dependent. > So I must assume 8 bytes of size. Add comment that code reserves maximum expected size for referenced constants since we don't know actual size at this point. And may be use sizeof(jlong) instead of 8. Thanks, Vladimir > > Therefore I proposed to move the functionality from MachConstantNode > to operands, and add operands to calls (similar to TEMP operands). Then > I could check the operands in this loop and find out about the constants > But I guess that's far more change, out of scope for the PPC port. > > I updated the webrev with the improved formatting. > > Thanks a lot for the review! > Best regards, > Goetz > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, November 19, 2013 11:04 PM > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028580: PPC64 (part 114/120): Support for Call nodes with constants. > > It is much better than I expected! > This is too good to be true :) Are you sure it is complete changes? > > Few small notes: > > Could you, please, change code (new and old) in in_RegMask() methods you > touched in machnode.cpp to put 'return' on separate line after condition > and use {} ? > > I think the next code should be more general where you loop over all > const inputs and ask each one for size: > > add_size += (n->as_Mach()->ins_num_consts() * 8); > > In ConstantTable::calculate_offsets_and_size() we have: > > int typesize = type_to_size_in_bytes(con->type()); > offset = align_size_up(offset, typesize); > > Thanks, > Vladimir > > On 11/19/13 3:58 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> C2 Call nodes use several constant values. So far C2 does not >> support placing these values in the constant table of the nmethod. >> >> Among others, these constants are >> - the called address >> - the inline cache >> - values required by the C-calling convention (on PPC, env pointer >> and toc from function descriptor) >> >> This change extends Call nodes so that they can issue constants >> to the constant table. >> http://cr.openjdk.java.net/~goetz/webrevs/8028580-0-call/ >> >> - Extend adlc to add edge to MachConstantBaseNode if >> $constanttablebase is used in the specification. >> - Extend Call nodes to deliver proper register mask to >> register allocation for this new input. >> - Add method ins_num_consts() so that number of required >> constants can be specified in the call node. >> - Extend output() so that it reserves space for the >> constants in the Calls, using ins_num_consts(). >> >> Please review and test this change. >> >> Thanks and best regards, >> Goetz. >> From david.r.chase at oracle.com Tue Nov 19 17:18:28 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 19 Nov 2013 20:18:28 -0500 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <528BEBCF.30200@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> <528BEBCF.30200@oracle.com> Message-ID: <9C416865-3050-49CD-B875-B5E7CED33C24@oracle.com> vote: yes From blackdrag at gmx.org Wed Nov 20 00:51:14 2013 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 20 Nov 2013 09:51:14 +0100 Subject: Testing Groovy against JDK 8 EA builds In-Reply-To: <528B9360.1010601@oracle.com> References: <528B5CD2.9010606@oracle.com> <528B83D2.6020802@gmx.org> <528B9360.1010601@oracle.com> Message-ID: <528C7802.3030004@gmx.org> > The VerifyError is VM related and there are still ongoing changes as the > spec settles and the implementation catches up. can you tell me which invoke instruction are how supposed to be able to call default methods? I am sure that if Foo implements Bar and bar() is a default method on Bar, that an invokevirtual Foo#bar() is supposed to be ok. But what about invokespecial on Bar#bar (like a super call)? > The List issue is something to discuss on lambda-dev. We know there are > some source incompatabilities with default methods in Java 8. This is an > accepted price to pay for moving the Java libraries forward. it is not a source incompatibility for us, but since it is Groovy code, not Java code that might be another story bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From frederic.parain at oracle.com Wed Nov 20 00:51:35 2013 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 20 Nov 2013 09:51:35 +0100 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528C7817.1010906@oracle.com> Vote: yes Fred On 11/19/2013 08:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From goetz.lindenmaier at sap.com Wed Nov 20 01:37:22 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Nov 2013 09:37:22 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528BC10E.3030802@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE671EE@DEWDFEMB12A.global.corp.sap> Hi David, I don't know what you mean by uni/bi-directional. I guess we agree that the documentation of the intrinsics, let's take loadFence for an example, talks about loads before the loadFence, and stores and loads after it: loads ------------loadFence()-------------- loads, stores With this, you can achieve any ordering by moving nodes up OR down: Op1 Move Op1 Op2 Op2 down ------------- --------- =========> Op3 Op3 Op1 Alternatively, you can move op3 up, and get the same order: Op1 Reorder Op2 Move Op3 Op2 Op2 Ops 1 and 2 Op1 up Op3 --------- =========> -------------- =========> Op1 Op3 Not restricted Op3 ---------- by later loadFence So, if the operation restricts only moves in one direction, it's of no help because you can still get an execution order you did not expect. So unidirectional operations (e.g., only hindering operations from moving up) are pointless. By the way, are you questioning whether the implementation is correct, or whether the names express what is desired? If it's the first, it's of no concern to this change, which is only about matching these operations independently from those, that address a dedicated memory operation. If It's the second, please tell me what names to use, and I'll fix it. (I hope you can properly read the 'drawings') Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Dienstag, 19. November 2013 20:51 To: Lindenmaier, Goetz Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: > Hi David, > > this are the instrinsics for sun/misc/Unsafe, which are documented > as shown below. So I guess that's just what is desired. I don't think so! What is described for Unsafe are full bi-directional fences and "acquire" and "release" are only uni-directional fences! David ----- > Best regards, > Goetz. > > /** > * Ensures lack of reordering of loads before the fence > * with loads or stores after the fence. > * @since 1.8 > */ > public native void loadFence(); > > /** > * Ensures lack of reordering of stores before the fence > * with loads or stores after the fence. > * @since 1.8 > */ > public native void storeFence(); > > /** > * Ensures lack of reordering of loads or stores before the fence > * with loads or stores after the fence. > * @since 1.8 > */ > public native void fullFence(); > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 19, 2013 8:08 PM > To: Lindenmaier, Goetz > Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > So I like the rename but I am concerned there are semantic issues here: > > switch(id) { > case vmIntrinsics::_loadFence: > - insert_mem_bar(Op_MemBarAcquire); > + insert_mem_bar(Op_MemBarFenceAcquire); > return true; > case vmIntrinsics::_storeFence: > - insert_mem_bar(Op_MemBarRelease); > + insert_mem_bar(Op_MemBarFenceRelease); > return true; > > What is a _loadFence operation? Does it really map to > MembarFenceAcquire? Ditto for the _storeFence. These sound like > bi-directional fences - are they? Are they really only concerned with > loads or stores ? > > David > > On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I made a new webrev, using the new names: >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >> >> Thanks, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Montag, 18. November 2013 23:28 >> To: Lindenmaier, Goetz; 'David Holmes' >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>> Hi David, Vladimir, >>> >>> I also would prefer MemBarFenceAquire/Release, for two reasons >>> - the same prefix shows they are all similar nodes. >>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>> change yet and which is used in more places. >> >> Okay. >> >> Vladimir >> >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Monday, November 18, 2013 10:49 PM >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> Vladimir, >>> >>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>> I think David asked for different nodes not just one. >>>> We can have new membar nodes with names matching Unsafe methods names: >>>> LoadFence, StoreFence, FullFence. I am fine with it. >>> >>> But I don't think that actually describes them - they don't distinguish >>> between loads and stores only the direction in which the barrier >>> operates. "acquire" only allows accesses to move below it; "release" >>> only allows accesses to move above it ie: >>> >>> load a >>> store b, c >>> acquire(); >>> load d >>> store e,f >>> release(); >>> load g >>> store h, i >>> >>> allows the loads of 'a' and 'g' to move into the region between acquire >>> and release; similarly for the stores to b and h. But the load of d nor >>> the store to e can not move in relation to either acquire or release. >>> >>> Thanks, >>> David >>> >>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> as reply to your comment on the bug: >>>>> >>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>> MemBarAcquireWide --> lwsync >>>>> MemBarReleaseWide --> lwsync >>>>> MemBarVolatile --> sync. >>>>> On Sparc, you even do 3 different operations. >>>>> >>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>> This all depends a lot on the available instructions of the processors. >>>>> Therefore I think a really clean representation that, at the same >>>>> time, allows >>>>> to find the cheapest set of instructions to express it on all >>>>> processors, is impossible. >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>> PS: Should I respond to comments in the bug right in the bug >>>>> or on the mailing lists? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>> Lindenmaier, Goetz >>>>> Sent: Montag, 18. November 2013 15:19 >>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>> MemBarAcquire/ReleaseWide. >>>>> >>>>> Hi, >>>>> >>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>> ordering in various places. Some order a certain load/store with other >>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>> correspont to a memory operation. So far, the same nodes were used. >>>>> >>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>> matched differently, what is needed on PPC64. >>>>> >>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>> >>>>> Please review and test this change. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From vladimir.x.ivanov at oracle.com Wed Nov 20 01:51:12 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 20 Nov 2013 13:51:12 +0400 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528C8610.5000105@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 11/19/13 11:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca > From goetz.lindenmaier at sap.com Wed Nov 20 02:11:42 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Nov 2013 10:11:42 +0000 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> Hi, ImplicitNullChecks did not work on platforms where the zero page is only write protected. This change adds os property 'zero_page_read_protected' and extends the ImplicitNullCheck optimization to consider only stores if this property is not true. If a decoded compressed oop will access the guard page before the heap, Loads work again. This is needed on AIX, where the page at address '0' is only write-protected. Please review and test this change: http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ I tagged this S, as a majority of the patches apply to the ppc platform files. Best regards, Goetz. From zhengyu.gu at oracle.com Wed Nov 20 05:17:14 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 20 Nov 2013 08:17:14 -0500 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528CB65A.1030803@oracle.com> Vote: yes -Zhengyu On 11/19/2013 2:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From goetz.lindenmaier at sap.com Wed Nov 20 06:22:05 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Nov 2013 14:22:05 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528CB958.9030809@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> Hi David, thanks for the comprehensive explanation. That's in agreement with what I understand. Except that I think, unidirectional barriers only make sense if you have Acquire/Release operations dedicated to a certain operation. Then other operations of the same kind can pass the barrier in one direction. This also matches the extension I contributed to hotspot (8024921), which now allows to issue such operations right along with the loads/stores. This change here tries to separate the barriers used after load/stores from the 'wide' or better 'fence' variants. Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible operations. Unfortunately, Hotspot knows only four of these: MemBarStoreStore: S-S MemBarAcquire: L-S, L-L MemBarRelease: L-S, S-S MemBarVolatile: L-L, L-S, S-L, S-S and these don't map, e.g., the operations available on PPC: lwsync: L-S, L-L, S-S sync: L-L, L-S, S-L, S-S What is the reason why it's hard for us to generate optimal code with the available optimizations: MemBarAcquire; MemBarRelease; are mapped to lwsync lwsync which is obviously redundant. A generic solution would be to have a single operation, that can be Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. Two operations could be merged by an optimization simply by or-ing the tags. But this is not reality in HotSpot, and out of scope of this change. > I think perhaps that Vladimir's suggestion is best - if these are the > Membar nodes for these unsafe ops (and only these) then name them to > match the unsafe ops. At least then it is clearer where the > specification for their behaviour comes from. OK, so I'll rename them as Vladimir proposed, and post a new webrev. Best regards and a good flight home, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Mittwoch, 20. November 2013 14:30 To: Lindenmaier, Goetz Cc: David Holmes Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. Hi Goetz, On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: > Hi David, > I don't know what you mean by uni/bi-directional. Pretty much as you describe below. A unidirectional barrier allows things to cross in one direction only ie it blocks motion one way; a bi-directional barrier ("full fence") blocks both ways and so prevents any reordering. As I described in earlier emails these kind of unreferenced acquire/release semantics ie not associated with any stores/loads is used to describe the memory barrier properties of a synchronized block, for example. Monitor acquisition has acquire semantics, while monitor release has store semantics. The implied barriers mean that any accesses can move into the synchronized region but none can move out - the "roach motel" semantics. Now as you say this kind of barrier is not what is wanted with these loadFence/storeFence operations, hence I think the generic MembarAcquire/MembarRelease are inappropriate names (whether the implementation is correct is a different matter). Similarly I find the MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - what do they mean ??? The loadFence semantics imply a loadLoad|loadStore barrier. The storeFence semantics imply a storeLoad|storeStore barrier. The fullFence is of course all four. Again I'm unclear if the current or proposed MembarXXX actions actually map to barriers that implement those semantics. So yes this comes down to naming initially but also verification that the implementation does as required. I think perhaps that Vladimir's suggestion is best - if these are the Membar nodes for these unsafe ops (and only these) then name them to match the unsafe ops. At least then it is clearer where the specification for their behaviour comes from. I'll post a follow up email to the list when I get a chance. I'm currently in the US and attending lots of meetings then head back to Australia tomorrow evening. Thanks, David > I guess we agree that the documentation of the intrinsics, let's take > loadFence > for an example, talks about loads before the loadFence, and stores and > loads after it: > loads > ------------loadFence()-------------- > loads, stores > With this, you can achieve any ordering by moving nodes up OR down: > Op1 Move Op1 Op2 > Op2 down ------------- > --------- =========> Op3 > Op3 Op1 > Alternatively, you can move op3 up, and get the same order: > Op1 Reorder Op2 Move Op3 Op2 > Op2 Ops 1 and 2 Op1 up Op3 > --------- =========> -------------- =========> Op1 > Op3 Not restricted Op3 ---------- > by later loadFence > So, if the operation restricts only moves in one direction, it's of no > help because > you can still get an execution order you did not expect. So > unidirectional operations > (e.g., only hindering operations from moving up) are pointless. > By the way, are you questioning whether the implementation is correct, or > whether the names express what is desired? > If it's the first, it's of no concern to this change, which is only about > matching these operations independently from those, that address > a dedicated memory operation. > If It's the second, please tell me what names to use, and I'll fix it. > (I hope you can properly read the 'drawings') > Best regards, > Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 19. November 2013 20:51 > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; > 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce > MemBarAcquire/ReleaseWide. > On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> this are the instrinsics for sun/misc/Unsafe, which are documented >> as shown below. So I guess that's just what is desired. > I don't think so! What is described for Unsafe are full bi-directional > fences and "acquire" and "release" are only uni-directional fences! > David > ----- >> Best regards, >> Goetz. >> >> /** >> * Ensures lack of reordering of loads before the fence >> * with loads or stores after the fence. >> * @since 1.8 >> */ >> public native void loadFence(); >> >> /** >> * Ensures lack of reordering of stores before the fence >> * with loads or stores after the fence. >> * @since 1.8 >> */ >> public native void storeFence(); >> >> /** >> * Ensures lack of reordering of loads or stores before the fence >> * with loads or stores after the fence. >> * @since 1.8 >> */ >> public native void fullFence(); >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 19, 2013 8:08 PM >> To: Lindenmaier, Goetz >> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> So I like the rename but I am concerned there are semantic issues here: >> >> switch(id) { >> case vmIntrinsics::_loadFence: >> - insert_mem_bar(Op_MemBarAcquire); >> + insert_mem_bar(Op_MemBarFenceAcquire); >> return true; >> case vmIntrinsics::_storeFence: >> - insert_mem_bar(Op_MemBarRelease); >> + insert_mem_bar(Op_MemBarFenceRelease); >> return true; >> >> What is a _loadFence operation? Does it really map to >> MembarFenceAcquire? Ditto for the _storeFence. These sound like >> bi-directional fences - are they? Are they really only concerned with >> loads or stores ? >> >> David >> >> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I made a new webrev, using the new names: >>>http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>> >>> Thanks, >>> Goetz. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Montag, 18. November 2013 23:28 >>> To: Lindenmaier, Goetz; 'David Holmes' >>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>> Hi David, Vladimir, >>>> >>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>> - the same prefix shows they are all similar nodes. >>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>> change yet and which is used in more places. >>> >>> Okay. >>> >>> Vladimir >>> >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Monday, November 18, 2013 10:49 PM >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> Vladimir, >>>> >>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>> I think David asked for different nodes not just one. >>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>> >>>> But I don't think that actually describes them - they don't distinguish >>>> between loads and stores only the direction in which the barrier >>>> operates. "acquire" only allows accesses to move below it; "release" >>>> only allows accesses to move above it ie: >>>> >>>> load a >>>> store b, c >>>> acquire(); >>>> load d >>>> store e,f >>>> release(); >>>> load g >>>> store h, i >>>> >>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>> and release; similarly for the stores to b and h. But the load of d nor >>>> the store to e can not move in relation to either acquire or release. >>>> >>>> Thanks, >>>> David >>>> >>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> as reply to your comment on the bug: >>>>>> >>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>> MemBarAcquireWide --> lwsync >>>>>> MemBarReleaseWide --> lwsync >>>>>> MemBarVolatile --> sync. >>>>>> On Sparc, you even do 3 different operations. >>>>>> >>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>> This all depends a lot on the available instructions of the processors. >>>>>> Therefore I think a really clean representation that, at the same >>>>>> time, allows >>>>>> to find the cheapest set of instructions to express it on all >>>>>> processors, is impossible. >>>>>> >>>>>> Best regards, >>>>>> Goetz >>>>>> >>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>> or on the mailing lists? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net > >>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>> Lindenmaier, Goetz >>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>> MemBarAcquire/ReleaseWide. >>>>>> >>>>>> Hi, >>>>>> >>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>> ordering in various places. Some order a certain load/store with other >>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>> >>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>> matched differently, what is needed on PPC64. >>>>>> >>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>> >>>>>> Please review and test this change. >>>>>>http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From goetz.lindenmaier at sap.com Wed Nov 20 08:16:46 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Nov 2013 16:16:46 +0000 Subject: Is it possible to stop a specific application thread? In-Reply-To: References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE67546@DEWDFEMB12A.global.corp.sap> Hi, I prepared a webrev for our implementation of loading the poll address from the thread. http://cr.openjdk.java.net/~goetz/webrevs/loadpolladrfromthrd/ This applies to hotspot-main. This feature is only implemented for the C2 compiler, C1 adaptions are missing. So you have to set -XX:-TieredCompilation to test it. Else the VM crashes on the first safepoint poll in C1-compiled code. The feature in on per default, you can switch it off by setting -XX:-LoadPollAddressFromThread For more details, see the comment in the webrev. If you want to submit this to hotspot, I can open a bug and send a proper RFR. Which would be the appropriate mailing list? Hotspot-rt? I can not push it to JPRT, though. I would be happy if somebody contributes the adaptions for C1. Best regards, Goetz. From: Keith Chapman [mailto:keithgchapman at gmail.com] Sent: Dienstag, 12. November 2013 14:27 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net Subject: Re: Is it possible to stop a specific application thread? On Tue, Nov 12, 2013 at 3:24 AM, Lindenmaier, Goetz > wrote: Hi, our VM is running with what we call PerThreadSafepoints for a long time. We implement this by loading the page from the thread as you propose. But we don't have a page per thread, as poisoning them seems to costly if there are many threads and all threads must be stopped. Instead, we adapt the field in the thread: usually it points to some valid address. If a safepoint is required, the polling page is written into that field. We implemented this when we tried to improve BiasedLocking, but as we could not gain anything, we don't really use it any more. If you really have interest in this feature, I can prepare a webrev for it. That would be awesome. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan Sent: Dienstag, 12. November 2013 06:46 To: David Holmes Cc: hotspot-dev at openjdk.java.net Subject: Re: Is it possible to stop a specific application thread? I had a prototype at one point that did #2, but I don't have the source for it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they can reply with the diffs to give someone a leg up in doing this again. -- - Keith (McGuigan) On Monday, November 11, 2013, David Holmes wrote: > On 12/11/2013 11:16 AM, Keith Chapman wrote: > >> Hi David, >> >> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >> >> wrote: >> >> Hi Keith, >> >> >> On 12/11/2013 6:29 AM, Keith Chapman wrote: >> >> Hi, >> >> I'm playing around with some research ideas on hotspot. >> >> One of my runtime services of the VM needs to stop a specific >> application >> thread (I have a handle to the pthread of the application >> thread). How can >> the VM stop such a thread? Is there any mechanism in place to do >> this? >> >> >> There is no general purpose mechanism currently in place. >> >> >> Thats a bummer, having such a mechanism would have been useful for >> numerous VM services like biased locking revocation, concurrent GC. >> > > For which safepoints are generally used so a per-thread safepoint > mechanism is what you are looking for. > > >> You could use the deprecated and inherently dangerous Thread.suspend >> mechanism (either directly or via the JVMTI suspension interface). >> >> Or if you are more adventurous with your VM hacking you could >> introduce a per-thread safepoint operation to cause it to stop. >> >> >> I actually thought about that and explored the way safepoints are >> implemented. The place that I had most trouble was getting threads >> running compiled code to stop. The way it currently works is by >> allocating a polling page (at startup) and drilling in that address into >> the compiled code. Hence i I am to do it per thread I would have to make >> a call to the runtime to get the address of the polling page for that >> particular thread. I presume this would be too expensive (Making a VM >> call at the end of each method and through some loop iterations). >> >> Is there any insight you could offer on how this could be done? >> > > Two basic options I can think of: > > 1. Use a single shared page and have other threads simply ignore the > safepoint request. This might incur some overhead as not-wanted threads > could hit this multiple times. > > 2. Use a per-thread page accessed via the current thread. There would be a > little overhead for the indirection but the compiler knows how to access > the current JavaThread object. No need for runtime calls that I can see. > > Good luck. > > David > > Thanks, >> Keith. >> >> Or you could hack in a special "magic exception" type the processing >> of which simply blocks the thread until "resumed" somehow (not sure >> how ??). Or ... >> >> Cheers, >> David >> >> Thanks, >> Keith. >> >> >> >> >> -- >> >> Keith Chapman >> blog: http://www.keith-chapman.org >> > -- Keith Chapman blog: http://www.keith-chapman.org From calvin.cheung at oracle.com Wed Nov 20 09:29:49 2013 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 20 Nov 2013 09:29:49 -0800 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528CF18D.90202@oracle.com> Vote: yes On 11/19/2013 11:28 AM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From vladimir.kozlov at oracle.com Wed Nov 20 12:03:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Nov 2013 12:03:45 -0800 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> Message-ID: <528D15A1.9080400@oracle.com> Hi, Goetz Can you move all checks in lcm.cpp into new method and rename it to needs_explicit_null_check_for_read()? So the condition will be simple: if (!was_store && needs_explicit_null_check_for_read(val)) { continue; } You should also add ShouldNotReachHere() for AIX near Unimplemented() for non AIX. And, please, fix indents in new method. Thanks, Vladimir On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: > Hi, > > ImplicitNullChecks did not work on platforms where the zero > page is only write protected. > > This change adds os property 'zero_page_read_protected' and extends > the ImplicitNullCheck optimization to consider only stores if > this property is not true. If a decoded compressed oop will access the > guard page before the heap, Loads work again. > This is needed on AIX, where the page at address '0' is only write-protected. > > Please review and test this change: > http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ > > I tagged this S, as a majority of the patches apply to the ppc platform files. > > Best regards, > Goetz. > From david.holmes at oracle.com Wed Nov 20 12:05:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Nov 2013 06:05:49 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> Message-ID: <528D161D.8030803@oracle.com> First apologies that the email you replied to here didn't go to the lists. Due to the way it was filtered I assumed it was a direct email only. :) On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for the comprehensive explanation. That's in agreement with > what I understand. Except that I think, unidirectional barriers only > make sense if you have Acquire/Release operations dedicated to > a certain operation. Then other operations of the same kind can pass > the barrier in one direction. > > This also matches the extension I contributed to hotspot (8024921), > which now allows to issue such operations right along with the > loads/stores. > > This change here tries to separate the barriers used after load/stores from > the 'wide' or better 'fence' variants. But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after loads/stores - but with stronger semantics than just simple loadLoad or storeStore barriers. > Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible > operations. Unfortunately, Hotspot knows only four of these: > MemBarStoreStore: S-S Okay - nice and clear. > MemBarAcquire: L-S, L-L I'm not sure what makes this "acquire" but this seems to be exactly what Unsafe.loadFence requires. > MemBarRelease: L-S, S-S Again I'm not sure what makes this "release" - I also find it odd that it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence needs. > MemBarVolatile: L-L, L-S, S-L, S-S A full fence, needed in the worst case when accessing a volatile variable. Also note that in different parts of the VM we have different expressions of these, both at the JIT level and runtime eg see orderAccess.hpp (which is not in itself self-consistent or clear: see https://bugs.openjdk.java.net/browse/JDK-7143664). Also I said that the Unsafe ops require bi-directional fences but that was imprecise - the _load and _store ops only require two of the four possible barriers which may be why you see these as distinct from the membars associated directly with variable accesses ? > and these don't map, e.g., the operations available on PPC: > lwsync: L-S, L-L, S-S > sync: L-L, L-S, S-L, S-S > What is the reason why it's hard for us to generate optimal code > with the available optimizations: > MemBarAcquire; > MemBarRelease; > are mapped to > lwsync > lwsync > which is obviously redundant. Are you referring to generated code if these nodes are adjacent? If so I assume the problem is that you can't logically coalesce these, even if the actual generated code could be coalesced? > A generic solution would be to have a single operation, that can be > Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. > Two operations could be merged by an optimization simply by > or-ing the tags. > But this is not reality in HotSpot, and out of scope of this change. Ok >> I think perhaps that Vladimir's suggestion is best - if these are the >> Membar nodes for these unsafe ops (and only these) then name them to >> match the unsafe ops. At least then it is clearer where the >> specification for their behaviour comes from. > OK, so I'll rename them as Vladimir proposed, and post a new webrev. I still have this concern regarding the fact you think these are not related to load/store operations. But I'll wait for the webrev. Thanks for your patience on this. Hopefully we can sort it out in the next 24 hours before I takeoff. David ----- > Best regards and a good flight home, > Goetz. > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 20. November 2013 14:30 > To: Lindenmaier, Goetz > Cc: David Holmes > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi Goetz, > > On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >> Hi David, >> I don't know what you mean by uni/bi-directional. > > Pretty much as you describe below. A unidirectional barrier allows > things to cross in one direction only ie it blocks motion one way; a > bi-directional barrier ("full fence") blocks both ways and so prevents > any reordering. > > As I described in earlier emails these kind of unreferenced > acquire/release semantics ie not associated with any stores/loads is > used to describe the memory barrier properties of a synchronized block, > for example. Monitor acquisition has acquire semantics, while monitor > release has store semantics. The implied barriers mean that any accesses > can move into the synchronized region but none can move out - the "roach > motel" semantics. > > Now as you say this kind of barrier is not what is wanted with these > loadFence/storeFence operations, hence I think the generic > MembarAcquire/MembarRelease are inappropriate names (whether the > implementation is correct is a different matter). Similarly I find the > MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - > what do they mean ??? > > The loadFence semantics imply a loadLoad|loadStore barrier. > The storeFence semantics imply a storeLoad|storeStore barrier. > The fullFence is of course all four. > > Again I'm unclear if the current or proposed MembarXXX actions actually > map to barriers that implement those semantics. > > So yes this comes down to naming initially but also verification that > the implementation does as required. > > I think perhaps that Vladimir's suggestion is best - if these are the > Membar nodes for these unsafe ops (and only these) then name them to > match the unsafe ops. At least then it is clearer where the > specification for their behaviour comes from. > > I'll post a follow up email to the list when I get a chance. I'm > currently in the US and attending lots of meetings then head back to > Australia tomorrow evening. > > Thanks, > David > >> I guess we agree that the documentation of the intrinsics, let's take >> loadFence >> for an example, talks about loads before the loadFence, and stores and >> loads after it: >> loads >> ------------loadFence()-------------- >> loads, stores >> With this, you can achieve any ordering by moving nodes up OR down: >> Op1 Move Op1 Op2 >> Op2 down ------------- >> --------- =========> Op3 >> Op3 Op1 >> Alternatively, you can move op3 up, and get the same order: >> Op1 Reorder Op2 Move Op3 Op2 >> Op2 Ops 1 and 2 Op1 up Op3 >> --------- =========> -------------- =========> Op1 >> Op3 Not restricted Op3 ---------- >> by later loadFence >> So, if the operation restricts only moves in one direction, it's of no >> help because >> you can still get an execution order you did not expect. So >> unidirectional operations >> (e.g., only hindering operations from moving up) are pointless. >> By the way, are you questioning whether the implementation is correct, or >> whether the names express what is desired? >> If it's the first, it's of no concern to this change, which is only about >> matching these operations independently from those, that address >> a dedicated memory operation. >> If It's the second, please tell me what names to use, and I'll fix it. >> (I hope you can properly read the 'drawings') >> Best regards, >> Goetz. >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 19. November 2013 20:51 >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >> 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >> MemBarAcquire/ReleaseWide. >> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> this are the instrinsics for sun/misc/Unsafe, which are documented >>> as shown below. So I guess that's just what is desired. >> I don't think so! What is described for Unsafe are full bi-directional >> fences and "acquire" and "release" are only uni-directional fences! >> David >> ----- >>> Best regards, >>> Goetz. >>> >>> /** >>> * Ensures lack of reordering of loads before the fence >>> * with loads or stores after the fence. >>> * @since 1.8 >>> */ >>> public native void loadFence(); >>> >>> /** >>> * Ensures lack of reordering of stores before the fence >>> * with loads or stores after the fence. >>> * @since 1.8 >>> */ >>> public native void storeFence(); >>> >>> /** >>> * Ensures lack of reordering of loads or stores before the fence >>> * with loads or stores after the fence. >>> * @since 1.8 >>> */ >>> public native void fullFence(); >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 19, 2013 8:08 PM >>> To: Lindenmaier, Goetz >>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> So I like the rename but I am concerned there are semantic issues here: >>> >>> switch(id) { >>> case vmIntrinsics::_loadFence: >>> - insert_mem_bar(Op_MemBarAcquire); >>> + insert_mem_bar(Op_MemBarFenceAcquire); >>> return true; >>> case vmIntrinsics::_storeFence: >>> - insert_mem_bar(Op_MemBarRelease); >>> + insert_mem_bar(Op_MemBarFenceRelease); >>> return true; >>> >>> What is a _loadFence operation? Does it really map to >>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>> bi-directional fences - are they? Are they really only concerned with >>> loads or stores ? >>> >>> David >>> >>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I made a new webrev, using the new names: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>> >>>> Thanks, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Montag, 18. November 2013 23:28 >>>> To: Lindenmaier, Goetz; 'David Holmes' >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, Vladimir, >>>>> >>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>> - the same prefix shows they are all similar nodes. >>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>> change yet and which is used in more places. >>>> >>>> Okay. >>>> >>>> Vladimir >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> Vladimir, >>>>> >>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>> I think David asked for different nodes not just one. >>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>> >>>>> But I don't think that actually describes them - they don't distinguish >>>>> between loads and stores only the direction in which the barrier >>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>> only allows accesses to move above it ie: >>>>> >>>>> load a >>>>> store b, c >>>>> acquire(); >>>>> load d >>>>> store e,f >>>>> release(); >>>>> load g >>>>> store h, i >>>>> >>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>> the store to e can not move in relation to either acquire or release. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> as reply to your comment on the bug: >>>>>>> >>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>> MemBarAcquireWide --> lwsync >>>>>>> MemBarReleaseWide --> lwsync >>>>>>> MemBarVolatile --> sync. >>>>>>> On Sparc, you even do 3 different operations. >>>>>>> >>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>> Therefore I think a really clean representation that, at the same >>>>>>> time, allows >>>>>>> to find the cheapest set of instructions to express it on all >>>>>>> processors, is impossible. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>> or on the mailing lists? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >> >>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>> Lindenmaier, Goetz >>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>> MemBarAcquire/ReleaseWide. >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>> >>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>> matched differently, what is needed on PPC64. >>>>>>> >>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>> >>>>>>> Please review and test this change. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> From david.holmes at oracle.com Wed Nov 20 12:49:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Nov 2013 06:49:23 +1000 Subject: Is it possible to stop a specific application thread? In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE67546@DEWDFEMB12A.global.corp.sap> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE67546@DEWDFEMB12A.global.corp.sap> Message-ID: <528D2053.4000606@oracle.com> On 21/11/2013 2:16 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for our implementation of loading the poll address from > the thread. > http://cr.openjdk.java.net/~goetz/webrevs/loadpolladrfromthrd/ > This applies to hotspot-main. > > This feature is only implemented for the C2 compiler, C1 adaptions are missing. > So you have to set -XX:-TieredCompilation to test it. Else the VM crashes on > the first safepoint poll in C1-compiled code. > The feature in on per default, you can switch it off by setting > -XX:-LoadPollAddressFromThread > > For more details, see the comment in the webrev. > > If you want to submit this to hotspot, I can open a bug and send a proper > RFR. Which would be the appropriate mailing list? Hotspot-rt? > I can not push it to JPRT, though. This is not suitable for pushing to OpenJDK at this time. It would need to be complete, and the feature would also need a JEP in my opinion. David ----- > I would be happy if somebody contributes the adaptions for C1. > > Best regards, > Goetz. > > > > From: Keith Chapman [mailto:keithgchapman at gmail.com] > Sent: Dienstag, 12. November 2013 14:27 > To: Lindenmaier, Goetz > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > > > On Tue, Nov 12, 2013 at 3:24 AM, Lindenmaier, Goetz > wrote: > Hi, > > our VM is running with what we call PerThreadSafepoints for a long time. > > We implement this by loading the page from the thread as you propose. > But we don't have a page per thread, as poisoning them seems to costly > if there are many threads and all threads must be stopped. > > Instead, we adapt the field in the thread: usually it points to some > valid address. If a safepoint is required, the polling page is written > into that field. > > We implemented this when we tried to improve BiasedLocking, > but as we could not gain anything, we don't really use it any more. > > If you really have interest in this feature, I can prepare a webrev > for it. > > That would be awesome. > > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan > Sent: Dienstag, 12. November 2013 06:46 > To: David Holmes > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > I had a prototype at one point that did #2, but I don't have the source for > it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they > can reply with the diffs to give someone a leg up in doing this again. > > -- > - Keith (McGuigan) > > On Monday, November 11, 2013, David Holmes wrote: > >> On 12/11/2013 11:16 AM, Keith Chapman wrote: >> >>> Hi David, >>> >>> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >>> >> wrote: >>> >>> Hi Keith, >>> >>> >>> On 12/11/2013 6:29 AM, Keith Chapman wrote: >>> >>> Hi, >>> >>> I'm playing around with some research ideas on hotspot. >>> >>> One of my runtime services of the VM needs to stop a specific >>> application >>> thread (I have a handle to the pthread of the application >>> thread). How can >>> the VM stop such a thread? Is there any mechanism in place to do >>> this? >>> >>> >>> There is no general purpose mechanism currently in place. >>> >>> >>> Thats a bummer, having such a mechanism would have been useful for >>> numerous VM services like biased locking revocation, concurrent GC. >>> >> >> For which safepoints are generally used so a per-thread safepoint >> mechanism is what you are looking for. >> >> >>> You could use the deprecated and inherently dangerous Thread.suspend >>> mechanism (either directly or via the JVMTI suspension interface). >>> >>> Or if you are more adventurous with your VM hacking you could >>> introduce a per-thread safepoint operation to cause it to stop. >>> >>> >>> I actually thought about that and explored the way safepoints are >>> implemented. The place that I had most trouble was getting threads >>> running compiled code to stop. The way it currently works is by >>> allocating a polling page (at startup) and drilling in that address into >>> the compiled code. Hence i I am to do it per thread I would have to make >>> a call to the runtime to get the address of the polling page for that >>> particular thread. I presume this would be too expensive (Making a VM >>> call at the end of each method and through some loop iterations). >>> >>> Is there any insight you could offer on how this could be done? >>> >> >> Two basic options I can think of: >> >> 1. Use a single shared page and have other threads simply ignore the >> safepoint request. This might incur some overhead as not-wanted threads >> could hit this multiple times. >> >> 2. Use a per-thread page accessed via the current thread. There would be a >> little overhead for the indirection but the compiler knows how to access >> the current JavaThread object. No need for runtime calls that I can see. >> >> Good luck. >> >> David >> >> Thanks, >>> Keith. >>> >>> Or you could hack in a special "magic exception" type the processing >>> of which simply blocks the thread until "resumed" somehow (not sure >>> how ??). Or ... >>> >>> Cheers, >>> David >>> >>> Thanks, >>> Keith. >>> >>> >>> >>> >>> -- >>> >>> Keith Chapman >>> blog: http://www.keith-chapman.org >>> >> > > > > -- > > Keith Chapman > blog: http://www.keith-chapman.org > From david.holmes at oracle.com Wed Nov 20 13:59:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Nov 2013 07:59:01 +1000 Subject: Testing Groovy against JDK 8 EA builds In-Reply-To: <528C7802.3030004@gmx.org> References: <528B5CD2.9010606@oracle.com> <528B83D2.6020802@gmx.org> <528B9360.1010601@oracle.com> <528C7802.3030004@gmx.org> Message-ID: <528D30A5.9090908@oracle.com> On 20/11/2013 6:51 PM, Jochen Theodorou wrote: >> The VerifyError is VM related and there are still ongoing changes as the >> spec settles and the implementation catches up. > > can you tell me which invoke instruction are how supposed to be able to > call default methods? I am sure that if Foo implements Bar and bar() is > a default method on Bar, that an invokevirtual Foo#bar() is supposed to > be ok. But what about invokespecial on Bar#bar (like a super call)? invokespecial's can be used but I'm not sure of the exact context. The proposed specification for this is here: http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html David >> The List issue is something to discuss on lambda-dev. We know there are >> some source incompatabilities with default methods in Java 8. This is an >> accepted price to pay for moving the Java libraries forward. > > it is not a source incompatibility for us, but since it is Groovy code, > not Java code that might be another story > > bye Jochen > From forax at univ-mlv.fr Wed Nov 20 14:11:11 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 20 Nov 2013 23:11:11 +0100 Subject: Testing Groovy against JDK 8 EA builds In-Reply-To: <528D30A5.9090908@oracle.com> References: <528B5CD2.9010606@oracle.com> <528B83D2.6020802@gmx.org> <528B9360.1010601@oracle.com> <528C7802.3030004@gmx.org> <528D30A5.9090908@oracle.com> Message-ID: <528D337F.9070706@univ-mlv.fr> On 11/20/2013 10:59 PM, David Holmes wrote: > On 20/11/2013 6:51 PM, Jochen Theodorou wrote: >>> The VerifyError is VM related and there are still ongoing changes as >>> the >>> spec settles and the implementation catches up. >> >> can you tell me which invoke instruction are how supposed to be able to >> call default methods? I am sure that if Foo implements Bar and bar() is >> a default method on Bar, that an invokevirtual Foo#bar() is supposed to >> be ok. But what about invokespecial on Bar#bar (like a super call)? > > invokespecial's can be used but I'm not sure of the exact context. The > proposed specification for this is here: > > http://cr.openjdk.java.net/~dlsmith/jsr335-0.7.0/J.html > > David Hi Jochen, hi David, the VM now supports invokespecial and invokestatic on interface, invoking a default method from another class is done with invokeinterface, invoking a default method of a super interface from a class or an interface is done with invokespecial, invoking a static method on an interface is done with invokestatic. And with an ASM dev hat, Jochen, if you want to emit invokespecial or invokestatic on an interface with ASM, you need to downlod the latest version from the trunk, we haven't release a version with that support yet. > >>> The List issue is something to discuss on lambda-dev. We know there are >>> some source incompatabilities with default methods in Java 8. This >>> is an >>> accepted price to pay for moving the Java libraries forward. >> >> it is not a source incompatibility for us, but since it is Groovy code, >> not Java code that might be another story >> >> bye Jochen >> cheers, R?mi From goetz.lindenmaier at sap.com Wed Nov 20 15:18:41 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 20 Nov 2013 23:18:41 +0000 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <528D15A1.9080400@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> <528D15A1.9080400@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for the quick review! I updated the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ I made an additional method with the name you proposed. I prefer two methods, as one tests whether the operation traps, the other checks how the narrow oop was decoded -- two different things. Should be optimized by the C-compiler anyways. No ShouldNotReachHere for AIX. I tried to improve the comment instead. Sorry for the wrong indents. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, November 20, 2013 9:04 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. Hi, Goetz Can you move all checks in lcm.cpp into new method and rename it to needs_explicit_null_check_for_read()? So the condition will be simple: if (!was_store && needs_explicit_null_check_for_read(val)) { continue; } You should also add ShouldNotReachHere() for AIX near Unimplemented() for non AIX. And, please, fix indents in new method. Thanks, Vladimir On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: > Hi, > > ImplicitNullChecks did not work on platforms where the zero > page is only write protected. > > This change adds os property 'zero_page_read_protected' and extends > the ImplicitNullCheck optimization to consider only stores if > this property is not true. If a decoded compressed oop will access the > guard page before the heap, Loads work again. > This is needed on AIX, where the page at address '0' is only write-protected. > > Please review and test this change: > http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ > > I tagged this S, as a majority of the patches apply to the ppc platform files. > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Wed Nov 20 17:04:10 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Nov 2013 17:04:10 -0800 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> <528D15A1.9080400@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> Message-ID: <528D5C0A.2020001@oracle.com> On 11/20/13 3:18 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for the quick review! > > I updated the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ > > I made an additional method with the name you proposed. > I prefer two methods, as one tests whether the operation > traps, the other checks how the narrow oop was decoded -- > two different things. Should be optimized by the C-compiler > anyways. Without (UseCompressedOops && Universe::narrow_oop_base() > 0) check Universe::narrow_oop_use_implicit_null_checks() is useless because it is 'true' by default. That is why I asked to move check inside to combine them in one place. You can use Matcher::gen_narrow_oop_implicit_null_checks() check instead. Note Universe::narrow_oop_base() != NULL only if UseCompressedOops is true. > > No ShouldNotReachHere for AIX. I tried to improve the comment > instead. So you want to return false if it is not DecodeN. Right? Thanks, Vladimir > > Sorry for the wrong indents. > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, November 20, 2013 9:04 PM > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. > > Hi, Goetz > > Can you move all checks in lcm.cpp into new method and rename it to > needs_explicit_null_check_for_read()? So the condition will be simple: > > if (!was_store && needs_explicit_null_check_for_read(val)) { > continue; > } > > You should also add ShouldNotReachHere() for AIX near Unimplemented() > for non AIX. > > And, please, fix indents in new method. > > Thanks, > Vladimir > > On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> ImplicitNullChecks did not work on platforms where the zero >> page is only write protected. >> >> This change adds os property 'zero_page_read_protected' and extends >> the ImplicitNullCheck optimization to consider only stores if >> this property is not true. If a decoded compressed oop will access the >> guard page before the heap, Loads work again. >> This is needed on AIX, where the page at address '0' is only write-protected. >> >> Please review and test this change: >> http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ >> >> I tagged this S, as a majority of the patches apply to the ppc platform files. >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Thu Nov 21 00:30:18 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Nov 2013 08:30:18 +0000 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <528D5C0A.2020001@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> <528D15A1.9080400@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> <528D5C0A.2020001@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE67BF0@DEWDFEMB12A.global.corp.sap> Hi Vladimir, > Without (UseCompressedOops && Universe::narrow_oop_base() > 0) check > Universe::narrow_oop_use_implicit_null_checks() is useless because it is > 'true' by default. That is why I asked to move check inside to combine > them in one place. Yes, it is useless, but it will not be evaluated. And I need it if narrow_oop_base() is set. But is it really true by default? See arguments.cpp: #ifdef _WIN64 if (UseLargePages && UseCompressedOops) { // Cannot allocate guard pages for implicit checks in indexed addressing // mode, when large pages are specified on windows. // This flag could be switched ON if narrow oop base address is set to 0, // see code in Universe::initialize_heap(). Universe::set_narrow_oop_use_implicit_null_checks(false); } #endif // _WIN64 > You can use Matcher::gen_narrow_oop_implicit_null_checks() check > instead. No, that returns true if narrow_oop_use_complex_address() is set. I must know whether the page before the heapbased heap is protected. There should be Universe::heapbased_base_page_is_protected(), that would be much more descriptive. > Note Universe::narrow_oop_base() != NULL only if > UseCompressedOops is true. Yes, you mean I should remove the test for UseCompressedOops? >> No ShouldNotReachHere for AIX. I tried to improve the comment >> instead. > So you want to return false if it is not DecodeN. Right? No, if it's not DecodeN_NN: xn = loadn xo = xn == 0 ? 0 : xn<<3+base // DecodeN loadI (xo+offset) will not trap, as it accesses the zero page. xn = loadn xo = xn<<3+base // DecodeN_NN loadI (xo+offset) will trap, as it accesses the base page of the heapbased heap. If you match the decode into the memory operand of the second Load, this check will not work, therefore I put the unimplemented() there: xn = loadn loadI (xo<<3+base+offset) but ppc has no loads that support this. There is no obvious, platform independent way to distinguish DecodeN_NN and DecodeN. Thanks for this detailed review! Best regards, Goetz. Thanks, Vladimir > > Sorry for the wrong indents. > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, November 20, 2013 9:04 PM > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. > > Hi, Goetz > > Can you move all checks in lcm.cpp into new method and rename it to > needs_explicit_null_check_for_read()? So the condition will be simple: > > if (!was_store && needs_explicit_null_check_for_read(val)) { > continue; > } > > You should also add ShouldNotReachHere() for AIX near Unimplemented() > for non AIX. > > And, please, fix indents in new method. > > Thanks, > Vladimir > > On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> ImplicitNullChecks did not work on platforms where the zero >> page is only write protected. >> >> This change adds os property 'zero_page_read_protected' and extends >> the ImplicitNullCheck optimization to consider only stores if >> this property is not true. If a decoded compressed oop will access the >> guard page before the heap, Loads work again. >> This is needed on AIX, where the page at address '0' is only write-protected. >> >> Please review and test this change: >> http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ >> >> I tagged this S, as a majority of the patches apply to the ppc platform files. >> >> Best regards, >> Goetz. >> From goetz.lindenmaier at sap.com Thu Nov 21 02:23:02 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Nov 2013 10:23:02 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528D161D.8030803@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> Hi David, here the new webrev, naming the nodes LoadFence/StoreFence: http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ The thing with the mail was my fault, I had sent the first mail only to you accidentially. Sorry for that. > But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after > loads/stores - but with stronger semantics than just simple loadLoad or > storeStore barriers. Yes. I mean they do not intend to sort a single load/store with succeeding operations. This can not be implemented this way, as the operation is not known in the intrinsic. I mean cases where you can use ia64 ld.acq or ppc ld-twi-lwsync. > Also I said that the Unsafe ops require bi-directional fences but that > was imprecise - the _load and _store ops only require two of the four > possible barriers which may be why you see these as distinct from the > membars associated directly with variable accesses ? On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. For the intrinsic I must use mf, which sorts _all_ previous loads with all following ld/st operations (and more). So my distinction is if I have a store on one processor, and a load on the other, and I want to make sure the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. If I did some arbitrary stores, and I want assure an other processor doing some arbitrary load,s then I must use - on ia64- mf on both. On sparc I can do a membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); But, on sparc, there is no operation as ld.acq as far as I know. Change 8024921 enables to distinguish normal loads and such that should do ld.acq. This change enables the compiler to differentiate the MemBar nodes used better: such coming after a dedicated load, and such valid for any load before the barrier. This is already visible in the IR by some means: MemBars after dedicated loads have an input edge at position MemBar::precedence connecting them with the load, but that does not suffice to match it (in the matcher) correctly. If I use ld.acq, the following MemBarAcquire is superfluous, but the MemBarAcquire used in the intrinsic is not. So want to have different nodes. In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, and with #ifdef ia64 we use MemBarVolatile, as we know these operations will issue the proper assembly instructions. But this is bad - I want to do it better here. > Are you referring to generated code if these nodes are adjacent? If so I > assume the problem is that you can't logically coalesce these, even if > the actual generated code could be coalesced? Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire and Volatile with mf() if we would not use ld.acq/st.rel. Then there would be even more redundant operations. But that's out of scope of this change. > I still have this concern regarding the fact you think these are not > related to load/store operations. But I'll wait for the webrev. As stated above, yes, they are related to store/load operations. But not to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not part of the intrinsic. (I'm using the ia64 mnemonics in the implementation because I think they are nicely orthogonal. Also it's important to know that ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only the one load mentioned in the sequence. That's some hack in the processor.) Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Mittwoch, 20. November 2013 21:06 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. First apologies that the email you replied to here didn't go to the lists. Due to the way it was filtered I assumed it was a direct email only. :) On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for the comprehensive explanation. That's in agreement with > what I understand. Except that I think, unidirectional barriers only > make sense if you have Acquire/Release operations dedicated to > a certain operation. Then other operations of the same kind can pass > the barrier in one direction. > > This also matches the extension I contributed to hotspot (8024921), > which now allows to issue such operations right along with the > loads/stores. > > This change here tries to separate the barriers used after load/stores from > the 'wide' or better 'fence' variants. But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after loads/stores - but with stronger semantics than just simple loadLoad or storeStore barriers. > Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible > operations. Unfortunately, Hotspot knows only four of these: > MemBarStoreStore: S-S Okay - nice and clear. > MemBarAcquire: L-S, L-L I'm not sure what makes this "acquire" but this seems to be exactly what Unsafe.loadFence requires. > MemBarRelease: L-S, S-S Again I'm not sure what makes this "release" - I also find it odd that it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence needs. > MemBarVolatile: L-L, L-S, S-L, S-S A full fence, needed in the worst case when accessing a volatile variable. Also note that in different parts of the VM we have different expressions of these, both at the JIT level and runtime eg see orderAccess.hpp (which is not in itself self-consistent or clear: see https://bugs.openjdk.java.net/browse/JDK-7143664). Also I said that the Unsafe ops require bi-directional fences but that was imprecise - the _load and _store ops only require two of the four possible barriers which may be why you see these as distinct from the membars associated directly with variable accesses ? > and these don't map, e.g., the operations available on PPC: > lwsync: L-S, L-L, S-S > sync: L-L, L-S, S-L, S-S > What is the reason why it's hard for us to generate optimal code > with the available optimizations: > MemBarAcquire; > MemBarRelease; > are mapped to > lwsync > lwsync > which is obviously redundant. Are you referring to generated code if these nodes are adjacent? If so I assume the problem is that you can't logically coalesce these, even if the actual generated code could be coalesced? > A generic solution would be to have a single operation, that can be > Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. > Two operations could be merged by an optimization simply by > or-ing the tags. > But this is not reality in HotSpot, and out of scope of this change. Ok >> I think perhaps that Vladimir's suggestion is best - if these are the >> Membar nodes for these unsafe ops (and only these) then name them to >> match the unsafe ops. At least then it is clearer where the >> specification for their behaviour comes from. > OK, so I'll rename them as Vladimir proposed, and post a new webrev. I still have this concern regarding the fact you think these are not related to load/store operations. But I'll wait for the webrev. Thanks for your patience on this. Hopefully we can sort it out in the next 24 hours before I takeoff. David ----- > Best regards and a good flight home, > Goetz. > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 20. November 2013 14:30 > To: Lindenmaier, Goetz > Cc: David Holmes > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi Goetz, > > On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >> Hi David, >> I don't know what you mean by uni/bi-directional. > > Pretty much as you describe below. A unidirectional barrier allows > things to cross in one direction only ie it blocks motion one way; a > bi-directional barrier ("full fence") blocks both ways and so prevents > any reordering. > > As I described in earlier emails these kind of unreferenced > acquire/release semantics ie not associated with any stores/loads is > used to describe the memory barrier properties of a synchronized block, > for example. Monitor acquisition has acquire semantics, while monitor > release has store semantics. The implied barriers mean that any accesses > can move into the synchronized region but none can move out - the "roach > motel" semantics. > > Now as you say this kind of barrier is not what is wanted with these > loadFence/storeFence operations, hence I think the generic > MembarAcquire/MembarRelease are inappropriate names (whether the > implementation is correct is a different matter). Similarly I find the > MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - > what do they mean ??? > > The loadFence semantics imply a loadLoad|loadStore barrier. > The storeFence semantics imply a storeLoad|storeStore barrier. > The fullFence is of course all four. > > Again I'm unclear if the current or proposed MembarXXX actions actually > map to barriers that implement those semantics. > > So yes this comes down to naming initially but also verification that > the implementation does as required. > > I think perhaps that Vladimir's suggestion is best - if these are the > Membar nodes for these unsafe ops (and only these) then name them to > match the unsafe ops. At least then it is clearer where the > specification for their behaviour comes from. > > I'll post a follow up email to the list when I get a chance. I'm > currently in the US and attending lots of meetings then head back to > Australia tomorrow evening. > > Thanks, > David > >> I guess we agree that the documentation of the intrinsics, let's take >> loadFence >> for an example, talks about loads before the loadFence, and stores and >> loads after it: >> loads >> ------------loadFence()-------------- >> loads, stores >> With this, you can achieve any ordering by moving nodes up OR down: >> Op1 Move Op1 Op2 >> Op2 down ------------- >> --------- =========> Op3 >> Op3 Op1 >> Alternatively, you can move op3 up, and get the same order: >> Op1 Reorder Op2 Move Op3 Op2 >> Op2 Ops 1 and 2 Op1 up Op3 >> --------- =========> -------------- =========> Op1 >> Op3 Not restricted Op3 ---------- >> by later loadFence >> So, if the operation restricts only moves in one direction, it's of no >> help because >> you can still get an execution order you did not expect. So >> unidirectional operations >> (e.g., only hindering operations from moving up) are pointless. >> By the way, are you questioning whether the implementation is correct, or >> whether the names express what is desired? >> If it's the first, it's of no concern to this change, which is only about >> matching these operations independently from those, that address >> a dedicated memory operation. >> If It's the second, please tell me what names to use, and I'll fix it. >> (I hope you can properly read the 'drawings') >> Best regards, >> Goetz. >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Dienstag, 19. November 2013 20:51 >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >> 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >> MemBarAcquire/ReleaseWide. >> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> this are the instrinsics for sun/misc/Unsafe, which are documented >>> as shown below. So I guess that's just what is desired. >> I don't think so! What is described for Unsafe are full bi-directional >> fences and "acquire" and "release" are only uni-directional fences! >> David >> ----- >>> Best regards, >>> Goetz. >>> >>> /** >>> * Ensures lack of reordering of loads before the fence >>> * with loads or stores after the fence. >>> * @since 1.8 >>> */ >>> public native void loadFence(); >>> >>> /** >>> * Ensures lack of reordering of stores before the fence >>> * with loads or stores after the fence. >>> * @since 1.8 >>> */ >>> public native void storeFence(); >>> >>> /** >>> * Ensures lack of reordering of loads or stores before the fence >>> * with loads or stores after the fence. >>> * @since 1.8 >>> */ >>> public native void fullFence(); >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 19, 2013 8:08 PM >>> To: Lindenmaier, Goetz >>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> So I like the rename but I am concerned there are semantic issues here: >>> >>> switch(id) { >>> case vmIntrinsics::_loadFence: >>> - insert_mem_bar(Op_MemBarAcquire); >>> + insert_mem_bar(Op_MemBarFenceAcquire); >>> return true; >>> case vmIntrinsics::_storeFence: >>> - insert_mem_bar(Op_MemBarRelease); >>> + insert_mem_bar(Op_MemBarFenceRelease); >>> return true; >>> >>> What is a _loadFence operation? Does it really map to >>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>> bi-directional fences - are they? Are they really only concerned with >>> loads or stores ? >>> >>> David >>> >>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I made a new webrev, using the new names: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>> >>>> Thanks, >>>> Goetz. >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Montag, 18. November 2013 23:28 >>>> To: Lindenmaier, Goetz; 'David Holmes' >>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, Vladimir, >>>>> >>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>> - the same prefix shows they are all similar nodes. >>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>> change yet and which is used in more places. >>>> >>>> Okay. >>>> >>>> Vladimir >>>> >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>> To: Vladimir Kozlov >>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> Vladimir, >>>>> >>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>> I think David asked for different nodes not just one. >>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>> >>>>> But I don't think that actually describes them - they don't distinguish >>>>> between loads and stores only the direction in which the barrier >>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>> only allows accesses to move above it ie: >>>>> >>>>> load a >>>>> store b, c >>>>> acquire(); >>>>> load d >>>>> store e,f >>>>> release(); >>>>> load g >>>>> store h, i >>>>> >>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>> the store to e can not move in relation to either acquire or release. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> as reply to your comment on the bug: >>>>>>> >>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>> MemBarAcquireWide --> lwsync >>>>>>> MemBarReleaseWide --> lwsync >>>>>>> MemBarVolatile --> sync. >>>>>>> On Sparc, you even do 3 different operations. >>>>>>> >>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>> Therefore I think a really clean representation that, at the same >>>>>>> time, allows >>>>>>> to find the cheapest set of instructions to express it on all >>>>>>> processors, is impossible. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>> or on the mailing lists? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >> >>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>> Lindenmaier, Goetz >>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>> MemBarAcquire/ReleaseWide. >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>> >>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>> matched differently, what is needed on PPC64. >>>>>>> >>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>> >>>>>>> Please review and test this change. >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> From bengt.rutisson at oracle.com Thu Nov 21 02:24:25 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Nov 2013 11:24:25 +0100 Subject: CFV: New hotspot Group Member: Thomas Schatzl In-Reply-To: <527A6760.7030101@oracle.com> References: <527A6760.7030101@oracle.com> Message-ID: <528DDF59.4060908@oracle.com> The vote for Thomas Schatzl [1] is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011500.html From bengt.rutisson at oracle.com Thu Nov 21 02:24:48 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Nov 2013 11:24:48 +0100 Subject: Result: CFV: New hotspot Group Member: Mikael Gerdin In-Reply-To: <527A57BD.4020504@oracle.com> References: <527A57BD.4020504@oracle.com> Message-ID: <528DDF70.6030504@oracle.com> The vote for Mikael Gerdin [1] is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011499.html From bengt.rutisson at oracle.com Thu Nov 21 02:24:41 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Nov 2013 11:24:41 +0100 Subject: Result: CFV: New hotspot Group Member: Erik Helin In-Reply-To: <527A5830.9050703@oracle.com> References: <527A5830.9050703@oracle.com> Message-ID: <528DDF69.8050303@oracle.com> The vote for Erik Helin [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011497.html From bengt.rutisson at oracle.com Thu Nov 21 02:24:33 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Nov 2013 11:24:33 +0100 Subject: Result: CFV: New hotspot Group Member: Jesper Wilhelmsson In-Reply-To: <527A64C7.1030502@oracle.com> References: <527A64C7.1030502@oracle.com> Message-ID: <528DDF61.3070401@oracle.com> The vote for Jesper Wilhelmsson [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011498.html From bengt.rutisson at oracle.com Thu Nov 21 03:26:40 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Nov 2013 12:26:40 +0100 Subject: CFV: New hsx Committer: Eric McCorkle In-Reply-To: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> References: <4A7A811B-7533-4B8D-8D74-11F6ACFB68F4@oracle.com> Message-ID: <528DEDF0.4090207@oracle.com> Vote: yes Bengt On 11/19/13 8:28 PM, Karen Kinnear wrote: > I hereby nominate Eric McCorkle (openjdk username: emc ) to be an OpenJDK hsx > [0] Committer [1]. > > Eric McCorkle joined the langtools team over a year ago and in addition to the work > he has contributed to the jdk, has been a significant contributor to the hotspot team. > Specifically, he added the Method Parameter Annotations, including reflection, serviceability > agent and redefineclasses support. He also has done some work in jni and jvm > interfaces. > > In addition, Eric has been extremely helpful with the lambda default methods effort. > > Votes are due Thursday December 3rd at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] 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 [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/56c364daccc3 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24a91505f9d5 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9eb431c3efe > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ade95d680b42 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d1644a010f52 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/58bb870a0cbd > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ba9dacff9c9d > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35 > > Eric also contributed the majority of the code changes to the following > serviceability patch: > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d2db09f281ca From david.holmes at oracle.com Thu Nov 21 06:30:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Nov 2013 00:30:15 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> Message-ID: <528E18F7.7050001@oracle.com> Hi Goetz, On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: > Hi David, > > here the new webrev, naming the nodes LoadFence/StoreFence: > http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ Okay. I think I now disagree (when seeing in context) that Membar should have been dropped from the name but I'll let that lie. Aside: I find the descriptions of all those "membar" nodes very unclear - it would be better, for me, if there were expressed more clearly in terms of storeStore, storeLoad etc. Could you add to the comments in memnode.hpp that those nodes are only used by the respective Unsafe intrinisics? Or at least use that as an example usage? > The thing with the mail was my fault, I had sent the first mail > only to you accidentially. Sorry for that. > >> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >> loads/stores - but with stronger semantics than just simple loadLoad or >> storeStore barriers. > Yes. I mean they do not intend to sort a single load/store with succeeding > operations. This can not be implemented this way, as the operation > is not known in the intrinsic. I mean cases where you can use ia64 ld.acq > or ppc ld-twi-lwsync. If you are saying that loadFence and storeFence can not be implemented using ld.acq and st.rel then good I agree with you. But I would argue that general ld;MembarAcquire and st;MembarRelease can also not be implemented with those instructions! As you state ld.acq and st.rel only relate to the target load/store _but_ there are no actions in the Java Memory Model that only provide ordering with respect to a single load or store! The Unsafe *Ordered() operations may come closer to this but I would expect them to be handled via an intrinsic - and they are outside the JMM. So I would think the applicability of using ld.acq and st.rel would be very limited, so it concerns me that it seems to be associated with the very general MembarAcquire and MembarRelease nodes (ditto for the changes in 8024921). But how you implement this is your concern. :) From the perspective of this shared code my concern is that it is not clear exactly what the practical distinction is between MembarAcquire and LoadFence, and MembarRelease and StoreFence. I'm not a compiler person but I would find it quite difficult to know which can/should be used when. And given for most platforms they would be implemented the same, that would add to the uncertainty (with a risk that someone will make an arbitrary choice). Thanks, David ----- >> Also I said that the Unsafe ops require bi-directional fences but that >> was imprecise - the _load and _store ops only require two of the four >> possible barriers which may be why you see these as distinct from the >> membars associated directly with variable accesses ? > On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. > For the intrinsic I must use mf, which sorts _all_ previous loads with all > following ld/st operations (and more). So my distinction is if I have a > store on one processor, and a load on the other, and I want to make sure > the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. > If I did some arbitrary stores, and I want assure an other processor doing > some arbitrary load,s then I must use - on ia64- mf on both. > On sparc I can do a > membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); > membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); > But, on sparc, there is no operation as ld.acq as far as I know. > > Change 8024921 enables to distinguish normal loads and such > that should do ld.acq. This change enables the compiler to > differentiate the MemBar nodes used better: such coming after > a dedicated load, and such valid for any load before the barrier. > This is already visible in the IR by some means: MemBars after > dedicated loads have an input edge at position MemBar::precedence > connecting them with the load, but that does not suffice to > match it (in the matcher) correctly. > If I use ld.acq, the following MemBarAcquire is superfluous, > but the MemBarAcquire used in the intrinsic is not. So want to > have different nodes. > In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, > and with #ifdef ia64 we use MemBarVolatile, as we know these operations will > issue the proper assembly instructions. But this is bad - I want to do it better > here. > >> Are you referring to generated code if these nodes are adjacent? If so I >> assume the problem is that you can't logically coalesce these, even if >> the actual generated code could be coalesced? > Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire > and Volatile with mf() if we would not use ld.acq/st.rel. Then there > would be even more redundant operations. But that's out of scope of this change. > >> I still have this concern regarding the fact you think these are not >> related to load/store operations. But I'll wait for the webrev. > As stated above, yes, they are related to store/load operations. But not > to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not > part of the intrinsic. > > (I'm using the ia64 mnemonics in the implementation because I think > they are nicely orthogonal. Also it's important to know that > ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only > the one load mentioned in the sequence. That's some hack in the > processor.) > > Best regards, > Goetz. > > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 20. November 2013 21:06 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > First apologies that the email you replied to here didn't go to the > lists. Due to the way it was filtered I assumed it was a direct email > only. :) > > On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> thanks for the comprehensive explanation. That's in agreement with >> what I understand. Except that I think, unidirectional barriers only >> make sense if you have Acquire/Release operations dedicated to >> a certain operation. Then other operations of the same kind can pass >> the barrier in one direction. >> >> This also matches the extension I contributed to hotspot (8024921), >> which now allows to issue such operations right along with the >> loads/stores. >> >> This change here tries to separate the barriers used after load/stores from >> the 'wide' or better 'fence' variants. > > But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after > loads/stores - but with stronger semantics than just simple loadLoad or > storeStore barriers. > >> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible >> operations. Unfortunately, Hotspot knows only four of these: >> MemBarStoreStore: S-S > > Okay - nice and clear. > >> MemBarAcquire: L-S, L-L > > I'm not sure what makes this "acquire" but this seems to be exactly what > Unsafe.loadFence requires. > >> MemBarRelease: L-S, S-S > > Again I'm not sure what makes this "release" - I also find it odd that > it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence > needs. > >> MemBarVolatile: L-L, L-S, S-L, S-S > > A full fence, needed in the worst case when accessing a volatile variable. > > Also note that in different parts of the VM we have different > expressions of these, both at the JIT level and runtime eg see > orderAccess.hpp (which is not in itself self-consistent or clear: see > https://bugs.openjdk.java.net/browse/JDK-7143664). > > Also I said that the Unsafe ops require bi-directional fences but that > was imprecise - the _load and _store ops only require two of the four > possible barriers which may be why you see these as distinct from the > membars associated directly with variable accesses ? > >> and these don't map, e.g., the operations available on PPC: >> lwsync: L-S, L-L, S-S >> sync: L-L, L-S, S-L, S-S >> What is the reason why it's hard for us to generate optimal code >> with the available optimizations: >> MemBarAcquire; >> MemBarRelease; >> are mapped to >> lwsync >> lwsync >> which is obviously redundant. > > Are you referring to generated code if these nodes are adjacent? If so I > assume the problem is that you can't logically coalesce these, even if > the actual generated code could be coalesced? > >> A generic solution would be to have a single operation, that can be >> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >> Two operations could be merged by an optimization simply by >> or-ing the tags. >> But this is not reality in HotSpot, and out of scope of this change. > > Ok > >>> I think perhaps that Vladimir's suggestion is best - if these are the >>> Membar nodes for these unsafe ops (and only these) then name them to >>> match the unsafe ops. At least then it is clearer where the >>> specification for their behaviour comes from. >> OK, so I'll rename them as Vladimir proposed, and post a new webrev. > > I still have this concern regarding the fact you think these are not > related to load/store operations. But I'll wait for the webrev. > > Thanks for your patience on this. Hopefully we can sort it out in the > next 24 hours before I takeoff. > > David > ----- > >> Best regards and a good flight home, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. November 2013 14:30 >> To: Lindenmaier, Goetz >> Cc: David Holmes >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> Hi Goetz, >> >> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> I don't know what you mean by uni/bi-directional. >> >> Pretty much as you describe below. A unidirectional barrier allows >> things to cross in one direction only ie it blocks motion one way; a >> bi-directional barrier ("full fence") blocks both ways and so prevents >> any reordering. >> >> As I described in earlier emails these kind of unreferenced >> acquire/release semantics ie not associated with any stores/loads is >> used to describe the memory barrier properties of a synchronized block, >> for example. Monitor acquisition has acquire semantics, while monitor >> release has store semantics. The implied barriers mean that any accesses >> can move into the synchronized region but none can move out - the "roach >> motel" semantics. >> >> Now as you say this kind of barrier is not what is wanted with these >> loadFence/storeFence operations, hence I think the generic >> MembarAcquire/MembarRelease are inappropriate names (whether the >> implementation is correct is a different matter). Similarly I find the >> MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - >> what do they mean ??? >> >> The loadFence semantics imply a loadLoad|loadStore barrier. >> The storeFence semantics imply a storeLoad|storeStore barrier. >> The fullFence is of course all four. >> >> Again I'm unclear if the current or proposed MembarXXX actions actually >> map to barriers that implement those semantics. >> >> So yes this comes down to naming initially but also verification that >> the implementation does as required. >> >> I think perhaps that Vladimir's suggestion is best - if these are the >> Membar nodes for these unsafe ops (and only these) then name them to >> match the unsafe ops. At least then it is clearer where the >> specification for their behaviour comes from. >> >> I'll post a follow up email to the list when I get a chance. I'm >> currently in the US and attending lots of meetings then head back to >> Australia tomorrow evening. >> >> Thanks, >> David >> >>> I guess we agree that the documentation of the intrinsics, let's take >>> loadFence >>> for an example, talks about loads before the loadFence, and stores and >>> loads after it: >>> loads >>> ------------loadFence()-------------- >>> loads, stores >>> With this, you can achieve any ordering by moving nodes up OR down: >>> Op1 Move Op1 Op2 >>> Op2 down ------------- >>> --------- =========> Op3 >>> Op3 Op1 >>> Alternatively, you can move op3 up, and get the same order: >>> Op1 Reorder Op2 Move Op3 Op2 >>> Op2 Ops 1 and 2 Op1 up Op3 >>> --------- =========> -------------- =========> Op1 >>> Op3 Not restricted Op3 ---------- >>> by later loadFence >>> So, if the operation restricts only moves in one direction, it's of no >>> help because >>> you can still get an execution order you did not expect. So >>> unidirectional operations >>> (e.g., only hindering operations from moving up) are pointless. >>> By the way, are you questioning whether the implementation is correct, or >>> whether the names express what is desired? >>> If it's the first, it's of no concern to this change, which is only about >>> matching these operations independently from those, that address >>> a dedicated memory operation. >>> If It's the second, please tell me what names to use, and I'll fix it. >>> (I hope you can properly read the 'drawings') >>> Best regards, >>> Goetz. >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 19. November 2013 20:51 >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>> 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>> MemBarAcquire/ReleaseWide. >>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>> as shown below. So I guess that's just what is desired. >>> I don't think so! What is described for Unsafe are full bi-directional >>> fences and "acquire" and "release" are only uni-directional fences! >>> David >>> ----- >>>> Best regards, >>>> Goetz. >>>> >>>> /** >>>> * Ensures lack of reordering of loads before the fence >>>> * with loads or stores after the fence. >>>> * @since 1.8 >>>> */ >>>> public native void loadFence(); >>>> >>>> /** >>>> * Ensures lack of reordering of stores before the fence >>>> * with loads or stores after the fence. >>>> * @since 1.8 >>>> */ >>>> public native void storeFence(); >>>> >>>> /** >>>> * Ensures lack of reordering of loads or stores before the fence >>>> * with loads or stores after the fence. >>>> * @since 1.8 >>>> */ >>>> public native void fullFence(); >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>> To: Lindenmaier, Goetz >>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> So I like the rename but I am concerned there are semantic issues here: >>>> >>>> switch(id) { >>>> case vmIntrinsics::_loadFence: >>>> - insert_mem_bar(Op_MemBarAcquire); >>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>> return true; >>>> case vmIntrinsics::_storeFence: >>>> - insert_mem_bar(Op_MemBarRelease); >>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>> return true; >>>> >>>> What is a _loadFence operation? Does it really map to >>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>> bi-directional fences - are they? Are they really only concerned with >>>> loads or stores ? >>>> >>>> David >>>> >>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I made a new webrev, using the new names: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>> >>>>> Thanks, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Montag, 18. November 2013 23:28 >>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, Vladimir, >>>>>> >>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>> - the same prefix shows they are all similar nodes. >>>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>>> change yet and which is used in more places. >>>>> >>>>> Okay. >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>> To: Vladimir Kozlov >>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>> >>>>>> Vladimir, >>>>>> >>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>> I think David asked for different nodes not just one. >>>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>> >>>>>> But I don't think that actually describes them - they don't distinguish >>>>>> between loads and stores only the direction in which the barrier >>>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>>> only allows accesses to move above it ie: >>>>>> >>>>>> load a >>>>>> store b, c >>>>>> acquire(); >>>>>> load d >>>>>> store e,f >>>>>> release(); >>>>>> load g >>>>>> store h, i >>>>>> >>>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>>> the store to e can not move in relation to either acquire or release. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> as reply to your comment on the bug: >>>>>>>> >>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>> MemBarVolatile --> sync. >>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>> >>>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>>> Therefore I think a really clean representation that, at the same >>>>>>>> time, allows >>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>> processors, is impossible. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz >>>>>>>> >>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>> or on the mailing lists? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>> >>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>> Lindenmaier, Goetz >>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>>> >>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>>> matched differently, what is needed on PPC64. >>>>>>>> >>>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>> >>>>>>>> Please review and test this change. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> From stefan.johansson at oracle.com Thu Nov 21 08:43:23 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 21 Nov 2013 17:43:23 +0100 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 Message-ID: <528E382B.2030001@oracle.com> Hi all, Can I have a couple reviews for this fix for: https://bugs.openjdk.java.net/browse/JDK-8027675 Webrev: http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ Summary: When doing permgen removal we had to change the way classes were marked and handled in the GC. When doing this we ended up doing some things a little less efficient than before. The regression is easy to reproduce and when doing a JFR recording we can see that we now spend more time in both the mark and adjust phase. To improve the mark phase: * Enabled the calls to follow_klass to be inlined. * Reduce the extensive amount of calls to follow_class_loader in follow_klass and instead just mark the klass holder (the class loader or the java mirror) for the given klass. To improve the adjust phase: * All calls to adjust_klass have been removed since this is already handled by processing the ClassLoaderDataGraph. Testing: * Manually ran SPECjbb2005 to verify fixing the regression * JPRT for functional sanity testing * Nashorn tests to stress anonymous classes Thanks, StefanJ From john.coomes at oracle.com Thu Nov 21 10:31:53 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:31:53 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b117 for changeset c1d234d4f164 Message-ID: <20131121183202.4174562753@hg.openjdk.java.net> Changeset: e4e5069250e7 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/e4e5069250e7 Added tag jdk8-b117 for changeset c1d234d4f164 ! .hgtags From john.coomes at oracle.com Thu Nov 21 10:31:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:31:34 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b117 for changeset a4afb0a8d55e Message-ID: <20131121183134.D608162751@hg.openjdk.java.net> Changeset: 0a6db1aac998 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0a6db1aac998 Added tag jdk8-b117 for changeset a4afb0a8d55e ! .hgtags From john.coomes at oracle.com Thu Nov 21 10:31:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:31:41 +0000 Subject: hg: hsx/hotspot-main/corba: 4 new changesets Message-ID: <20131121183146.A4EBE62752@hg.openjdk.java.net> Changeset: b99535e22efe Author: mchung Date: 2013-11-07 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/b99535e22efe 8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45 Reviewed-by: msheppar, alanb, lancea ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: 4796555c4dc8 Author: lana Date: 2013-11-08 17:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/4796555c4dc8 Merge Changeset: e53d1ee4d2ae Author: lana Date: 2013-11-14 23:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e53d1ee4d2ae Merge Changeset: d6820a414f18 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d6820a414f18 Added tag jdk8-b117 for changeset e53d1ee4d2ae ! .hgtags From john.coomes at oracle.com Thu Nov 21 10:32:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:32:11 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b117 for changeset fe56ba456fd3 Message-ID: <20131121183217.9829962754@hg.openjdk.java.net> Changeset: 76a598cf50c4 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/76a598cf50c4 Added tag jdk8-b117 for changeset fe56ba456fd3 ! .hgtags From john.coomes at oracle.com Thu Nov 21 10:35:07 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:35:07 +0000 Subject: hg: hsx/hotspot-main/jdk: 90 new changesets Message-ID: <20131121185356.D28DB62756@hg.openjdk.java.net> Changeset: f2ae86dba4bc Author: prr Date: 2013-11-13 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f2ae86dba4bc 8028206: sun/java2d/cmm/ProfileOp/SetDataTest.java fails Reviewed-by: bae, jchen ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: b691a6abf9e0 Author: lana Date: 2013-11-14 23:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b691a6abf9e0 Merge Changeset: 30766f910509 Author: malenkov Date: 2013-11-01 21:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30766f910509 8026491: Typos in string literals Reviewed-by: alexsch, anthony ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/macosx/classes/com/apple/laf/resources/aqua.properties ! src/share/classes/com/sun/imageio/plugins/common/StandardMetadataFormatResources.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubNextRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubRequestHandler.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/script/shell/init.js ! src/share/classes/com/sun/tools/script/shell/messages.properties ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/sample/nio/chatserver/ClientReader.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java Changeset: b8eb21e93fa7 Author: yan Date: 2013-11-07 18:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b8eb21e93fa7 8025234: [javadoc] fix some errors in javax.swing.** Reviewed-by: alexsch, malenkov Contributed-by: Dmitry Ginzburg ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/Action.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DesktopManager.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JTextField.java Changeset: 29f979efbabf Author: malenkov Date: 2013-11-08 14:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/29f979efbabf 8027648: Type of overridden property is resolved incorrectly Reviewed-by: alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java + test/java/beans/Introspector/Test8027648.java + test/java/beans/Introspector/Test8027905.java Changeset: 184f13eeed41 Author: lana Date: 2013-11-08 15:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/184f13eeed41 Merge - src/share/classes/java/lang/invoke/MagicLambdaImpl.java - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties - test/java/net/NetworkInterface/MemLeakTest.java - test/jdk/lambda/vm/DefaultMethodsTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out Changeset: 4bc2414624e2 Author: leonidr Date: 2013-11-12 20:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bc2414624e2 8027972: [macosx] Provide a regression test for JDK-8007006 Reviewed-by: anthony + test/java/awt/MenuBar/8007006/bug8007006.java Changeset: 0242fce0f717 Author: serb Date: 2013-11-12 20:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0242fce0f717 8027696: Incorrect copyright header in the tests Reviewed-by: alanb, malenkov, mullan ! test/ProblemList.txt ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/Client.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/ConfigKey.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Client/TestNotification.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/ConfigKey.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Server.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/Ste.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/SteMBean.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/Server/TestNotification.java ! test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java ! test/com/sun/jndi/cosnaming/CNNameParser.java ! test/com/sun/jndi/cosnaming/IiopUrlIPv6.java ! test/demo/zipfs/ZipFSTester.java ! test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java ! test/java/awt/Choice/ChoiceKeyEventReaction/ChoiceKeyEventReaction.html ! test/java/awt/Choice/NonFocusablePopupMenuTest/NonFocusablePopupMenuTest.html ! test/java/awt/Component/F10TopToplevel/F10TopToplevel.html ! test/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html ! test/java/awt/EventQueue/MainAppContext/MainAppContext.java ! test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java ! test/java/awt/FileDialog/FileDialogReturnTest/FileDialogReturnTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.html ! test/java/awt/FileDialog/FileNameOverrideTest/FileNameOverrideTest.java ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html ! test/java/awt/FileDialog/MultipleMode/MultipleMode.html ! test/java/awt/FileDialog/RegexpFilterTest/RegexpFilterTest.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.html ! test/java/awt/FileDialog/SaveFileNameOverrideTest/SaveFileNameOverrideTest.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java ! test/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html ! test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_AWT.java ! test/java/awt/Focus/FocusTraversalPolicy/InitialFTP_Swing.java ! test/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html ! test/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html ! test/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html ! test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java ! test/java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html ! test/java/awt/Frame/ShownOnPack/ShownOnPack.html ! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java ! test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java ! test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java ! test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.html ! test/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html ! test/java/awt/List/SetFontTest/SetFontTest.html ! test/java/awt/Menu/NullMenuLabelTest/NullMenuLabelTest.java ! test/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html ! test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java ! test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java ! test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java ! test/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html ! test/java/awt/Multiscreen/TranslucencyThrowsExceptionWhenFullScreen/TranslucencyThrowsExceptionWhenFullScreen.java ! test/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html ! test/java/awt/PrintJob/Text/stringwidth.sh ! test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java ! test/java/awt/Robot/ManualInstructions/ManualInstructions.java ! test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java ! test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java ! test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java ! test/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.html ! test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html ! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html ! test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java ! test/java/awt/Toolkit/Headless/ExceptionContract/ExceptionContract.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJob.java ! test/java/awt/Toolkit/Headless/GetPrintJob/GetPrintJobHeadless.java ! test/java/awt/Toolkit/SecurityTest/SecurityTest2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java ! test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java ! test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java ! test/java/awt/Window/Grab/GrabTest.java ! test/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java ! test/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/test.html ! test/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html ! test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html ! test/java/awt/dnd/Button2DragTest/Button2DragTest.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.html ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java ! test/java/awt/dnd/DnDFileGroupDescriptor/DnDTarget.java ! test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html ! test/java/awt/dnd/ImageDecoratedDnD/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnD/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.html ! test/java/awt/dnd/ImageDecoratedDnD/ImageDecoratedDnD.java ! test/java/awt/dnd/ImageDecoratedDnD/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnD/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDInOut/MyCursor.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDSource.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/DnDTarget.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageGenerator.java ! test/java/awt/dnd/ImageDecoratedDnDNegative/MyCursor.java ! test/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html ! test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.html ! test/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java ! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html ! test/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html ! test/java/awt/event/MouseEvent/AWTPanelSmoothWheel/AWTPanelSmoothWheel.html ! test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java ! test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java ! test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java ! test/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html ! test/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html ! test/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html ! test/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html ! test/java/awt/event/OtherEvents/UngrabID/UngrabID.java ! test/java/awt/im/4490692/bug4490692.html ! test/java/awt/im/4959409/bug4959409.html ! test/java/awt/im/JTextFieldTest.html ! test/java/awt/image/BufferedImage/TinyScale.java ! test/java/awt/image/DrawImage/EABlitTest.java ! test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java ! test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java ! test/java/awt/print/bug8023392/bug8023392.html ! test/java/awt/print/bug8023392/bug8023392.java ! test/java/beans/Introspector/6380849/beans/FirstBean.java ! test/java/beans/Introspector/6380849/beans/FirstBeanBeanInfo.java ! test/java/beans/Introspector/6380849/beans/SecondBean.java ! test/java/beans/Introspector/6380849/beans/ThirdBean.java ! test/java/beans/Introspector/6380849/infos/SecondBeanBeanInfo.java ! test/java/beans/Introspector/6380849/infos/ThirdBeanBeanInfo.java ! test/java/beans/Introspector/6976577/test/Accessor.java ! test/java/beans/Introspector/7122138/pack/Sub.java ! test/java/beans/Introspector/7122138/pack/Super.java ! test/java/beans/XMLEncoder/6380849/Bean.java ! test/java/beans/XMLEncoder/6380849/BeanPersistenceDelegate.java ! test/java/io/FileInputStream/OpsAfterClose.java ! test/java/io/FileOutputStream/OpsAfterClose.java ! test/java/io/RandomAccessFile/OpsAfterClose.java ! test/java/lang/StringBuffer/BufferForwarding.java ! test/java/lang/StringBuilder/BuilderForwarding.java ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RevealDirectTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/TestCatchExceptionWithVarargs.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/lang/ref/ReferenceEnqueuePending.java ! test/java/net/URLClassLoader/closetest/build.sh ! test/java/security/cert/CertPathBuilder/selfIssued/generate.sh ! test/java/security/cert/CertPathValidator/indirectCRL/generate.sh ! test/java/security/cert/CertPathValidator/nameConstraints/generate.sh ! test/java/security/cert/CertificateRevokedException/Basic.java ! test/java/util/Calendar/CldrFormatNamesTest.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/Locale/LocaleTestFmwk.java ! test/java/util/Locale/tools/EquivMapsGenerator.java ! test/java/util/TimeZone/Bug6912560.java ! test/java/util/TimeZone/CLDRDisplayNamesTest.java ! test/java/util/TimeZone/ListTimeZones.java ! test/java/util/TimeZone/OldIDMappingTest.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/java/util/TimeZone/SetDefaultSecurityTest.java ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.java ! test/java/util/TimeZone/TzIDOldMapping.java ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefFirst.java ! test/java/util/prefs/CheckUserPrefLater.java ! test/java/util/regex/RegExTest.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TotalInOut.java ! test/javax/imageio/plugins/gif/GifTransparencyTest.java ! test/javax/management/modelmbean/LoggingExceptionTest.java ! test/javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java ! test/javax/print/DialogMargins.java ! test/javax/print/StreamPrintingOrientation.java ! test/javax/print/applet/AppletPrintLookup.html ! test/javax/sound/midi/File/SMPTESequence.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java ! test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java ! test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java ! test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java ! test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java ! test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java ! test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java ! test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java ! test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetName.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java ! test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java ! test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java ! test/javax/sound/midi/Gervill/ModelSource/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java ! test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java ! test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java ! test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java ! test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java ! test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java ! test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java ! test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/Controller.java ! test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java ! test/javax/sound/midi/Gervill/SoftChannel/Mono.java ! test/javax/sound/midi/Gervill/SoftChannel/Mute.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest.java ! test/javax/sound/midi/Gervill/SoftChannel/NoteOverFlowTest2.java ! test/javax/sound/midi/Gervill/SoftChannel/Omni.java ! test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java ! test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java ! test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftChannel/Solo.java ! test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java ! test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java ! test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java ! test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java ! test/javax/sound/midi/Gervill/SoftLowFrequencyOscillator/TestProcessControlLogic.java ! test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Close.java ! test/javax/sound/midi/Gervill/SoftReceiver/GetMidiDevice.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java ! test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java ! test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java ! test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestPreciseTimestampRendering.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java ! test/javax/sound/midi/Gervill/SoftTuning/GetName.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java ! test/javax/sound/midi/Gervill/SoftTuning/Load1.java ! test/javax/sound/midi/Gervill/SoftTuning/Load2.java ! test/javax/sound/midi/Gervill/SoftTuning/Load4.java ! test/javax/sound/midi/Gervill/SoftTuning/Load5.java ! test/javax/sound/midi/Gervill/SoftTuning/Load6.java ! test/javax/sound/midi/Gervill/SoftTuning/Load7.java ! test/javax/sound/midi/Gervill/SoftTuning/Load8.java ! test/javax/sound/midi/Gervill/SoftTuning/Load9.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java ! test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java ! test/javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java ! test/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java ! test/javax/sound/midi/Sequencer/SequencerImplicitSynthOpen.java ! test/javax/sound/sampled/AudioFormat/Matches_NOT_SPECIFIED.java ! test/javax/sound/sampled/AudioFormat/PCM_FLOAT_support.java ! test/javax/sound/sampled/Clip/ClipSetPos.java ! test/javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java ! test/javax/sound/sampled/DirectAudio/bug6400879.java ! test/javax/sound/sampled/FileWriter/AlawEncoderSync.java ! test/javax/sound/sampled/FileWriter/WriterCloseInput.java ! test/javax/swing/JCheckBox/4449413/bug4449413.html ! test/javax/swing/JColorChooser/Test4222508.html ! test/javax/swing/JColorChooser/Test4759306.html ! test/javax/swing/JColorChooser/Test4759934.html ! test/javax/swing/JColorChooser/Test4887836.html ! test/javax/swing/JColorChooser/Test6348456.html ! test/javax/swing/JColorChooser/Test6977726.html ! test/javax/swing/JComponent/4337267/bug4337267.java ! test/javax/swing/JComponent/6683775/bug6683775.java ! test/javax/swing/JEditorPane/4492274/test.html ! test/javax/swing/JEditorPane/6917744/test.html ! test/javax/swing/JEditorPane/bug4714674.java ! test/javax/swing/JFileChooser/6570445/bug6570445.java ! test/javax/swing/JFileChooser/6698013/bug6698013.html ! test/javax/swing/JFileChooser/6698013/bug6698013.java ! test/javax/swing/JFileChooser/6798062/bug6798062.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.html ! test/javax/swing/JInternalFrame/6726866/bug6726866.java ! test/javax/swing/JSlider/4987336/bug4987336.html ! test/javax/swing/JSlider/6524424/bug6524424.html ! test/javax/swing/JSlider/6587742/bug6587742.html ! test/javax/swing/JSlider/6742358/bug6742358.html ! test/javax/swing/JTabbedPane/4310381/bug4310381.html ! test/javax/swing/JTree/4314199/bug4314199.html ! test/javax/swing/SwingUtilities/7170657/bug7170657.java ! test/javax/swing/border/Test4129681.html ! test/javax/swing/border/Test4243289.html ! test/javax/swing/border/Test4247606.html ! test/javax/swing/border/Test4252164.html ! test/javax/swing/border/Test4760089.html ! test/javax/swing/border/Test6910490.html ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/html/TableView/7030332/bug7030332.html ! test/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html ! test/sun/nio/cs/EUC_TW_OLD.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/X11CNS11643.java ! test/sun/nio/cs/X11CNS11643P1.java ! test/sun/nio/cs/X11CNS11643P2.java ! test/sun/nio/cs/X11CNS11643P3.java ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java ! test/sun/security/pkcs11/ec/TestECGenSpec.java ! test/sun/security/pkcs11/ec/TestKeyFactory.java ! test/sun/util/resources/Locale/Bug6275682.java ! test/tools/launcher/DiacriticTest.java ! test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java ! test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java Changeset: d6fe4e451dfb Author: bagiras Date: 2013-11-13 20:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6fe4e451dfb 8028283: Revert JavaDoc changes pushed for JDK-7068423 Reviewed-by: art, serb ! src/share/classes/java/awt/GraphicsDevice.java Changeset: 535f19dd3960 Author: pchelko Date: 2013-11-14 10:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/535f19dd3960 8028230: Behavior of SystemFlavorMap.getNativesForFlavor differ from that in Java 7 Reviewed-by: anthony, serb ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java + test/java/awt/datatransfer/DuplicatedNativesTest/DuplicatedNativesTest.java Changeset: 8d17ebcef958 Author: pchelko Date: 2013-11-14 11:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d17ebcef958 8025440: [TEST_BUG] com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java failed since jdk8b108 Reviewed-by: anthony + test/com/sun/awt/SecurityWarning/CustomSecurityManager.java ! test/com/sun/awt/SecurityWarning/GetSizeShouldNotReturnZero.java + test/java/awt/regtesthelpers/CopyClassFile.java Changeset: ca0db77f6d6b Author: lana Date: 2013-11-14 23:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ca0db77f6d6b Merge Changeset: c35f6df5bce9 Author: sla Date: 2013-11-01 10:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c35f6df5bce9 8027692: Remove java/lang/management/MemoryMXBean/LowMemoryTest2.sh from ProblemList.txt Reviewed-by: stefank, alanb ! test/ProblemList.txt Changeset: c59ccad6eb72 Author: sla Date: 2013-11-01 15:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c59ccad6eb72 8027705: com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. Reviewed-by: dcubed ! test/com/sun/jdi/JdbMethodExitTest.sh ! test/com/sun/jdi/ShellScaffold.sh Changeset: 6a6faa00acc4 Author: dxu Date: 2013-11-01 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a6faa00acc4 8027624: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java unstable again Reviewed-by: wetmore ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java Changeset: adcc01f5bc93 Author: jrose Date: 2013-11-02 20:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/adcc01f5bc93 8024635: Caching MethodType's descriptor string improves lambda linkage performance Summary: Better interpreted and compiled performance of operations in MethodType important to LambdaMetafactory. Reviewed-by: jrose, twisti, mchung Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: d19ab5da83cc Author: dholmes Date: 2013-11-04 06:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d19ab5da83cc 8025198: Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java Reviewed-by: martin, dholmes Contributed-by: Tristan Yan ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk ! src/share/bin/java.c ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java Changeset: 23982079ad49 Author: dholmes Date: 2013-11-04 07:39 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23982079ad49 8027755: Anti-delta incorrect push for 8025198 Reviewed-by: alanb ! makefiles/CompileLaunchers.gmk ! makefiles/lib/CoreLibraries.gmk ! src/share/bin/java.c Changeset: 92fb6baaebc4 Author: bpb Date: 2013-11-04 08:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92fb6baaebc4 8027625: test/java/math/BigInteger/ExtremeShiftingTests.java needs @run tag to specify heap size Summary: Add @run tag to specify heap size Reviewed-by: alanb, dxu ! test/java/math/BigInteger/ExtremeShiftingTests.java Changeset: 48449b5390fa Author: michaelm Date: 2013-11-04 17:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/48449b5390fa 8027687: The constructors of URLPermission class do not behave as described in javad Reviewed-by: chegar, mduigou ! src/share/classes/java/net/HostPortrange.java ! src/share/classes/java/net/URLPermission.java ! test/java/net/URLPermission/URLPermissionTest.java Changeset: 51b002381b35 Author: rfield Date: 2013-11-04 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/51b002381b35 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class 8027681: Lambda serialization fails once reflection proxy generation kicks in Reviewed-by: ksrini, briangoetz, jfranck Contributed-by: joel.franck at oracle.com, brian.goetz at oracle.com, robert.field at oracle.com ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/NativeMethodAccessorImpl.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java + test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java + test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java Changeset: 78a0dcde6b67 Author: alundblad Date: 2013-11-04 15:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78a0dcde6b67 8016725: TEST_BUG: java/lang/reflect/Method/DefaultMethodModeling.java failing intermittently Summary: Moved DefaultMethodModeling.java to its own directory to avoid conflicts with Equals.java. Reviewed-by: darcy - test/java/lang/reflect/Method/DefaultMethodModeling.java + test/java/lang/reflect/Method/defaultMethodModeling/DefaultMethodModeling.java Changeset: 6d1f3ba68db2 Author: dxu Date: 2013-11-04 15:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d1f3ba68db2 8027612: java/io/File/MaxPathLength.java fails intermittently in the clean-up stage Reviewed-by: chegar ! test/java/io/File/MaxPathLength.java Changeset: d5b3f83ffc40 Author: psandoz Date: 2013-11-05 12:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d5b3f83ffc40 8027712: DistinctOpTest fails for unordered test Reviewed-by: henryjen, alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java Changeset: a8a044db575c Author: joehw Date: 2013-11-05 11:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8a044db575c 8027860: [TEST_BUG] File not closed in javax/xml/jaxp/parsers/8022548/XOMParserTest.java Reviewed-by: alanb ! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java Changeset: 85fd2ae0a845 Author: mchung Date: 2013-11-05 17:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/85fd2ae0a845 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java 6944188: ThreadMXBean/ThreadStateTest.java fails intermittently Reviewed-by: dholmes, chegar + test/java/lang/Thread/ThreadStateController.java ! test/java/lang/Thread/ThreadStateTest.java + test/java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java - test/java/lang/management/ThreadMXBean/ThreadStateTest.java Changeset: 9c30cbc316e9 Author: mduigou Date: 2013-11-05 19:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c30cbc316e9 8021309: replace test/Makefile jdk_* targets with jtreg groups 8015068: Use jtreg -exclude for handling problemList.txt exclusions Reviewed-by: jjg, smarks, chegar, alanb, dholmes ! .hgignore ! test/Makefile Changeset: 6ea1f9d8ec78 Author: dxu Date: 2013-11-06 13:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ea1f9d8ec78 8025698: (fs) Typo in exception thrown by encode() in UnixPath.java Reviewed-by: dxu, mduigou, henryjen, weijun Contributed-by: ajuckel at gmail.com ! src/solaris/classes/sun/nio/fs/UnixPath.java Changeset: 81cbdd5876e8 Author: ksrini Date: 2013-11-06 11:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/81cbdd5876e8 8027227: [asm] generate CONSTANT_InterfaceMethodref for invoke{special/static) of non-abstract methods on ifaces Reviewed-by: ksrini, lagergren Contributed-by: ebruneton at free.fr, forax at univ-mlv.fr, john.r.rose at oracle.com, paul.sandoz at oracle.com ! 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/ClassWriter.java ! src/share/classes/jdk/internal/org/objectweb/asm/Handle.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/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/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/StaticInitMerger.java ! src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.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/FieldNode.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/TypeAnnotationNode.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.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/Printer.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java ! src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java ! src/share/classes/jdk/internal/org/objectweb/asm/version.txt Changeset: dbda97d6aa3a Author: ksrini Date: 2013-11-06 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dbda97d6aa3a 8027232: Update j.l.invoke code generating class files to use ASM enhancements for invocation of non-abstract methods on ifaces Reviewed-by: ksrini, rfield Contributed-by: john.r.rose at oracle.com, paul.sandoz at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaAsm.java Changeset: f37d62e295c0 Author: chegar Date: 2013-11-07 08:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f37d62e295c0 8027822: ProblemList.txt Updates (11/2013) Reviewed-by: chegar, alanb Contributed-by: Amy Lu ! test/ProblemList.txt Changeset: 82b276590b85 Author: chegar Date: 2013-11-07 08:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/82b276590b85 8027961: Inet[4|6]Address native initializing code should check field/MethodID values Reviewed-by: michaelm, rriggs ! src/share/native/java/net/Inet4Address.c ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/InetAddress.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: 88d1ed05a246 Author: michaelm Date: 2013-11-07 10:22 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/88d1ed05a246 8027881: test/java/net/URLPermission/nstest/LookupTest.java failing intermittently, output insufficient Reviewed-by: chegar ! test/java/net/URLPermission/URLPermissionTest.java ! test/java/net/URLPermission/nstest/LookupTest.java + test/java/net/URLPermission/nstest/lookup.sh - test/java/net/URLPermission/nstest/policy Changeset: 44fa6bf42846 Author: jfranck Date: 2013-11-07 13:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44fa6bf42846 8027796: Refactor Core Reflection for Type Annotations Reviewed-by: psandoz ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/TypeAnnotation.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java Changeset: fb7abd509bd2 Author: naoto Date: 2013-11-07 10:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fb7abd509bd2 8027930: ResourceBundle test failures in fr locale Reviewed-by: smarks ! test/java/util/ResourceBundle/ResourceBundleTest.java ! test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java Changeset: 04f071a95c29 Author: rriggs Date: 2013-11-07 20:56 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04f071a95c29 8024458: DataInput.readDouble refers to "readlong" instead of "readLong" Summary: fix the typo Reviewed-by: lancea, chegar, dxu ! src/share/classes/java/io/DataInput.java Changeset: e10a182c973a Author: yhuang Date: 2013-11-07 22:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e10a182c973a 8027695: There should be a space before % sign in Swedish locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: b5748857ef42 Author: jbachorik Date: 2013-11-08 08:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b5748857ef42 8007984: Null pointer dereference in jdk/linux-amd64/democlasses/demo/jvmti/heapTracker/src/java_crw_demo.c Reviewed-by: dholmes ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c Changeset: 8a4405fb40ba Author: ykantser Date: 2013-11-07 16:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8a4405fb40ba 8027752: sun/tools/jstatd/TestJstatdExternalRegistry.java: java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object Reviewed-by: sla, jbachorik ! test/sun/tools/jstatd/JstatdTest.java Changeset: 41d7ce111bd8 Author: mchung Date: 2013-11-08 07:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/41d7ce111bd8 8027351: (ref) Private finalize method invoked in preference to protected superclass method Reviewed-by: alanb, dholmes, mr, plevart, psandoz ! makefiles/lib/CoreLibraries.gmk ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjava/reorder-sparc ! makefiles/mapfiles/libjava/reorder-sparcv9 ! makefiles/mapfiles/libjava/reorder-x86 ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ref/Finalizer.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/VM.java + test/java/lang/ref/FinalizeOverride.java Changeset: 3112729d6b74 Author: tyan Date: 2013-11-08 15:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3112729d6b74 8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface Reviewed-by: chegar ! test/java/net/MulticastSocket/TestInterfaces.java ! test/java/net/NetworkInterface/Equals.java Changeset: 771c77b49bb6 Author: chegar Date: 2013-11-08 15:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/771c77b49bb6 8019834: InetAddress.getByName hangs for bad IPv6 literals Reviewed-by: alanb ! src/share/classes/java/net/InetAddress.java ! test/java/net/ipv6tests/BadIPv6Addresses.java Changeset: 1c9ba18198d5 Author: mchung Date: 2013-11-08 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c9ba18198d5 8028069: (ref) Finalizer.c not deleted in the changeset for JDK-8027351 Reviewed-by: alanb - src/share/native/java/lang/ref/Finalizer.c Changeset: 46982ca895b4 Author: tyan Date: 2013-11-08 18:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/46982ca895b4 8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/B6433018.java Changeset: 40ca9e4866de Author: mchung Date: 2013-11-08 12:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40ca9e4866de 8025985: com.sun.management.OSMBeanFactory should not be public Reviewed-by: alanb, erikj, ihse, jbachorik ! makefiles/lib/ServiceabilityLibraries.gmk ! makefiles/mapfiles/libmanagement/mapfile-vers + src/share/classes/sun/management/BaseOperatingSystemImpl.java ! src/share/classes/sun/management/ManagementFactoryHelper.java - src/share/classes/sun/management/OperatingSystemImpl.java - src/solaris/classes/com/sun/management/OSMBeanFactory.java - src/solaris/classes/com/sun/management/UnixOperatingSystem.java + src/solaris/classes/sun/management/OperatingSystemImpl.java - src/solaris/native/com/sun/management/LinuxOperatingSystem.c - src/solaris/native/com/sun/management/MacosxOperatingSystem.c - src/solaris/native/com/sun/management/SolarisOperatingSystem.c - src/solaris/native/com/sun/management/UnixOperatingSystem_md.c + src/solaris/native/sun/management/LinuxOperatingSystem.c + src/solaris/native/sun/management/MacosxOperatingSystem.c + src/solaris/native/sun/management/OperatingSystemImpl.c + src/solaris/native/sun/management/SolarisOperatingSystem.c - src/windows/classes/com/sun/management/OSMBeanFactory.java - src/windows/classes/com/sun/management/OperatingSystem.java + src/windows/classes/sun/management/OperatingSystemImpl.java - src/windows/native/com/sun/management/OperatingSystem_md.c + src/windows/native/sun/management/OperatingSystemImpl.c Changeset: 11376ad23e21 Author: darcy Date: 2013-11-08 12:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11376ad23e21 8028076: Correct raw type lint warnings in core reflection implementation classes Reviewed-by: lancea, alanb ! src/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java Changeset: 50df04934e86 Author: alanb Date: 2013-11-08 21:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/50df04934e86 8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f Reviewed-by: chegar ! src/share/classes/java/net/InetAddress.java Changeset: df2f7f288353 Author: rriggs Date: 2013-11-08 17:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/df2f7f288353 8028041: Serialized Form description of j.l.String is not consistent with the implementation Summary: Replaced incorrect description with reference to the serialization specification Reviewed-by: alanb, smarks ! src/share/classes/java/lang/String.java Changeset: a579e2f73bca Author: lana Date: 2013-11-08 17:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a579e2f73bca Merge ! src/share/classes/java/lang/invoke/MethodType.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! test/java/lang/Thread/ThreadStateTest.java Changeset: 9130770fb6e3 Author: alanb Date: 2013-11-09 16:46 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9130770fb6e3 8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS Reviewed-by: dholmes, alanb Contributed-by: patrick.zhang at oracle.com ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/java/util/Calendar/NarrowNamesTest.sh Changeset: 3add16c86970 Author: rriggs Date: 2013-11-09 14:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3add16c86970 8028092: Lint cleanup of java.time.format Summary: correct declarations and add @SuppressWarnings Reviewed-by: darcy, lancea ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/Parsed.java Changeset: 0c75cc07d264 Author: jbachorik Date: 2013-11-10 20:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c75cc07d264 6523160: RuntimeMXBean.getUptime() returns negative values Summary: RuntimeMXBean.getUptime() should be based on HR timers rather than on the OS time Reviewed-by: dholmes, sla ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/VMManagementImpl.c ! test/java/lang/management/RuntimeMXBean/UpTime.java Changeset: 2525b91ca5a6 Author: alanb Date: 2013-11-11 08:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2525b91ca5a6 8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win) Reviewed-by: mchung ! src/windows/classes/sun/management/OperatingSystemImpl.java Changeset: 7304b3195212 Author: weijun Date: 2013-11-11 16:54 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7304b3195212 8027991: InputStream should be closed in sun.security.tools.jarsigner.Main Reviewed-by: xuelei ! src/share/classes/sun/security/tools/jarsigner/Main.java + test/sun/security/tools/jarsigner/CertChainUnclosed.java Changeset: b48eded97dff Author: chegar Date: 2013-11-11 10:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b48eded97dff 8028102: All test targets, jdk/test/Makefile, fail on Windows Reviewed-by: mduigou ! test/Makefile Changeset: 0e47462f03a0 Author: michaelm Date: 2013-11-11 16:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e47462f03a0 8028060: test/java/net/URLPermission/nstest/lookup.sh failing (win) Reviewed-by: alanb ! test/java/net/URLPermission/nstest/LookupTest.java ! test/java/net/URLPermission/nstest/lookup.sh Changeset: 59ff7957c26f Author: lancea Date: 2013-11-11 14:22 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/59ff7957c26f 8028149: Clean-up javac -Xlint warnings in com.sun.rowset and com.sun.rowset.internal Reviewed-by: darcy ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java Changeset: 0cacac7f5c37 Author: sla Date: 2013-11-08 18:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0cacac7f5c37 8014506: Test of Jdp feature Reviewed-by: sla Contributed-by: Alex Schenkman + test/sun/management/jdp/ClientConnection.java + test/sun/management/jdp/DynamicLauncher.java ! test/sun/management/jdp/JdpClient.java + test/sun/management/jdp/JdpDefaultsTest.java ! test/sun/management/jdp/JdpDoSomething.java + test/sun/management/jdp/JdpOffTest.java + test/sun/management/jdp/JdpOffTestCase.java + test/sun/management/jdp/JdpOnTestCase.java + test/sun/management/jdp/JdpSpecificAddressTest.java ! test/sun/management/jdp/JdpTest.sh + test/sun/management/jdp/JdpTestCase.java + test/sun/management/jdp/JdpTestUtil.java + test/sun/management/jdp/JdpTestUtilTest.java ! test/sun/management/jdp/JdpUnitTest.java + test/sun/management/jdp/PacketTest.java + test/sun/management/jdp/PortAlreadyInUseTest.java + test/sun/management/jdp/README Changeset: 8e8e423fa3dc Author: sherman Date: 2013-11-11 14:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e8e423fa3dc 8026330: java.util.Base64 urlEncoder should omit padding Summary: to add Encoder.withoutPadding() Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: c04e46dbfea8 Author: rfield Date: 2013-11-11 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c04e46dbfea8 8027803: test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java fails Summary: fix NPE in test infrastructure Reviewed-by: ksrini, jfranck, alanb, rfield Contributed-by: alan.bateman at oracle.com ! test/lib/testlibrary/ClassFileInstaller.java Changeset: 9fcb07df1c92 Author: vlivanov Date: 2013-11-09 04:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9fcb07df1c92 8027823: catchException combinator fails with 9 argument target Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + test/java/lang/invoke/MethodHandles/TestCatchException.java Changeset: 41dcb0c2e194 Author: egahlin Date: 2013-11-12 14:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/41dcb0c2e194 8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently Reviewed-by: sla, jbachorik ! test/javax/management/monitor/ThreadPoolAccTest.java Changeset: f6012ca3bdd3 Author: smarks Date: 2013-11-12 16:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f6012ca3bdd3 8028027: serialver should emit declaration with the 'private' modifier Reviewed-by: darcy, mchung, alanb, chegar ! src/share/classes/sun/tools/serialver/SerialVer.java Changeset: 4cff9f59644f Author: egahlin Date: 2013-11-12 17:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4cff9f59644f 6543856: MonitorVmStartTerminate.sh fails intermittently Reviewed-by: sla, dholmes ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/jvmstat/testlibrary/JavaProcess.java Changeset: d9f827e4d20c Author: egahlin Date: 2013-11-12 18:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d9f827e4d20c 6849945: VM Periodic Task Thread CPU time = -1ns in HotspotThreadMBean.getInternalThreadCpuTimes() Reviewed-by: sla ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java Changeset: 0c414ac10700 Author: alanb Date: 2013-11-12 17:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c414ac10700 8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win) Reviewed-by: chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! test/ProblemList.txt Changeset: 69432cb5bca2 Author: darcy Date: 2013-11-12 09:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69432cb5bca2 8028229: Fix more raw types lint warning in core libraries Reviewed-by: chegar, forax, lancea, alanb, jfranck ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/sun/misc/Cleaner.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java Changeset: ebe27e1a2e2d Author: rriggs Date: 2013-11-12 14:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ebe27e1a2e2d 8028014: Doclint warning/error cleanup in javax.management Summary: Improve generated html by fixing doclint warnings Reviewed-by: sla, jbachorik ! src/share/classes/javax/management/AttributeList.java ! src/share/classes/javax/management/BooleanValueExp.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/DescriptorKey.java ! src/share/classes/javax/management/ImmutableDescriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/MBeanServerNotification.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/NumericValueExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/PersistentMBean.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetParser.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationBroadcaster.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/relation/Relation.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationServiceMBean.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/remote/JMXConnectionNotification.java ! src/share/classes/javax/management/remote/JMXConnector.java ! src/share/classes/javax/management/remote/JMXConnectorProvider.java ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java Changeset: c4c84b5a3dfa Author: alanb Date: 2013-11-13 07:43 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c4c84b5a3dfa 8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError Reviewed-by: mchung, egahlin ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh Changeset: 1158d504e39e Author: xuelei Date: 2013-11-13 01:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1158d504e39e 8023147: Test DisabledShortRSAKeys.java intermittent failed Reviewed-by: mullan ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java Changeset: 30a3aefc4084 Author: dfuchs Date: 2013-11-13 10:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/30a3aefc4084 8026952: Test java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has wrong @bug id Summary: Trivial: change @bug 8023163 into @bug 8026499 Reviewed-by: mchung, alanb ! test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java Changeset: 680ef14a2cc0 Author: jbachorik Date: 2013-11-13 13:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/680ef14a2cc0 8004126: TEST_BUG: com/sun/jdi/BadHandshakeTest.java fails intermittently Reviewed-by: dholmes, ykantser ! test/com/sun/jdi/BadHandshakeTest.java Changeset: ddaa9a8acaed Author: egahlin Date: 2013-11-13 15:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ddaa9a8acaed 6959636: testcase failing on windows javax/management/loading/LibraryLoader/LibraryLoaderTest.java Reviewed-by: sla, jbachorik ! test/ProblemList.txt ! test/javax/management/loading/LibraryLoader/LibraryLoaderTest.java Changeset: a42a416351b8 Author: ykantser Date: 2013-11-13 11:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a42a416351b8 8015497: Take new fixes from hotspot/test/testlibrary to jdk/test/lib/testlibrary Reviewed-by: sla + test/lib/testlibrary/AssertsTest.java + test/lib/testlibrary/OutputAnalyzerReportingTest.java + test/lib/testlibrary/jdk/testlibrary/InputArguments.java ! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java - test/lib/testlibrary/jdk/testlibrary/JdkFinder.java ! test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java Changeset: 7c55fecfae65 Author: mchung Date: 2013-11-13 07:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7c55fecfae65 8028234: Remove unused methods in sun.misc.JavaAWTAccess Reviewed-by: art, dfuchs, lancea ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! test/java/util/logging/TestAppletLoggerContext.java Changeset: 70f1bed5e7fd Author: chegar Date: 2013-11-13 16:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70f1bed5e7fd 8022213: Intermittent test failures in java/net/URLClassLoader Reviewed-by: dxu, alanb ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/closetest/Common.java ! test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/lib/testlibrary/jdk/testlibrary/FileUtils.java Changeset: a493871959c2 Author: alanb Date: 2013-11-13 16:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a493871959c2 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission Reviewed-by: mchung, martin, chegar ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! test/java/nio/file/Files/CheckPermissions.java Changeset: 256b3395346b Author: egahlin Date: 2013-11-13 18:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/256b3395346b 6954510: TEST_BUG: Testcase failure com/sun/jdi/BreakpointWithFullGC.sh Reviewed-by: sla, sspitsyn ! test/com/sun/jdi/BreakpointWithFullGC.sh Changeset: e6333788b117 Author: darcy Date: 2013-11-13 11:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6333788b117 8028300: Fix raw type lint warnings in java.util.concurrent Reviewed-by: chegar, martin ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java Changeset: 9e37caf07ce0 Author: sherman Date: 2013-11-13 11:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9e37caf07ce0 8027645: Pattern.split() with positive lookahead 6559590: Pattern.compile(".*").split("") returns incorrect result Summary: updated spec/impl for these two corner cases Reviewed-by: alanb, psandoz ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/regex/Pattern.java ! test/java/lang/String/Split.java ! test/java/util/regex/RegExTest.java Changeset: ea91826bc2e9 Author: emc Date: 2013-11-13 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea91826bc2e9 8026884: test for fix of JDK-8021398 does not have @bug tag 8028021: @since 1.8 missing for certain methods in java.lang.reflect.Method in generated api docs Summary: two documentation fixes Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java Changeset: 1d790a56de4e Author: sherman Date: 2013-11-13 22:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d790a56de4e 8028321: Fix for String.split() empty input sequence/JDK-6559590 triggers regression Summary: to undo the change for 6559590 Reviewed-by: darcy ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/regex/Pattern.java ! test/java/lang/String/Split.java ! test/java/util/regex/RegExTest.java Changeset: ecf85f4aecf0 Author: alanb Date: 2013-11-14 10:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ecf85f4aecf0 8028343: More ProblemList.txt updates (11/2013) Reviewed-by: chegar ! test/ProblemList.txt Changeset: 83c768d6cb93 Author: jfranck Date: 2013-11-14 12:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/83c768d6cb93 8028055: (reflect) invoking Method/Constructor in anonymous classes breaks with -Dsun.reflect.noInflation=true Reviewed-by: briangoetz ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! test/java/lang/invoke/lambda/RepetitiveLambdaSerialization.java ! test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java Changeset: 65f7b83ab477 Author: sla Date: 2013-11-14 19:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/65f7b83ab477 8027765: Make exit codes and stdout/stderr printing from jmap/jinfo/jstack/jps consistent Reviewed-by: alanb, allwin, sspitsyn, mgronlun ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java Changeset: 59f46f135584 Author: hseigel Date: 2013-11-14 10:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/59f46f135584 8023041: The CDS classlist needs to be updated for JDK 8 Summary: Generate new classlists from JDK 8 classes Reviewed-by: alanb, coleenp, hseigel Contributed-by: ekaterina.pavlova at oracle.com ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.macosx ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows Changeset: f893901ba29c Author: coleenp Date: 2013-11-14 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f893901ba29c Merge Changeset: 40d0ccd00f87 Author: xuelei Date: 2013-11-14 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40d0ccd00f87 8014266: regression test AsyncSSLSocketClose.java time out. Reviewed-by: xuelei Contributed-by: Rajan Halade ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java Changeset: fc4ac66aa657 Author: lana Date: 2013-11-15 07:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fc4ac66aa657 Merge ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/sun/awt/AppContext.java - src/share/classes/sun/management/OperatingSystemImpl.java - src/share/native/java/lang/ref/Finalizer.c - src/solaris/classes/com/sun/management/OSMBeanFactory.java - src/solaris/classes/com/sun/management/UnixOperatingSystem.java - src/solaris/native/com/sun/management/LinuxOperatingSystem.c - src/solaris/native/com/sun/management/MacosxOperatingSystem.c - src/solaris/native/com/sun/management/SolarisOperatingSystem.c - src/solaris/native/com/sun/management/UnixOperatingSystem_md.c - src/windows/classes/com/sun/management/OSMBeanFactory.java - src/windows/classes/com/sun/management/OperatingSystem.java - src/windows/native/com/sun/management/OperatingSystem_md.c ! test/ProblemList.txt - test/java/lang/management/ThreadMXBean/ThreadStateTest.java - test/java/lang/reflect/Method/DefaultMethodModeling.java - test/java/net/URLPermission/nstest/policy ! test/java/util/regex/RegExTest.java - test/lib/testlibrary/jdk/testlibrary/JdkFinder.java Changeset: 8bc258c021a3 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8bc258c021a3 Added tag jdk8-b117 for changeset fc4ac66aa657 ! .hgtags From john.coomes at oracle.com Thu Nov 21 10:57:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:57:04 +0000 Subject: hg: hsx/hotspot-main/langtools: 18 new changesets Message-ID: <20131121185802.6CE7162757@hg.openjdk.java.net> Changeset: cc80c03c41e4 Author: vromero Date: 2013-11-01 19:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cc80c03c41e4 8027660: javac crash while creating LVT entry for a local variable defined in an inner block Reviewed-by: jjg Contributed-by: vicente.romero at oracle.com, jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! test/tools/javac/flow/LVTHarness.java + test/tools/javac/flow/tests/TestCaseLocalInInnerBlock.java Changeset: 8b4e1421a9b7 Author: jlahoda Date: 2013-11-01 21:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8b4e1421a9b7 8027310: Annotation Processor crashes with NPE Summary: JCAnnotation.attribute is null when annotation type is unavailable Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/processing/errors/CrashOnNonExistingAnnotation/Processor.java + test/tools/javac/processing/errors/CrashOnNonExistingAnnotation/Source.java Changeset: 106b8fa32d71 Author: cl Date: 2013-11-04 17:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/106b8fa32d71 8025844: Need test to provide coverage for new DocumentationTool.Location enum Reviewed-by: jjg + test/tools/javadoc/api/basic/DocumentationToolLocationTest.java Changeset: 658861d1b36e Author: cl Date: 2013-11-04 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/658861d1b36e 8027411: javap tonga tests cleanup: write a java program to test invalid options -h and -b Reviewed-by: jjg + test/tools/javap/InvalidOptions.java Changeset: 126dc007ba3f Author: cl Date: 2013-11-04 18:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/126dc007ba3f 8027530: javap tonga tests cleanup: test -public, -protected, -package, -private options Reviewed-by: jjg + test/tools/javap/AccessModifiers.java Changeset: 75c8cde12ab6 Author: jlahoda Date: 2013-11-06 17:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/75c8cde12ab6 8027281: Incorrect invokespecial generated for JCK lang EXPR/expr636/expr63602m* tests Summary: When invoking interface default method via a superclass, use the direct superclass in the reference. Reviewed-by: vromero, dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/defaultMethods/super/TestDirectSuperInterfaceInvoke.java Changeset: e39bd9401ea5 Author: darcy Date: 2013-11-07 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e39bd9401ea5 8027730: Fix release-8 type visitors to support intersection types Reviewed-by: jjg, jlahoda, sogoel ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java + test/tools/javac/processing/model/util/TestIntersectionTypeVisitors.java Changeset: 21294feaf311 Author: lana Date: 2013-11-08 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/21294feaf311 Merge Changeset: 6e0f31d61e56 Author: jlahoda Date: 2013-11-09 15:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6e0f31d61e56 8027142: Invokedynamic instructions don't get line number table entries Summary: When emitting invokedynamic instruction, write pendingStatPos, if set, into the LineNumberTable. Invokedynamic itself does not set the pendingStatPos. Reviewed-by: jjg, jrose, ksrini, vromero ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! test/tools/javac/T8019486/WrongLNTForLambdaTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: 4788eb38cac5 Author: emc Date: 2013-11-11 09:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4788eb38cac5 8027439: Compile-time error in the case of ((Integer[] & Serializable)new Integer[1]).getClass() 8027253: javac illegally accepts array as bound Summary: backing out change allowing arrays in intersection types Reviewed-by: vromero ! 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/resources/compiler.properties - test/tools/javac/ArraysInIntersections.java - test/tools/javac/InferArraysInIntersections.java - test/tools/javac/diags/examples/InterfaceOrArrayExpected.java ! test/tools/javac/generics/typevars/6680106/T6680106.out Changeset: f3ca12d680f3 Author: jfranck Date: 2013-11-11 17:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f3ca12d680f3 8027375: javac asserts on nested erroneous annotations Summary: make sure JCAnnotation trees have type != null before annotation processing Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/testCrashNestedAnnos/TestCrashNestedAnnos.java + test/tools/javac/annotations/testCrashNestedAnnos/TestCrashNestedAnnos.out Changeset: f90d88913c5f Author: sogoel Date: 2013-11-13 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f90d88913c5f 8025113: Convert 7 tools TryWithResources tests to jtreg format Reviewed-by: darcy, jjg + test/tools/javac/TryWithResources/ResDeclOutsideTry.java + test/tools/javac/TryWithResources/ResDeclOutsideTry.out + test/tools/javac/TryWithResources/ResInNestedExpr.java + test/tools/javac/TryWithResources/ResourceNameConflict.java + test/tools/javac/TryWithResources/ResourceNameConflict.out + test/tools/javac/TryWithResources/ResourceRedecl.java + test/tools/javac/TryWithResources/ResourceRedecl.out + test/tools/javac/TryWithResources/ResourceShadow.java + test/tools/javac/TryWithResources/TestTwr09.java Changeset: 24eaf41a3974 Author: emc Date: 2013-11-14 12:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/24eaf41a3974 8028282: Remove @ignore from test langtools/test/tools/javac/T7042623.java Summary: Remove @ignore from test Reviewed-by: jjg ! test/tools/javac/T7042623.java Changeset: e79d6425f1c4 Author: vromero Date: 2013-11-14 19:28 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e79d6425f1c4 8026963: type annotations code crashes for code with erroneous trees Reviewed-by: jjg, jlahoda ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.java + test/tools/javac/T8026963/TypeAnnotationsCrashWithErroneousTreeTest.out Changeset: 5ae66d372d57 Author: bpatel Date: 2013-11-14 13:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5ae66d372d57 8025524: javadoc does not correctly locate constructors for nested classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java + test/com/sun/javadoc/testConstructors/TestConstructors.java + test/com/sun/javadoc/testConstructors/pkg1/Outer.java ! test/tools/javadoc/generics/genericInnerAndOuter/expected.out Changeset: d4cbb671de1c Author: vromero Date: 2013-11-15 11:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d4cbb671de1c 8026231: Look at 'static' flag when checking method references Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Kinds.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/Resolve.java ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference51.java ! test/tools/javac/lambda/MethodReference68.out + test/tools/javac/lambda/MethodReference73.java + test/tools/javac/lambda/MethodReference73.out ! test/tools/javac/lambda/TargetType60.java ! test/tools/javac/lambda/TargetType60.out Changeset: 19de039a03a6 Author: lana Date: 2013-11-15 07:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/19de039a03a6 Merge - test/tools/javac/ArraysInIntersections.java - test/tools/javac/InferArraysInIntersections.java - test/tools/javac/diags/examples/InterfaceOrArrayExpected.java Changeset: 4fd6a7ff8c06 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4fd6a7ff8c06 Added tag jdk8-b117 for changeset 19de039a03a6 ! .hgtags From john.coomes at oracle.com Thu Nov 21 10:58:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 21 Nov 2013 18:58:14 +0000 Subject: hg: hsx/hotspot-main/nashorn: 13 new changesets Message-ID: <20131121185828.76EC462758@hg.openjdk.java.net> Changeset: ae5f2130c3b9 Author: sundar Date: 2013-11-01 19:54 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ae5f2130c3b9 8027700: function redeclaration checks missing for declaration binding instantiation Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/script/basic/JDK-8015355.js + test/script/basic/JDK-8027700.js Changeset: 98bab0cdd7bf Author: attila Date: 2013-11-01 15:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/98bab0cdd7bf 8027236: Ensure ScriptObject and ConsString aren't visible to Java Reviewed-by: lagergren, sundar ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java + test/script/basic/JDK-8027236.js + test/script/basic/JDK-8027236.js.EXPECTED + test/src/jdk/nashorn/api/javaaccess/ConsStringTest.java Changeset: 144861e24260 Author: sundar Date: 2013-11-04 09:29 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/144861e24260 Merge Changeset: dcedc753fd09 Author: sundar Date: 2013-11-04 18:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/dcedc753fd09 8027753: Support ScriptObject to JSObject, ScriptObjectMirror, Map, Bindings auto-conversion as well as explicit wrap, unwrap Reviewed-by: jlaskey, hannesw, attila ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java + test/script/basic/JDK-8027753.js + test/script/basic/JDK-8027753.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java Changeset: b0d4ef6fb2db Author: sundar Date: 2013-11-05 09:13 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b0d4ef6fb2db Merge Changeset: bda654c6d59c Author: kshefov Date: 2013-11-05 13:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bda654c6d59c 8027708: NASHORN TEST: Create Nashorn test that draws image step-by-step using JavaFX canvas. Reviewed-by: jlaskey, lagergren ! make/build.xml ! make/project.properties ! test/script/jfx.js ! test/script/jfx/flyingimage.js ! test/script/jfx/flyingimage/flyingimage.png ! test/script/jfx/flyingimage/golden/linux.png ! test/script/jfx/flyingimage/golden/macosx.png ! test/script/jfx/flyingimage/golden/windows.png ! test/script/jfx/kaleidoscope.js ! test/script/jfx/kaleidoscope/golden/linux.png ! test/script/jfx/kaleidoscope/golden/macosx.png ! test/script/jfx/kaleidoscope/golden/windows.png + test/script/jfx/spread.js + test/script/jfx/spread/golden/linux.png + test/script/jfx/spread/golden/macosx.png + test/script/jfx/spread/golden/windows.png Changeset: 2f07b4234451 Author: sundar Date: 2013-11-07 17:26 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2f07b4234451 8027828: ClassCastException when converting return value of a Java method to boolean Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/JDK-8027828.js + test/script/basic/JDK-8027828.js.EXPECTED + test/script/basic/convert.js + test/script/basic/convert.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 3b794f364c77 Author: sundar Date: 2013-11-07 18:11 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3b794f364c77 Merge Changeset: d091499d67fc Author: lana Date: 2013-11-08 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d091499d67fc Merge Changeset: e65a98146b94 Author: attila Date: 2013-11-11 14:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e65a98146b94 8028020: Function parameter as last expression in comma in return value causes bad type calculation Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8028020.js + test/script/basic/JDK-8028020.js.EXPECTED Changeset: 2f0f8d1d0753 Author: sundar Date: 2013-11-12 10:23 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2f0f8d1d0753 Merge Changeset: 1db3d4e4d189 Author: lana Date: 2013-11-15 07:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1db3d4e4d189 Merge Changeset: 8d014b039b44 Author: cl Date: 2013-11-21 09:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8d014b039b44 Added tag jdk8-b117 for changeset 1db3d4e4d189 ! .hgtags From coleen.phillimore at oracle.com Thu Nov 21 11:11:22 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Nov 2013 14:11:22 -0500 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <528E382B.2030001@oracle.com> References: <528E382B.2030001@oracle.com> Message-ID: <528E5ADA.3030700@oracle.com> Stefan, I think the function MarkSweep::adjust_class_loader() is now unused, but I couldn't find where we adjust the class in the CLD walk. There are similar functions in ParallelScavenge - are they also not needed? I don't recommend adding this change, just noting it may be cleaned up later if so. This change seems good but I'm not a GC person. thanks, Coleen On 11/21/2013 11:43 AM, Stefan Johansson wrote: > Hi all, > > Can I have a couple reviews for this fix for: > https://bugs.openjdk.java.net/browse/JDK-8027675 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ > > Summary: > When doing permgen removal we had to change the way classes were > marked and handled in the GC. When doing this we ended up doing some > things a little less efficient than before. The regression is easy to > reproduce and when doing a JFR recording we can see that we now spend > more time in both the mark and adjust phase. > > To improve the mark phase: > * Enabled the calls to follow_klass to be inlined. > * Reduce the extensive amount of calls to follow_class_loader in > follow_klass and instead just mark the klass holder (the class loader > or the java mirror) for the given klass. > > To improve the adjust phase: > * All calls to adjust_klass have been removed since this is already > handled by processing the ClassLoaderDataGraph. > > Testing: > * Manually ran SPECjbb2005 to verify fixing the regression > * JPRT for functional sanity testing > * Nashorn tests to stress anonymous classes > > Thanks, > StefanJ From vladimir.kozlov at oracle.com Thu Nov 21 11:48:27 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Nov 2013 11:48:27 -0800 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE67BF0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> <528D15A1.9080400@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> <528D5C0A.2020001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67BF0@DEWDFEMB12A.global.corp.sap> Message-ID: <528E638B.4020803@oracle.com> On 11/21/13 12:30 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> Without (UseCompressedOops && Universe::narrow_oop_base() > 0) check >> Universe::narrow_oop_use_implicit_null_checks() is useless because it is >> 'true' by default. That is why I asked to move check inside to combine >> them in one place. > Yes, it is useless, but it will not be evaluated. And I need it if narrow_oop_base() > is set. > But is it really true by default? See arguments.cpp: It is initialized by 'true': NarrowPtrStruct Universe::_narrow_oop = { NULL, 0, true }; except special case for Win64: > #ifdef _WIN64 > if (UseLargePages && UseCompressedOops) { > // Cannot allocate guard pages for implicit checks in indexed addressing > // mode, when large pages are specified on windows. > // This flag could be switched ON if narrow oop base address is set to 0, > // see code in Universe::initialize_heap(). > Universe::set_narrow_oop_use_implicit_null_checks(false); > } > #endif // _WIN64 which can be reset back to 'true' if 0 page is used for traps: Universe::set_narrow_oop_base(NULL); // Don't need guard page for implicit checks in indexed // addressing mode with zero based Compressed Oops. Universe::set_narrow_oop_use_implicit_null_checks(true); > >> You can use Matcher::gen_narrow_oop_implicit_null_checks() check >> instead. > No, that returns true if narrow_oop_use_complex_address() is set. But you said narrow_oop_use_complex_address() is false on AIX: "> but ppc has no loads that support this." Did I get it wrong? If it could be true then yes, we can't use it. > I must know whether the page before the heapbased heap is protected. > There should be Universe::heapbased_base_page_is_protected(), > that would be much more descriptive. > >> Note Universe::narrow_oop_base() != NULL only if >> UseCompressedOops is true. > Yes, you mean I should remove the test for UseCompressedOops? Yes. > >>> No ShouldNotReachHere for AIX. I tried to improve the comment >>> instead. >> So you want to return false if it is not DecodeN. Right? > No, if it's not DecodeN_NN: > > xn = loadn > xo = xn == 0 ? 0 : xn<<3+base // DecodeN > loadI (xo+offset) > will not trap, as it accesses the zero page. > > xn = loadn > xo = xn<<3+base // DecodeN_NN > loadI (xo+offset) > will trap, as it accesses the base page of the heapbased heap. > > If you match the decode into the memory operand of the second > Load, this check will not work, therefore I put the unimplemented() > there: > xn = loadn > loadI (xo<<3+base+offset) > but ppc has no loads that support this. > > There is no obvious, platform independent way to distinguish > DecodeN_NN and DecodeN. You may be misunderstood me (or I you :) ). This code is only executed for AIX: (!os::zero_page_read_protected()). So I am fine to have NOT_AIX(Unimplemented()) because our current platforms will not hit it. My question was about AIX. If Op_DecodeN and following NotNULL checks are false you return 'false' from accesses_heap_base_zone() and EXPLICIT check will be generated. My question was, is that what you want for AIX? Because you have next comment: "On AIX, no such memory operands exist, so we need not check for them." Which I read as AIX only have case with DecodeN so above checks should always succeed. That is why I am confused and asked if you need ShouldNotReachHere there. Thanks, Vladimir > > Thanks for this detailed review! > Best regards, > Goetz. > > > > Thanks, > Vladimir > >> >> Sorry for the wrong indents. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, November 20, 2013 9:04 PM >> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. >> >> Hi, Goetz >> >> Can you move all checks in lcm.cpp into new method and rename it to >> needs_explicit_null_check_for_read()? So the condition will be simple: >> >> if (!was_store && needs_explicit_null_check_for_read(val)) { >> continue; >> } >> >> You should also add ShouldNotReachHere() for AIX near Unimplemented() >> for non AIX. >> >> And, please, fix indents in new method. >> >> Thanks, >> Vladimir >> >> On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> ImplicitNullChecks did not work on platforms where the zero >>> page is only write protected. >>> >>> This change adds os property 'zero_page_read_protected' and extends >>> the ImplicitNullCheck optimization to consider only stores if >>> this property is not true. If a decoded compressed oop will access the >>> guard page before the heap, Loads work again. >>> This is needed on AIX, where the page at address '0' is only write-protected. >>> >>> Please review and test this change: >>> http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ >>> >>> I tagged this S, as a majority of the patches apply to the ppc platform files. >>> >>> Best regards, >>> Goetz. >>> From goetz.lindenmaier at sap.com Thu Nov 21 12:39:22 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Nov 2013 20:39:22 +0000 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <528E638B.4020803@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> <528D15A1.9080400@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> <528D5C0A.2020001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67BF0@DEWDFEMB12A.global.corp.sap> <528E638B.4020803@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE67EAF@DEWDFEMB12A.global.corp.sap> Hi Vladimir, ok, I see, narrow_oop_use_implicit_null_checks() is set as one would expect: at most true in heapbased mode. I removed the check for UseCompressedOops. In our VM, narrow_oop_use_implicit_null_checks() can be true in unscaled mode. I didn't contribute that as it requires too much shared changes. > My question was, is that what you want for AIX? Because you have next > comment: > "On AIX, no such memory operands exist, so we need not check for them." With 'need not', I mean that I must not implement it. On other platforms, a lot of opportunities for null checks could be lost, so I put the Unimplemented() there. I adapted the comment: // returns true everywhere else. On PPC, no such memory operands // exist, therefore we did not yet implement a check for such operands. I updated the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ Best regards, Goetz. -----Original Message----- From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Thursday, November 21, 2013 8:48 PM To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. On 11/21/13 12:30 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> Without (UseCompressedOops && Universe::narrow_oop_base() > 0) check >> Universe::narrow_oop_use_implicit_null_checks() is useless because it is >> 'true' by default. That is why I asked to move check inside to combine >> them in one place. > Yes, it is useless, but it will not be evaluated. And I need it if narrow_oop_base() > is set. > But is it really true by default? See arguments.cpp: It is initialized by 'true': NarrowPtrStruct Universe::_narrow_oop = { NULL, 0, true }; except special case for Win64: > #ifdef _WIN64 > if (UseLargePages && UseCompressedOops) { > // Cannot allocate guard pages for implicit checks in indexed addressing > // mode, when large pages are specified on windows. > // This flag could be switched ON if narrow oop base address is set to 0, > // see code in Universe::initialize_heap(). > Universe::set_narrow_oop_use_implicit_null_checks(false); > } > #endif // _WIN64 which can be reset back to 'true' if 0 page is used for traps: Universe::set_narrow_oop_base(NULL); // Don't need guard page for implicit checks in indexed // addressing mode with zero based Compressed Oops. Universe::set_narrow_oop_use_implicit_null_checks(true); > >> You can use Matcher::gen_narrow_oop_implicit_null_checks() check >> instead. > No, that returns true if narrow_oop_use_complex_address() is set. But you said narrow_oop_use_complex_address() is false on AIX: "> but ppc has no loads that support this." Did I get it wrong? If it could be true then yes, we can't use it. > I must know whether the page before the heapbased heap is protected. > There should be Universe::heapbased_base_page_is_protected(), > that would be much more descriptive. > >> Note Universe::narrow_oop_base() != NULL only if >> UseCompressedOops is true. > Yes, you mean I should remove the test for UseCompressedOops? Yes. > >>> No ShouldNotReachHere for AIX. I tried to improve the comment >>> instead. >> So you want to return false if it is not DecodeN. Right? > No, if it's not DecodeN_NN: > > xn = loadn > xo = xn == 0 ? 0 : xn<<3+base // DecodeN > loadI (xo+offset) > will not trap, as it accesses the zero page. > > xn = loadn > xo = xn<<3+base // DecodeN_NN > loadI (xo+offset) > will trap, as it accesses the base page of the heapbased heap. > > If you match the decode into the memory operand of the second > Load, this check will not work, therefore I put the unimplemented() > there: > xn = loadn > loadI (xo<<3+base+offset) > but ppc has no loads that support this. > > There is no obvious, platform independent way to distinguish > DecodeN_NN and DecodeN. You may be misunderstood me (or I you :) ). This code is only executed for AIX: (!os::zero_page_read_protected()). So I am fine to have NOT_AIX(Unimplemented()) because our current platforms will not hit it. My question was about AIX. If Op_DecodeN and following NotNULL checks are false you return 'false' from accesses_heap_base_zone() and EXPLICIT check will be generated. My question was, is that what you want for AIX? Because you have next comment: "On AIX, no such memory operands exist, so we need not check for them." Which I read as AIX only have case with DecodeN so above checks should always succeed. That is why I am confused and asked if you need ShouldNotReachHere there. Thanks, Vladimir > > Thanks for this detailed review! > Best regards, > Goetz. > > > > Thanks, > Vladimir > >> >> Sorry for the wrong indents. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, November 20, 2013 9:04 PM >> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. >> >> Hi, Goetz >> >> Can you move all checks in lcm.cpp into new method and rename it to >> needs_explicit_null_check_for_read()? So the condition will be simple: >> >> if (!was_store && needs_explicit_null_check_for_read(val)) { >> continue; >> } >> >> You should also add ShouldNotReachHere() for AIX near Unimplemented() >> for non AIX. >> >> And, please, fix indents in new method. >> >> Thanks, >> Vladimir >> >> On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> ImplicitNullChecks did not work on platforms where the zero >>> page is only write protected. >>> >>> This change adds os property 'zero_page_read_protected' and extends >>> the ImplicitNullCheck optimization to consider only stores if >>> this property is not true. If a decoded compressed oop will access the >>> guard page before the heap, Loads work again. >>> This is needed on AIX, where the page at address '0' is only write-protected. >>> >>> Please review and test this change: >>> http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ >>> >>> I tagged this S, as a majority of the patches apply to the ppc platform files. >>> >>> Best regards, >>> Goetz. >>> From vladimir.kozlov at oracle.com Thu Nov 21 12:45:02 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Nov 2013 12:45:02 -0800 Subject: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE67EAF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6722E@DEWDFEMB12A.global.corp.sap> <528D15A1.9080400@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67B61@DEWDFEMB12A.global.corp.sap> <528D5C0A.2020001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67BF0@DEWDFEMB12A.global.corp.sap> <528E638B.4020803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67EAF@DEWDFEMB12A.global.corp.sap> Message-ID: <528E70CE.5020804@oracle.com> Okay. I will push it after sync is done. Thanks, Vladimir On 11/21/13 12:39 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > ok, I see, narrow_oop_use_implicit_null_checks() is set as one would > expect: at most true in heapbased mode. > > I removed the check for UseCompressedOops. > > In our VM, narrow_oop_use_implicit_null_checks() can be true in unscaled > mode. I didn't contribute that as it requires too much shared changes. > >> My question was, is that what you want for AIX? Because you have next >> comment: >> "On AIX, no such memory operands exist, so we need not check for them." > With 'need not', I mean that I must not implement it. On other platforms, > a lot of opportunities for null checks could be lost, so I put the Unimplemented() > there. I adapted the comment: > // returns true everywhere else. On PPC, no such memory operands > // exist, therefore we did not yet implement a check for such operands. > > I updated the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ > > Best regards, > Goetz. > > -----Original Message----- > From: ppc-aix-port-dev-bounces at openjdk.java.net [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Thursday, November 21, 2013 8:48 PM > To: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. > > On 11/21/13 12:30 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Without (UseCompressedOops && Universe::narrow_oop_base() > 0) check >>> Universe::narrow_oop_use_implicit_null_checks() is useless because it is >>> 'true' by default. That is why I asked to move check inside to combine >>> them in one place. >> Yes, it is useless, but it will not be evaluated. And I need it if narrow_oop_base() >> is set. >> But is it really true by default? See arguments.cpp: > > It is initialized by 'true': > > NarrowPtrStruct Universe::_narrow_oop = { NULL, 0, true }; > > except special case for Win64: > >> #ifdef _WIN64 >> if (UseLargePages && UseCompressedOops) { >> // Cannot allocate guard pages for implicit checks in indexed addressing >> // mode, when large pages are specified on windows. >> // This flag could be switched ON if narrow oop base address is set to 0, >> // see code in Universe::initialize_heap(). >> Universe::set_narrow_oop_use_implicit_null_checks(false); >> } >> #endif // _WIN64 > > which can be reset back to 'true' if 0 page is used for traps: > > Universe::set_narrow_oop_base(NULL); > // Don't need guard page for implicit checks in indexed > // addressing mode with zero based Compressed Oops. > Universe::set_narrow_oop_use_implicit_null_checks(true); > >> >>> You can use Matcher::gen_narrow_oop_implicit_null_checks() check >>> instead. >> No, that returns true if narrow_oop_use_complex_address() is set. > > But you said narrow_oop_use_complex_address() is false on AIX: > > "> but ppc has no loads that support this." > > Did I get it wrong? If it could be true then yes, we can't use it. > >> I must know whether the page before the heapbased heap is protected. >> There should be Universe::heapbased_base_page_is_protected(), >> that would be much more descriptive. >> >>> Note Universe::narrow_oop_base() != NULL only if >>> UseCompressedOops is true. >> Yes, you mean I should remove the test for UseCompressedOops? > > Yes. > >> >>>> No ShouldNotReachHere for AIX. I tried to improve the comment >>>> instead. >>> So you want to return false if it is not DecodeN. Right? >> No, if it's not DecodeN_NN: >> >> xn = loadn >> xo = xn == 0 ? 0 : xn<<3+base // DecodeN >> loadI (xo+offset) >> will not trap, as it accesses the zero page. >> >> xn = loadn >> xo = xn<<3+base // DecodeN_NN >> loadI (xo+offset) >> will trap, as it accesses the base page of the heapbased heap. >> >> If you match the decode into the memory operand of the second >> Load, this check will not work, therefore I put the unimplemented() >> there: >> xn = loadn >> loadI (xo<<3+base+offset) >> but ppc has no loads that support this. >> >> There is no obvious, platform independent way to distinguish >> DecodeN_NN and DecodeN. > > You may be misunderstood me (or I you :) ). > > This code is only executed for AIX: (!os::zero_page_read_protected()). > So I am fine to have NOT_AIX(Unimplemented()) because our current > platforms will not hit it. > > My question was about AIX. If Op_DecodeN and following NotNULL checks > are false you return 'false' from accesses_heap_base_zone() and EXPLICIT > check will be generated. > > My question was, is that what you want for AIX? Because you have next > comment: > > "On AIX, no such memory operands exist, so we need not check for them." > > Which I read as AIX only have case with DecodeN so above checks should > always succeed. That is why I am confused and asked if you need > ShouldNotReachHere there. > > Thanks, > Vladimir > >> >> Thanks for this detailed review! >> Best regards, >> Goetz. >> >> >> >> Thanks, >> Vladimir >> >>> >>> Sorry for the wrong indents. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, November 20, 2013 9:04 PM >>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(S): 8028471: PPC64 (part 215): opto: Extend ImplicitNullCheck optimization. >>> >>> Hi, Goetz >>> >>> Can you move all checks in lcm.cpp into new method and rename it to >>> needs_explicit_null_check_for_read()? So the condition will be simple: >>> >>> if (!was_store && needs_explicit_null_check_for_read(val)) { >>> continue; >>> } >>> >>> You should also add ShouldNotReachHere() for AIX near Unimplemented() >>> for non AIX. >>> >>> And, please, fix indents in new method. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/20/13 2:11 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> ImplicitNullChecks did not work on platforms where the zero >>>> page is only write protected. >>>> >>>> This change adds os property 'zero_page_read_protected' and extends >>>> the ImplicitNullCheck optimization to consider only stores if >>>> this property is not true. If a decoded compressed oop will access the >>>> guard page before the heap, Loads work again. >>>> This is needed on AIX, where the page at address '0' is only write-protected. >>>> >>>> Please review and test this change: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8028471-0-zpage/ >>>> >>>> I tagged this S, as a majority of the patches apply to the ppc platform files. >>>> >>>> Best regards, >>>> Goetz. >>>> From david.r.chase at oracle.com Thu Nov 21 13:29:14 2013 From: david.r.chase at oracle.com (david.r.chase at oracle.com) Date: Thu, 21 Nov 2013 21:29:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 3 new changesets Message-ID: <20131121212924.9842062781@hg.openjdk.java.net> Changeset: 570aaefce624 Author: morris Date: 2013-11-18 12:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/570aaefce624 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Summary: Change _abstract_method_handler to return AbstractMethodError i2c, c2i and c2iv entries. Reviewed-by: kvn, vlivanov ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 938e1e64e28f Author: anoll Date: 2013-11-14 19:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/938e1e64e28f 8028306: nsk stress tests, CodeCache fills, then safepoint asserts Summary: Move handle_full_code_cache() out of block that forbids safepoints Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: fca8f4799229 Author: roland Date: 2013-11-20 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fca8f4799229 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop Summary: rbp not restored when stack overflow is thrown from deopt/uncommon trap blobs Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + test/compiler/uncommontrap/TestStackBangRbp.java From keithgchapman at gmail.com Thu Nov 21 14:06:00 2013 From: keithgchapman at gmail.com (Keith Chapman) Date: Thu, 21 Nov 2013 17:06:00 -0500 Subject: Is it possible to stop a specific application thread? In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE67546@DEWDFEMB12A.global.corp.sap> References: <52817598.1050703@oracle.com> <52818370.4050004@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6445E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE67546@DEWDFEMB12A.global.corp.sap> Message-ID: Thanks Goetz, This is certainly very helpful. Thanks, Keith. On Wed, Nov 20, 2013 at 11:16 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > > > I prepared a webrev for our implementation of loading the poll address > from > > the thread. > > http://cr.openjdk.java.net/~goetz/webrevs/loadpolladrfromthrd/ > > This applies to hotspot-main. > > > > This feature is only implemented for the C2 compiler, C1 adaptions are > missing. > > So you have to set -XX:-TieredCompilation to test it. Else the VM crashes > on > > the first safepoint poll in C1-compiled code. > > The feature in on per default, you can switch it off by setting > > ?XX:-LoadPollAddressFromThread > > > > For more details, see the comment in the webrev. > > > > If you want to submit this to hotspot, I can open a bug and send a proper > > RFR. Which would be the appropriate mailing list? Hotspot-rt? > > I can not push it to JPRT, though. > > > > I would be happy if somebody contributes the adaptions for C1. > > > > Best regards, > > Goetz. > > > > > > > > *From:* Keith Chapman [mailto:keithgchapman at gmail.com] > *Sent:* Dienstag, 12. November 2013 14:27 > *To:* Lindenmaier, Goetz > > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: Is it possible to stop a specific application thread? > > > > > > > > On Tue, Nov 12, 2013 at 3:24 AM, Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > > Hi, > > our VM is running with what we call PerThreadSafepoints for a long time. > > We implement this by loading the page from the thread as you propose. > But we don't have a page per thread, as poisoning them seems to costly > if there are many threads and all threads must be stopped. > > Instead, we adapt the field in the thread: usually it points to some > valid address. If a safepoint is required, the polling page is written > into that field. > > We implemented this when we tried to improve BiasedLocking, > but as we could not gain anything, we don't really use it any more. > > If you really have interest in this feature, I can prepare a webrev > for it. > > > > That would be awesome. > > > > > Best regards, > Goetz. > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto: > hotspot-dev-bounces at openjdk.java.net] On Behalf Of Keith McGuigan > Sent: Dienstag, 12. November 2013 06:46 > To: David Holmes > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Is it possible to stop a specific application thread? > > I had a prototype at one point that did #2, but I don't have the source for > it anymore. If Karen or Coleen kept a copy of my workspace, perhaps they > can reply with the diffs to give someone a leg up in doing this again. > > -- > - Keith (McGuigan) > > On Monday, November 11, 2013, David Holmes wrote: > > > On 12/11/2013 11:16 AM, Keith Chapman wrote: > > > >> Hi David, > >> > >> On Mon, Nov 11, 2013 at 7:26 PM, David Holmes >> > wrote: > >> > >> Hi Keith, > >> > >> > >> On 12/11/2013 6:29 AM, Keith Chapman wrote: > >> > >> Hi, > >> > >> I'm playing around with some research ideas on hotspot. > >> > >> One of my runtime services of the VM needs to stop a specific > >> application > >> thread (I have a handle to the pthread of the application > >> thread). How can > >> the VM stop such a thread? Is there any mechanism in place to do > >> this? > >> > >> > >> There is no general purpose mechanism currently in place. > >> > >> > >> Thats a bummer, having such a mechanism would have been useful for > >> numerous VM services like biased locking revocation, concurrent GC. > >> > > > > For which safepoints are generally used so a per-thread safepoint > > mechanism is what you are looking for. > > > > > >> You could use the deprecated and inherently dangerous Thread.suspend > >> mechanism (either directly or via the JVMTI suspension interface). > >> > >> Or if you are more adventurous with your VM hacking you could > >> introduce a per-thread safepoint operation to cause it to stop. > >> > >> > >> I actually thought about that and explored the way safepoints are > >> implemented. The place that I had most trouble was getting threads > >> running compiled code to stop. The way it currently works is by > >> allocating a polling page (at startup) and drilling in that address into > >> the compiled code. Hence i I am to do it per thread I would have to make > >> a call to the runtime to get the address of the polling page for that > >> particular thread. I presume this would be too expensive (Making a VM > >> call at the end of each method and through some loop iterations). > >> > >> Is there any insight you could offer on how this could be done? > >> > > > > Two basic options I can think of: > > > > 1. Use a single shared page and have other threads simply ignore the > > safepoint request. This might incur some overhead as not-wanted threads > > could hit this multiple times. > > > > 2. Use a per-thread page accessed via the current thread. There would be > a > > little overhead for the indirection but the compiler knows how to access > > the current JavaThread object. No need for runtime calls that I can see. > > > > Good luck. > > > > David > > > > Thanks, > >> Keith. > >> > >> Or you could hack in a special "magic exception" type the processing > >> of which simply blocks the thread until "resumed" somehow (not sure > >> how ??). Or ... > >> > >> Cheers, > >> David > >> > >> Thanks, > >> Keith. > >> > >> > >> > >> > >> -- > >> > >> Keith Chapman > >> blog: http://www.keith-chapman.org > >> > > > > > > > > -- > > Keith Chapman > blog: http://www.keith-chapman.org > -- Keith Chapman blog: http://www.keith-chapman.org From goetz.lindenmaier at sap.com Thu Nov 21 14:25:41 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Nov 2013 22:25:41 +0000 Subject: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6801F@DEWDFEMB12A.global.corp.sap> Hi, This change contains a row of smaller shared changes required to build the C2 compiler on PPC64. http://cr.openjdk.java.net/~goetz/webrevs/8028767-0-basic/ - fixes for aix build - make some methods public we need to call - use RegL for Vectors - some new utility methods Please review and test this change. Best regards, Goetz. From vladimir.kozlov at oracle.com Thu Nov 21 14:56:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 21 Nov 2013 14:56:36 -0800 Subject: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6801F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6801F@DEWDFEMB12A.global.corp.sap> Message-ID: <528E8FA4.2090608@oracle.com> Looks fine to me. I assume you ran our vector tests in test/compiler. Thanks, Vladimir On 11/21/13 2:25 PM, Lindenmaier, Goetz wrote: > Hi, > > This change contains a row of smaller shared changes required to build the C2 compiler on PPC64. > http://cr.openjdk.java.net/~goetz/webrevs/8028767-0-basic/ > > - fixes for aix build > - make some methods public we need to call > - use RegL for Vectors > - some new utility methods > > Please review and test this change. > > Best regards, > Goetz. > From alejandro.murillo at oracle.com Thu Nov 21 17:07:51 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 22 Nov 2013 01:07:51 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.60-b03 for changeset 90cfd4ad3c92 Message-ID: <20131122010754.37BD36278C@hg.openjdk.java.net> Changeset: 8fd0e931efa5 Author: amurillo Date: 2013-11-21 13:37 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/8fd0e931efa5 Added tag hs24.60-b03 for changeset 90cfd4ad3c92 ! .hgtags From alejandro.murillo at oracle.com Thu Nov 21 21:07:07 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 22 Nov 2013 05:07:07 +0000 Subject: hg: hsx/jdk7u/hotspot: 8027579: new hotspot build - hs24.60-b04 Message-ID: <20131122050709.D47166279B@hg.openjdk.java.net> Changeset: ca7dab518021 Author: amurillo Date: 2013-11-21 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ca7dab518021 8027579: new hotspot build - hs24.60-b04 Reviewed-by: jcoomes ! make/hotspot_version From niclas.adlertz at oracle.com Fri Nov 22 00:49:34 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 22 Nov 2013 09:49:34 +0100 Subject: =?ISO-8859-1?Q?Result=3A_CFV=3A_New_hotspot_Group_Memb?= =?ISO-8859-1?Q?er=3A_Rickard_B=E4ckman?= Message-ID: <528F1A9E.7060501@oracle.com> The vote for Rickard B?ckman [1] is now closed. Yes: 12 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-November/011482.html From mikael.gerdin at oracle.com Fri Nov 22 00:56:01 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 22 Nov 2013 09:56:01 +0100 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <528E5ADA.3030700@oracle.com> References: <528E382B.2030001@oracle.com> <528E5ADA.3030700@oracle.com> Message-ID: <1918875.JCQytm4udc@mgerdin03> Coleen, On November 21, 2013 8:11:22 PM Coleen Phillimore wrote: > > Stefan, > > I think the function MarkSweep::adjust_class_loader() is now unused, but I > couldn't find where we adjust the class in the CLD walk. There are similar > functions in ParallelScavenge - are they also not needed? I don't > recommend adding this change, just noting it may be cleaned up later if so. All Klasses are adjusted because we call oops_do on CLDG with the adjust closure. We don't need to discover the CLDs a second time after we are done with marking. MarkSweep::adjust_class_loader() can be removed since it's not used. The same problem affects ParallelScavenge but it's possible that the regression is not as obvious due to the parallelism. > > This change seems good but I'm not a GC person. Stefan, This change looks good but since I was involved with developing the fix I'd like another gc Reviewer to look at the fix as well. /Mikael > > thanks, > Coleen > > On 11/21/2013 11:43 AM, Stefan Johansson wrote: > > Hi all, > > > > Can I have a couple reviews for this fix for: > > https://bugs.openjdk.java.net/browse/JDK-8027675 > > > > Webrev: > > http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ > > > > Summary: > > When doing permgen removal we had to change the way classes were marked > and handled in the GC. When doing this we ended up doing some things a > little less efficient than before. The regression is easy to reproduce and > when doing a JFR recording we can see that we now spend more time in both > the mark and adjust phase. > > > > To improve the mark phase: > > * Enabled the calls to follow_klass to be inlined. > > * Reduce the extensive amount of calls to follow_class_loader in > follow_klass and instead just mark the klass holder (the class loader or > the java mirror) for the given klass. > > > > To improve the adjust phase: > > * All calls to adjust_klass have been removed since this is already > handled by processing the ClassLoaderDataGraph. > > > > Testing: > > * Manually ran SPECjbb2005 to verify fixing the regression > > * JPRT for functional sanity testing > > * Nashorn tests to stress anonymous classes > > > > Thanks, > > StefanJ > From stefan.johansson at oracle.com Fri Nov 22 01:08:32 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 22 Nov 2013 10:08:32 +0100 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <528E5ADA.3030700@oracle.com> References: <528E382B.2030001@oracle.com> <528E5ADA.3030700@oracle.com> Message-ID: <528F1F10.2010808@oracle.com> Thanks for taking a look at this Coleen, Please see answers inline. On 2013-11-21 20:11, Coleen Phillimore wrote: > > Stefan, > > I think the function MarkSweep::adjust_class_loader() is now unused, > but I couldn't find where we adjust the class in the CLD walk. You're correct, MarkSweep::adjust_class_loader() should be removed as well. Updated webrev: http://cr.openjdk.java.net/~sjohanss/8027675/webrev.01/ We adjust the classes in phase 3 by calling process_strong_roots with scanning option SO_AllClasses, this will in SharedHeap::process_strong_roots lead to calling ClassLoaderDataGraph::oops_do with the adjust closures. > There are similar functions in ParallelScavenge - are they also not > needed? I don't recommend adding this change, just noting it may be > cleaned up later if so. We've also looked at this and similar improvements should be possible to do for the PS old-collections. But as you say that is a separate issue that needs more investigation as well. Thanks, Stefan > > This change seems good but I'm not a GC person. > > thanks, > Coleen > > On 11/21/2013 11:43 AM, Stefan Johansson wrote: >> Hi all, >> >> Can I have a couple reviews for this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8027675 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ >> >> Summary: >> When doing permgen removal we had to change the way classes were >> marked and handled in the GC. When doing this we ended up doing some >> things a little less efficient than before. The regression is easy to >> reproduce and when doing a JFR recording we can see that we now spend >> more time in both the mark and adjust phase. >> >> To improve the mark phase: >> * Enabled the calls to follow_klass to be inlined. >> * Reduce the extensive amount of calls to follow_class_loader in >> follow_klass and instead just mark the klass holder (the class loader >> or the java mirror) for the given klass. >> >> To improve the adjust phase: >> * All calls to adjust_klass have been removed since this is already >> handled by processing the ClassLoaderDataGraph. >> >> Testing: >> * Manually ran SPECjbb2005 to verify fixing the regression >> * JPRT for functional sanity testing >> * Nashorn tests to stress anonymous classes >> >> Thanks, >> StefanJ > From volker.simonis at gmail.com Fri Nov 22 01:23:53 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Nov 2013 10:23:53 +0100 Subject: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 In-Reply-To: <528E8FA4.2090608@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6801F@DEWDFEMB12A.global.corp.sap> <528E8FA4.2090608@oracle.com> Message-ID: Hi Vladimir, which tests are you referring to? I can not find a vector subbdirectory under test/compiler. Regards, Volker On Thu, Nov 21, 2013 at 11:56 PM, Vladimir Kozlov < vladimir.kozlov at oracle.com> wrote: > Looks fine to me. > > I assume you ran our vector tests in test/compiler. > > Thanks, > Vladimir > > > On 11/21/13 2:25 PM, Lindenmaier, Goetz wrote: > >> Hi, >> >> This change contains a row of smaller shared changes required to build >> the C2 compiler on PPC64. >> http://cr.openjdk.java.net/~goetz/webrevs/8028767-0-basic/ >> >> - fixes for aix build >> - make some methods public we need to call >> - use RegL for Vectors >> - some new utility methods >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> >> From thomas.schatzl at oracle.com Fri Nov 22 02:13:46 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 22 Nov 2013 11:13:46 +0100 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <1918875.JCQytm4udc@mgerdin03> References: <528E382B.2030001@oracle.com> <528E5ADA.3030700@oracle.com> <1918875.JCQytm4udc@mgerdin03> Message-ID: <1385115226.3189.3.camel@cirrus> Hi, On Fri, 2013-11-22 at 09:56 +0100, Mikael Gerdin wrote: > Coleen, > > On November 21, 2013 8:11:22 PM Coleen Phillimore > wrote: > > > > Stefan, > > > > I think the function MarkSweep::adjust_class_loader() is now unused, but I > > couldn't find where we adjust the class in the CLD walk. There are similar > > functions in ParallelScavenge - are they also not needed? I don't > > recommend adding this change, just noting it may be cleaned up later if so. > > All Klasses are adjusted because we call oops_do on CLDG with the adjust > closure. We don't need to discover the CLDs a second time after we are done > with marking. > > MarkSweep::adjust_class_loader() can be removed since it's not used. > The same problem affects ParallelScavenge but it's possible that the > regression is not as obvious due to the parallelism. Stefan, could you file an RFE for this? > > > > This change seems good but I'm not a GC person. > > Stefan, > This change looks good but since I was involved with developing the fix I'd > like another gc Reviewer to look at the fix as well. Looks good to me (also the .01 webrev). Thomas From stefan.johansson at oracle.com Fri Nov 22 04:34:39 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 22 Nov 2013 13:34:39 +0100 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <1385115226.3189.3.camel@cirrus> References: <528E382B.2030001@oracle.com> <528E5ADA.3030700@oracle.com> <1918875.JCQytm4udc@mgerdin03> <1385115226.3189.3.camel@cirrus> Message-ID: <528F4F5F.1030307@oracle.com> Thanks for having a look Thomas, On 2013-11-22 11:13, Thomas Schatzl wrote: > Hi, > > On Fri, 2013-11-22 at 09:56 +0100, Mikael Gerdin wrote: >> Coleen, >> >> On November 21, 2013 8:11:22 PM Coleen Phillimore >> wrote: >>> Stefan, >>> >>> I think the function MarkSweep::adjust_class_loader() is now unused, but I >>> couldn't find where we adjust the class in the CLD walk. There are similar >>> functions in ParallelScavenge - are they also not needed? I don't >>> recommend adding this change, just noting it may be cleaned up later if so. >> All Klasses are adjusted because we call oops_do on CLDG with the adjust >> closure. We don't need to discover the CLDs a second time after we are done >> with marking. >> >> MarkSweep::adjust_class_loader() can be removed since it's not used. >> The same problem affects ParallelScavenge but it's possible that the >> regression is not as obvious due to the parallelism. > Stefan, could you file an RFE for this? I've already filed it as a bug (JDK-8028993). Since it's a regression I think we should see this as a bug, trying to fix it as soon as possible. > >>> This change seems good but I'm not a GC person. >> Stefan, >> This change looks good but since I was involved with developing the fix I'd >> like another gc Reviewer to look at the fix as well. > Looks good to me (also the .01 webrev). Thanks! Cheers, StefanJ > > Thomas > From goetz.lindenmaier at sap.com Fri Nov 22 06:41:43 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Nov 2013 14:41:43 +0000 Subject: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks Message-ID: <4295855A5C1DE049A61835A1887419CC2CE68276@DEWDFEMB12A.global.corp.sap> Hi, I prepared a webrev for the trap based checks feature used on PPC: http://cr.openjdk.java.net/~goetz/webrevs/8029015-0-trch/ PPC has the tdi instruction that does a compare and raises SIGTRAP if the compare is successful. With this instruction conditional branches leading to uncommon traps can be implemented very efficiently. This is especially needed on AIX, where there are almost no possibilities for ImplicitNullChecks as the zero page is not protected. On linux, this accounts for about 2% jvm2008 performance. Possibilities for trap based range checks and trap based null checks are recognized during matching. To support this, we added a method branches_to_uncommon_trap() to be used in the predicate during matching. The computation of the final block layout must know about this, as it must place the fallthrough properly and adapt the condition in the tdi instruction. We added a method is_TrapBasedCheckNode so these nodes can be recogized in a platform independent way. Please review and test this change. Best regards, Goetz From goetz.lindenmaier at sap.com Fri Nov 22 07:16:20 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Nov 2013 15:16:20 +0000 Subject: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 In-Reply-To: <528E8FA4.2090608@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6801F@DEWDFEMB12A.global.corp.sap> <528E8FA4.2090608@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE68298@DEWDFEMB12A.global.corp.sap> Hi Vladimir, you probably meant the test below? They pass. Thanks for reviewing and testing this! Best regards, Goetz. compiler/6340864/TestByteVect.java Passed. Execution successful compiler/6340864/TestDoubleVect.java Passed. Execution successful compiler/6340864/TestFloatVect.java Passed. Execution successful compiler/6340864/TestIntVect.java Passed. Execution successful compiler/6340864/TestLongVect.java Passed. Execution successful compiler/6340864/TestShortVect.java Passed. Execution successful compiler/7119644/TestBooleanVect.java Passed. Execution successful compiler/7119644/TestByteDoubleVect.java Passed. Execution successful compiler/7119644/TestByteFloatVect.java Passed. Execution successful compiler/7119644/TestByteIntVect.java Passed. Execution successful compiler/7119644/TestByteLongVect.java Passed. Execution successful compiler/7119644/TestByteShortVect.java Passed. Execution successful compiler/7119644/TestByteVect.java Passed. Execution successful compiler/7119644/TestCharShortVect.java Passed. Execution successful compiler/7119644/TestCharVect.java Passed. Execution successful compiler/7119644/TestDoubleVect.java Passed. Execution successful compiler/7119644/TestFloatDoubleVect.java Passed. Execution successful compiler/7119644/TestFloatVect.java Passed. Execution successful compiler/7119644/TestIntDoubleVect.java Passed. Execution successful compiler/7119644/TestIntFloatVect.java Passed. Execution successful compiler/7119644/TestIntLongVect.java Passed. Execution successful compiler/7119644/TestIntVect.java Passed. Execution successful compiler/7119644/TestLongDoubleVect.java Passed. Execution successful compiler/7119644/TestLongFloatVect.java Passed. Execution successful compiler/7119644/TestLongVect.java Passed. Execution successful compiler/7119644/TestShortDoubleVect.java Passed. Execution successful compiler/7119644/TestShortFloatVect.java Passed. Execution successful compiler/7119644/TestShortIntVect.java Passed. Execution successful compiler/7119644/TestShortLongVect.java Passed. Execution successful compiler/7119644/TestShortVect.java Passed. Execution successful compiler/7192963/TestByteVect.java Passed. Execution successful compiler/7192963/TestDoubleVect.java Passed. Execution successful compiler/7192963/TestFloatVect.java Passed. Execution successful compiler/7192963/TestIntVect.java Passed. Execution successful compiler/7192963/TestLongVect.java Passed. Execution successful compiler/7192963/TestShortVect.java Passed. Execution successful compiler/7200264/TestIntVect.java Passed. Execution successful compiler/8001183/TestCharVect.java Passed. Execution successful -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Donnerstag, 21. November 2013 23:57 To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 Looks fine to me. I assume you ran our vector tests in test/compiler. Thanks, Vladimir On 11/21/13 2:25 PM, Lindenmaier, Goetz wrote: > Hi, > > This change contains a row of smaller shared changes required to build the C2 compiler on PPC64. > http://cr.openjdk.java.net/~goetz/webrevs/8028767-0-basic/ > > - fixes for aix build > - make some methods public we need to call > - use RegL for Vectors > - some new utility methods > > Please review and test this change. > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Fri Nov 22 07:39:33 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Nov 2013 15:39:33 +0000 Subject: RFR (S): 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. Message-ID: <4295855A5C1DE049A61835A1887419CC2CE682AF@DEWDFEMB12A.global.corp.sap> Hi, I prepared a webrev containing some debugging support. http://cr.openjdk.java.net/~goetz/webrevs/8029025-0-ndmp/ To allow some special cases when dumping debug information about IR nodes, _in_dump_cnt can be increased. Unfortunately this is a global field. If running with more than one compiler thread races can happen. As consequence, dumping crashes e.g. in MachProjNode::adr_type(). This change moves the field to the Compile object. It also introduces the compiler oracle 'option' feature for PrintAssembly. This is not a mandatory part of the port, but we find this very useful if debugging the compiler. Please review and test this change Best regards, Goetz. From coleen.phillimore at oracle.com Fri Nov 22 07:46:16 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Nov 2013 10:46:16 -0500 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <528F1F10.2010808@oracle.com> References: <528E382B.2030001@oracle.com> <528E5ADA.3030700@oracle.com> <528F1F10.2010808@oracle.com> Message-ID: <528F7C48.5030208@oracle.com> On 11/22/2013 4:08 AM, Stefan Johansson wrote: > Thanks for taking a look at this Coleen, This looks good to me also. Thanks to the GC reviewers. Coleen > > Please see answers inline. > > On 2013-11-21 20:11, Coleen Phillimore wrote: >> >> Stefan, >> >> I think the function MarkSweep::adjust_class_loader() is now unused, >> but I couldn't find where we adjust the class in the CLD walk. > You're correct, MarkSweep::adjust_class_loader() should be removed as > well. Updated webrev: > http://cr.openjdk.java.net/~sjohanss/8027675/webrev.01/ > > We adjust the classes in phase 3 by calling process_strong_roots with > scanning option SO_AllClasses, this will in > SharedHeap::process_strong_roots lead to calling > ClassLoaderDataGraph::oops_do with the adjust closures. >> There are similar functions in ParallelScavenge - are they also not >> needed? I don't recommend adding this change, just noting it may be >> cleaned up later if so. > We've also looked at this and similar improvements should be possible > to do for the PS old-collections. But as you say that is a separate > issue that needs more investigation as well. > > Thanks, > Stefan >> >> This change seems good but I'm not a GC person. >> >> thanks, >> Coleen >> >> On 11/21/2013 11:43 AM, Stefan Johansson wrote: >>> Hi all, >>> >>> Can I have a couple reviews for this fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8027675 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ >>> >>> Summary: >>> When doing permgen removal we had to change the way classes were >>> marked and handled in the GC. When doing this we ended up doing some >>> things a little less efficient than before. The regression is easy >>> to reproduce and when doing a JFR recording we can see that we now >>> spend more time in both the mark and adjust phase. >>> >>> To improve the mark phase: >>> * Enabled the calls to follow_klass to be inlined. >>> * Reduce the extensive amount of calls to follow_class_loader in >>> follow_klass and instead just mark the klass holder (the class >>> loader or the java mirror) for the given klass. >>> >>> To improve the adjust phase: >>> * All calls to adjust_klass have been removed since this is already >>> handled by processing the ClassLoaderDataGraph. >>> >>> Testing: >>> * Manually ran SPECjbb2005 to verify fixing the regression >>> * JPRT for functional sanity testing >>> * Nashorn tests to stress anonymous classes >>> >>> Thanks, >>> StefanJ >> > From jon.masamitsu at oracle.com Fri Nov 22 08:21:38 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 22 Nov 2013 08:21:38 -0800 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <528E382B.2030001@oracle.com> References: <528E382B.2030001@oracle.com> Message-ID: <528F8492.8060801@oracle.com> Stefan, Changes look good. Just some questions to be sure I understand what was previously happening. Thanks. Jon On 11/21/2013 8:43 AM, Stefan Johansson wrote: > Hi all, > > Can I have a couple reviews for this fix for: > https://bugs.openjdk.java.net/browse/JDK-8027675 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ > > Summary: > When doing permgen removal we had to change the way classes were > marked and handled in the GC. When doing this we ended up doing some > things a little less efficient than before. The regression is easy to > reproduce and when doing a JFR recording we can see that we now spend > more time in both the mark and adjust phase. > > To improve the mark phase: > * Enabled the calls to follow_klass to be inlined. > * Reduce the extensive amount of calls to follow_class_loader in > follow_klass and instead just mark the klass holder (the class loader > or the java mirror) for the given klass. The calls to follow_class_loader() were there just for the case of the anonymous classes? > > To improve the adjust phase: > * All calls to adjust_klass have been removed since this is already > handled by processing the ClassLoaderDataGraph. So in the original code the call were made to ClassLoaderData::oops_do() and found the CLD already claimed so did nothing? > > Testing: > * Manually ran SPECjbb2005 to verify fixing the regression > * JPRT for functional sanity testing > * Nashorn tests to stress anonymous classes > > Thanks, > StefanJ From vladimir.kozlov at oracle.com Fri Nov 22 08:37:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2013 08:37:28 -0800 Subject: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE68298@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6801F@DEWDFEMB12A.global.corp.sap> <528E8FA4.2090608@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE68298@DEWDFEMB12A.global.corp.sap> Message-ID: <528F8848.9030802@oracle.com> Yes, I mean that tests. We used only float regs for vectors before and you added RegL so I wanted make sure it works. Thanks, Vladimir On 11/22/13 7:16 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > you probably meant the test below? They pass. > Thanks for reviewing and testing this! > > Best regards, > Goetz. > > compiler/6340864/TestByteVect.java Passed. Execution successful > compiler/6340864/TestDoubleVect.java Passed. Execution successful > compiler/6340864/TestFloatVect.java Passed. Execution successful > compiler/6340864/TestIntVect.java Passed. Execution successful > compiler/6340864/TestLongVect.java Passed. Execution successful > compiler/6340864/TestShortVect.java Passed. Execution successful > > compiler/7119644/TestBooleanVect.java Passed. Execution successful > compiler/7119644/TestByteDoubleVect.java Passed. Execution successful > compiler/7119644/TestByteFloatVect.java Passed. Execution successful > compiler/7119644/TestByteIntVect.java Passed. Execution successful > compiler/7119644/TestByteLongVect.java Passed. Execution successful > compiler/7119644/TestByteShortVect.java Passed. Execution successful > compiler/7119644/TestByteVect.java Passed. Execution successful > compiler/7119644/TestCharShortVect.java Passed. Execution successful > compiler/7119644/TestCharVect.java Passed. Execution successful > compiler/7119644/TestDoubleVect.java Passed. Execution successful > compiler/7119644/TestFloatDoubleVect.java Passed. Execution successful > compiler/7119644/TestFloatVect.java Passed. Execution successful > compiler/7119644/TestIntDoubleVect.java Passed. Execution successful > compiler/7119644/TestIntFloatVect.java Passed. Execution successful > compiler/7119644/TestIntLongVect.java Passed. Execution successful > compiler/7119644/TestIntVect.java Passed. Execution successful > compiler/7119644/TestLongDoubleVect.java Passed. Execution successful > compiler/7119644/TestLongFloatVect.java Passed. Execution successful > compiler/7119644/TestLongVect.java Passed. Execution successful > compiler/7119644/TestShortDoubleVect.java Passed. Execution successful > compiler/7119644/TestShortFloatVect.java Passed. Execution successful > compiler/7119644/TestShortIntVect.java Passed. Execution successful > compiler/7119644/TestShortLongVect.java Passed. Execution successful > compiler/7119644/TestShortVect.java Passed. Execution successful > > compiler/7192963/TestByteVect.java Passed. Execution successful > compiler/7192963/TestDoubleVect.java Passed. Execution successful > compiler/7192963/TestFloatVect.java Passed. Execution successful > compiler/7192963/TestIntVect.java Passed. Execution successful > compiler/7192963/TestLongVect.java Passed. Execution successful > compiler/7192963/TestShortVect.java Passed. Execution successful > compiler/7200264/TestIntVect.java Passed. Execution successful > compiler/8001183/TestCharVect.java Passed. Execution successful > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Donnerstag, 21. November 2013 23:57 > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028767: PPC64: (part 121): smaller shared changes needed to build C2 > > Looks fine to me. > > I assume you ran our vector tests in test/compiler. > > Thanks, > Vladimir > > On 11/21/13 2:25 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> This change contains a row of smaller shared changes required to build the C2 compiler on PPC64. >> http://cr.openjdk.java.net/~goetz/webrevs/8028767-0-basic/ >> >> - fixes for aix build >> - make some methods public we need to call >> - use RegL for Vectors >> - some new utility methods >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Fri Nov 22 08:57:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2013 08:57:38 -0800 Subject: RFR (S): 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE682AF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE682AF@DEWDFEMB12A.global.corp.sap> Message-ID: <528F8D02.9070202@oracle.com> Looks good. Compile::current() is expensive but it is only for debugging. I will push it today. Thanks, Vladimir On 11/22/13 7:39 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev containing some debugging support. > http://cr.openjdk.java.net/~goetz/webrevs/8029025-0-ndmp/ > > To allow some special cases when dumping debug information about IR > nodes, _in_dump_cnt can be increased. Unfortunately this is a global > field. If running with more than one compiler thread races can happen. > As consequence, dumping crashes e.g. in MachProjNode::adr_type(). > > This change moves the field to the Compile object. > > It also introduces the compiler oracle 'option' feature for PrintAssembly. > > This is not a mandatory part of the port, but we find this very useful > if debugging the compiler. > > Please review and test this change > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Fri Nov 22 10:00:43 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Nov 2013 18:00:43 +0000 Subject: RFR (S): 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. In-Reply-To: <528F8D02.9070202@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE682AF@DEWDFEMB12A.global.corp.sap> <528F8D02.9070202@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE683A8@DEWDFEMB12A.global.corp.sap> Thank you! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, November 22, 2013 5:58 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR (S): 8029025: PPC64 (part 203): opto: Move static _in_dump_cnt to Compile object. Looks good. Compile::current() is expensive but it is only for debugging. I will push it today. Thanks, Vladimir On 11/22/13 7:39 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev containing some debugging support. > http://cr.openjdk.java.net/~goetz/webrevs/8029025-0-ndmp/ > > To allow some special cases when dumping debug information about IR > nodes, _in_dump_cnt can be increased. Unfortunately this is a global > field. If running with more than one compiler thread races can happen. > As consequence, dumping crashes e.g. in MachProjNode::adr_type(). > > This change moves the field to the Compile object. > > It also introduces the compiler oracle 'option' feature for PrintAssembly. > > This is not a mandatory part of the port, but we find this very useful > if debugging the compiler. > > Please review and test this change > > Best regards, > Goetz. > From david.r.chase at oracle.com Fri Nov 22 11:07:56 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 22 Nov 2013 14:07:56 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method Message-ID: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Updated request. This is for a bug that it "deferred" by compilers, but runtime really wants it fixed because they are working in the same area and don't like it at all. In particular, they want it committed to hotspot-rt ASAP (don't want to wait for the multiweek turnaround) and thus the diffs and testing are against hotspot-rt. There are jdk and hotspot webrevs; the hotspot webrev is designed to allow it to run (with old behavior) in the absence of the jdk change. Bug: https://bugs.openjdk.java.net/browse/JDK-8016839 Related test bug: https://bugs.openjdk.java.net/browse/JDK-8027733 (confidential, sorry) Webrev(s): http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ Testing: ute vm.quick.testlist A/B, no (new) failures jtreg compiler runtime sanity, no (new) failures defmeth, no new failures, fewer old failures New test, specifically tested on Sparc, Intel, embedded -Xint, -Xcomp, plain, and with jdb on embedded, and Netbeans on x86. (this was specifically to address the main uncertainty, which was calling a zero-arg exception-throwing method instead of the expected perhaps-multi-arg inaccessible method; it is possible to devise calling conventions that will make that not work, but we appear not to have done this. The test includes 0- and 11-arg instances of the not-legally-accessible methods). Problem: Various patterns of inheritance and faulty overriding are supposed to throw IllegalAccessError (IAE). At the time the bug was filed, they instead threw NullPointerException (NPE) but after a related bug was fixed the wrong exception changed to AbstractMethodError (AME). The root cause of the error is that (1) by convention, if an itable entry is null, AME is thrown, and (2) in the case of inaccessible methods overriding other methods that implement interface methods, a null was entered into the itable (leading to throws of AME on code paths that use the itable). This is a long-standing problem dating back to at least JDK 6, but made much easier to observe by the introduction of method handles. Before methodhandles this bug was more difficult to observe because resolution of invokeinterface would aggressively evaluate errors and leave the invoke unresolved if there was an error; thus repeated testing with error receivers would always throw the proper error. If, however, a good receiver is used for the invokeinterface, then resolution succeeds, and subsequent invocations with bad receivers throws the wrong error (AME instead of NPE) because the resolved code goes directly to the itable and sees the null method. With Methodhandles, resolution and invocation are separate, and it always throws the wrong error. Fix: I considered (and discussed with John Rose and Coleen Phillimore and Karen Kinnear) use of a "second null value", where instead of using 0x0 for the missing method, I would use 0x1, and then special case the null checks (in triplicate, across all platforms) to instead unsigned compare against a small integer and also special-case the trap handler for this value. This seemed like a big change, potentially confusing to C programmers, hacky, and somewhat hateful. I next considered creating a "bridge to nowhere" stub that would always throw IAE, and fill that Method * in instead of null. Unfortunately, the need for this stub is not discovered until after constant pool rewriting has occurred, and adding new methods and CPC entries after the rewriting looked very hairy. The last choice was to define a helper method in sun.misc.Unsafe that would always throw IllegalAccessError when called, and use that Method * in the should-throw-IAE case. The risk here is that the helper method is zero-arg, where the method about to be called (and whose parameters had been pushed on the stack) could have a different set of arguments, and perhaps there is some platform where this does not work cleanly. However, the existing code that checks for null and throws AME seems to not be special-cased for number of args (that is, it branches to a generic exception thrower with no additional cleanup). In addition, I enhanced the test to try faulty invocations with both zero and 11 args, and to run under jtreg in several modes, and I added iteration to help force code to the compiled case as well, and it has performed properly on Sparc, Intel, and embedded. From karen.kinnear at oracle.com Fri Nov 22 11:56:57 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 22 Nov 2013 14:56:57 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: David, Thank you so much for finding a way to do this. We do think this is important to get in for 8. And thank you for a way to check the hotspot changes in without waiting for the jdk changes. Code looks good. Couple of minor comments: 1. universe.cpp - when the hotspot change gets in and the jdk change isn't in yet, are we going to see the tty->print_cr message? 2. style: Method* rather than Method space * 3. Head's up that ASM is being updated for default method support - visitMethoInsn will take an additional argument at the end for "isinterface" to determine if it needs a methodref or an interfacemethodref in the constant pool. I think that is in b117 (?) so we don't have it yet - so this will need modifying later - don't let that stop you from pushing the fix. See Lois's test webrev http://javaweb.us.oracle.com/~lfoltan/webrev/defmeth_asm_interfacemethodef_2/src/vm/runtime/defmeth/shared/ClassFileGenerator.java.sdiff.html thanks, Karen On Nov 22, 2013, at 2:07 PM, David Chase wrote: > Updated request. > > This is for a bug that it "deferred" by compilers, > but runtime really wants it fixed because they > are working in the same area and don't like it at all. > In particular, they want it committed to hotspot-rt ASAP > (don't want to wait for the multiweek turnaround) > and thus the diffs and testing are against hotspot-rt. > > There are jdk and hotspot webrevs; the hotspot webrev > is designed to allow it to run (with old behavior) in the > absence of the jdk change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016839 > Related test bug: https://bugs.openjdk.java.net/browse/JDK-8027733 (confidential, sorry) > > Webrev(s): > http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ > http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ > > Testing: > ute vm.quick.testlist A/B, no (new) failures > jtreg compiler runtime sanity, no (new) failures > defmeth, no new failures, fewer old failures > > New test, specifically tested on Sparc, Intel, embedded > -Xint, -Xcomp, plain, and with jdb on embedded, and > Netbeans on x86. (this was specifically to address the main > uncertainty, which was calling a zero-arg exception-throwing > method instead of the expected perhaps-multi-arg inaccessible > method; it is possible to devise calling conventions that will > make that not work, but we appear not to have done this. The test > includes 0- and 11-arg instances of the not-legally-accessible > methods). > > Problem: > Various patterns of inheritance and faulty overriding are supposed to > throw IllegalAccessError (IAE). At the time the bug was filed, they > instead threw NullPointerException (NPE) but after a related bug was > fixed the wrong exception changed to AbstractMethodError (AME). > > The root cause of the error is that (1) by convention, if an itable > entry is null, AME is thrown, and (2) in the case of inaccessible > methods overriding other methods that implement interface methods, a > null was entered into the itable (leading to throws of AME on code paths > that use the itable). > > This is a long-standing problem dating back to at least JDK 6, but made > much easier to observe by the introduction of method handles. Before > methodhandles this bug was more difficult to observe because resolution > of invokeinterface would aggressively evaluate errors and leave the > invoke unresolved if there was an error; thus repeated testing with > error receivers would always throw the proper error. If, however, a > good receiver is used for the invokeinterface, then resolution succeeds, > and subsequent invocations with bad receivers throws the wrong error > (AME instead of NPE) because the resolved code goes directly to the > itable and sees the null method. > > With Methodhandles, resolution and invocation are separate, and it > always throws the wrong error. > > Fix: > > I considered (and discussed with John Rose and Coleen Phillimore and > Karen Kinnear) use of a "second null value", where instead of using 0x0 > for the missing method, I would use 0x1, and then special case the null > checks (in triplicate, across all platforms) to instead unsigned compare > against a small integer and also special-case the trap handler for this > value. > > This seemed like a big change, potentially confusing to C programmers, > hacky, and somewhat hateful. > > I next considered creating a "bridge to nowhere" stub that would always > throw IAE, and fill that Method * in instead of null. Unfortunately, > the need for this stub is not discovered until after constant pool > rewriting has occurred, and adding new methods and CPC entries after > the rewriting looked very hairy. > > The last choice was to define a helper method in sun.misc.Unsafe that > would always throw IllegalAccessError when called, and use that Method * > in the should-throw-IAE case. The risk here is that the helper method > is zero-arg, where the method about to be called (and whose parameters > had been pushed on the stack) could have a different set of arguments, > and perhaps there is some platform where this does not work cleanly. > However, the existing code that checks for null and throws AME seems to > not be special-cased for number of args (that is, it branches to a > generic exception thrower with no additional cleanup). In addition, I > enhanced the test to try faulty invocations with both zero and 11 args, > and to run under jtreg in several modes, and I added iteration to help > force code to the compiled case as well, and it has performed properly > on Sparc, Intel, and embedded. > From david.r.chase at oracle.com Fri Nov 22 12:49:44 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 22 Nov 2013 15:49:44 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: On 2013-11-22, at 2:56 PM, Karen Kinnear wrote: > David, > > Thank you so much for finding a way to do this. We do think this is important to get in for 8. > And thank you for a way to check the hotspot changes in without waiting for the jdk changes. > > Code looks good. > > Couple of minor comments: > 1. universe.cpp - when the hotspot change gets in and the jdk change isn't in yet, are > we going to see the tty->print_cr message? No. if (m != NULL && !m->is_static()) { It only occurs if m is incorrectly defined (defined, so not null, but not static). > 2. style: Method* rather than Method space * Will fix. > 3. Head's up that ASM is being updated for default method support > - visitMethoInsn will take an additional argument at the end for "isinterface" to determine > if it needs a methodref or an interfacemethodref in the constant pool. I think that is in b117 (?) > so we don't have it yet - so this will need modifying later - don't let that stop you from pushing the > fix. > > See Lois's test webrev > http://javaweb.us.oracle.com/~lfoltan/webrev/defmeth_asm_interfacemethodef_2/src/vm/runtime/defmeth/shared/ClassFileGenerator.java.sdiff.html From markus.gronlund at oracle.com Fri Nov 22 12:55:26 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Fri, 22 Nov 2013 20:55:26 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20131122205545.44CB6627C4@hg.openjdk.java.net> Changeset: cdf20166ec45 Author: minqi Date: 2013-11-13 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cdf20166ec45 8025632: Remove all references to MagicLambdaImpl from Hotspot Summary: MagicLambdaImpl was removed from jdk side, this should be done in vm side too Reviewed-by: coleenp, hseigel, rdurbin ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 3edddbff4865 Author: minqi Date: 2013-11-13 16:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3edddbff4865 Merge Changeset: b03f33670080 Author: sla Date: 2013-11-14 19:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b03f33670080 6606002: jinfo doesn't detect dynamic vm flags changing Reviewed-by: coleenp, jbachorik, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java Changeset: 5280822ddfcd Author: sla Date: 2013-11-14 20:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5280822ddfcd 6626412: jstack using SA prints some info messages into err stream Reviewed-by: coleenp, farvidsson, jbachorik, dsamersoff, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java Changeset: 438fe38c63c8 Author: mgronlun Date: 2013-11-15 21:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/438fe38c63c8 Merge ! src/share/vm/runtime/globals.hpp Changeset: d61a1a166f44 Author: coleenp Date: 2013-11-15 17:20 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d61a1a166f44 8028347: Rewriter::scan_method asserts with array oob in RT_Baseline Summary: Fix reversing rewriting for invokespecial Reviewed-by: jrose, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp Changeset: 0b9ea9a72436 Author: sla Date: 2013-11-18 10:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0b9ea9a72436 8027630: SIGSEGV in const char*Klass::external_name() Reviewed-by: coleenp, sspitsyn, mgronlun ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 396564992823 Author: sgabdura Date: 2013-11-18 08:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/396564992823 8028341: PSR:FUNC: SCOPE PARAMETER MISSING FROM THE -XX:+PRINTFLAGSFINAL Reviewed-by: dcubed, sla ! src/share/vm/runtime/globals.cpp Changeset: aa933e6b061d Author: mgronlun Date: 2013-11-22 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aa933e6b061d Merge From coleen.phillimore at oracle.com Fri Nov 22 15:37:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Nov 2013 18:37:06 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: <528FEAA2.9050700@oracle.com> I have reviewed both the hotspot change, including test, and the JDK change. They look good. Thank you for all the testing on different platforms. Coleen On 11/22/2013 2:07 PM, David Chase wrote: > Updated request. > > This is for a bug that it "deferred" by compilers, > but runtime really wants it fixed because they > are working in the same area and don't like it at all. > In particular, they want it committed to hotspot-rt ASAP > (don't want to wait for the multiweek turnaround) > and thus the diffs and testing are against hotspot-rt. > > There are jdk and hotspot webrevs; the hotspot webrev > is designed to allow it to run (with old behavior) in the > absence of the jdk change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016839 > Related test bug: https://bugs.openjdk.java.net/browse/JDK-8027733 (confidential, sorry) > > Webrev(s): > http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ > http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ > > Testing: > ute vm.quick.testlist A/B, no (new) failures > jtreg compiler runtime sanity, no (new) failures > defmeth, no new failures, fewer old failures > > New test, specifically tested on Sparc, Intel, embedded > -Xint, -Xcomp, plain, and with jdb on embedded, and > Netbeans on x86. (this was specifically to address the main > uncertainty, which was calling a zero-arg exception-throwing > method instead of the expected perhaps-multi-arg inaccessible > method; it is possible to devise calling conventions that will > make that not work, but we appear not to have done this. The test > includes 0- and 11-arg instances of the not-legally-accessible > methods). > > Problem: > Various patterns of inheritance and faulty overriding are supposed to > throw IllegalAccessError (IAE). At the time the bug was filed, they > instead threw NullPointerException (NPE) but after a related bug was > fixed the wrong exception changed to AbstractMethodError (AME). > > The root cause of the error is that (1) by convention, if an itable > entry is null, AME is thrown, and (2) in the case of inaccessible > methods overriding other methods that implement interface methods, a > null was entered into the itable (leading to throws of AME on code paths > that use the itable). > > This is a long-standing problem dating back to at least JDK 6, but made > much easier to observe by the introduction of method handles. Before > methodhandles this bug was more difficult to observe because resolution > of invokeinterface would aggressively evaluate errors and leave the > invoke unresolved if there was an error; thus repeated testing with > error receivers would always throw the proper error. If, however, a > good receiver is used for the invokeinterface, then resolution succeeds, > and subsequent invocations with bad receivers throws the wrong error > (AME instead of NPE) because the resolved code goes directly to the > itable and sees the null method. > > With Methodhandles, resolution and invocation are separate, and it > always throws the wrong error. > > Fix: > > I considered (and discussed with John Rose and Coleen Phillimore and > Karen Kinnear) use of a "second null value", where instead of using 0x0 > for the missing method, I would use 0x1, and then special case the null > checks (in triplicate, across all platforms) to instead unsigned compare > against a small integer and also special-case the trap handler for this > value. > > This seemed like a big change, potentially confusing to C programmers, > hacky, and somewhat hateful. > > I next considered creating a "bridge to nowhere" stub that would always > throw IAE, and fill that Method * in instead of null. Unfortunately, > the need for this stub is not discovered until after constant pool > rewriting has occurred, and adding new methods and CPC entries after > the rewriting looked very hairy. > > The last choice was to define a helper method in sun.misc.Unsafe that > would always throw IllegalAccessError when called, and use that Method * > in the should-throw-IAE case. The risk here is that the helper method > is zero-arg, where the method about to be called (and whose parameters > had been pushed on the stack) could have a different set of arguments, > and perhaps there is some platform where this does not work cleanly. > However, the existing code that checks for null and throws AME seems to > not be special-cased for number of args (that is, it branches to a > generic exception thrower with no additional cleanup). In addition, I > enhanced the test to try faulty invocations with both zero and 11 args, > and to run under jtreg in several modes, and I added iteration to help > force code to the compiled case as well, and it has performed properly > on Sparc, Intel, and embedded. > From alejandro.murillo at oracle.com Fri Nov 22 16:34:50 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 23 Nov 2013 00:34:50 +0000 Subject: hg: hsx/hsx25/hotspot: 16 new changesets Message-ID: <20131123003527.DCA33627C9@hg.openjdk.java.net> Changeset: 55be5aac78e2 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/55be5aac78e2 Added tag jdk8-b117 for changeset f573d00213b7 ! .hgtags Changeset: 854a42db7069 Author: amurillo Date: 2013-11-15 07:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/854a42db7069 8028444: new hotspot build - hs25-b60 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 570aaefce624 Author: morris Date: 2013-11-18 12:26 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/570aaefce624 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Summary: Change _abstract_method_handler to return AbstractMethodError i2c, c2i and c2iv entries. Reviewed-by: kvn, vlivanov ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 938e1e64e28f Author: anoll Date: 2013-11-14 19:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/938e1e64e28f 8028306: nsk stress tests, CodeCache fills, then safepoint asserts Summary: Move handle_full_code_cache() out of block that forbids safepoints Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: fca8f4799229 Author: roland Date: 2013-11-20 12:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fca8f4799229 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop Summary: rbp not restored when stack overflow is thrown from deopt/uncommon trap blobs Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + test/compiler/uncommontrap/TestStackBangRbp.java Changeset: cdf20166ec45 Author: minqi Date: 2013-11-13 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cdf20166ec45 8025632: Remove all references to MagicLambdaImpl from Hotspot Summary: MagicLambdaImpl was removed from jdk side, this should be done in vm side too Reviewed-by: coleenp, hseigel, rdurbin ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 3edddbff4865 Author: minqi Date: 2013-11-13 16:35 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3edddbff4865 Merge Changeset: b03f33670080 Author: sla Date: 2013-11-14 19:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b03f33670080 6606002: jinfo doesn't detect dynamic vm flags changing Reviewed-by: coleenp, jbachorik, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java Changeset: 5280822ddfcd Author: sla Date: 2013-11-14 20:03 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5280822ddfcd 6626412: jstack using SA prints some info messages into err stream Reviewed-by: coleenp, farvidsson, jbachorik, dsamersoff, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java Changeset: 438fe38c63c8 Author: mgronlun Date: 2013-11-15 21:39 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/438fe38c63c8 Merge ! src/share/vm/runtime/globals.hpp Changeset: d61a1a166f44 Author: coleenp Date: 2013-11-15 17:20 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d61a1a166f44 8028347: Rewriter::scan_method asserts with array oob in RT_Baseline Summary: Fix reversing rewriting for invokespecial Reviewed-by: jrose, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp Changeset: 0b9ea9a72436 Author: sla Date: 2013-11-18 10:20 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0b9ea9a72436 8027630: SIGSEGV in const char*Klass::external_name() Reviewed-by: coleenp, sspitsyn, mgronlun ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 396564992823 Author: sgabdura Date: 2013-11-18 08:21 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/396564992823 8028341: PSR:FUNC: SCOPE PARAMETER MISSING FROM THE -XX:+PRINTFLAGSFINAL Reviewed-by: dcubed, sla ! src/share/vm/runtime/globals.cpp Changeset: aa933e6b061d Author: mgronlun Date: 2013-11-22 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aa933e6b061d Merge Changeset: abad3b2d905d Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/abad3b2d905d Merge Changeset: c9f439732b18 Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c9f439732b18 Added tag hs25-b60 for changeset abad3b2d905d ! .hgtags From vladimir.kozlov at oracle.com Fri Nov 22 17:17:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Nov 2013 17:17:31 -0800 Subject: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE68276@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE68276@DEWDFEMB12A.global.corp.sap> Message-ID: <5290022B.8010009@oracle.com> Hi Goetz, First general question. Why you did not create specialized Mach node like MachNullCheckNode to handle such cases and using existing code in lcm.cpp? Or it would be more complicated changes? To avoid changes in closed sources can you put TrapBasedNullChecks and TrapBasedRangeChecks into opto/c2_globals.hpp (thay are used only by C2) and set them to 'true' if FLAG_IS_DEFAULT() in src/cpu/ppc/vm/vm_version_ppc.cpp ? output_h.cpp: since you touching the code can you add explicit != 0 for all checks (ins_cost and ins_short_branch)? block.cpp: Could you rename local 'bra' in no_flip_branch() and in new code in fixup_flow()? It is not good name :) Use full name 'branch'. + // Don't flip if bra has an implicit check. + if (bra->is_TrapBasedCheckNode()) return true; And, please, move new code in PhaseCFG::fixup_flow() into separate method. You moved _allowed_reasons code to Compile::Init() which is called for stubs too. But you removed if (C->is_method_compilation()) check. Why? matcher.cpp: we usually use C variable name for Compile object: Compile *Co = Compile::current(); Where branches_to_uncommon_trap() is used? output.cpp: can you replace next node to move is_TrapBasedCheckNode() to MachNode class?: if (n->is_TrapBasedCheckNode()) { replace with if (n->is_Mach() && n->as_Mach()->is_TrapBasedCheckNode()) { Thanks, Vladimir On 11/22/13 6:41 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for the trap based checks feature used on PPC: > http://cr.openjdk.java.net/~goetz/webrevs/8029015-0-trch/ > > PPC has the tdi instruction that does a compare and raises SIGTRAP > if the compare is successful. > With this instruction conditional branches leading to uncommon > traps can be implemented very efficiently. > This is especially needed on AIX, where there are almost no > possibilities for ImplicitNullChecks as the zero page is not > protected. > > On linux, this accounts for about 2% jvm2008 performance. > > Possibilities for trap based range checks and trap based null checks > are recognized during matching. To support this, we added a method > branches_to_uncommon_trap() to be used in the predicate during > matching. > The computation of the final block layout must know about this, > as it must place the fallthrough properly and adapt the condition > in the tdi instruction. > We added a method is_TrapBasedCheckNode so these nodes > can be recogized in a platform independent way. > > Please review and test this change. > > Best regards, > Goetz > From alejandro.murillo at oracle.com Fri Nov 22 18:40:55 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 23 Nov 2013 02:40:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131123024104.DA5D6627CF@hg.openjdk.java.net> Changeset: 55be5aac78e2 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/55be5aac78e2 Added tag jdk8-b117 for changeset f573d00213b7 ! .hgtags Changeset: abad3b2d905d Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/abad3b2d905d Merge Changeset: c9f439732b18 Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c9f439732b18 Added tag hs25-b60 for changeset abad3b2d905d ! .hgtags Changeset: e51d73189692 Author: amurillo Date: 2013-11-22 13:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e51d73189692 8028815: new hotspot build - hs25-b61 Reviewed-by: jcoomes ! make/hotspot_version From stefan.johansson at oracle.com Mon Nov 25 01:09:14 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 25 Nov 2013 10:09:14 +0100 Subject: RFR: 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 In-Reply-To: <528F8492.8060801@oracle.com> References: <528E382B.2030001@oracle.com> <528F8492.8060801@oracle.com> Message-ID: <529313BA.5010209@oracle.com> Thanks for taking a look Jon. On 2013-11-22 17:21, Jon Masamitsu wrote: > Stefan, > > Changes look good. Just some questions to be sure I > understand what was previously happening. > > Thanks. > > Jon > > On 11/21/2013 8:43 AM, Stefan Johansson wrote: >> Hi all, >> >> Can I have a couple reviews for this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8027675 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8027675/webrev.00/ >> >> Summary: >> When doing permgen removal we had to change the way classes were >> marked and handled in the GC. When doing this we ended up doing some >> things a little less efficient than before. The regression is easy to >> reproduce and when doing a JFR recording we can see that we now spend >> more time in both the mark and adjust phase. >> >> To improve the mark phase: >> * Enabled the calls to follow_klass to be inlined. >> * Reduce the extensive amount of calls to follow_class_loader in >> follow_klass and instead just mark the klass holder (the class loader >> or the java mirror) for the given klass. > The calls to follow_class_loader() were there just for the case > of the anonymous classes? > Yes, for other classes it's sufficient to just mark and push the class loader. >> >> To improve the adjust phase: >> * All calls to adjust_klass have been removed since this is already >> handled by processing the ClassLoaderDataGraph. > > So in the original code the call were made to > ClassLoaderData::oops_do() and found the CLD > already claimed so did nothing? > Yes, all calls to adjust_klass did nothing more that check and find that things were already adjusted. > >> >> Testing: >> * Manually ran SPECjbb2005 to verify fixing the regression >> * JPRT for functional sanity testing >> * Nashorn tests to stress anonymous classes >> >> Thanks, >> StefanJ > From goetz.lindenmaier at sap.com Mon Nov 25 03:26:05 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Nov 2013 11:26:05 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <528E18F7.7050001@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> <528E18F7.7050001@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> Hi David, I promised to comment on your concern about individual load/stores: > As you state ld.acq and st.rel only > relate to the target load/store _but_ there are no actions in the Java > Memory Model that only provide ordering with respect to a single load or > store! We derive this from the well-known cookbook: http://g.oswego.edu/dl/jmm/cookbook.html Have a look at the table "required Barriers". It talks about individual operations. E.g., imagine Normal load 1 Volatile load 2 Normal load 3 Then load1 may float arbitrarily to any place, but load3 may not float above load2. If I issue a 'wide' Acquire barriers after load2 (lwsync), this hinders load1 to float below this barrier, introducing a constraint not specified by this table. Does this satisfy your concerns? Best regards, Goetz and Martin -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Donnerstag, 21. November 2013 15:30 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. Hi Goetz, On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: > Hi David, > > here the new webrev, naming the nodes LoadFence/StoreFence: > http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ Okay. I think I now disagree (when seeing in context) that Membar should have been dropped from the name but I'll let that lie. Aside: I find the descriptions of all those "membar" nodes very unclear - it would be better, for me, if there were expressed more clearly in terms of storeStore, storeLoad etc. Could you add to the comments in memnode.hpp that those nodes are only used by the respective Unsafe intrinisics? Or at least use that as an example usage? > The thing with the mail was my fault, I had sent the first mail > only to you accidentially. Sorry for that. > >> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >> loads/stores - but with stronger semantics than just simple loadLoad or >> storeStore barriers. > Yes. I mean they do not intend to sort a single load/store with succeeding > operations. This can not be implemented this way, as the operation > is not known in the intrinsic. I mean cases where you can use ia64 ld.acq > or ppc ld-twi-lwsync. If you are saying that loadFence and storeFence can not be implemented using ld.acq and st.rel then good I agree with you. But I would argue that general ld;MembarAcquire and st;MembarRelease can also not be implemented with those instructions! As you state ld.acq and st.rel only relate to the target load/store _but_ there are no actions in the Java Memory Model that only provide ordering with respect to a single load or store! The Unsafe *Ordered() operations may come closer to this but I would expect them to be handled via an intrinsic - and they are outside the JMM. So I would think the applicability of using ld.acq and st.rel would be very limited, so it concerns me that it seems to be associated with the very general MembarAcquire and MembarRelease nodes (ditto for the changes in 8024921). But how you implement this is your concern. :) From the perspective of this shared code my concern is that it is not clear exactly what the practical distinction is between MembarAcquire and LoadFence, and MembarRelease and StoreFence. I'm not a compiler person but I would find it quite difficult to know which can/should be used when. And given for most platforms they would be implemented the same, that would add to the uncertainty (with a risk that someone will make an arbitrary choice). Thanks, David ----- >> Also I said that the Unsafe ops require bi-directional fences but that >> was imprecise - the _load and _store ops only require two of the four >> possible barriers which may be why you see these as distinct from the >> membars associated directly with variable accesses ? > On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. > For the intrinsic I must use mf, which sorts _all_ previous loads with all > following ld/st operations (and more). So my distinction is if I have a > store on one processor, and a load on the other, and I want to make sure > the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. > If I did some arbitrary stores, and I want assure an other processor doing > some arbitrary load,s then I must use - on ia64- mf on both. > On sparc I can do a > membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); > membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); > But, on sparc, there is no operation as ld.acq as far as I know. > > Change 8024921 enables to distinguish normal loads and such > that should do ld.acq. This change enables the compiler to > differentiate the MemBar nodes used better: such coming after > a dedicated load, and such valid for any load before the barrier. > This is already visible in the IR by some means: MemBars after > dedicated loads have an input edge at position MemBar::precedence > connecting them with the load, but that does not suffice to > match it (in the matcher) correctly. > If I use ld.acq, the following MemBarAcquire is superfluous, > but the MemBarAcquire used in the intrinsic is not. So want to > have different nodes. > In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, > and with #ifdef ia64 we use MemBarVolatile, as we know these operations will > issue the proper assembly instructions. But this is bad - I want to do it better > here. > >> Are you referring to generated code if these nodes are adjacent? If so I >> assume the problem is that you can't logically coalesce these, even if >> the actual generated code could be coalesced? > Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire > and Volatile with mf() if we would not use ld.acq/st.rel. Then there > would be even more redundant operations. But that's out of scope of this change. > >> I still have this concern regarding the fact you think these are not >> related to load/store operations. But I'll wait for the webrev. > As stated above, yes, they are related to store/load operations. But not > to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not > part of the intrinsic. > > (I'm using the ia64 mnemonics in the implementation because I think > they are nicely orthogonal. Also it's important to know that > ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only > the one load mentioned in the sequence. That's some hack in the > processor.) > > Best regards, > Goetz. > > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 20. November 2013 21:06 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > First apologies that the email you replied to here didn't go to the > lists. Due to the way it was filtered I assumed it was a direct email > only. :) > > On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> thanks for the comprehensive explanation. That's in agreement with >> what I understand. Except that I think, unidirectional barriers only >> make sense if you have Acquire/Release operations dedicated to >> a certain operation. Then other operations of the same kind can pass >> the barrier in one direction. >> >> This also matches the extension I contributed to hotspot (8024921), >> which now allows to issue such operations right along with the >> loads/stores. >> >> This change here tries to separate the barriers used after load/stores from >> the 'wide' or better 'fence' variants. > > But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after > loads/stores - but with stronger semantics than just simple loadLoad or > storeStore barriers. > >> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible >> operations. Unfortunately, Hotspot knows only four of these: >> MemBarStoreStore: S-S > > Okay - nice and clear. > >> MemBarAcquire: L-S, L-L > > I'm not sure what makes this "acquire" but this seems to be exactly what > Unsafe.loadFence requires. > >> MemBarRelease: L-S, S-S > > Again I'm not sure what makes this "release" - I also find it odd that > it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence > needs. > >> MemBarVolatile: L-L, L-S, S-L, S-S > > A full fence, needed in the worst case when accessing a volatile variable. > > Also note that in different parts of the VM we have different > expressions of these, both at the JIT level and runtime eg see > orderAccess.hpp (which is not in itself self-consistent or clear: see > https://bugs.openjdk.java.net/browse/JDK-7143664). > > Also I said that the Unsafe ops require bi-directional fences but that > was imprecise - the _load and _store ops only require two of the four > possible barriers which may be why you see these as distinct from the > membars associated directly with variable accesses ? > >> and these don't map, e.g., the operations available on PPC: >> lwsync: L-S, L-L, S-S >> sync: L-L, L-S, S-L, S-S >> What is the reason why it's hard for us to generate optimal code >> with the available optimizations: >> MemBarAcquire; >> MemBarRelease; >> are mapped to >> lwsync >> lwsync >> which is obviously redundant. > > Are you referring to generated code if these nodes are adjacent? If so I > assume the problem is that you can't logically coalesce these, even if > the actual generated code could be coalesced? > >> A generic solution would be to have a single operation, that can be >> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >> Two operations could be merged by an optimization simply by >> or-ing the tags. >> But this is not reality in HotSpot, and out of scope of this change. > > Ok > >>> I think perhaps that Vladimir's suggestion is best - if these are the >>> Membar nodes for these unsafe ops (and only these) then name them to >>> match the unsafe ops. At least then it is clearer where the >>> specification for their behaviour comes from. >> OK, so I'll rename them as Vladimir proposed, and post a new webrev. > > I still have this concern regarding the fact you think these are not > related to load/store operations. But I'll wait for the webrev. > > Thanks for your patience on this. Hopefully we can sort it out in the > next 24 hours before I takeoff. > > David > ----- > >> Best regards and a good flight home, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. November 2013 14:30 >> To: Lindenmaier, Goetz >> Cc: David Holmes >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> Hi Goetz, >> >> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> I don't know what you mean by uni/bi-directional. >> >> Pretty much as you describe below. A unidirectional barrier allows >> things to cross in one direction only ie it blocks motion one way; a >> bi-directional barrier ("full fence") blocks both ways and so prevents >> any reordering. >> >> As I described in earlier emails these kind of unreferenced >> acquire/release semantics ie not associated with any stores/loads is >> used to describe the memory barrier properties of a synchronized block, >> for example. Monitor acquisition has acquire semantics, while monitor >> release has store semantics. The implied barriers mean that any accesses >> can move into the synchronized region but none can move out - the "roach >> motel" semantics. >> >> Now as you say this kind of barrier is not what is wanted with these >> loadFence/storeFence operations, hence I think the generic >> MembarAcquire/MembarRelease are inappropriate names (whether the >> implementation is correct is a different matter). Similarly I find the >> MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - >> what do they mean ??? >> >> The loadFence semantics imply a loadLoad|loadStore barrier. >> The storeFence semantics imply a storeLoad|storeStore barrier. >> The fullFence is of course all four. >> >> Again I'm unclear if the current or proposed MembarXXX actions actually >> map to barriers that implement those semantics. >> >> So yes this comes down to naming initially but also verification that >> the implementation does as required. >> >> I think perhaps that Vladimir's suggestion is best - if these are the >> Membar nodes for these unsafe ops (and only these) then name them to >> match the unsafe ops. At least then it is clearer where the >> specification for their behaviour comes from. >> >> I'll post a follow up email to the list when I get a chance. I'm >> currently in the US and attending lots of meetings then head back to >> Australia tomorrow evening. >> >> Thanks, >> David >> >>> I guess we agree that the documentation of the intrinsics, let's take >>> loadFence >>> for an example, talks about loads before the loadFence, and stores and >>> loads after it: >>> loads >>> ------------loadFence()-------------- >>> loads, stores >>> With this, you can achieve any ordering by moving nodes up OR down: >>> Op1 Move Op1 Op2 >>> Op2 down ------------- >>> --------- =========> Op3 >>> Op3 Op1 >>> Alternatively, you can move op3 up, and get the same order: >>> Op1 Reorder Op2 Move Op3 Op2 >>> Op2 Ops 1 and 2 Op1 up Op3 >>> --------- =========> -------------- =========> Op1 >>> Op3 Not restricted Op3 ---------- >>> by later loadFence >>> So, if the operation restricts only moves in one direction, it's of no >>> help because >>> you can still get an execution order you did not expect. So >>> unidirectional operations >>> (e.g., only hindering operations from moving up) are pointless. >>> By the way, are you questioning whether the implementation is correct, or >>> whether the names express what is desired? >>> If it's the first, it's of no concern to this change, which is only about >>> matching these operations independently from those, that address >>> a dedicated memory operation. >>> If It's the second, please tell me what names to use, and I'll fix it. >>> (I hope you can properly read the 'drawings') >>> Best regards, >>> Goetz. >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Dienstag, 19. November 2013 20:51 >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>> 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>> MemBarAcquire/ReleaseWide. >>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>> as shown below. So I guess that's just what is desired. >>> I don't think so! What is described for Unsafe are full bi-directional >>> fences and "acquire" and "release" are only uni-directional fences! >>> David >>> ----- >>>> Best regards, >>>> Goetz. >>>> >>>> /** >>>> * Ensures lack of reordering of loads before the fence >>>> * with loads or stores after the fence. >>>> * @since 1.8 >>>> */ >>>> public native void loadFence(); >>>> >>>> /** >>>> * Ensures lack of reordering of stores before the fence >>>> * with loads or stores after the fence. >>>> * @since 1.8 >>>> */ >>>> public native void storeFence(); >>>> >>>> /** >>>> * Ensures lack of reordering of loads or stores before the fence >>>> * with loads or stores after the fence. >>>> * @since 1.8 >>>> */ >>>> public native void fullFence(); >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>> To: Lindenmaier, Goetz >>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> So I like the rename but I am concerned there are semantic issues here: >>>> >>>> switch(id) { >>>> case vmIntrinsics::_loadFence: >>>> - insert_mem_bar(Op_MemBarAcquire); >>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>> return true; >>>> case vmIntrinsics::_storeFence: >>>> - insert_mem_bar(Op_MemBarRelease); >>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>> return true; >>>> >>>> What is a _loadFence operation? Does it really map to >>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>> bi-directional fences - are they? Are they really only concerned with >>>> loads or stores ? >>>> >>>> David >>>> >>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I made a new webrev, using the new names: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>> >>>>> Thanks, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>> Sent: Montag, 18. November 2013 23:28 >>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, Vladimir, >>>>>> >>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>> - the same prefix shows they are all similar nodes. >>>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>>> change yet and which is used in more places. >>>>> >>>>> Okay. >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>> To: Vladimir Kozlov >>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>> >>>>>> Vladimir, >>>>>> >>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>> I think David asked for different nodes not just one. >>>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>> >>>>>> But I don't think that actually describes them - they don't distinguish >>>>>> between loads and stores only the direction in which the barrier >>>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>>> only allows accesses to move above it ie: >>>>>> >>>>>> load a >>>>>> store b, c >>>>>> acquire(); >>>>>> load d >>>>>> store e,f >>>>>> release(); >>>>>> load g >>>>>> store h, i >>>>>> >>>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>>> the store to e can not move in relation to either acquire or release. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> as reply to your comment on the bug: >>>>>>>> >>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>> MemBarVolatile --> sync. >>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>> >>>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>>> Therefore I think a really clean representation that, at the same >>>>>>>> time, allows >>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>> processors, is impossible. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz >>>>>>>> >>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>> or on the mailing lists? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>> >>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>> Lindenmaier, Goetz >>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>>> >>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>>> matched differently, what is needed on PPC64. >>>>>>>> >>>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>> >>>>>>>> Please review and test this change. >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> From goetz.lindenmaier at sap.com Mon Nov 25 05:24:12 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Nov 2013 13:24:12 +0000 Subject: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks In-Reply-To: <5290022B.8010009@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE68276@DEWDFEMB12A.global.corp.sap> <5290022B.8010009@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE687CC@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I made a new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8029015-1-trch/ > First general question. Why you did not create specialized Mach node > like MachNullCheckNode to handle such cases and using existing code in > lcm.cpp? Or it would be more complicated changes? I think lcm is not a good place to create new nodes. The right place is the matcher. Also, I would have to implement a platform independent factory method to create the nodes, that is implemented on each platform. And to specify a node that inherits from a shared MachNode, mayby MachTrapCheckNode, requires a rule with an idea opcode. Finally, I think the nodes checking ranges are not handles in lcm? > To avoid changes in closed sources can you put TrapBasedNullChecks and > TrapBasedRangeChecks into opto/c2_globals.hpp (thay are used only by C2) > and set them to 'true' if FLAG_IS_DEFAULT() in > src/cpu/ppc/vm/vm_version_ppc.cpp ? It's in ARCH_FLAGS, so that it can be a develop flag on sparc/x86 and a product on ppc. But being in ARCH_FLAGS, closed sources should not need adaptions. There is no ARCH_FLAGS for the c2_globals_.hpp files. > output_h.cpp: since you touching the code can you add explicit != 0 for > all checks (ins_cost and ins_short_branch)? Done. Also inserted space after commas. > block.cpp: Could you rename local 'bra' in no_flip_branch() and in new > code in fixup_flow()? It is not good name :) Use full name 'branch'. Done. Also fixed spaces and added {}. > And, please, move new code in PhaseCFG::fixup_flow() into separate method. Done, but it doesn't look good as I have to pass a lot of context in there. > You moved _allowed_reasons code to Compile::Init() which is called for > stubs too. But you removed if (C->is_method_compilation()) check. Why? Did I? It's still in gcm! And I also check it in branches_to_uncommon_trap(). > matcher.cpp: we usually use C variable name for Compile object: Fixed. It's bad C is not available in the predicates. It's quite useful there. You need it in post_store_load_barrier(), too. > Where branches_to_uncommon_trap() is used? In the predicates in ppc.ad, but also In our zArch/s390 port. > output.cpp: can you replace next node to move is_TrapBasedCheckNode() to > MachNode class?: Done. But it's the only typecheck method in MachNode now, all the others are in node, as the one used a few lines above: is_MachNullCheck. But well, it's not tied to a node class as the others. Thanks for the review and best regards, Goetz. > Thanks, > Vladimir On 11/22/13 6:41 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for the trap based checks feature used on PPC: > http://cr.openjdk.java.net/~goetz/webrevs/8029015-0-trch/ > > PPC has the tdi instruction that does a compare and raises SIGTRAP > if the compare is successful. > With this instruction conditional branches leading to uncommon > traps can be implemented very efficiently. > This is especially needed on AIX, where there are almost no > possibilities for ImplicitNullChecks as the zero page is not > protected. > > On linux, this accounts for about 2% jvm2008 performance. > > Possibilities for trap based range checks and trap based null checks > are recognized during matching. To support this, we added a method > branches_to_uncommon_trap() to be used in the predicate during > matching. > The computation of the final block layout must know about this, > as it must place the fallthrough properly and adapt the condition > in the tdi instruction. > We added a method is_TrapBasedCheckNode so these nodes > can be recogized in a platform independent way. > > Please review and test this change. > > Best regards, > Goetz > From goetz.lindenmaier at sap.com Mon Nov 25 08:16:09 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Nov 2013 16:16:09 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> Hi, I preprared a webrev with fixes for PPC for the VolatileIRIWTest of the torture test suite: http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ Example: volatile x=0, y=0 __________ __________ __________ __________ | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | write(x=1) read(x) write(y=1) read(y) read(y) read(x) Disallowed: x=1, y=0 y=1, x=0 Solution: This example requires multiple-copy-atomicity. This is only assured by the sync instruction and if it is executed in the threads doing the loads. Thus we implement volatile read as sync-load-acquire and omit the sync/MemBarVolatile after the volatile store. MemBarVolatile happens to be implemented by sync. We fix this in C2 and the cpp interpreter. This addresses a similar issue as fix "8012144: multiple SIGSEGVs fails on staxf" for taskqueue.hpp. Further this change contains a fix that assures that volatile fields written in constructors are visible before the reference gets published. Looking at the code, we found a MemBarRelease that to us, seems too strong. We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. What do you think? Please review and test this change. Best regards, Goetz. From david.r.chase at oracle.com Mon Nov 25 09:12:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 25 Nov 2013 12:12:51 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: I wasn't 100% clear on the desire to not add another preloaded class, and I was under the impression that if s.m.Unsafe could not load, then things were hosed indeed. If there's another already preloaded class that would be a good choice, it is an easy change to make; MethodHandleNatives, or others in the java.lang.invoke world, also seem potentially appropriate, though there is also a possibility that someone might want to backport this to 7 (I can demonstrate the bug in 6, and I suspect also in 5 if I could get my hands on such a VM) so we need to be aware of that, too (I am not myself 100% clear on which of those files appeared when, except that sun.misc.Unsafe has been around for a while). David On 2013-11-25, at 4:49 AM, Paul Sandoz wrote: > HI David, > > Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? > > Paul. > > > > From coleen.phillimore at oracle.com Mon Nov 25 10:10:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 25 Nov 2013 13:10:02 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: <5293927A.2090300@oracle.com> On 11/25/2013 12:12 PM, David Chase wrote: > I wasn't 100% clear on the desire to not add another preloaded class, and I was under the impression that if s.m.Unsafe could not load, then things were hosed indeed. If there's another already preloaded class that would be a good choice, it is an easy change to make; MethodHandleNatives, or others in the java.lang.invoke world, also seem potentially appropriate, though there is also a possibility that someone might want to backport this to 7 (I can demonstrate the bug in 6, and I suspect also in 5 if I could get my hands on such a VM) so we need to be aware of that, too (I am not myself 100% clear on which of those files appeared when, except that sun.misc.Unsafe has been around for a while). I didn't think MethodHandles was an appropriate place to put this function since it is generic and we might want to use this mechanism to have Method* metadata when we throw other pre-existing exceptions. Somewhere else in java/lang might be better but it seemed like Unsafe would be the lowest overhead to add something, without changing the documentation/specification of the basic jdk classes. Coleen David On 2013-11-25, at 4:49 AM, Paul Sandoz wrote: >> HI David, >> >> Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? >> >> Paul. >> >> >> >> From joel.franck at oracle.com Mon Nov 25 10:33:44 2013 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Mon, 25 Nov 2013 19:33:44 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: <062F2AA5-48A7-4D6C-BB37-55673126B453@oracle.com> Hi, On 22 Nov 2013, at 20:07, David Chase wrote: > The last choice was to define a helper method in sun.misc.Unsafe that > would always throw IllegalAccessError when called, and use that Method * > in the should-throw-IAE case. The risk here is that the helper method > is zero-arg, where the method about to be called (and whose parameters > had been pushed on the stack) could have a different set of arguments, > and perhaps there is some platform where this does not work cleanly. > However, the existing code that checks for null and throws AME seems to > not be special-cased for number of args (that is, it branches to a > generic exception thrower with no additional cleanup). In addition, I > enhanced the test to try faulty invocations with both zero and 11 args, > and to run under jtreg in several modes, and I added iteration to help > force code to the compiled case as well, and it has performed properly > on Sparc, Intel, and embedded. I was under the impression that a HotSpot Method can move as the result of a class redefine. An added bonus of having this in s.m.Unsafe is that hopefully it should be very uncommon to redefine those methods. cheers /Joel From paul.sandoz at oracle.com Mon Nov 25 01:49:42 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Nov 2013 10:49:42 +0100 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> HI David, Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? Paul. From vladimir.kozlov at oracle.com Mon Nov 25 15:21:15 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 15:21:15 -0800 Subject: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE687CC@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE68276@DEWDFEMB12A.global.corp.sap> <5290022B.8010009@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE687CC@DEWDFEMB12A.global.corp.sap> Message-ID: <5293DB6B.6020901@oracle.com> On 11/25/13 5:24 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I made a new webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8029015-1-trch/ > >> First general question. Why you did not create specialized Mach node >> like MachNullCheckNode to handle such cases and using existing code in >> lcm.cpp? Or it would be more complicated changes? > I think lcm is not a good place to create new nodes. The right place is the > matcher. Also, I would have to implement a platform independent factory > method to create the nodes, that is implemented on each platform. > And to specify a node that inherits from a shared MachNode, mayby > MachTrapCheckNode, requires a rule with an idea opcode. > Finally, I think the nodes checking ranges are not handles in lcm? I thought that in lcm you will have more opportunity to generate trap checks. Anyway, it is not correctness issue but performance (and may be not). I am fine with what you have now. Also I was looking on predicates for these nodes in ppc.ad and I thought may be you can factor out repetitive checks to a separate method in IfNode: predicate(TrapBasedNullChecks && _kids[0]->_leaf->as_Bool()->_test._test == BoolTest::ne && _leaf->as_If()->_prob >= PROB_ALWAYS); you will get more clean code there and you will not need next change: + AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in predicate. >> To avoid changes in closed sources can you put TrapBasedNullChecks and >> TrapBasedRangeChecks into opto/c2_globals.hpp (thay are used only by C2) >> and set them to 'true' if FLAG_IS_DEFAULT() in >> src/cpu/ppc/vm/vm_version_ppc.cpp ? > It's in ARCH_FLAGS, so that it can be a develop flag on sparc/x86 and a > product on ppc. But being in ARCH_FLAGS, closed sources should not need > adaptions. There is no ARCH_FLAGS for the c2_globals_.hpp files. No, they can not be ARCH_FLAGS because they are referenced in C2 shared code (PhaseCFG::fixup_flow()): + if ((TrapBasedNullChecks || TrapBasedRangeChecks) && They are C2 flags. To compile this code for closed sources flags have to be defined. I asked to define them in opto/c2_globals.hpp because otherwise I will have to add them to ARCH_FLAGS in closed globals_.hpp The example of strict ARCH_FLAGS is UseAddressNop which is used only in src/cpu/x86/vm/* files. >> You moved _allowed_reasons code to Compile::Init() which is called for >> stubs too. But you removed if (C->is_method_compilation()) check. Why? > Did I? It's still in gcm! And I also check it in branches_to_uncommon_trap(). I phrased my question not accurately. The code which set _allowed_reasons was done before only under (C->is_method_compilation()) check. And I see that you added the check to Compile::Init() in this version so it is good. >> Where branches_to_uncommon_trap() is used? > In the predicates in ppc.ad, but also In our zArch/s390 port. I don't see it in the ppc.ad version I have, that is why I asked: http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/09f97b967480/src/cpu/ppc/vm/ppc.ad Thanks, Vladimir > >> output.cpp: can you replace next node to move is_TrapBasedCheckNode() to >> MachNode class?: > Done. But it's the only typecheck method in MachNode now, all the others > are in node, as the one used a few lines above: is_MachNullCheck. But well, it's not tied > to a node class as the others. > > Thanks for the review and best regards, > Goetz. > >> Thanks, >> Vladimir > > On 11/22/13 6:41 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I prepared a webrev for the trap based checks feature used on PPC: >> http://cr.openjdk.java.net/~goetz/webrevs/8029015-0-trch/ >> >> PPC has the tdi instruction that does a compare and raises SIGTRAP >> if the compare is successful. >> With this instruction conditional branches leading to uncommon >> traps can be implemented very efficiently. >> This is especially needed on AIX, where there are almost no >> possibilities for ImplicitNullChecks as the zero page is not >> protected. >> >> On linux, this accounts for about 2% jvm2008 performance. >> >> Possibilities for trap based range checks and trap based null checks >> are recognized during matching. To support this, we added a method >> branches_to_uncommon_trap() to be used in the predicate during >> matching. >> The computation of the final block layout must know about this, >> as it must place the fallthrough properly and adapt the condition >> in the tdi instruction. >> We added a method is_TrapBasedCheckNode so these nodes >> can be recogized in a platform independent way. >> >> Please review and test this change. >> >> Best regards, >> Goetz >> From david.holmes at oracle.com Mon Nov 25 16:42:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 10:42:59 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> <528E18F7.7050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> Message-ID: <5293EE93.8010406@oracle.com> Hi Goetz & Martin, On 25/11/2013 9:26 PM, Lindenmaier, Goetz wrote: > Hi David, > > I promised to comment on your concern about individual load/stores: >> As you state ld.acq and st.rel only >> relate to the target load/store _but_ there are no actions in the Java >> Memory Model that only provide ordering with respect to a single load or >> store! > We derive this from the well-known cookbook: > http://g.oswego.edu/dl/jmm/cookbook.html > Have a look at the table "required Barriers". > It talks about individual operations. E.g., imagine > Normal load 1 > Volatile load 2 > Normal load 3 > Then load1 may float arbitrarily to any place, but load3 may not > float above load2. > If I issue a 'wide' Acquire barriers after load2 (lwsync), this hinders load1 to > float below this barrier, introducing a constraint not specified by this > table. > > Does this satisfy your concerns? I was far too general in my comment re the JMM, I was thinking in terms of happens-before which is a transitive relation, and generalizing that to infer that all barriers have more far reaching affects that just the current load/store. But of course when you drill down into the actual requirements there are places where these more directed barriers are perfectly fine. Thanks, David > Best regards, > Goetz and Martin > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 21. November 2013 15:30 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi Goetz, > > On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> here the new webrev, naming the nodes LoadFence/StoreFence: >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ > > Okay. I think I now disagree (when seeing in context) that Membar should > have been dropped from the name but I'll let that lie. > > Aside: I find the descriptions of all those "membar" nodes very unclear > - it would be better, for me, if there were expressed more clearly in > terms of storeStore, storeLoad etc. > > Could you add to the comments in memnode.hpp that those nodes are only > used by the respective Unsafe intrinisics? Or at least use that as an > example usage? > >> The thing with the mail was my fault, I had sent the first mail >> only to you accidentially. Sorry for that. >> >>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >>> loads/stores - but with stronger semantics than just simple loadLoad or >>> storeStore barriers. >> Yes. I mean they do not intend to sort a single load/store with succeeding >> operations. This can not be implemented this way, as the operation >> is not known in the intrinsic. I mean cases where you can use ia64 ld.acq >> or ppc ld-twi-lwsync. > > If you are saying that loadFence and storeFence can not be implemented > using ld.acq and st.rel then good I agree with you. But I would argue > that general ld;MembarAcquire and st;MembarRelease can also not be > implemented with those instructions! As you state ld.acq and st.rel only > relate to the target load/store _but_ there are no actions in the Java > Memory Model that only provide ordering with respect to a single load or > store! The Unsafe *Ordered() operations may come closer to this but I > would expect them to be handled via an intrinsic - and they are outside > the JMM. So I would think the applicability of using ld.acq and st.rel > would be very limited, so it concerns me that it seems to be associated > with the very general MembarAcquire and MembarRelease nodes (ditto for > the changes in 8024921). > > But how you implement this is your concern. :) From the perspective of > this shared code my concern is that it is not clear exactly what the > practical distinction is between MembarAcquire and LoadFence, and > MembarRelease and StoreFence. I'm not a compiler person but I would find > it quite difficult to know which can/should be used when. And given for > most platforms they would be implemented the same, that would add to the > uncertainty (with a risk that someone will make an arbitrary choice). > > Thanks, > David > ----- > >>> Also I said that the Unsafe ops require bi-directional fences but that >>> was imprecise - the _load and _store ops only require two of the four >>> possible barriers which may be why you see these as distinct from the >>> membars associated directly with variable accesses ? >> On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. >> For the intrinsic I must use mf, which sorts _all_ previous loads with all >> following ld/st operations (and more). So my distinction is if I have a >> store on one processor, and a load on the other, and I want to make sure >> the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. >> If I did some arbitrary stores, and I want assure an other processor doing >> some arbitrary load,s then I must use - on ia64- mf on both. >> On sparc I can do a >> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); >> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); >> But, on sparc, there is no operation as ld.acq as far as I know. >> >> Change 8024921 enables to distinguish normal loads and such >> that should do ld.acq. This change enables the compiler to >> differentiate the MemBar nodes used better: such coming after >> a dedicated load, and such valid for any load before the barrier. >> This is already visible in the IR by some means: MemBars after >> dedicated loads have an input edge at position MemBar::precedence >> connecting them with the load, but that does not suffice to >> match it (in the matcher) correctly. >> If I use ld.acq, the following MemBarAcquire is superfluous, >> but the MemBarAcquire used in the intrinsic is not. So want to >> have different nodes. >> In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, >> and with #ifdef ia64 we use MemBarVolatile, as we know these operations will >> issue the proper assembly instructions. But this is bad - I want to do it better >> here. >> >>> Are you referring to generated code if these nodes are adjacent? If so I >>> assume the problem is that you can't logically coalesce these, even if >>> the actual generated code could be coalesced? >> Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire >> and Volatile with mf() if we would not use ld.acq/st.rel. Then there >> would be even more redundant operations. But that's out of scope of this change. >> >>> I still have this concern regarding the fact you think these are not >>> related to load/store operations. But I'll wait for the webrev. >> As stated above, yes, they are related to store/load operations. But not >> to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not >> part of the intrinsic. >> >> (I'm using the ia64 mnemonics in the implementation because I think >> they are nicely orthogonal. Also it's important to know that >> ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only >> the one load mentioned in the sequence. That's some hack in the >> processor.) >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. November 2013 21:06 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> First apologies that the email you replied to here didn't go to the >> lists. Due to the way it was filtered I assumed it was a direct email >> only. :) >> >> On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> thanks for the comprehensive explanation. That's in agreement with >>> what I understand. Except that I think, unidirectional barriers only >>> make sense if you have Acquire/Release operations dedicated to >>> a certain operation. Then other operations of the same kind can pass >>> the barrier in one direction. >>> >>> This also matches the extension I contributed to hotspot (8024921), >>> which now allows to issue such operations right along with the >>> loads/stores. >>> >>> This change here tries to separate the barriers used after load/stores from >>> the 'wide' or better 'fence' variants. >> >> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >> loads/stores - but with stronger semantics than just simple loadLoad or >> storeStore barriers. >> >>> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible >>> operations. Unfortunately, Hotspot knows only four of these: >>> MemBarStoreStore: S-S >> >> Okay - nice and clear. >> >>> MemBarAcquire: L-S, L-L >> >> I'm not sure what makes this "acquire" but this seems to be exactly what >> Unsafe.loadFence requires. >> >>> MemBarRelease: L-S, S-S >> >> Again I'm not sure what makes this "release" - I also find it odd that >> it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence >> needs. >> >>> MemBarVolatile: L-L, L-S, S-L, S-S >> >> A full fence, needed in the worst case when accessing a volatile variable. >> >> Also note that in different parts of the VM we have different >> expressions of these, both at the JIT level and runtime eg see >> orderAccess.hpp (which is not in itself self-consistent or clear: see >> https://bugs.openjdk.java.net/browse/JDK-7143664). >> >> Also I said that the Unsafe ops require bi-directional fences but that >> was imprecise - the _load and _store ops only require two of the four >> possible barriers which may be why you see these as distinct from the >> membars associated directly with variable accesses ? >> >>> and these don't map, e.g., the operations available on PPC: >>> lwsync: L-S, L-L, S-S >>> sync: L-L, L-S, S-L, S-S >>> What is the reason why it's hard for us to generate optimal code >>> with the available optimizations: >>> MemBarAcquire; >>> MemBarRelease; >>> are mapped to >>> lwsync >>> lwsync >>> which is obviously redundant. >> >> Are you referring to generated code if these nodes are adjacent? If so I >> assume the problem is that you can't logically coalesce these, even if >> the actual generated code could be coalesced? >> >>> A generic solution would be to have a single operation, that can be >>> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >>> Two operations could be merged by an optimization simply by >>> or-ing the tags. >>> But this is not reality in HotSpot, and out of scope of this change. >> >> Ok >> >>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>> Membar nodes for these unsafe ops (and only these) then name them to >>>> match the unsafe ops. At least then it is clearer where the >>>> specification for their behaviour comes from. >>> OK, so I'll rename them as Vladimir proposed, and post a new webrev. >> >> I still have this concern regarding the fact you think these are not >> related to load/store operations. But I'll wait for the webrev. >> >> Thanks for your patience on this. Hopefully we can sort it out in the >> next 24 hours before I takeoff. >> >> David >> ----- >> >>> Best regards and a good flight home, >>> Goetz. >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 20. November 2013 14:30 >>> To: Lindenmaier, Goetz >>> Cc: David Holmes >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> Hi Goetz, >>> >>> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> I don't know what you mean by uni/bi-directional. >>> >>> Pretty much as you describe below. A unidirectional barrier allows >>> things to cross in one direction only ie it blocks motion one way; a >>> bi-directional barrier ("full fence") blocks both ways and so prevents >>> any reordering. >>> >>> As I described in earlier emails these kind of unreferenced >>> acquire/release semantics ie not associated with any stores/loads is >>> used to describe the memory barrier properties of a synchronized block, >>> for example. Monitor acquisition has acquire semantics, while monitor >>> release has store semantics. The implied barriers mean that any accesses >>> can move into the synchronized region but none can move out - the "roach >>> motel" semantics. >>> >>> Now as you say this kind of barrier is not what is wanted with these >>> loadFence/storeFence operations, hence I think the generic >>> MembarAcquire/MembarRelease are inappropriate names (whether the >>> implementation is correct is a different matter). Similarly I find the >>> MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - >>> what do they mean ??? >>> >>> The loadFence semantics imply a loadLoad|loadStore barrier. >>> The storeFence semantics imply a storeLoad|storeStore barrier. >>> The fullFence is of course all four. >>> >>> Again I'm unclear if the current or proposed MembarXXX actions actually >>> map to barriers that implement those semantics. >>> >>> So yes this comes down to naming initially but also verification that >>> the implementation does as required. >>> >>> I think perhaps that Vladimir's suggestion is best - if these are the >>> Membar nodes for these unsafe ops (and only these) then name them to >>> match the unsafe ops. At least then it is clearer where the >>> specification for their behaviour comes from. >>> >>> I'll post a follow up email to the list when I get a chance. I'm >>> currently in the US and attending lots of meetings then head back to >>> Australia tomorrow evening. >>> >>> Thanks, >>> David >>> >>>> I guess we agree that the documentation of the intrinsics, let's take >>>> loadFence >>>> for an example, talks about loads before the loadFence, and stores and >>>> loads after it: >>>> loads >>>> ------------loadFence()-------------- >>>> loads, stores >>>> With this, you can achieve any ordering by moving nodes up OR down: >>>> Op1 Move Op1 Op2 >>>> Op2 down ------------- >>>> --------- =========> Op3 >>>> Op3 Op1 >>>> Alternatively, you can move op3 up, and get the same order: >>>> Op1 Reorder Op2 Move Op3 Op2 >>>> Op2 Ops 1 and 2 Op1 up Op3 >>>> --------- =========> -------------- =========> Op1 >>>> Op3 Not restricted Op3 ---------- >>>> by later loadFence >>>> So, if the operation restricts only moves in one direction, it's of no >>>> help because >>>> you can still get an execution order you did not expect. So >>>> unidirectional operations >>>> (e.g., only hindering operations from moving up) are pointless. >>>> By the way, are you questioning whether the implementation is correct, or >>>> whether the names express what is desired? >>>> If it's the first, it's of no concern to this change, which is only about >>>> matching these operations independently from those, that address >>>> a dedicated memory operation. >>>> If It's the second, please tell me what names to use, and I'll fix it. >>>> (I hope you can properly read the 'drawings') >>>> Best regards, >>>> Goetz. >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 19. November 2013 20:51 >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>> MemBarAcquire/ReleaseWide. >>>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>>> as shown below. So I guess that's just what is desired. >>>> I don't think so! What is described for Unsafe are full bi-directional >>>> fences and "acquire" and "release" are only uni-directional fences! >>>> David >>>> ----- >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> /** >>>>> * Ensures lack of reordering of loads before the fence >>>>> * with loads or stores after the fence. >>>>> * @since 1.8 >>>>> */ >>>>> public native void loadFence(); >>>>> >>>>> /** >>>>> * Ensures lack of reordering of stores before the fence >>>>> * with loads or stores after the fence. >>>>> * @since 1.8 >>>>> */ >>>>> public native void storeFence(); >>>>> >>>>> /** >>>>> * Ensures lack of reordering of loads or stores before the fence >>>>> * with loads or stores after the fence. >>>>> * @since 1.8 >>>>> */ >>>>> public native void fullFence(); >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> So I like the rename but I am concerned there are semantic issues here: >>>>> >>>>> switch(id) { >>>>> case vmIntrinsics::_loadFence: >>>>> - insert_mem_bar(Op_MemBarAcquire); >>>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>>> return true; >>>>> case vmIntrinsics::_storeFence: >>>>> - insert_mem_bar(Op_MemBarRelease); >>>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>>> return true; >>>>> >>>>> What is a _loadFence operation? Does it really map to >>>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>>> bi-directional fences - are they? Are they really only concerned with >>>>> loads or stores ? >>>>> >>>>> David >>>>> >>>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I made a new webrev, using the new names: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>>> >>>>>> Thanks, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Montag, 18. November 2013 23:28 >>>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>> >>>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, Vladimir, >>>>>>> >>>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>>> - the same prefix shows they are all similar nodes. >>>>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>>>> change yet and which is used in more places. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>>> To: Vladimir Kozlov >>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>> >>>>>>> Vladimir, >>>>>>> >>>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>>> I think David asked for different nodes not just one. >>>>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>>> >>>>>>> But I don't think that actually describes them - they don't distinguish >>>>>>> between loads and stores only the direction in which the barrier >>>>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>>>> only allows accesses to move above it ie: >>>>>>> >>>>>>> load a >>>>>>> store b, c >>>>>>> acquire(); >>>>>>> load d >>>>>>> store e,f >>>>>>> release(); >>>>>>> load g >>>>>>> store h, i >>>>>>> >>>>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>>>> the store to e can not move in relation to either acquire or release. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> as reply to your comment on the bug: >>>>>>>>> >>>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>>> MemBarVolatile --> sync. >>>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>>> >>>>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>>>> Therefore I think a really clean representation that, at the same >>>>>>>>> time, allows >>>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>>> processors, is impossible. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz >>>>>>>>> >>>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>>> or on the mailing lists? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>>> >>>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>>> Lindenmaier, Goetz >>>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>>>> >>>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>>>> matched differently, what is needed on PPC64. >>>>>>>>> >>>>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>>> >>>>>>>>> Please review and test this change. >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> From vladimir.kozlov at oracle.com Mon Nov 25 16:51:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 16:51:19 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> Message-ID: <5293F087.2080700@oracle.com> I have to ask David to do correctness evaluation. I am fine with suggested changes because you did not change our current code for our platforms (please, do not change do_exits() now). But may be it should be done using more general query which is set depending on platform: OrderAccess::needs_support_iriw_ordering() or similar to what we use now: VM_Version::needs_support_iriw_ordering() From what I understand our ppc port is also affected. David? In library_call.cpp can you add {}? New comment should be inside else {}. I think you should make _wrote_volatile field not ppc64 specific which will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() except in do_put_xxx() where it is set to true. Too many #ifdefs. In do_put_xxx() can you combine your changes: if (is_vol) { // See comment in do_get_xxx(). #ifndef PPC64 insert_mem_bar(Op_MemBarVolatile); // Use fat membar #else if (is_field) { // Add MemBarRelease for constructors which write volatile field (PPC64). set_wrote_volatile(true); } #endif } Thanks, Vladimir On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: > Hi, > > I preprared a webrev with fixes for PPC for the VolatileIRIWTest of the torture test suite: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ > > Example: > volatile x=0, y=0 > __________ __________ __________ __________ > | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | > > write(x=1) read(x) write(y=1) read(y) > read(y) read(x) > > Disallowed: x=1, y=0 y=1, x=0 > > > Solution: This example requires multiple-copy-atomicity. This is only > assured by the sync instruction and if it is executed in the threads > doing the loads. Thus we implement volatile read as sync-load-acquire > and omit the sync/MemBarVolatile after the volatile store. > MemBarVolatile happens to be implemented by sync. > We fix this in C2 and the cpp interpreter. > > This addresses a similar issue as fix "8012144: multiple SIGSEGVs > fails on staxf" for taskqueue.hpp. > > Further this change contains a fix that assures that volatile fields > written in constructors are visible before the reference gets > published. > > > Looking at the code, we found a MemBarRelease that to us, seems too strong. > We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. > What do you think? > > Please review and test this change. > > Best regards, > Goetz. > From vitalyd at gmail.com Mon Nov 25 17:12:38 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 25 Nov 2013 20:12:38 -0500 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> Message-ID: Hi Goetz, Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; this guarantee only applies to final fields and StoreStore (in JMM parlance) before ref assignment should be sufficient. Of course making the implementation stronger is probably ok, but just wanted to point that out as there seem to be changes aimed at this, as you say. The reason volatile is excluded is because the ref assignment following the volatile store is a plain one, and plain stores can move before volatile stores (but not the other way, of course). So only final fields get this special treatment; if someone is unsafely publishing a ref and assumes the volatile store in constructor is sufficient, they're mistaken :). Thanks Sent from my phone On Nov 25, 2013 11:17 AM, "Lindenmaier, Goetz" wrote: > Hi, > > I preprared a webrev with fixes for PPC for the VolatileIRIWTest of the > torture test suite: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ > > Example: > volatile x=0, y=0 > __________ __________ __________ __________ > | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | > > write(x=1) read(x) write(y=1) read(y) > read(y) read(x) > > Disallowed: x=1, y=0 y=1, x=0 > > > Solution: This example requires multiple-copy-atomicity. This is only > assured by the sync instruction and if it is executed in the threads > doing the loads. Thus we implement volatile read as sync-load-acquire > and omit the sync/MemBarVolatile after the volatile store. > MemBarVolatile happens to be implemented by sync. > We fix this in C2 and the cpp interpreter. > > This addresses a similar issue as fix "8012144: multiple SIGSEGVs > fails on staxf" for taskqueue.hpp. > > Further this change contains a fix that assures that volatile fields > written in constructors are visible before the reference gets > published. > > > Looking at the code, we found a MemBarRelease that to us, seems too strong. > We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. > What do you think? > > Please review and test this change. > > Best regards, > Goetz. > From john.r.rose at oracle.com Mon Nov 25 17:29:22 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Nov 2013 17:29:22 -0800 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: On Nov 25, 2013, at 1:49 AM, Paul Sandoz wrote: > Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? Unsafe is used everywhere, including from some of the preloaded classes. Thus it will be preloaded even if it is not on the JVM's preload list, so there's no harm in naming it this way from the JVM. And thus we get to the Naming Question... As a class, Unsafe is a stable, non-public name space, and is (unusually) tightly coupled to the JVM. It has no other qualifications specific to this new use. We don't already have "sun.misc.InternalMethods", but it's not something we want to invent, just for this method. David has noted that introducing a new class would complicate backporting. ? John From david.holmes at oracle.com Mon Nov 25 17:49:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 11:49:09 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <5293F087.2080700@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> Message-ID: <5293FE15.9050100@oracle.com> Okay this is my second attempt at answering this in a reasonable way :) On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: > I have to ask David to do correctness evaluation. From what I understand what we see here is an attempt to fix an existing issue with the implementation of volatiles so that the IRIW problem is addressed. The solution proposed for PPC64 is to make volatile reads extremely heavyweight by adding a fence() when doing the load. Now if this was purely handled in ppc64 source code then I would be happy to let them do whatever they like (surely this kills performance though!). But I do not agree with the changes to the shared code that allow this solution to be implemented - even with PPC64_ONLY this is polluting the shared code. My concern is similar to what I said with the taskQueue changes - these algorithms should be expressed using the correct OrderAccess operations to guarantee the desired properties independent of architecture. If such a "barrier" is not needed on a given architecture then the implementation in OrderAccess should reduce to a no-op. And as Vitaly points out the constructor barriers are not needed under the JMM. > I am fine with suggested changes because you did not change our current > code for our platforms (please, do not change do_exits() now). > But may be it should be done using more general query which is set > depending on platform: > > OrderAccess::needs_support_iriw_ordering() > > or similar to what we use now: > > VM_Version::needs_support_iriw_ordering() Every platform has to support IRIW this is simply part of the Java Memory Model, there should not be any need to call this out explicitly like this. Is there some subtlety of the hardware I am missing here? Are there visibility issues beyond the ordering constraints that the JMM defines? > From what I understand our ppc port is also affected. David? We can not discuss that on an OpenJDK mailing list - sorry. David ----- > In library_call.cpp can you add {}? New comment should be inside else {}. > > I think you should make _wrote_volatile field not ppc64 specific which > will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() > except in do_put_xxx() where it is set to true. Too many #ifdefs. > > In do_put_xxx() can you combine your changes: > > if (is_vol) { > // See comment in do_get_xxx(). > #ifndef PPC64 > insert_mem_bar(Op_MemBarVolatile); // Use fat membar > #else > if (is_field) { > // Add MemBarRelease for constructors which write volatile field > (PPC64). > set_wrote_volatile(true); > } > #endif > } > > Thanks, > Vladimir > > On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >> the torture test suite: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >> >> Example: >> volatile x=0, y=0 >> __________ __________ __________ __________ >> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >> >> write(x=1) read(x) write(y=1) read(y) >> read(y) read(x) >> >> Disallowed: x=1, y=0 y=1, x=0 >> >> >> Solution: This example requires multiple-copy-atomicity. This is only >> assured by the sync instruction and if it is executed in the threads >> doing the loads. Thus we implement volatile read as sync-load-acquire >> and omit the sync/MemBarVolatile after the volatile store. >> MemBarVolatile happens to be implemented by sync. >> We fix this in C2 and the cpp interpreter. >> >> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >> fails on staxf" for taskqueue.hpp. >> >> Further this change contains a fix that assures that volatile fields >> written in constructors are visible before the reference gets >> published. >> >> >> Looking at the code, we found a MemBarRelease that to us, seems too >> strong. >> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >> What do you think? >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> From david.holmes at oracle.com Mon Nov 25 18:18:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 12:18:59 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> Message-ID: <52940513.6010503@oracle.com> On 26/11/2013 11:29 AM, John Rose wrote: > On Nov 25, 2013, at 1:49 AM, Paul Sandoz wrote: > >> Just curious: why did you chose to add the method, throwIllegalAccessError, to s.m.Unsafe and add Unsafe to the list pre-loaded classes rather than modifying an existing pre-loaded class? > > Unsafe is used everywhere, including from some of the preloaded classes. Thus it will be preloaded even if it is not on the JVM's preload list, so there's no harm in naming it this way from the JVM. Not quite. Unsafe is needed during system class initialization, but it is not needed during class pre-loading. So this change will be loading it earlier, but that is harmless AFAICS. Non of the other pre-loaded classes are really suitable in any case. > And thus we get to the Naming Question... > > As a class, Unsafe is a stable, non-public name space, and is (unusually) tightly coupled to the JVM. It has no other qualifications specific to this new use. > > We don't already have "sun.misc.InternalMethods", but it's not something we want to invent, just for this method. David has noted that introducing a new class would complicate backporting. We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? Overall this approach kind of makes me cringe anyway. Cheers, David H. > ? John > From goetz.lindenmaier at sap.com Mon Nov 25 23:24:31 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Nov 2013 07:24:31 +0000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <5293EE93.8010406@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> <528E18F7.7050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> <5293EE93.8010406@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6A0AE@DEWDFEMB12B.global.corp.sap> Hi David, OK, thank you! Do you think this change can be pushed now? Which naming would you prefer, finally? http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide MemBarFenceAcquire http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide loadFence Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, November 26, 2013 1:43 AM To: Lindenmaier, Goetz Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. Hi Goetz & Martin, On 25/11/2013 9:26 PM, Lindenmaier, Goetz wrote: > Hi David, > > I promised to comment on your concern about individual load/stores: >> As you state ld.acq and st.rel only >> relate to the target load/store _but_ there are no actions in the Java >> Memory Model that only provide ordering with respect to a single load or >> store! > We derive this from the well-known cookbook: > http://g.oswego.edu/dl/jmm/cookbook.html > Have a look at the table "required Barriers". > It talks about individual operations. E.g., imagine > Normal load 1 > Volatile load 2 > Normal load 3 > Then load1 may float arbitrarily to any place, but load3 may not > float above load2. > If I issue a 'wide' Acquire barriers after load2 (lwsync), this hinders load1 to > float below this barrier, introducing a constraint not specified by this > table. > > Does this satisfy your concerns? I was far too general in my comment re the JMM, I was thinking in terms of happens-before which is a transitive relation, and generalizing that to infer that all barriers have more far reaching affects that just the current load/store. But of course when you drill down into the actual requirements there are places where these more directed barriers are perfectly fine. Thanks, David > Best regards, > Goetz and Martin > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 21. November 2013 15:30 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi Goetz, > > On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> here the new webrev, naming the nodes LoadFence/StoreFence: >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ > > Okay. I think I now disagree (when seeing in context) that Membar should > have been dropped from the name but I'll let that lie. > > Aside: I find the descriptions of all those "membar" nodes very unclear > - it would be better, for me, if there were expressed more clearly in > terms of storeStore, storeLoad etc. > > Could you add to the comments in memnode.hpp that those nodes are only > used by the respective Unsafe intrinisics? Or at least use that as an > example usage? > >> The thing with the mail was my fault, I had sent the first mail >> only to you accidentially. Sorry for that. >> >>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >>> loads/stores - but with stronger semantics than just simple loadLoad or >>> storeStore barriers. >> Yes. I mean they do not intend to sort a single load/store with succeeding >> operations. This can not be implemented this way, as the operation >> is not known in the intrinsic. I mean cases where you can use ia64 ld.acq >> or ppc ld-twi-lwsync. > > If you are saying that loadFence and storeFence can not be implemented > using ld.acq and st.rel then good I agree with you. But I would argue > that general ld;MembarAcquire and st;MembarRelease can also not be > implemented with those instructions! As you state ld.acq and st.rel only > relate to the target load/store _but_ there are no actions in the Java > Memory Model that only provide ordering with respect to a single load or > store! The Unsafe *Ordered() operations may come closer to this but I > would expect them to be handled via an intrinsic - and they are outside > the JMM. So I would think the applicability of using ld.acq and st.rel > would be very limited, so it concerns me that it seems to be associated > with the very general MembarAcquire and MembarRelease nodes (ditto for > the changes in 8024921). > > But how you implement this is your concern. :) From the perspective of > this shared code my concern is that it is not clear exactly what the > practical distinction is between MembarAcquire and LoadFence, and > MembarRelease and StoreFence. I'm not a compiler person but I would find > it quite difficult to know which can/should be used when. And given for > most platforms they would be implemented the same, that would add to the > uncertainty (with a risk that someone will make an arbitrary choice). > > Thanks, > David > ----- > >>> Also I said that the Unsafe ops require bi-directional fences but that >>> was imprecise - the _load and _store ops only require two of the four >>> possible barriers which may be why you see these as distinct from the >>> membars associated directly with variable accesses ? >> On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. >> For the intrinsic I must use mf, which sorts _all_ previous loads with all >> following ld/st operations (and more). So my distinction is if I have a >> store on one processor, and a load on the other, and I want to make sure >> the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. >> If I did some arbitrary stores, and I want assure an other processor doing >> some arbitrary load,s then I must use - on ia64- mf on both. >> On sparc I can do a >> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); >> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); >> But, on sparc, there is no operation as ld.acq as far as I know. >> >> Change 8024921 enables to distinguish normal loads and such >> that should do ld.acq. This change enables the compiler to >> differentiate the MemBar nodes used better: such coming after >> a dedicated load, and such valid for any load before the barrier. >> This is already visible in the IR by some means: MemBars after >> dedicated loads have an input edge at position MemBar::precedence >> connecting them with the load, but that does not suffice to >> match it (in the matcher) correctly. >> If I use ld.acq, the following MemBarAcquire is superfluous, >> but the MemBarAcquire used in the intrinsic is not. So want to >> have different nodes. >> In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, >> and with #ifdef ia64 we use MemBarVolatile, as we know these operations will >> issue the proper assembly instructions. But this is bad - I want to do it better >> here. >> >>> Are you referring to generated code if these nodes are adjacent? If so I >>> assume the problem is that you can't logically coalesce these, even if >>> the actual generated code could be coalesced? >> Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire >> and Volatile with mf() if we would not use ld.acq/st.rel. Then there >> would be even more redundant operations. But that's out of scope of this change. >> >>> I still have this concern regarding the fact you think these are not >>> related to load/store operations. But I'll wait for the webrev. >> As stated above, yes, they are related to store/load operations. But not >> to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not >> part of the intrinsic. >> >> (I'm using the ia64 mnemonics in the implementation because I think >> they are nicely orthogonal. Also it's important to know that >> ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only >> the one load mentioned in the sequence. That's some hack in the >> processor.) >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 20. November 2013 21:06 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> First apologies that the email you replied to here didn't go to the >> lists. Due to the way it was filtered I assumed it was a direct email >> only. :) >> >> On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> thanks for the comprehensive explanation. That's in agreement with >>> what I understand. Except that I think, unidirectional barriers only >>> make sense if you have Acquire/Release operations dedicated to >>> a certain operation. Then other operations of the same kind can pass >>> the barrier in one direction. >>> >>> This also matches the extension I contributed to hotspot (8024921), >>> which now allows to issue such operations right along with the >>> loads/stores. >>> >>> This change here tries to separate the barriers used after load/stores from >>> the 'wide' or better 'fence' variants. >> >> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >> loads/stores - but with stronger semantics than just simple loadLoad or >> storeStore barriers. >> >>> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible >>> operations. Unfortunately, Hotspot knows only four of these: >>> MemBarStoreStore: S-S >> >> Okay - nice and clear. >> >>> MemBarAcquire: L-S, L-L >> >> I'm not sure what makes this "acquire" but this seems to be exactly what >> Unsafe.loadFence requires. >> >>> MemBarRelease: L-S, S-S >> >> Again I'm not sure what makes this "release" - I also find it odd that >> it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence >> needs. >> >>> MemBarVolatile: L-L, L-S, S-L, S-S >> >> A full fence, needed in the worst case when accessing a volatile variable. >> >> Also note that in different parts of the VM we have different >> expressions of these, both at the JIT level and runtime eg see >> orderAccess.hpp (which is not in itself self-consistent or clear: see >> https://bugs.openjdk.java.net/browse/JDK-7143664). >> >> Also I said that the Unsafe ops require bi-directional fences but that >> was imprecise - the _load and _store ops only require two of the four >> possible barriers which may be why you see these as distinct from the >> membars associated directly with variable accesses ? >> >>> and these don't map, e.g., the operations available on PPC: >>> lwsync: L-S, L-L, S-S >>> sync: L-L, L-S, S-L, S-S >>> What is the reason why it's hard for us to generate optimal code >>> with the available optimizations: >>> MemBarAcquire; >>> MemBarRelease; >>> are mapped to >>> lwsync >>> lwsync >>> which is obviously redundant. >> >> Are you referring to generated code if these nodes are adjacent? If so I >> assume the problem is that you can't logically coalesce these, even if >> the actual generated code could be coalesced? >> >>> A generic solution would be to have a single operation, that can be >>> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >>> Two operations could be merged by an optimization simply by >>> or-ing the tags. >>> But this is not reality in HotSpot, and out of scope of this change. >> >> Ok >> >>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>> Membar nodes for these unsafe ops (and only these) then name them to >>>> match the unsafe ops. At least then it is clearer where the >>>> specification for their behaviour comes from. >>> OK, so I'll rename them as Vladimir proposed, and post a new webrev. >> >> I still have this concern regarding the fact you think these are not >> related to load/store operations. But I'll wait for the webrev. >> >> Thanks for your patience on this. Hopefully we can sort it out in the >> next 24 hours before I takeoff. >> >> David >> ----- >> >>> Best regards and a good flight home, >>> Goetz. >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 20. November 2013 14:30 >>> To: Lindenmaier, Goetz >>> Cc: David Holmes >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> Hi Goetz, >>> >>> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> I don't know what you mean by uni/bi-directional. >>> >>> Pretty much as you describe below. A unidirectional barrier allows >>> things to cross in one direction only ie it blocks motion one way; a >>> bi-directional barrier ("full fence") blocks both ways and so prevents >>> any reordering. >>> >>> As I described in earlier emails these kind of unreferenced >>> acquire/release semantics ie not associated with any stores/loads is >>> used to describe the memory barrier properties of a synchronized block, >>> for example. Monitor acquisition has acquire semantics, while monitor >>> release has store semantics. The implied barriers mean that any accesses >>> can move into the synchronized region but none can move out - the "roach >>> motel" semantics. >>> >>> Now as you say this kind of barrier is not what is wanted with these >>> loadFence/storeFence operations, hence I think the generic >>> MembarAcquire/MembarRelease are inappropriate names (whether the >>> implementation is correct is a different matter). Similarly I find the >>> MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - >>> what do they mean ??? >>> >>> The loadFence semantics imply a loadLoad|loadStore barrier. >>> The storeFence semantics imply a storeLoad|storeStore barrier. >>> The fullFence is of course all four. >>> >>> Again I'm unclear if the current or proposed MembarXXX actions actually >>> map to barriers that implement those semantics. >>> >>> So yes this comes down to naming initially but also verification that >>> the implementation does as required. >>> >>> I think perhaps that Vladimir's suggestion is best - if these are the >>> Membar nodes for these unsafe ops (and only these) then name them to >>> match the unsafe ops. At least then it is clearer where the >>> specification for their behaviour comes from. >>> >>> I'll post a follow up email to the list when I get a chance. I'm >>> currently in the US and attending lots of meetings then head back to >>> Australia tomorrow evening. >>> >>> Thanks, >>> David >>> >>>> I guess we agree that the documentation of the intrinsics, let's take >>>> loadFence >>>> for an example, talks about loads before the loadFence, and stores and >>>> loads after it: >>>> loads >>>> ------------loadFence()-------------- >>>> loads, stores >>>> With this, you can achieve any ordering by moving nodes up OR down: >>>> Op1 Move Op1 Op2 >>>> Op2 down ------------- >>>> --------- =========> Op3 >>>> Op3 Op1 >>>> Alternatively, you can move op3 up, and get the same order: >>>> Op1 Reorder Op2 Move Op3 Op2 >>>> Op2 Ops 1 and 2 Op1 up Op3 >>>> --------- =========> -------------- =========> Op1 >>>> Op3 Not restricted Op3 ---------- >>>> by later loadFence >>>> So, if the operation restricts only moves in one direction, it's of no >>>> help because >>>> you can still get an execution order you did not expect. So >>>> unidirectional operations >>>> (e.g., only hindering operations from moving up) are pointless. >>>> By the way, are you questioning whether the implementation is correct, or >>>> whether the names express what is desired? >>>> If it's the first, it's of no concern to this change, which is only about >>>> matching these operations independently from those, that address >>>> a dedicated memory operation. >>>> If It's the second, please tell me what names to use, and I'll fix it. >>>> (I hope you can properly read the 'drawings') >>>> Best regards, >>>> Goetz. >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Dienstag, 19. November 2013 20:51 >>>> To: Lindenmaier, Goetz >>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>> 'hotspot-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>> MemBarAcquire/ReleaseWide. >>>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>>> as shown below. So I guess that's just what is desired. >>>> I don't think so! What is described for Unsafe are full bi-directional >>>> fences and "acquire" and "release" are only uni-directional fences! >>>> David >>>> ----- >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> /** >>>>> * Ensures lack of reordering of loads before the fence >>>>> * with loads or stores after the fence. >>>>> * @since 1.8 >>>>> */ >>>>> public native void loadFence(); >>>>> >>>>> /** >>>>> * Ensures lack of reordering of stores before the fence >>>>> * with loads or stores after the fence. >>>>> * @since 1.8 >>>>> */ >>>>> public native void storeFence(); >>>>> >>>>> /** >>>>> * Ensures lack of reordering of loads or stores before the fence >>>>> * with loads or stores after the fence. >>>>> * @since 1.8 >>>>> */ >>>>> public native void fullFence(); >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>>> To: Lindenmaier, Goetz >>>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> So I like the rename but I am concerned there are semantic issues here: >>>>> >>>>> switch(id) { >>>>> case vmIntrinsics::_loadFence: >>>>> - insert_mem_bar(Op_MemBarAcquire); >>>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>>> return true; >>>>> case vmIntrinsics::_storeFence: >>>>> - insert_mem_bar(Op_MemBarRelease); >>>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>>> return true; >>>>> >>>>> What is a _loadFence operation? Does it really map to >>>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>>> bi-directional fences - are they? Are they really only concerned with >>>>> loads or stores ? >>>>> >>>>> David >>>>> >>>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I made a new webrev, using the new names: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>>> >>>>>> Thanks, >>>>>> Goetz. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>> Sent: Montag, 18. November 2013 23:28 >>>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>> >>>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, Vladimir, >>>>>>> >>>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>>> - the same prefix shows they are all similar nodes. >>>>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>>>> change yet and which is used in more places. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>>> To: Vladimir Kozlov >>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>> >>>>>>> Vladimir, >>>>>>> >>>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>>> I think David asked for different nodes not just one. >>>>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>>> >>>>>>> But I don't think that actually describes them - they don't distinguish >>>>>>> between loads and stores only the direction in which the barrier >>>>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>>>> only allows accesses to move above it ie: >>>>>>> >>>>>>> load a >>>>>>> store b, c >>>>>>> acquire(); >>>>>>> load d >>>>>>> store e,f >>>>>>> release(); >>>>>>> load g >>>>>>> store h, i >>>>>>> >>>>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>>>> the store to e can not move in relation to either acquire or release. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> as reply to your comment on the bug: >>>>>>>>> >>>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>>> MemBarVolatile --> sync. >>>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>>> >>>>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>>>> Therefore I think a really clean representation that, at the same >>>>>>>>> time, allows >>>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>>> processors, is impossible. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz >>>>>>>>> >>>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>>> or on the mailing lists? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>>> >>>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>>> Lindenmaier, Goetz >>>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>>>> >>>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>>>> matched differently, what is needed on PPC64. >>>>>>>>> >>>>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>>> >>>>>>>>> Please review and test this change. >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> From david.holmes at oracle.com Mon Nov 25 23:29:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 17:29:13 +1000 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6A0AE@DEWDFEMB12B.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CE66AB3@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> <528E18F7.7050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> <5293EE93.8010406@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6A0AE@DEWDFEMB12B.global.corp.sap> Message-ID: <52944DC9.3050305@oracle.com> On 26/11/2013 5:24 PM, Lindenmaier, Goetz wrote: > Hi David, > > OK, thank you! > > Do you think this change can be pushed now? I think so. > Which naming would you prefer, finally? > http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide MemBarFenceAcquire > http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide loadFence loadFence out of those two choices, but I'll leave that to Vladimir to confirm. Thanks, David > Best regards, > Goetz. > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 26, 2013 1:43 AM > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. > > Hi Goetz & Martin, > > On 25/11/2013 9:26 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I promised to comment on your concern about individual load/stores: >>> As you state ld.acq and st.rel only >>> relate to the target load/store _but_ there are no actions in the Java >>> Memory Model that only provide ordering with respect to a single load or >>> store! >> We derive this from the well-known cookbook: >> http://g.oswego.edu/dl/jmm/cookbook.html >> Have a look at the table "required Barriers". >> It talks about individual operations. E.g., imagine >> Normal load 1 >> Volatile load 2 >> Normal load 3 >> Then load1 may float arbitrarily to any place, but load3 may not >> float above load2. >> If I issue a 'wide' Acquire barriers after load2 (lwsync), this hinders load1 to >> float below this barrier, introducing a constraint not specified by this >> table. >> >> Does this satisfy your concerns? > > I was far too general in my comment re the JMM, I was thinking in terms > of happens-before which is a transitive relation, and generalizing that > to infer that all barriers have more far reaching affects that just the > current load/store. But of course when you drill down into the actual > requirements there are places where these more directed barriers are > perfectly fine. > > Thanks, > David > >> Best regards, >> Goetz and Martin >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 21. November 2013 15:30 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> Hi Goetz, >> >> On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> here the new webrev, naming the nodes LoadFence/StoreFence: >>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ >> >> Okay. I think I now disagree (when seeing in context) that Membar should >> have been dropped from the name but I'll let that lie. >> >> Aside: I find the descriptions of all those "membar" nodes very unclear >> - it would be better, for me, if there were expressed more clearly in >> terms of storeStore, storeLoad etc. >> >> Could you add to the comments in memnode.hpp that those nodes are only >> used by the respective Unsafe intrinisics? Or at least use that as an >> example usage? >> >>> The thing with the mail was my fault, I had sent the first mail >>> only to you accidentially. Sorry for that. >>> >>>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >>>> loads/stores - but with stronger semantics than just simple loadLoad or >>>> storeStore barriers. >>> Yes. I mean they do not intend to sort a single load/store with succeeding >>> operations. This can not be implemented this way, as the operation >>> is not known in the intrinsic. I mean cases where you can use ia64 ld.acq >>> or ppc ld-twi-lwsync. >> >> If you are saying that loadFence and storeFence can not be implemented >> using ld.acq and st.rel then good I agree with you. But I would argue >> that general ld;MembarAcquire and st;MembarRelease can also not be >> implemented with those instructions! As you state ld.acq and st.rel only >> relate to the target load/store _but_ there are no actions in the Java >> Memory Model that only provide ordering with respect to a single load or >> store! The Unsafe *Ordered() operations may come closer to this but I >> would expect them to be handled via an intrinsic - and they are outside >> the JMM. So I would think the applicability of using ld.acq and st.rel >> would be very limited, so it concerns me that it seems to be associated >> with the very general MembarAcquire and MembarRelease nodes (ditto for >> the changes in 8024921). >> >> But how you implement this is your concern. :) From the perspective of >> this shared code my concern is that it is not clear exactly what the >> practical distinction is between MembarAcquire and LoadFence, and >> MembarRelease and StoreFence. I'm not a compiler person but I would find >> it quite difficult to know which can/should be used when. And given for >> most platforms they would be implemented the same, that would add to the >> uncertainty (with a risk that someone will make an arbitrary choice). >> >> Thanks, >> David >> ----- >> >>>> Also I said that the Unsafe ops require bi-directional fences but that >>>> was imprecise - the _load and _store ops only require two of the four >>>> possible barriers which may be why you see these as distinct from the >>>> membars associated directly with variable accesses ? >>> On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. >>> For the intrinsic I must use mf, which sorts _all_ previous loads with all >>> following ld/st operations (and more). So my distinction is if I have a >>> store on one processor, and a load on the other, and I want to make sure >>> the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. >>> If I did some arbitrary stores, and I want assure an other processor doing >>> some arbitrary load,s then I must use - on ia64- mf on both. >>> On sparc I can do a >>> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); >>> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); >>> But, on sparc, there is no operation as ld.acq as far as I know. >>> >>> Change 8024921 enables to distinguish normal loads and such >>> that should do ld.acq. This change enables the compiler to >>> differentiate the MemBar nodes used better: such coming after >>> a dedicated load, and such valid for any load before the barrier. >>> This is already visible in the IR by some means: MemBars after >>> dedicated loads have an input edge at position MemBar::precedence >>> connecting them with the load, but that does not suffice to >>> match it (in the matcher) correctly. >>> If I use ld.acq, the following MemBarAcquire is superfluous, >>> but the MemBarAcquire used in the intrinsic is not. So want to >>> have different nodes. >>> In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, >>> and with #ifdef ia64 we use MemBarVolatile, as we know these operations will >>> issue the proper assembly instructions. But this is bad - I want to do it better >>> here. >>> >>>> Are you referring to generated code if these nodes are adjacent? If so I >>>> assume the problem is that you can't logically coalesce these, even if >>>> the actual generated code could be coalesced? >>> Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire >>> and Volatile with mf() if we would not use ld.acq/st.rel. Then there >>> would be even more redundant operations. But that's out of scope of this change. >>> >>>> I still have this concern regarding the fact you think these are not >>>> related to load/store operations. But I'll wait for the webrev. >>> As stated above, yes, they are related to store/load operations. But not >>> to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not >>> part of the intrinsic. >>> >>> (I'm using the ia64 mnemonics in the implementation because I think >>> they are nicely orthogonal. Also it's important to know that >>> ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only >>> the one load mentioned in the sequence. That's some hack in the >>> processor.) >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Mittwoch, 20. November 2013 21:06 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> First apologies that the email you replied to here didn't go to the >>> lists. Due to the way it was filtered I assumed it was a direct email >>> only. :) >>> >>> On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> thanks for the comprehensive explanation. That's in agreement with >>>> what I understand. Except that I think, unidirectional barriers only >>>> make sense if you have Acquire/Release operations dedicated to >>>> a certain operation. Then other operations of the same kind can pass >>>> the barrier in one direction. >>>> >>>> This also matches the extension I contributed to hotspot (8024921), >>>> which now allows to issue such operations right along with the >>>> loads/stores. >>>> >>>> This change here tries to separate the barriers used after load/stores from >>>> the 'wide' or better 'fence' variants. >>> >>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >>> loads/stores - but with stronger semantics than just simple loadLoad or >>> storeStore barriers. >>> >>>> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible >>>> operations. Unfortunately, Hotspot knows only four of these: >>>> MemBarStoreStore: S-S >>> >>> Okay - nice and clear. >>> >>>> MemBarAcquire: L-S, L-L >>> >>> I'm not sure what makes this "acquire" but this seems to be exactly what >>> Unsafe.loadFence requires. >>> >>>> MemBarRelease: L-S, S-S >>> >>> Again I'm not sure what makes this "release" - I also find it odd that >>> it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence >>> needs. >>> >>>> MemBarVolatile: L-L, L-S, S-L, S-S >>> >>> A full fence, needed in the worst case when accessing a volatile variable. >>> >>> Also note that in different parts of the VM we have different >>> expressions of these, both at the JIT level and runtime eg see >>> orderAccess.hpp (which is not in itself self-consistent or clear: see >>> https://bugs.openjdk.java.net/browse/JDK-7143664). >>> >>> Also I said that the Unsafe ops require bi-directional fences but that >>> was imprecise - the _load and _store ops only require two of the four >>> possible barriers which may be why you see these as distinct from the >>> membars associated directly with variable accesses ? >>> >>>> and these don't map, e.g., the operations available on PPC: >>>> lwsync: L-S, L-L, S-S >>>> sync: L-L, L-S, S-L, S-S >>>> What is the reason why it's hard for us to generate optimal code >>>> with the available optimizations: >>>> MemBarAcquire; >>>> MemBarRelease; >>>> are mapped to >>>> lwsync >>>> lwsync >>>> which is obviously redundant. >>> >>> Are you referring to generated code if these nodes are adjacent? If so I >>> assume the problem is that you can't logically coalesce these, even if >>> the actual generated code could be coalesced? >>> >>>> A generic solution would be to have a single operation, that can be >>>> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >>>> Two operations could be merged by an optimization simply by >>>> or-ing the tags. >>>> But this is not reality in HotSpot, and out of scope of this change. >>> >>> Ok >>> >>>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>>> Membar nodes for these unsafe ops (and only these) then name them to >>>>> match the unsafe ops. At least then it is clearer where the >>>>> specification for their behaviour comes from. >>>> OK, so I'll rename them as Vladimir proposed, and post a new webrev. >>> >>> I still have this concern regarding the fact you think these are not >>> related to load/store operations. But I'll wait for the webrev. >>> >>> Thanks for your patience on this. Hopefully we can sort it out in the >>> next 24 hours before I takeoff. >>> >>> David >>> ----- >>> >>>> Best regards and a good flight home, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 20. November 2013 14:30 >>>> To: Lindenmaier, Goetz >>>> Cc: David Holmes >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> Hi Goetz, >>>> >>>> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> I don't know what you mean by uni/bi-directional. >>>> >>>> Pretty much as you describe below. A unidirectional barrier allows >>>> things to cross in one direction only ie it blocks motion one way; a >>>> bi-directional barrier ("full fence") blocks both ways and so prevents >>>> any reordering. >>>> >>>> As I described in earlier emails these kind of unreferenced >>>> acquire/release semantics ie not associated with any stores/loads is >>>> used to describe the memory barrier properties of a synchronized block, >>>> for example. Monitor acquisition has acquire semantics, while monitor >>>> release has store semantics. The implied barriers mean that any accesses >>>> can move into the synchronized region but none can move out - the "roach >>>> motel" semantics. >>>> >>>> Now as you say this kind of barrier is not what is wanted with these >>>> loadFence/storeFence operations, hence I think the generic >>>> MembarAcquire/MembarRelease are inappropriate names (whether the >>>> implementation is correct is a different matter). Similarly I find the >>>> MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - >>>> what do they mean ??? >>>> >>>> The loadFence semantics imply a loadLoad|loadStore barrier. >>>> The storeFence semantics imply a storeLoad|storeStore barrier. >>>> The fullFence is of course all four. >>>> >>>> Again I'm unclear if the current or proposed MembarXXX actions actually >>>> map to barriers that implement those semantics. >>>> >>>> So yes this comes down to naming initially but also verification that >>>> the implementation does as required. >>>> >>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>> Membar nodes for these unsafe ops (and only these) then name them to >>>> match the unsafe ops. At least then it is clearer where the >>>> specification for their behaviour comes from. >>>> >>>> I'll post a follow up email to the list when I get a chance. I'm >>>> currently in the US and attending lots of meetings then head back to >>>> Australia tomorrow evening. >>>> >>>> Thanks, >>>> David >>>> >>>>> I guess we agree that the documentation of the intrinsics, let's take >>>>> loadFence >>>>> for an example, talks about loads before the loadFence, and stores and >>>>> loads after it: >>>>> loads >>>>> ------------loadFence()-------------- >>>>> loads, stores >>>>> With this, you can achieve any ordering by moving nodes up OR down: >>>>> Op1 Move Op1 Op2 >>>>> Op2 down ------------- >>>>> --------- =========> Op3 >>>>> Op3 Op1 >>>>> Alternatively, you can move op3 up, and get the same order: >>>>> Op1 Reorder Op2 Move Op3 Op2 >>>>> Op2 Ops 1 and 2 Op1 up Op3 >>>>> --------- =========> -------------- =========> Op1 >>>>> Op3 Not restricted Op3 ---------- >>>>> by later loadFence >>>>> So, if the operation restricts only moves in one direction, it's of no >>>>> help because >>>>> you can still get an execution order you did not expect. So >>>>> unidirectional operations >>>>> (e.g., only hindering operations from moving up) are pointless. >>>>> By the way, are you questioning whether the implementation is correct, or >>>>> whether the names express what is desired? >>>>> If it's the first, it's of no concern to this change, which is only about >>>>> matching these operations independently from those, that address >>>>> a dedicated memory operation. >>>>> If It's the second, please tell me what names to use, and I'll fix it. >>>>> (I hope you can properly read the 'drawings') >>>>> Best regards, >>>>> Goetz. >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Dienstag, 19. November 2013 20:51 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>> 'hotspot-dev at openjdk.java.net' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>> MemBarAcquire/ReleaseWide. >>>>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>>>> as shown below. So I guess that's just what is desired. >>>>> I don't think so! What is described for Unsafe are full bi-directional >>>>> fences and "acquire" and "release" are only uni-directional fences! >>>>> David >>>>> ----- >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> /** >>>>>> * Ensures lack of reordering of loads before the fence >>>>>> * with loads or stores after the fence. >>>>>> * @since 1.8 >>>>>> */ >>>>>> public native void loadFence(); >>>>>> >>>>>> /** >>>>>> * Ensures lack of reordering of stores before the fence >>>>>> * with loads or stores after the fence. >>>>>> * @since 1.8 >>>>>> */ >>>>>> public native void storeFence(); >>>>>> >>>>>> /** >>>>>> * Ensures lack of reordering of loads or stores before the fence >>>>>> * with loads or stores after the fence. >>>>>> * @since 1.8 >>>>>> */ >>>>>> public native void fullFence(); >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>> >>>>>> So I like the rename but I am concerned there are semantic issues here: >>>>>> >>>>>> switch(id) { >>>>>> case vmIntrinsics::_loadFence: >>>>>> - insert_mem_bar(Op_MemBarAcquire); >>>>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>>>> return true; >>>>>> case vmIntrinsics::_storeFence: >>>>>> - insert_mem_bar(Op_MemBarRelease); >>>>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>>>> return true; >>>>>> >>>>>> What is a _loadFence operation? Does it really map to >>>>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>>>> bi-directional fences - are they? Are they really only concerned with >>>>>> loads or stores ? >>>>>> >>>>>> David >>>>>> >>>>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I made a new webrev, using the new names: >>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>>>> >>>>>>> Thanks, >>>>>>> Goetz. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>> Sent: Montag, 18. November 2013 23:28 >>>>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>> >>>>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, Vladimir, >>>>>>>> >>>>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>>>> - the same prefix shows they are all similar nodes. >>>>>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>>>>> change yet and which is used in more places. >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>>>> To: Vladimir Kozlov >>>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>>> >>>>>>>> Vladimir, >>>>>>>> >>>>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>>>> I think David asked for different nodes not just one. >>>>>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>>>> >>>>>>>> But I don't think that actually describes them - they don't distinguish >>>>>>>> between loads and stores only the direction in which the barrier >>>>>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>>>>> only allows accesses to move above it ie: >>>>>>>> >>>>>>>> load a >>>>>>>> store b, c >>>>>>>> acquire(); >>>>>>>> load d >>>>>>>> store e,f >>>>>>>> release(); >>>>>>>> load g >>>>>>>> store h, i >>>>>>>> >>>>>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>>>>> the store to e can not move in relation to either acquire or release. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> as reply to your comment on the bug: >>>>>>>>>> >>>>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>>>> MemBarVolatile --> sync. >>>>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>>>> >>>>>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>>>>> Therefore I think a really clean representation that, at the same >>>>>>>>>> time, allows >>>>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>>>> processors, is impossible. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz >>>>>>>>>> >>>>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>>>> or on the mailing lists? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>>>> >>>>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>>>> Lindenmaier, Goetz >>>>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>>>>> >>>>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>>>>> matched differently, what is needed on PPC64. >>>>>>>>>> >>>>>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>>>> >>>>>>>>>> Please review and test this change. >>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> From vladimir.kozlov at oracle.com Mon Nov 25 23:49:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 25 Nov 2013 23:49:25 -0800 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <52944DC9.3050305@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> <528E18F7.7050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> <5293EE93.8010406@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6A0AE@DEWDFEMB12B.global.corp.sap> <52944DC9.3050305@oracle.com> Message-ID: <52945285.4010204@oracle.com> I prefer Load/StoreFence. I need to prepare closed changes and do testing before push. I will do it tomorrow. Thanks, Vladimir On 11/25/13 11:29 PM, David Holmes wrote: > On 26/11/2013 5:24 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> OK, thank you! >> >> Do you think this change can be pushed now? > > I think so. > >> Which naming would you prefer, finally? >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide MemBarFenceAcquire >> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide loadFence > > loadFence out of those two choices, but I'll leave that to Vladimir to confirm. > > Thanks, > David > >> Best regards, >> Goetz. >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 26, 2013 1:43 AM >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >> >> Hi Goetz & Martin, >> >> On 25/11/2013 9:26 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> I promised to comment on your concern about individual load/stores: >>>> As you state ld.acq and st.rel only >>>> relate to the target load/store _but_ there are no actions in the Java >>>> Memory Model that only provide ordering with respect to a single load or >>>> store! >>> We derive this from the well-known cookbook: >>> http://g.oswego.edu/dl/jmm/cookbook.html >>> Have a look at the table "required Barriers". >>> It talks about individual operations. E.g., imagine >>> Normal load 1 >>> Volatile load 2 >>> Normal load 3 >>> Then load1 may float arbitrarily to any place, but load3 may not >>> float above load2. >>> If I issue a 'wide' Acquire barriers after load2 (lwsync), this hinders load1 to >>> float below this barrier, introducing a constraint not specified by this >>> table. >>> >>> Does this satisfy your concerns? >> >> I was far too general in my comment re the JMM, I was thinking in terms >> of happens-before which is a transitive relation, and generalizing that >> to infer that all barriers have more far reaching affects that just the >> current load/store. But of course when you drill down into the actual >> requirements there are places where these more directed barriers are >> perfectly fine. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz and Martin >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 21. November 2013 15:30 >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>> >>> Hi Goetz, >>> >>> On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> here the new webrev, naming the nodes LoadFence/StoreFence: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ >>> >>> Okay. I think I now disagree (when seeing in context) that Membar should >>> have been dropped from the name but I'll let that lie. >>> >>> Aside: I find the descriptions of all those "membar" nodes very unclear >>> - it would be better, for me, if there were expressed more clearly in >>> terms of storeStore, storeLoad etc. >>> >>> Could you add to the comments in memnode.hpp that those nodes are only >>> used by the respective Unsafe intrinisics? Or at least use that as an >>> example usage? >>> >>>> The thing with the mail was my fault, I had sent the first mail >>>> only to you accidentially. Sorry for that. >>>> >>>>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >>>>> loads/stores - but with stronger semantics than just simple loadLoad or >>>>> storeStore barriers. >>>> Yes. I mean they do not intend to sort a single load/store with succeeding >>>> operations. This can not be implemented this way, as the operation >>>> is not known in the intrinsic. I mean cases where you can use ia64 ld.acq >>>> or ppc ld-twi-lwsync. >>> >>> If you are saying that loadFence and storeFence can not be implemented >>> using ld.acq and st.rel then good I agree with you. But I would argue >>> that general ld;MembarAcquire and st;MembarRelease can also not be >>> implemented with those instructions! As you state ld.acq and st.rel only >>> relate to the target load/store _but_ there are no actions in the Java >>> Memory Model that only provide ordering with respect to a single load or >>> store! The Unsafe *Ordered() operations may come closer to this but I >>> would expect them to be handled via an intrinsic - and they are outside >>> the JMM. So I would think the applicability of using ld.acq and st.rel >>> would be very limited, so it concerns me that it seems to be associated >>> with the very general MembarAcquire and MembarRelease nodes (ditto for >>> the changes in 8024921). >>> >>> But how you implement this is your concern. :) From the perspective of >>> this shared code my concern is that it is not clear exactly what the >>> practical distinction is between MembarAcquire and LoadFence, and >>> MembarRelease and StoreFence. I'm not a compiler person but I would find >>> it quite difficult to know which can/should be used when. And given for >>> most platforms they would be implemented the same, that would add to the >>> uncertainty (with a risk that someone will make an arbitrary choice). >>> >>> Thanks, >>> David >>> ----- >>> >>>>> Also I said that the Unsafe ops require bi-directional fences but that >>>>> was imprecise - the _load and _store ops only require two of the four >>>>> possible barriers which may be why you see these as distinct from the >>>>> membars associated directly with variable accesses ? >>>> On ia64, ld.acq sorts _this_ _single_ load with all following ld/st operations. >>>> For the intrinsic I must use mf, which sorts _all_ previous loads with all >>>> following ld/st operations (and more). So my distinction is if I have a >>>> store on one processor, and a load on the other, and I want to make sure >>>> the other processor's load sees the stored value, I can use - on ia64 - st.rel/ld.acq and I'm fine. >>>> If I did some arbitrary stores, and I want assure an other processor doing >>>> some arbitrary load,s then I must use - on ia64- mf on both. >>>> On sparc I can do a >>>> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::LoadLoad) ); >>>> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | Assembler::StoreStore) ); >>>> But, on sparc, there is no operation as ld.acq as far as I know. >>>> >>>> Change 8024921 enables to distinguish normal loads and such >>>> that should do ld.acq. This change enables the compiler to >>>> differentiate the MemBar nodes used better: such coming after >>>> a dedicated load, and such valid for any load before the barrier. >>>> This is already visible in the IR by some means: MemBars after >>>> dedicated loads have an input edge at position MemBar::precedence >>>> connecting them with the load, but that does not suffice to >>>> match it (in the matcher) correctly. >>>> If I use ld.acq, the following MemBarAcquire is superfluous, >>>> but the MemBarAcquire used in the intrinsic is not. So want to >>>> have different nodes. >>>> In our VM, we use #ifdef PPC and issue MemBarRelease instead of MemBarAcquire, >>>> and with #ifdef ia64 we use MemBarVolatile, as we know these operations will >>>> issue the proper assembly instructions. But this is bad - I want to do it better >>>> here. >>>> >>>>> Are you referring to generated code if these nodes are adjacent? If so I >>>>> assume the problem is that you can't logically coalesce these, even if >>>>> the actual generated code could be coalesced? >>>> Yes. On ia64 it is worst, as we had to implement MemBarRelease, Acquire >>>> and Volatile with mf() if we would not use ld.acq/st.rel. Then there >>>> would be even more redundant operations. But that's out of scope of this change. >>>> >>>>> I still have this concern regarding the fact you think these are not >>>>> related to load/store operations. But I'll wait for the webrev. >>>> As stated above, yes, they are related to store/load operations. But not >>>> to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st are not >>>> part of the intrinsic. >>>> >>>> (I'm using the ia64 mnemonics in the implementation because I think >>>> they are nicely orthogonal. Also it's important to know that >>>> ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects only >>>> the one load mentioned in the sequence. That's some hack in the >>>> processor.) >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 20. November 2013 21:06 >>>> To: Lindenmaier, Goetz >>>> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>> >>>> First apologies that the email you replied to here didn't go to the >>>> lists. Due to the way it was filtered I assumed it was a direct email >>>> only. :) >>>> >>>> On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> thanks for the comprehensive explanation. That's in agreement with >>>>> what I understand. Except that I think, unidirectional barriers only >>>>> make sense if you have Acquire/Release operations dedicated to >>>>> a certain operation. Then other operations of the same kind can pass >>>>> the barrier in one direction. >>>>> >>>>> This also matches the extension I contributed to hotspot (8024921), >>>>> which now allows to issue such operations right along with the >>>>> loads/stores. >>>>> >>>>> This change here tries to separate the barriers used after load/stores from >>>>> the 'wide' or better 'fence' variants. >>>> >>>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use after >>>> loads/stores - but with stronger semantics than just simple loadLoad or >>>> storeStore barriers. >>>> >>>>> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 possible >>>>> operations. Unfortunately, Hotspot knows only four of these: >>>>> MemBarStoreStore: S-S >>>> >>>> Okay - nice and clear. >>>> >>>>> MemBarAcquire: L-S, L-L >>>> >>>> I'm not sure what makes this "acquire" but this seems to be exactly what >>>> Unsafe.loadFence requires. >>>> >>>>> MemBarRelease: L-S, S-S >>>> >>>> Again I'm not sure what makes this "release" - I also find it odd that >>>> it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence >>>> needs. >>>> >>>>> MemBarVolatile: L-L, L-S, S-L, S-S >>>> >>>> A full fence, needed in the worst case when accessing a volatile variable. >>>> >>>> Also note that in different parts of the VM we have different >>>> expressions of these, both at the JIT level and runtime eg see >>>> orderAccess.hpp (which is not in itself self-consistent or clear: see >>>> https://bugs.openjdk.java.net/browse/JDK-7143664). >>>> >>>> Also I said that the Unsafe ops require bi-directional fences but that >>>> was imprecise - the _load and _store ops only require two of the four >>>> possible barriers which may be why you see these as distinct from the >>>> membars associated directly with variable accesses ? >>>> >>>>> and these don't map, e.g., the operations available on PPC: >>>>> lwsync: L-S, L-L, S-S >>>>> sync: L-L, L-S, S-L, S-S >>>>> What is the reason why it's hard for us to generate optimal code >>>>> with the available optimizations: >>>>> MemBarAcquire; >>>>> MemBarRelease; >>>>> are mapped to >>>>> lwsync >>>>> lwsync >>>>> which is obviously redundant. >>>> >>>> Are you referring to generated code if these nodes are adjacent? If so I >>>> assume the problem is that you can't logically coalesce these, even if >>>> the actual generated code could be coalesced? >>>> >>>>> A generic solution would be to have a single operation, that can be >>>>> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >>>>> Two operations could be merged by an optimization simply by >>>>> or-ing the tags. >>>>> But this is not reality in HotSpot, and out of scope of this change. >>>> >>>> Ok >>>> >>>>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>>>> Membar nodes for these unsafe ops (and only these) then name them to >>>>>> match the unsafe ops. At least then it is clearer where the >>>>>> specification for their behaviour comes from. >>>>> OK, so I'll rename them as Vladimir proposed, and post a new webrev. >>>> >>>> I still have this concern regarding the fact you think these are not >>>> related to load/store operations. But I'll wait for the webrev. >>>> >>>> Thanks for your patience on this. Hopefully we can sort it out in the >>>> next 24 hours before I takeoff. >>>> >>>> David >>>> ----- >>>> >>>>> Best regards and a good flight home, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Mittwoch, 20. November 2013 14:30 >>>>> To: Lindenmaier, Goetz >>>>> Cc: David Holmes >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>> >>>>> Hi Goetz, >>>>> >>>>> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> I don't know what you mean by uni/bi-directional. >>>>> >>>>> Pretty much as you describe below. A unidirectional barrier allows >>>>> things to cross in one direction only ie it blocks motion one way; a >>>>> bi-directional barrier ("full fence") blocks both ways and so prevents >>>>> any reordering. >>>>> >>>>> As I described in earlier emails these kind of unreferenced >>>>> acquire/release semantics ie not associated with any stores/loads is >>>>> used to describe the memory barrier properties of a synchronized block, >>>>> for example. Monitor acquisition has acquire semantics, while monitor >>>>> release has store semantics. The implied barriers mean that any accesses >>>>> can move into the synchronized region but none can move out - the "roach >>>>> motel" semantics. >>>>> >>>>> Now as you say this kind of barrier is not what is wanted with these >>>>> loadFence/storeFence operations, hence I think the generic >>>>> MembarAcquire/MembarRelease are inappropriate names (whether the >>>>> implementation is correct is a different matter). Similarly I find the >>>>> MembarAcquireFence and MembarReleaseFence to be somewhat inappropriate - >>>>> what do they mean ??? >>>>> >>>>> The loadFence semantics imply a loadLoad|loadStore barrier. >>>>> The storeFence semantics imply a storeLoad|storeStore barrier. >>>>> The fullFence is of course all four. >>>>> >>>>> Again I'm unclear if the current or proposed MembarXXX actions actually >>>>> map to barriers that implement those semantics. >>>>> >>>>> So yes this comes down to naming initially but also verification that >>>>> the implementation does as required. >>>>> >>>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>>> Membar nodes for these unsafe ops (and only these) then name them to >>>>> match the unsafe ops. At least then it is clearer where the >>>>> specification for their behaviour comes from. >>>>> >>>>> I'll post a follow up email to the list when I get a chance. I'm >>>>> currently in the US and attending lots of meetings then head back to >>>>> Australia tomorrow evening. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I guess we agree that the documentation of the intrinsics, let's take >>>>>> loadFence >>>>>> for an example, talks about loads before the loadFence, and stores and >>>>>> loads after it: >>>>>> loads >>>>>> ------------loadFence()-------------- >>>>>> loads, stores >>>>>> With this, you can achieve any ordering by moving nodes up OR down: >>>>>> Op1 Move Op1 Op2 >>>>>> Op2 down ------------- >>>>>> --------- =========> Op3 >>>>>> Op3 Op1 >>>>>> Alternatively, you can move op3 up, and get the same order: >>>>>> Op1 Reorder Op2 Move Op3 Op2 >>>>>> Op2 Ops 1 and 2 Op1 up Op3 >>>>>> --------- =========> -------------- =========> Op1 >>>>>> Op3 Not restricted Op3 ---------- >>>>>> by later loadFence >>>>>> So, if the operation restricts only moves in one direction, it's of no >>>>>> help because >>>>>> you can still get an execution order you did not expect. So >>>>>> unidirectional operations >>>>>> (e.g., only hindering operations from moving up) are pointless. >>>>>> By the way, are you questioning whether the implementation is correct, or >>>>>> whether the names express what is desired? >>>>>> If it's the first, it's of no concern to this change, which is only about >>>>>> matching these operations independently from those, that address >>>>>> a dedicated memory operation. >>>>>> If It's the second, please tell me what names to use, and I'll fix it. >>>>>> (I hope you can properly read the 'drawings') >>>>>> Best regards, >>>>>> Goetz. >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Dienstag, 19. November 2013 20:51 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>>> 'hotspot-dev at openjdk.java.net' >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>> MemBarAcquire/ReleaseWide. >>>>>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>>>>> as shown below. So I guess that's just what is desired. >>>>>> I don't think so! What is described for Unsafe are full bi-directional >>>>>> fences and "acquire" and "release" are only uni-directional fences! >>>>>> David >>>>>> ----- >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> /** >>>>>>> * Ensures lack of reordering of loads before the fence >>>>>>> * with loads or stores after the fence. >>>>>>> * @since 1.8 >>>>>>> */ >>>>>>> public native void loadFence(); >>>>>>> >>>>>>> /** >>>>>>> * Ensures lack of reordering of stores before the fence >>>>>>> * with loads or stores after the fence. >>>>>>> * @since 1.8 >>>>>>> */ >>>>>>> public native void storeFence(); >>>>>>> >>>>>>> /** >>>>>>> * Ensures lack of reordering of loads or stores before the fence >>>>>>> * with loads or stores after the fence. >>>>>>> * @since 1.8 >>>>>>> */ >>>>>>> public native void fullFence(); >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>> >>>>>>> So I like the rename but I am concerned there are semantic issues here: >>>>>>> >>>>>>> switch(id) { >>>>>>> case vmIntrinsics::_loadFence: >>>>>>> - insert_mem_bar(Op_MemBarAcquire); >>>>>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>>>>> return true; >>>>>>> case vmIntrinsics::_storeFence: >>>>>>> - insert_mem_bar(Op_MemBarRelease); >>>>>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>>>>> return true; >>>>>>> >>>>>>> What is a _loadFence operation? Does it really map to >>>>>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>>>>> bi-directional fences - are they? Are they really only concerned with >>>>>>> loads or stores ? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I made a new webrev, using the new names: >>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>>> Sent: Montag, 18. November 2013 23:28 >>>>>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>>> >>>>>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, Vladimir, >>>>>>>>> >>>>>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>>>>> - the same prefix shows they are all similar nodes. >>>>>>>>> - I don't have to change MemBarVolatile to FullFence, which I didn't >>>>>>>>> change yet and which is used in more places. >>>>>>>> >>>>>>>> Okay. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>>>>> To: Vladimir Kozlov >>>>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. >>>>>>>>> >>>>>>>>> Vladimir, >>>>>>>>> >>>>>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>>>>> I think David asked for different nodes not just one. >>>>>>>>>> We can have new membar nodes with names matching Unsafe methods names: >>>>>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>>>>> >>>>>>>>> But I don't think that actually describes them - they don't distinguish >>>>>>>>> between loads and stores only the direction in which the barrier >>>>>>>>> operates. "acquire" only allows accesses to move below it; "release" >>>>>>>>> only allows accesses to move above it ie: >>>>>>>>> >>>>>>>>> load a >>>>>>>>> store b, c >>>>>>>>> acquire(); >>>>>>>>> load d >>>>>>>>> store e,f >>>>>>>>> release(); >>>>>>>>> load g >>>>>>>>> store h, i >>>>>>>>> >>>>>>>>> allows the loads of 'a' and 'g' to move into the region between acquire >>>>>>>>> and release; similarly for the stores to b and h. But the load of d nor >>>>>>>>> the store to e can not move in relation to either acquire or release. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> MemBar and Fence have similar meaning so lets don't mix them in node names. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> as reply to your comment on the bug: >>>>>>>>>>> >>>>>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>>>>> MemBarVolatile --> sync. >>>>>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>>>>> >>>>>>>>>>> Or should I name them MemBarFenceAcquire and MemBarFenceRelease? >>>>>>>>>>> This all depends a lot on the available instructions of the processors. >>>>>>>>>>> Therefore I think a really clean representation that, at the same >>>>>>>>>>> time, allows >>>>>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>>>>> processors, is impossible. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz >>>>>>>>>>> >>>>>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>>>>> or on the mailing lists? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>>>>> >>>>>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>>>>> Lindenmaier, Goetz >>>>>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to enforce memory >>>>>>>>>>> ordering in various places. Some order a certain load/store with other >>>>>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>>>>> correspont to a memory operation. So far, the same nodes were used. >>>>>>>>>>> >>>>>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use where no >>>>>>>>>>> dedicated load/store is ordered. With this change, these nodes can be >>>>>>>>>>> matched differently, what is needed on PPC64. >>>>>>>>>>> >>>>>>>>>>> When reviewing 8024921 (part 113) we decided to avoid #defines in >>>>>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>>>>> >>>>>>>>>>> Please review and test this change. >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> From goetz.lindenmaier at sap.com Tue Nov 26 03:22:15 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Nov 2013 11:22:15 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <5293FE15.9050100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> Hi everybody, thanks a lot for the detailed reviews! I'll try to answer to all in one mail. > Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; We don't think it's correct if we omit the barrier after initializing a volatile field. Previously, we discussed this with Aleksey Shipilev and Doug Lea, and they agreed. Also, concurrency torture tests LongVolatileTest AtomicIntegerInitialValueTest will fail. (In addition, observing 0 instead of the inital value of a volatile field would be very counter-intuitive for Java programmers, especially in AtomicInteger.) > proposed for PPC64 is to make volatile reads extremely heavyweight Yes, it costs measurable performance. But else it is wrong. We don't see a way to implement this cheaper. > - these algorithms should be expressed using the correct OrderAccess operations Basically, I agree on this. But you also have to take into account that due to the different memory ordering instructions on different platforms just implementing something empty is not sufficient. An example: MemBarRelease // means LoadStore, StoreStore barrier MemBarVolatile // means StoreLoad barrier If these are consecutively in the code, sparc code looks like this: MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) MemBarVolatile --> membar(Assembler::StoreLoad) Just doing what is required. On Power, we get suboptimal code, as there are no comparable, fine grained operations: MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, I need an additional optimization that removes the lwsync. I can not implement MemBarRelease empty, as it is also used independently. Back to the IRIW problem. I think here we have a comparable issue. Doing the MemBarVolatile or the OrderAccess::fence() before the read is inefficient on platforms that have multiple-read-atomicity. I would propose to guard the code by VM_Version::cpu_is_multiple_read_atomic() or even better OrderAccess::cpu_is_multiple_read_atomic() Else, David, how would you propose to implement this platform independent? (Maybe we can also use above method in taskqueue.hpp.) Best regards, Goetz. -- Other ports: The IRIW issue requires at least 3 processors to be relevant, so it might not happen on small machines. But I can use PPC_ONLY instead of PPC64_ONLY if you request so (and if we don't get rid of them). -- MemBarStoreStore after initialization I agree we should not change it in the ppc port. If you wish, I can prepare an extra webrev for hotspot-comp. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, November 26, 2013 2:49 AM To: Vladimir Kozlov Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Okay this is my second attempt at answering this in a reasonable way :) On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: > I have to ask David to do correctness evaluation. From what I understand what we see here is an attempt to fix an existing issue with the implementation of volatiles so that the IRIW problem is addressed. The solution proposed for PPC64 is to make volatile reads extremely heavyweight by adding a fence() when doing the load. Now if this was purely handled in ppc64 source code then I would be happy to let them do whatever they like (surely this kills performance though!). But I do not agree with the changes to the shared code that allow this solution to be implemented - even with PPC64_ONLY this is polluting the shared code. My concern is similar to what I said with the taskQueue changes - these algorithms should be expressed using the correct OrderAccess operations to guarantee the desired properties independent of architecture. If such a "barrier" is not needed on a given architecture then the implementation in OrderAccess should reduce to a no-op. And as Vitaly points out the constructor barriers are not needed under the JMM. > I am fine with suggested changes because you did not change our current > code for our platforms (please, do not change do_exits() now). > But may be it should be done using more general query which is set > depending on platform: > > OrderAccess::needs_support_iriw_ordering() > > or similar to what we use now: > > VM_Version::needs_support_iriw_ordering() Every platform has to support IRIW this is simply part of the Java Memory Model, there should not be any need to call this out explicitly like this. Is there some subtlety of the hardware I am missing here? Are there visibility issues beyond the ordering constraints that the JMM defines? > From what I understand our ppc port is also affected. David? We can not discuss that on an OpenJDK mailing list - sorry. David ----- > In library_call.cpp can you add {}? New comment should be inside else {}. > > I think you should make _wrote_volatile field not ppc64 specific which > will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() > except in do_put_xxx() where it is set to true. Too many #ifdefs. > > In do_put_xxx() can you combine your changes: > > if (is_vol) { > // See comment in do_get_xxx(). > #ifndef PPC64 > insert_mem_bar(Op_MemBarVolatile); // Use fat membar > #else > if (is_field) { > // Add MemBarRelease for constructors which write volatile field > (PPC64). > set_wrote_volatile(true); > } > #endif > } > > Thanks, > Vladimir > > On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >> the torture test suite: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >> >> Example: >> volatile x=0, y=0 >> __________ __________ __________ __________ >> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >> >> write(x=1) read(x) write(y=1) read(y) >> read(y) read(x) >> >> Disallowed: x=1, y=0 y=1, x=0 >> >> >> Solution: This example requires multiple-copy-atomicity. This is only >> assured by the sync instruction and if it is executed in the threads >> doing the loads. Thus we implement volatile read as sync-load-acquire >> and omit the sync/MemBarVolatile after the volatile store. >> MemBarVolatile happens to be implemented by sync. >> We fix this in C2 and the cpp interpreter. >> >> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >> fails on staxf" for taskqueue.hpp. >> >> Further this change contains a fix that assures that volatile fields >> written in constructors are visible before the reference gets >> published. >> >> >> Looking at the code, we found a MemBarRelease that to us, seems too >> strong. >> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >> What do you think? >> >> Please review and test this change. >> >> Best regards, >> Goetz. >> From david.r.chase at oracle.com Tue Nov 26 03:56:23 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 06:56:23 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <52940513.6010503@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> Message-ID: <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> On 2013-11-25, at 9:18 PM, David Holmes wrote: > We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? Does anyone have any problems with sun.misc.VM as a choice? I have to do a minor revision to the hotspot commit anyway. Is sun.misc.VM also loaded very early anyway? David From aleksey.shipilev at oracle.com Tue Nov 26 04:06:44 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 26 Nov 2013 16:06:44 +0400 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> Message-ID: <52948ED4.9060408@oracle.com> On 11/26/2013 05:12 AM, Vitaly Davidovich wrote: > Volatile fields written in constructor aren't guaranteed by JMM to occur > before the reference is assigned; this guarantee only applies to final > fields and StoreStore (in JMM parlance) before ref assignment should be > sufficient. Of course making the implementation stronger is probably ok, > but just wanted to point that out as there seem to be changes aimed at > this, as you say. > > The reason volatile is excluded is because the ref assignment following the > volatile store is a plain one, and plain stores can move before volatile > stores (but not the other way, of course). So only final fields get this > special treatment; if someone is unsafely publishing a ref and assumes the > volatile store in constructor is sufficient, they're mistaken :). That's a popular misconception. The rule of thumb, however, is: "you can replace finals with volatiles and have the same publishing guarantees". This particular PPC failure was discussed with Goetz and Doug somewhat a year ago, and the result of that discussion is sealed within the jcstress tests, e.g.: http://hg.openjdk.java.net/code-tools/jcstress/file/tip/tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/volatiles/LongVolatileTest.java The final fields indeed have the special treatment in spec. However, the volatile fields have effectively the same guarantees when initialized in constructor, because there is *no* valid execution that might expose the default value for the volatile field. Suppose you have the class: class A { volatile int f; A() { f = 42; } } ...and this test case (note it deliberately omits NPE cases to make reasoning simpler): T1 | T2 ---------------|---------------- a = new A(); | r1 = a.f; The only allowed value for r1 is {42}. The sketch for the proof follows. There are only two possible juxtapositions on volatile ops in the trace: a) the one that reads (r1=0): vread(a.f, 0) \----so---> vstore(a.f, 42) b) the one that reads (r1=42): vstore(a.f, 42) \----so---> vread(a.f, 42) Now, we can extend that skeleton with the program order, as follows in T1 and T2, yielding two traces: a) one that reads (r1=0): read(a) \--po--> vread (a.f, 0) \---so---> vstore(a.f, 42) \---po---> store (a) b) one that reads (r1=42): vstore (a.f, 42) \ \-----------so------------------> vread(a.f, 42) \ read(a) ----po----^ \----po--->store(a) Now, notice that trace (a) not well-formed, because we read(a) before store(a). The trace (b) is well-formed. Hence, the only valid execution yields r1=42. Q.E.D. -Aleksey. From david.holmes at oracle.com Tue Nov 26 04:11:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 22:11:29 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> Message-ID: <52948FF1.5080300@oracle.com> Hi Goetz, On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: > Hi everybody, > > thanks a lot for the detailed reviews! > I'll try to answer to all in one mail. > >> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; > We don't think it's correct if we omit the barrier after initializing > a volatile field. Previously, we discussed this with Aleksey Shipilev > and Doug Lea, and they agreed. > Also, concurrency torture tests > LongVolatileTest > AtomicIntegerInitialValueTest > will fail. > (In addition, observing 0 instead of the inital value of a volatile field would be > very counter-intuitive for Java programmers, especially in AtomicInteger.) The affects of unsafe publication are always surprising - volatiles do not add anything special here. AFAIK there is nothing in the JMM that requires the constructor barrier - discussions with Doug and Aleksey notwithstanding. AFAIK we have not seen those tests fail due to a missing constructor barrier. >> proposed for PPC64 is to make volatile reads extremely heavyweight > Yes, it costs measurable performance. But else it is wrong. We don't > see a way to implement this cheaper. > >> - these algorithms should be expressed using the correct OrderAccess operations > Basically, I agree on this. But you also have to take into account > that due to the different memory ordering instructions on different platforms > just implementing something empty is not sufficient. > An example: > MemBarRelease // means LoadStore, StoreStore barrier > MemBarVolatile // means StoreLoad barrier > If these are consecutively in the code, sparc code looks like this: > MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) > MemBarVolatile --> membar(Assembler::StoreLoad) > Just doing what is required. > On Power, we get suboptimal code, as there are no comparable, > fine grained operations: > MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad > MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad > obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, > I need an additional optimization that removes the lwsync. I can not implement > MemBarRelease empty, as it is also used independently. > > Back to the IRIW problem. I think here we have a comparable issue. > Doing the MemBarVolatile or the OrderAccess::fence() before the read > is inefficient on platforms that have multiple-read-atomicity. > > I would propose to guard the code by > VM_Version::cpu_is_multiple_read_atomic() or even better > OrderAccess::cpu_is_multiple_read_atomic() > Else, David, how would you propose to implement this platform independent? > (Maybe we can also use above method in taskqueue.hpp.) I can not possibly answer to the necessary level of detail with a few moments thought. You are implying there is a problem here that will impact numerous platforms (unless you can tell me why ppc is so different?) and I can not take that on face value at the moment. The only reason I can see IRIW not being handled by the JMM requirements for volatile accesses is if there are global visibility issues that are not addressed - but even then I would expect heavy barriers at the store would deal with that, not at the load. (This situation reminds me of the need for read-barriers on Alpha architecture due to the use of software cache-coherency rather than hardware cache-coherency - but we don't have that on ppc!) Sorry - There is no quick resolution here and in a couple of days I will be heading out on vacation for two weeks. David ----- > Best regards, > Goetz. > > -- Other ports: > The IRIW issue requires at least 3 processors to be relevant, so it might > not happen on small machines. But I can use PPC_ONLY instead > of PPC64_ONLY if you request so (and if we don't get rid of them). > > -- MemBarStoreStore after initialization > I agree we should not change it in the ppc port. If you wish, I can > prepare an extra webrev for hotspot-comp. > > > > > > > > > > > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 26, 2013 2:49 AM > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Okay this is my second attempt at answering this in a reasonable way :) > > On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >> I have to ask David to do correctness evaluation. > > From what I understand what we see here is an attempt to fix an > existing issue with the implementation of volatiles so that the IRIW > problem is addressed. The solution proposed for PPC64 is to make > volatile reads extremely heavyweight by adding a fence() when doing the > load. > > Now if this was purely handled in ppc64 source code then I would be > happy to let them do whatever they like (surely this kills performance > though!). But I do not agree with the changes to the shared code that > allow this solution to be implemented - even with PPC64_ONLY this is > polluting the shared code. My concern is similar to what I said with the > taskQueue changes - these algorithms should be expressed using the > correct OrderAccess operations to guarantee the desired properties > independent of architecture. If such a "barrier" is not needed on a > given architecture then the implementation in OrderAccess should reduce > to a no-op. > > And as Vitaly points out the constructor barriers are not needed under > the JMM. > >> I am fine with suggested changes because you did not change our current >> code for our platforms (please, do not change do_exits() now). >> But may be it should be done using more general query which is set >> depending on platform: >> >> OrderAccess::needs_support_iriw_ordering() >> >> or similar to what we use now: >> >> VM_Version::needs_support_iriw_ordering() > > Every platform has to support IRIW this is simply part of the Java > Memory Model, there should not be any need to call this out explicitly > like this. > > Is there some subtlety of the hardware I am missing here? Are there > visibility issues beyond the ordering constraints that the JMM defines? >> From what I understand our ppc port is also affected. David? > > We can not discuss that on an OpenJDK mailing list - sorry. > > David > ----- > >> In library_call.cpp can you add {}? New comment should be inside else {}. >> >> I think you should make _wrote_volatile field not ppc64 specific which >> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >> except in do_put_xxx() where it is set to true. Too many #ifdefs. >> >> In do_put_xxx() can you combine your changes: >> >> if (is_vol) { >> // See comment in do_get_xxx(). >> #ifndef PPC64 >> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >> #else >> if (is_field) { >> // Add MemBarRelease for constructors which write volatile field >> (PPC64). >> set_wrote_volatile(true); >> } >> #endif >> } >> >> Thanks, >> Vladimir >> >> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>> the torture test suite: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>> >>> Example: >>> volatile x=0, y=0 >>> __________ __________ __________ __________ >>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>> >>> write(x=1) read(x) write(y=1) read(y) >>> read(y) read(x) >>> >>> Disallowed: x=1, y=0 y=1, x=0 >>> >>> >>> Solution: This example requires multiple-copy-atomicity. This is only >>> assured by the sync instruction and if it is executed in the threads >>> doing the loads. Thus we implement volatile read as sync-load-acquire >>> and omit the sync/MemBarVolatile after the volatile store. >>> MemBarVolatile happens to be implemented by sync. >>> We fix this in C2 and the cpp interpreter. >>> >>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>> fails on staxf" for taskqueue.hpp. >>> >>> Further this change contains a fix that assures that volatile fields >>> written in constructors are visible before the reference gets >>> published. >>> >>> >>> Looking at the code, we found a MemBarRelease that to us, seems too >>> strong. >>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>> What do you think? >>> >>> Please review and test this change. >>> >>> Best regards, >>> Goetz. >>> From david.holmes at oracle.com Tue Nov 26 04:12:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 22:12:11 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> Message-ID: <5294901B.3080207@oracle.com> On 26/11/2013 9:56 PM, David Chase wrote: > > On 2013-11-25, at 9:18 PM, David Holmes wrote: >> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? > > Does anyone have any problems with sun.misc.VM as a choice? > I have to do a minor revision to the hotspot commit anyway. > Is sun.misc.VM also loaded very early anyway? No you would have to add it as for Unsafe. David > David > From david.r.chase at oracle.com Tue Nov 26 04:16:13 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 07:16:13 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5294901B.3080207@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> Message-ID: <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> On 2013-11-26, at 7:12 AM, David Holmes wrote: > On 26/11/2013 9:56 PM, David Chase wrote: >> >> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >> >> Does anyone have any problems with sun.misc.VM as a choice? >> I have to do a minor revision to the hotspot commit anyway. >> Is sun.misc.VM also loaded very early anyway? > > No you would have to add it as for Unsafe. But it's loaded early anyway as a normal consequence of other class loading, right? David From david.holmes at oracle.com Tue Nov 26 04:32:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Nov 2013 22:32:23 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> Message-ID: <529494D7.3080109@oracle.com> On 26/11/2013 10:16 PM, David Chase wrote: > > On 2013-11-26, at 7:12 AM, David Holmes wrote: >> On 26/11/2013 9:56 PM, David Chase wrote: >>> >>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>> >>> Does anyone have any problems with sun.misc.VM as a choice? >>> I have to do a minor revision to the hotspot commit anyway. >>> Is sun.misc.VM also loaded very early anyway? >> >> No you would have to add it as for Unsafe. > > But it's loaded early anyway as a normal consequence of other class loading, right? What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. David > David > From goetz.lindenmaier at sap.com Tue Nov 26 04:51:23 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Nov 2013 12:51:23 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52948FF1.5080300@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> Hi David, -- Volatile in constuctor > AFAIK we have not seen those tests fail due to a > missing constructor barrier. We see them on PPC64. Our test machines have typically 8-32 processors and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) -- IRIW issue > I can not possibly answer to the necessary level of detail with a few > moments thought. Sure. There also is no solution as you require for the taskqueue problem yet, and that's being discussed now for almost a year. > You are implying there is a problem here that will > impact numerous platforms (unless you can tell me why ppc is so different?) No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a solution with the #defines, and that's correct for all, but not nice, I admit. (I don't really know about ARM, though). So if I can write down a nicer solution testing for methods that are evaluated by the C-compiler I'm happy. The problem is not that IRIW is not handled by the JMM, the problem is that store sync does not assure multiple-read-atomicity, only sync load does so on PPC. And you require multiple-read-atomicity to pass that test. The JMM is fine. And store MemBarVolatile is fine on x86, sparc etc. as there exist assembler instructions that do what is required. So if you are off soon, please let's come to a solution that might be improvable in the way it's implemented, but that allows us to implement a correct PPC64 port. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, November 26, 2013 1:11 PM To: Lindenmaier, Goetz Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi Goetz, On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: > Hi everybody, > > thanks a lot for the detailed reviews! > I'll try to answer to all in one mail. > >> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; > We don't think it's correct if we omit the barrier after initializing > a volatile field. Previously, we discussed this with Aleksey Shipilev > and Doug Lea, and they agreed. > Also, concurrency torture tests > LongVolatileTest > AtomicIntegerInitialValueTest > will fail. > (In addition, observing 0 instead of the inital value of a volatile field would be > very counter-intuitive for Java programmers, especially in AtomicInteger.) The affects of unsafe publication are always surprising - volatiles do not add anything special here. AFAIK there is nothing in the JMM that requires the constructor barrier - discussions with Doug and Aleksey notwithstanding. AFAIK we have not seen those tests fail due to a missing constructor barrier. >> proposed for PPC64 is to make volatile reads extremely heavyweight > Yes, it costs measurable performance. But else it is wrong. We don't > see a way to implement this cheaper. > >> - these algorithms should be expressed using the correct OrderAccess operations > Basically, I agree on this. But you also have to take into account > that due to the different memory ordering instructions on different platforms > just implementing something empty is not sufficient. > An example: > MemBarRelease // means LoadStore, StoreStore barrier > MemBarVolatile // means StoreLoad barrier > If these are consecutively in the code, sparc code looks like this: > MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) > MemBarVolatile --> membar(Assembler::StoreLoad) > Just doing what is required. > On Power, we get suboptimal code, as there are no comparable, > fine grained operations: > MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad > MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad > obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, > I need an additional optimization that removes the lwsync. I can not implement > MemBarRelease empty, as it is also used independently. > > Back to the IRIW problem. I think here we have a comparable issue. > Doing the MemBarVolatile or the OrderAccess::fence() before the read > is inefficient on platforms that have multiple-read-atomicity. > > I would propose to guard the code by > VM_Version::cpu_is_multiple_read_atomic() or even better > OrderAccess::cpu_is_multiple_read_atomic() > Else, David, how would you propose to implement this platform independent? > (Maybe we can also use above method in taskqueue.hpp.) I can not possibly answer to the necessary level of detail with a few moments thought. You are implying there is a problem here that will impact numerous platforms (unless you can tell me why ppc is so different?) and I can not take that on face value at the moment. The only reason I can see IRIW not being handled by the JMM requirements for volatile accesses is if there are global visibility issues that are not addressed - but even then I would expect heavy barriers at the store would deal with that, not at the load. (This situation reminds me of the need for read-barriers on Alpha architecture due to the use of software cache-coherency rather than hardware cache-coherency - but we don't have that on ppc!) Sorry - There is no quick resolution here and in a couple of days I will be heading out on vacation for two weeks. David ----- > Best regards, > Goetz. > > -- Other ports: > The IRIW issue requires at least 3 processors to be relevant, so it might > not happen on small machines. But I can use PPC_ONLY instead > of PPC64_ONLY if you request so (and if we don't get rid of them). > > -- MemBarStoreStore after initialization > I agree we should not change it in the ppc port. If you wish, I can > prepare an extra webrev for hotspot-comp. > > > > > > > > > > > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 26, 2013 2:49 AM > To: Vladimir Kozlov > Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Okay this is my second attempt at answering this in a reasonable way :) > > On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >> I have to ask David to do correctness evaluation. > > From what I understand what we see here is an attempt to fix an > existing issue with the implementation of volatiles so that the IRIW > problem is addressed. The solution proposed for PPC64 is to make > volatile reads extremely heavyweight by adding a fence() when doing the > load. > > Now if this was purely handled in ppc64 source code then I would be > happy to let them do whatever they like (surely this kills performance > though!). But I do not agree with the changes to the shared code that > allow this solution to be implemented - even with PPC64_ONLY this is > polluting the shared code. My concern is similar to what I said with the > taskQueue changes - these algorithms should be expressed using the > correct OrderAccess operations to guarantee the desired properties > independent of architecture. If such a "barrier" is not needed on a > given architecture then the implementation in OrderAccess should reduce > to a no-op. > > And as Vitaly points out the constructor barriers are not needed under > the JMM. > >> I am fine with suggested changes because you did not change our current >> code for our platforms (please, do not change do_exits() now). >> But may be it should be done using more general query which is set >> depending on platform: >> >> OrderAccess::needs_support_iriw_ordering() >> >> or similar to what we use now: >> >> VM_Version::needs_support_iriw_ordering() > > Every platform has to support IRIW this is simply part of the Java > Memory Model, there should not be any need to call this out explicitly > like this. > > Is there some subtlety of the hardware I am missing here? Are there > visibility issues beyond the ordering constraints that the JMM defines? >> From what I understand our ppc port is also affected. David? > > We can not discuss that on an OpenJDK mailing list - sorry. > > David > ----- > >> In library_call.cpp can you add {}? New comment should be inside else {}. >> >> I think you should make _wrote_volatile field not ppc64 specific which >> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >> except in do_put_xxx() where it is set to true. Too many #ifdefs. >> >> In do_put_xxx() can you combine your changes: >> >> if (is_vol) { >> // See comment in do_get_xxx(). >> #ifndef PPC64 >> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >> #else >> if (is_field) { >> // Add MemBarRelease for constructors which write volatile field >> (PPC64). >> set_wrote_volatile(true); >> } >> #endif >> } >> >> Thanks, >> Vladimir >> >> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>> the torture test suite: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>> >>> Example: >>> volatile x=0, y=0 >>> __________ __________ __________ __________ >>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>> >>> write(x=1) read(x) write(y=1) read(y) >>> read(y) read(x) >>> >>> Disallowed: x=1, y=0 y=1, x=0 >>> >>> >>> Solution: This example requires multiple-copy-atomicity. This is only >>> assured by the sync instruction and if it is executed in the threads >>> doing the loads. Thus we implement volatile read as sync-load-acquire >>> and omit the sync/MemBarVolatile after the volatile store. >>> MemBarVolatile happens to be implemented by sync. >>> We fix this in C2 and the cpp interpreter. >>> >>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>> fails on staxf" for taskqueue.hpp. >>> >>> Further this change contains a fix that assures that volatile fields >>> written in constructors are visible before the reference gets >>> published. >>> >>> >>> Looking at the code, we found a MemBarRelease that to us, seems too >>> strong. >>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>> What do you think? >>> >>> Please review and test this change. >>> >>> Best regards, >>> Goetz. >>> From david.r.chase at oracle.com Tue Nov 26 05:12:40 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 08:12:40 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <529494D7.3080109@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> Message-ID: <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> On 2013-11-26, at 7:32 AM, David Holmes wrote: > On 26/11/2013 10:16 PM, David Chase wrote: >> >> On 2013-11-26, at 7:12 AM, David Holmes wrote: >>> On 26/11/2013 9:56 PM, David Chase wrote: >>>> >>>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>>> >>>> Does anyone have any problems with sun.misc.VM as a choice? >>>> I have to do a minor revision to the hotspot commit anyway. >>>> Is sun.misc.VM also loaded very early anyway? >>> >>> No you would have to add it as for Unsafe. >> >> But it's loaded early anyway as a normal consequence of other class loading, right? > > What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. 120 is earlier than 135, so by that measure it is superior. Do you see any other problems with the change? The method's not at all "Unsafe" in the technical sense of the word, so it is just a matter of choosing a good home. David From vitalyd at gmail.com Tue Nov 26 05:46:23 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 26 Nov 2013 08:46:23 -0500 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52948ED4.9060408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948ED4.9060408@oracle.com> Message-ID: Aleksey, I'm not sure I understand your reasoning in the example you gave. If we treat constructor like regular method, we have this sequence: 1) alloc memory 2) assign volatile field (constructor) 3) assign reference So what in the spec says step 3 cannot move above step 2? If it did move, then you could observe the default value of the volatile field (memory is zerod). Also, suppose the example class has many fields, but only one is volatile - what then? Basically, A and A.f are two separate memory locations (one is computed as offset from other) and I don't quite get why the reordering above is not possible with constructors, which is just a method anyway (unless it gets some special treatment). If volatile gets same treatment as final, then may as well update spec/Doug's cookbook to dispel the misconception. Thanks Sent from my phone On Nov 26, 2013 7:06 AM, "Aleksey Shipilev" wrote: > On 11/26/2013 05:12 AM, Vitaly Davidovich wrote: > > Volatile fields written in constructor aren't guaranteed by JMM to occur > > before the reference is assigned; this guarantee only applies to final > > fields and StoreStore (in JMM parlance) before ref assignment should be > > sufficient. Of course making the implementation stronger is probably ok, > > but just wanted to point that out as there seem to be changes aimed at > > this, as you say. > > > > The reason volatile is excluded is because the ref assignment following > the > > volatile store is a plain one, and plain stores can move before volatile > > stores (but not the other way, of course). So only final fields get this > > special treatment; if someone is unsafely publishing a ref and assumes > the > > volatile store in constructor is sufficient, they're mistaken :). > > That's a popular misconception. The rule of thumb, however, is: "you can > replace finals with volatiles and have the same publishing guarantees". > > This particular PPC failure was discussed with Goetz and Doug somewhat a > year ago, and the result of that discussion is sealed within the > jcstress tests, e.g.: > > http://hg.openjdk.java.net/code-tools/jcstress/file/tip/tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/volatiles/LongVolatileTest.java > > The final fields indeed have the special treatment in spec. However, the > volatile fields have effectively the same guarantees when initialized in > constructor, because there is *no* valid execution that might expose the > default value for the volatile field. > > Suppose you have the class: > > class A { > volatile int f; > A() { > f = 42; > } > } > > ...and this test case (note it deliberately omits NPE cases to make > reasoning simpler): > > T1 | T2 > ---------------|---------------- > a = new A(); | r1 = a.f; > > The only allowed value for r1 is {42}. The sketch for the proof follows. > There are only two possible juxtapositions on volatile ops in the trace: > > a) the one that reads (r1=0): > > vread(a.f, 0) > \----so---> vstore(a.f, 42) > > b) the one that reads (r1=42): > > vstore(a.f, 42) > \----so---> vread(a.f, 42) > > Now, we can extend that skeleton with the program order, as follows in > T1 and T2, yielding two traces: > > a) one that reads (r1=0): > > read(a) > \--po--> vread (a.f, 0) > \---so---> vstore(a.f, 42) > \---po---> store (a) > > b) one that reads (r1=42): > > vstore (a.f, 42) > \ \-----------so------------------> vread(a.f, 42) > \ read(a) ----po----^ > \----po--->store(a) > > Now, notice that trace (a) not well-formed, because we read(a) before > store(a). The trace (b) is well-formed. Hence, the only valid execution > yields r1=42. Q.E.D. > > -Aleksey. > From trent.tong at gmail.com Tue Nov 26 06:58:47 2013 From: trent.tong at gmail.com (Xin Tong) Date: Tue, 26 Nov 2013 06:58:47 -0800 Subject: reclaim code cache Message-ID: Hi I see some of the methods are made *non-entrant* and then *zombie* in the OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode). I am wondering whether OpenJDK reuses memory for those methods for later compiled methods or not ? Thank you, Xin From aleksey.shipilev at oracle.com Tue Nov 26 07:26:41 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 26 Nov 2013 19:26:41 +0400 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948ED4.9060408@oracle.com> Message-ID: <5294BDB1.3060501@oracle.com> Hi Vitaly, On 11/26/2013 05:46 PM, Vitaly Davidovich wrote: > I'm not sure I understand your reasoning in the example you gave. If we > treat constructor like regular method, we have this sequence: > 1) alloc memory > 2) assign volatile field (constructor) > 3) assign reference > > So what in the spec says step 3 cannot move above step 2? Nothing explicitly. Well, nothing in spec explicitly forbids it either. Because JMM is *not* specifying what reorderings are allowed/forbidden. The knowledge about the allowed/forbidden reorderings can be *derived* from JMM as spec-ed. JMM specifies what consitutes the valid execution. The sketch I outlined show that the only valid executions under the JMM yield only the effects which "publish" the value written into the volatile field in constructor. That is the same sketch we settled on a year ago discussing this very issue with Martin, Goetz, and Doug. At that time it was a consensus the correct behavior of volatile stores in constructors is consistent with the final field semantics. I think further discussion about this should be held at c-i@, if you want more rigorous discussion JMM-wise. I will also gladly retract my sketch and fix/remove the offending tests in jcstress if proven wrong, although it would be suprise me, because this effectively means many concurrent programs I saw are royally fubar-ed (AtomicInteger initial value is only the tip of the iceberg). > Also, suppose the example class has many fields, but > only one is volatile - what then? Basically, A and A.f are two separate > memory locations (one is computed as offset from other) and I don't > quite get why the reordering above is not possible with constructors, > which is just a method anyway (unless it gets some special treatment). Please stop saying "reordering" if you want to answer the advanced JMM question. In JMM terms, you have to ask if there are valid executions which yield the default value for the non-volatile field. It's hard for me to answer this question at this point (sigh). > If volatile gets same treatment as final, then may as well update > spec/Doug's cookbook to dispel the misconception. I don't think spec needs updating. Cookbook might need the update, but keep in mind that JSR 133 cookbook *is not* the JMM, it is (vague) *interpretation* of JMM. Way too many troubles are coming from the fact people get comfortable with JSR 133 Cookbook, and extend that comfort to the belief they understand the Java Memory Model. I've learned for myself that's the way the dragons lie. -Aleksey. From albert.noll at oracle.com Tue Nov 26 07:33:35 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 26 Nov 2013 16:33:35 +0100 Subject: reclaim code cache In-Reply-To: References: Message-ID: <5294BF4F.6090509@oracle.com> Hi Xin, if the code cache sweeper removes a method from the code cache, memory is made available for later compilations. Best, Albert On 11/26/2013 03:58 PM, Xin Tong wrote: > Hi > > I see some of the methods are made *non-entrant* and then *zombie* in > the OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode). I am wondering > whether OpenJDK reuses memory for those methods for later compiled methods > or not ? > > Thank you, > Xin From trent.tong at gmail.com Tue Nov 26 07:48:34 2013 From: trent.tong at gmail.com (Xin Tong) Date: Tue, 26 Nov 2013 07:48:34 -0800 Subject: reclaim code cache In-Reply-To: <5294BF4F.6090509@oracle.com> References: <5294BF4F.6090509@oracle.com> Message-ID: Hi Albert Thank you. I am trying to make the claim that self-modifying code happens in bulk when running java workloads in a dynamic binary translator. i.e. the reclaimed memory for zombie methods in the code cache are reused for other methods. i run the dacapo eclipse benchmark and see some of the methods being zombized but no methods are JITted to the reclaimed memory ? what are some of the criteria/conditions for the JIT to reuse the reclaimed memory ? Xin On Tue, Nov 26, 2013 at 7:33 AM, Albert Noll wrote: > Hi Xin, > > if the code cache sweeper removes a method from the code cache, memory is > made available for later compilations. > > Best, > Albert > > > On 11/26/2013 03:58 PM, Xin Tong wrote: > >> Hi >> >> I see some of the methods are made *non-entrant* and then *zombie* in >> the OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode). I am wondering >> whether OpenJDK reuses memory for those methods for later compiled methods >> or not ? >> >> Thank you, >> Xin >> > > From david.r.chase at oracle.com Tue Nov 26 08:16:19 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Nov 2013 11:16:19 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> Message-ID: <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> On 2013-11-26, at 8:12 AM, David Chase wrote: > On 2013-11-26, at 7:32 AM, David Holmes wrote: >> On 26/11/2013 10:16 PM, David Chase wrote: >>> >>> On 2013-11-26, at 7:12 AM, David Holmes wrote: >>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>> >>>>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>>>> >>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>> I have to do a minor revision to the hotspot commit anyway. >>>>> Is sun.misc.VM also loaded very early anyway? >>>> >>>> No you would have to add it as for Unsafe. >>> >>> But it's loaded early anyway as a normal consequence of other class loading, right? >> >> What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. > > 120 is earlier than 135, so by that measure it is superior. > Do you see any other problems with the change? > The method's not at all "Unsafe" in the technical sense of the word, so it is just a matter of choosing a good home. On further investigation, change to sun.misc.VM would be the first time that hotspot knows of the existence of sun.misc.VM; sun.misc.Unsafe is already filled with methods that the runtime knows about (intrinsics, etc). I think Unsafe is better. David From albert.noll at oracle.com Tue Nov 26 08:22:45 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 26 Nov 2013 17:22:45 +0100 Subject: reclaim code cache In-Reply-To: References: <5294BF4F.6090509@oracle.com> Message-ID: Hi Xin, The code cache maintains a free list. If memory is released from the code cache, the free list is updated accordingly. You can verify that by downloading the latest build of hotspot (117) and start the VM with the following flag: -XX:ReservedCodeCacheSize=8m You can also try smaller code cache sizes. You will see after some time that the code cache fills up (a corresponding message will be displayed on the console). However, methods will still be compiled ( you can see that by using -XX:+PrintCompilation) since the code cache sweeper removes methods from the code cache and that memory is being reused. Best, Albert Von meinem iPhone gesendet > Am 26.11.2013 um 16:48 schrieb Xin Tong : > > Hi Albert > > Thank you. I am trying to make the claim that self-modifying code happens in bulk when running java workloads in a dynamic binary translator. i.e. the reclaimed memory for zombie methods in the code cache are reused for other methods. i run the dacapo eclipse benchmark and see some of the methods being zombized but no methods are JITted to the reclaimed memory ? what are some of the criteria/conditions for the JIT to reuse the reclaimed memory ? > > Xin > > >> On Tue, Nov 26, 2013 at 7:33 AM, Albert Noll wrote: >> Hi Xin, >> >> if the code cache sweeper removes a method from the code cache, memory is >> made available for later compilations. >> >> Best, >> Albert >> >> >>> On 11/26/2013 03:58 PM, Xin Tong wrote: >>> Hi >>> >>> I see some of the methods are made *non-entrant* and then *zombie* in >>> the OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode). I am wondering >>> whether OpenJDK reuses memory for those methods for later compiled methods >>> or not ? >>> >>> Thank you, >>> Xin > From volker.simonis at gmail.com Tue Nov 26 09:35:06 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Nov 2013 18:35:06 +0100 Subject: CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs Message-ID: Hi, I've just opened "JDK-8029190: VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs" (https://bugs.openjdk.java.net/browse/JDK-8029190) and would like to get the input of some real SPARC experts on how this could be best fixed: The whole CPU detection for SPARC CPUs seems to be targeted solely to Sun/Oracle SPARC CPUs. If running on a recent Fujitsu Sparc64-X CPU, debug builds immediately crash with: assert(is_T_family(features) == is_niagara(features)) failed: Niagara should be T series This test can not be successful on a Fujitsu Sparc64 CPU because is_niagara(features) tests for the sysinfo string 'SI_MACHINE' which is 'sun4v' on both, Oracle and Fujitsu CPUs while is_T_family(features) checks that the kernel statistics module 'cpu_info.implementation' contains the name "SPARC-T" or "SPARC-M". However, on Fujitsu SPARC64-X CPUs, 'cpu_info.implementation' contains the value "SPARC64-X". This problem can easily be worked around by changing the above assertion to: assert((is_T_family(features) == is_niagara(features)) || (features & sparc64_family_m), "Niagara should be T series"); But if we are using a CMS or G1, the VM will immediately crash with the next assertion in arguments.cpp: if (VM_Version::is_sun4v() && UseMemSetInBOT) { assert(!FLAG_IS_DEFAULT(UseMemSetInBOT), "Error"); This is again because 'is_sun4v()' is used with the semantics of 'is_niagara()' and in VM_Version::initialize() in vm_version_sparc.cpp we reset 'UseMemSetInBOT' to false if 'is_niagara()' is true: if (is_niagara()) { // When using CMS or G1, we cannot use memset() in BOT updates // because the sun4v/CMT version in libc_psr uses BIS which // exposes "phantom zeros" to concurrent readers. See 6948537. if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || UseG1GC)) { FLAG_SET_DEFAULT(UseMemSetInBOT, false); } We could actually fix this in the same way like before, by replacing 'is_sun4v()' with 'is_niagara()' in the assertion, but this would require to make at least the following functions public in vm_version_sparc.hpp: static bool is_T_family(int features) { return (features & T_family_m) != 0; } static bool is_niagara() { return is_T_family(_features); } However the bigger problem is that I have no idea of what the semantics of these attributes (i.e. is_niagara, is_T_family, is_M_family) is for Fujitsu Sparc-X CPUs? E.g. do we need to switch of 'UseMemSetInBOT' as well? There's are also other CPU-features like 'UseBlockCopy' and 'UseBlockZeroing' which are actually detected by looking at the instruction set extensions AND the CPU family. E.g. the above options are only enabled if the CPU supports 'block init instructions' (which is true on both Fujitsu Sparc64-X and new Oracle Sparc-T4 CPUs) AND the CPU family is Sparc-T4 (which is of course only true for Oracle SParc CPUs). Altogether, I think we need a real SPARC expert which knows both, the Oracle and the Fujitsu Sparc CPUs and who can tell us which of the Oracle Sparc features currently used in the HotSpot are available in Fujitsu CPUs as well. Moreover we should unify the various 'has_xxx()' and 'is_xxx()' functions from vm_version_sparc.hpp to work equally well for both CPU types. Thank you and best regards, Volker PS: - the Fujitsu Sparc64-X I have access to returns the following instruction set extensions vector and CPU features: getisax(2) returned: 0x400081f0 cpu_info.implementation: SPARC64-X (chipid 0, clock 2800 MHz) Allocation prefetching: PREFETCH at distance 512, 3 lines of 64 bytes PrefetchCopyIntervalInBytes 512 PrefetchScanIntervalInBytes 512 ContendedPaddingWidth 128 CPU:total 16 v9, popc, vis1, vis2, blk_init, sun4v, sparc64 - for the Sparc-T4 I've acess to this information looks as follows: getisax(2) returned: 0x3ffe8df0 cpu_info.implementation: SPARC-T4 (chipid 0, clock 2848 MHz) Allocation prefetching: BIS at distance 64, 6 lines of 32 bytes PrefetchCopyIntervalInBytes 512 PrefetchScanIntervalInBytes 512 ContendedPaddingWidth 128 CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, niagara_plus As you probably know, the full meaning of the instruction set extensions vector can be derived by inspecting /usr/includ/sys/auxv_SPARC.h From john.r.rose at oracle.com Tue Nov 26 10:04:37 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Nov 2013 10:04:37 -0800 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> Message-ID: On Nov 22, 2013, at 11:07 AM, David Chase wrote: > Webrev(s): > http://cr.openjdk.java.net/~drchase/8016839/webrev-hotspot.01/ > http://cr.openjdk.java.net/~drchase/8016839/webrev-jdk.01/ Excellent work. Count me as reviewer, please. ? John From vladimir.kozlov at oracle.com Tue Nov 26 14:39:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Nov 2013 14:39:36 -0800 Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce MemBarAcquire/ReleaseWide. In-Reply-To: <52945285.4010204@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE66A4E@DEWDFEMB12A.global.corp.sap> <528A6C28.7080306@oracle.com> <528A8B63.9090605@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66C85@DEWDFEMB12A.global.corp.sap> <528A948A.20002@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66D59@DEWDFEMB12A.global.corp.sap> <528BB70D.70007@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE66FCB@DEWDFEMB12A.global.corp.sap> <528BC10E.3030802@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE671DA@DEWDFEMB12A.global.corp.sap> <528CB958.9030809@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE674E0@DEWDFEMB12A.global.corp.sap> <528D161D.8030803@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE67C67@DEWDFEMB12A.global.corp.sap> <528E18F7.7050001@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6877A@DEWDFEMB12A.global.corp.sap> <5293EE93.8010406@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6A0AE@DEWDFEMB12B.global.corp.sap> <52944DC9.3050305@oracle.com> <52945285.4010204@oracle.com> Message-ID: <52952328.3050903@oracle.com> Goetz, I got assert on macos: # Internal Error (src/share/vm/oops/oop.inline.hpp:192), pid=3715, tid=15363 # assert(Universe::heap()->is_in_reserved(v)) failed: Address not in heap I looked through all related placed and I think you missed two in adlc/formssel.cpp which could cause it. You also did not update runtime/vmStructs.cpp I fixed it and running test again. Regards, Vladimir On 11/25/13 11:49 PM, Vladimir Kozlov wrote: > I prefer Load/StoreFence. I need to prepare closed changes and do > testing before push. I will do it tomorrow. > > Thanks, > Vladimir > > On 11/25/13 11:29 PM, David Holmes wrote: >> On 26/11/2013 5:24 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> OK, thank you! >>> >>> Do you think this change can be pushed now? >> >> I think so. >> >>> Which naming would you prefer, finally? >>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide >>> MemBarFenceAcquire >>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide loadFence >> >> loadFence out of those two choices, but I'll leave that to Vladimir to >> confirm. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 1:43 AM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>> 'hotspot-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>> MemBarAcquire/ReleaseWide. >>> >>> Hi Goetz & Martin, >>> >>> On 25/11/2013 9:26 PM, Lindenmaier, Goetz wrote: >>>> Hi David, >>>> >>>> I promised to comment on your concern about individual load/stores: >>>>> As you state ld.acq and st.rel only >>>>> relate to the target load/store _but_ there are no actions in the Java >>>>> Memory Model that only provide ordering with respect to a single >>>>> load or >>>>> store! >>>> We derive this from the well-known cookbook: >>>> http://g.oswego.edu/dl/jmm/cookbook.html >>>> Have a look at the table "required Barriers". >>>> It talks about individual operations. E.g., imagine >>>> Normal load 1 >>>> Volatile load 2 >>>> Normal load 3 >>>> Then load1 may float arbitrarily to any place, but load3 may not >>>> float above load2. >>>> If I issue a 'wide' Acquire barriers after load2 (lwsync), this >>>> hinders load1 to >>>> float below this barrier, introducing a constraint not specified by >>>> this >>>> table. >>>> >>>> Does this satisfy your concerns? >>> >>> I was far too general in my comment re the JMM, I was thinking in terms >>> of happens-before which is a transitive relation, and generalizing that >>> to infer that all barriers have more far reaching affects that just the >>> current load/store. But of course when you drill down into the actual >>> requirements there are places where these more directed barriers are >>> perfectly fine. >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> Goetz and Martin >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 21. November 2013 15:30 >>>> To: Lindenmaier, Goetz >>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>> 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>> MemBarAcquire/ReleaseWide. >>>> >>>> Hi Goetz, >>>> >>>> On 21/11/2013 8:23 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> here the new webrev, naming the nodes LoadFence/StoreFence: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-2-wide/ >>>> >>>> Okay. I think I now disagree (when seeing in context) that Membar >>>> should >>>> have been dropped from the name but I'll let that lie. >>>> >>>> Aside: I find the descriptions of all those "membar" nodes very unclear >>>> - it would be better, for me, if there were expressed more clearly in >>>> terms of storeStore, storeLoad etc. >>>> >>>> Could you add to the comments in memnode.hpp that those nodes are only >>>> used by the respective Unsafe intrinisics? Or at least use that as an >>>> example usage? >>>> >>>>> The thing with the mail was my fault, I had sent the first mail >>>>> only to you accidentially. Sorry for that. >>>>> >>>>>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use >>>>>> after >>>>>> loads/stores - but with stronger semantics than just simple >>>>>> loadLoad or >>>>>> storeStore barriers. >>>>> Yes. I mean they do not intend to sort a single load/store with >>>>> succeeding >>>>> operations. This can not be implemented this way, as the operation >>>>> is not known in the intrinsic. I mean cases where you can use ia64 >>>>> ld.acq >>>>> or ppc ld-twi-lwsync. >>>> >>>> If you are saying that loadFence and storeFence can not be implemented >>>> using ld.acq and st.rel then good I agree with you. But I would argue >>>> that general ld;MembarAcquire and st;MembarRelease can also not be >>>> implemented with those instructions! As you state ld.acq and st.rel >>>> only >>>> relate to the target load/store _but_ there are no actions in the Java >>>> Memory Model that only provide ordering with respect to a single >>>> load or >>>> store! The Unsafe *Ordered() operations may come closer to this but I >>>> would expect them to be handled via an intrinsic - and they are outside >>>> the JMM. So I would think the applicability of using ld.acq and st.rel >>>> would be very limited, so it concerns me that it seems to be associated >>>> with the very general MembarAcquire and MembarRelease nodes (ditto for >>>> the changes in 8024921). >>>> >>>> But how you implement this is your concern. :) From the perspective of >>>> this shared code my concern is that it is not clear exactly what the >>>> practical distinction is between MembarAcquire and LoadFence, and >>>> MembarRelease and StoreFence. I'm not a compiler person but I would >>>> find >>>> it quite difficult to know which can/should be used when. And given for >>>> most platforms they would be implemented the same, that would add to >>>> the >>>> uncertainty (with a risk that someone will make an arbitrary choice). >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>>> Also I said that the Unsafe ops require bi-directional fences but >>>>>> that >>>>>> was imprecise - the _load and _store ops only require two of the four >>>>>> possible barriers which may be why you see these as distinct from the >>>>>> membars associated directly with variable accesses ? >>>>> On ia64, ld.acq sorts _this_ _single_ load with all following ld/st >>>>> operations. >>>>> For the intrinsic I must use mf, which sorts _all_ previous loads >>>>> with all >>>>> following ld/st operations (and more). So my distinction is if I >>>>> have a >>>>> store on one processor, and a load on the other, and I want to make >>>>> sure >>>>> the other processor's load sees the stored value, I can use - on >>>>> ia64 - st.rel/ld.acq and I'm fine. >>>>> If I did some arbitrary stores, and I want assure an other >>>>> processor doing >>>>> some arbitrary load,s then I must use - on ia64- mf on both. >>>>> On sparc I can do a >>>>> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | >>>>> Assembler::LoadLoad) ); >>>>> membar( Assembler::Membar_mask_bits(Assembler::LoadStore | >>>>> Assembler::StoreStore) ); >>>>> But, on sparc, there is no operation as ld.acq as far as I know. >>>>> >>>>> Change 8024921 enables to distinguish normal loads and such >>>>> that should do ld.acq. This change enables the compiler to >>>>> differentiate the MemBar nodes used better: such coming after >>>>> a dedicated load, and such valid for any load before the barrier. >>>>> This is already visible in the IR by some means: MemBars after >>>>> dedicated loads have an input edge at position MemBar::precedence >>>>> connecting them with the load, but that does not suffice to >>>>> match it (in the matcher) correctly. >>>>> If I use ld.acq, the following MemBarAcquire is superfluous, >>>>> but the MemBarAcquire used in the intrinsic is not. So want to >>>>> have different nodes. >>>>> In our VM, we use #ifdef PPC and issue MemBarRelease instead of >>>>> MemBarAcquire, >>>>> and with #ifdef ia64 we use MemBarVolatile, as we know these >>>>> operations will >>>>> issue the proper assembly instructions. But this is bad - I want >>>>> to do it better >>>>> here. >>>>> >>>>>> Are you referring to generated code if these nodes are adjacent? >>>>>> If so I >>>>>> assume the problem is that you can't logically coalesce these, >>>>>> even if >>>>>> the actual generated code could be coalesced? >>>>> Yes. On ia64 it is worst, as we had to implement MemBarRelease, >>>>> Acquire >>>>> and Volatile with mf() if we would not use ld.acq/st.rel. Then there >>>>> would be even more redundant operations. But that's out of scope >>>>> of this change. >>>>> >>>>>> I still have this concern regarding the fact you think these are not >>>>>> related to load/store operations. But I'll wait for the webrev. >>>>> As stated above, yes, they are related to store/load operations. >>>>> But not >>>>> to a dedicated ld/st -- I can not use ld.acq/st.rel as the ld/st >>>>> are not >>>>> part of the intrinsic. >>>>> >>>>> (I'm using the ia64 mnemonics in the implementation because I think >>>>> they are nicely orthogonal. Also it's important to know that >>>>> ld-tdi-lwsync on ppc is cheaper than ld-lwsync because it affects >>>>> only >>>>> the one load mentioned in the sequence. That's some hack in the >>>>> processor.) >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Mittwoch, 20. November 2013 21:06 >>>>> To: Lindenmaier, Goetz >>>>> Cc: 'hotspot-dev at openjdk.java.net'; >>>>> 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' >>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>> MemBarAcquire/ReleaseWide. >>>>> >>>>> First apologies that the email you replied to here didn't go to the >>>>> lists. Due to the way it was filtered I assumed it was a direct email >>>>> only. :) >>>>> >>>>> On 21/11/2013 12:22 AM, Lindenmaier, Goetz wrote: >>>>>> Hi David, >>>>>> >>>>>> thanks for the comprehensive explanation. That's in agreement with >>>>>> what I understand. Except that I think, unidirectional barriers only >>>>>> make sense if you have Acquire/Release operations dedicated to >>>>>> a certain operation. Then other operations of the same kind can pass >>>>>> the barrier in one direction. >>>>>> >>>>>> This also matches the extension I contributed to hotspot (8024921), >>>>>> which now allows to issue such operations right along with the >>>>>> loads/stores. >>>>>> >>>>>> This change here tries to separate the barriers used after >>>>>> load/stores from >>>>>> the 'wide' or better 'fence' variants. >>>>> >>>>> But Unsafe.loadFence and Unsafe.storeFence _are_ intended for use >>>>> after >>>>> loads/stores - but with stronger semantics than just simple >>>>> loadLoad or >>>>> storeStore barriers. >>>>> >>>>>> Given the basic four barriers (L-L, L-S, S-L, S-S) there are 16 >>>>>> possible >>>>>> operations. Unfortunately, Hotspot knows only four of these: >>>>>> MemBarStoreStore: S-S >>>>> >>>>> Okay - nice and clear. >>>>> >>>>>> MemBarAcquire: L-S, L-L >>>>> >>>>> I'm not sure what makes this "acquire" but this seems to be exactly >>>>> what >>>>> Unsafe.loadFence requires. >>>>> >>>>>> MemBarRelease: L-S, S-S >>>>> >>>>> Again I'm not sure what makes this "release" - I also find it odd that >>>>> it is L-S not S-L. If S-L this would be exactly what Unsafe.storeFence >>>>> needs. >>>>> >>>>>> MemBarVolatile: L-L, L-S, S-L, S-S >>>>> >>>>> A full fence, needed in the worst case when accessing a volatile >>>>> variable. >>>>> >>>>> Also note that in different parts of the VM we have different >>>>> expressions of these, both at the JIT level and runtime eg see >>>>> orderAccess.hpp (which is not in itself self-consistent or clear: see >>>>> https://bugs.openjdk.java.net/browse/JDK-7143664). >>>>> >>>>> Also I said that the Unsafe ops require bi-directional fences but that >>>>> was imprecise - the _load and _store ops only require two of the four >>>>> possible barriers which may be why you see these as distinct from the >>>>> membars associated directly with variable accesses ? >>>>> >>>>>> and these don't map, e.g., the operations available on PPC: >>>>>> lwsync: L-S, L-L, S-S >>>>>> sync: L-L, L-S, S-L, S-S >>>>>> What is the reason why it's hard for us to generate optimal code >>>>>> with the available optimizations: >>>>>> MemBarAcquire; >>>>>> MemBarRelease; >>>>>> are mapped to >>>>>> lwsync >>>>>> lwsync >>>>>> which is obviously redundant. >>>>> >>>>> Are you referring to generated code if these nodes are adjacent? If >>>>> so I >>>>> assume the problem is that you can't logically coalesce these, even if >>>>> the actual generated code could be coalesced? >>>>> >>>>>> A generic solution would be to have a single operation, that can be >>>>>> Tagged with the barriers (L-L, L-S, S-L, S-S) it should guarantee. >>>>>> Two operations could be merged by an optimization simply by >>>>>> or-ing the tags. >>>>>> But this is not reality in HotSpot, and out of scope of this change. >>>>> >>>>> Ok >>>>> >>>>>>> I think perhaps that Vladimir's suggestion is best - if these are >>>>>>> the >>>>>>> Membar nodes for these unsafe ops (and only these) then name them to >>>>>>> match the unsafe ops. At least then it is clearer where the >>>>>>> specification for their behaviour comes from. >>>>>> OK, so I'll rename them as Vladimir proposed, and post a new webrev. >>>>> >>>>> I still have this concern regarding the fact you think these are not >>>>> related to load/store operations. But I'll wait for the webrev. >>>>> >>>>> Thanks for your patience on this. Hopefully we can sort it out in the >>>>> next 24 hours before I takeoff. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Best regards and a good flight home, >>>>>> Goetz. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 20. November 2013 14:30 >>>>>> To: Lindenmaier, Goetz >>>>>> Cc: David Holmes >>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>> MemBarAcquire/ReleaseWide. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 20/11/2013 7:36 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> I don't know what you mean by uni/bi-directional. >>>>>> >>>>>> Pretty much as you describe below. A unidirectional barrier allows >>>>>> things to cross in one direction only ie it blocks motion one way; a >>>>>> bi-directional barrier ("full fence") blocks both ways and so >>>>>> prevents >>>>>> any reordering. >>>>>> >>>>>> As I described in earlier emails these kind of unreferenced >>>>>> acquire/release semantics ie not associated with any stores/loads is >>>>>> used to describe the memory barrier properties of a synchronized >>>>>> block, >>>>>> for example. Monitor acquisition has acquire semantics, while monitor >>>>>> release has store semantics. The implied barriers mean that any >>>>>> accesses >>>>>> can move into the synchronized region but none can move out - the >>>>>> "roach >>>>>> motel" semantics. >>>>>> >>>>>> Now as you say this kind of barrier is not what is wanted with these >>>>>> loadFence/storeFence operations, hence I think the generic >>>>>> MembarAcquire/MembarRelease are inappropriate names (whether the >>>>>> implementation is correct is a different matter). Similarly I find >>>>>> the >>>>>> MembarAcquireFence and MembarReleaseFence to be somewhat >>>>>> inappropriate - >>>>>> what do they mean ??? >>>>>> >>>>>> The loadFence semantics imply a loadLoad|loadStore barrier. >>>>>> The storeFence semantics imply a storeLoad|storeStore barrier. >>>>>> The fullFence is of course all four. >>>>>> >>>>>> Again I'm unclear if the current or proposed MembarXXX actions >>>>>> actually >>>>>> map to barriers that implement those semantics. >>>>>> >>>>>> So yes this comes down to naming initially but also verification that >>>>>> the implementation does as required. >>>>>> >>>>>> I think perhaps that Vladimir's suggestion is best - if these are the >>>>>> Membar nodes for these unsafe ops (and only these) then name them to >>>>>> match the unsafe ops. At least then it is clearer where the >>>>>> specification for their behaviour comes from. >>>>>> >>>>>> I'll post a follow up email to the list when I get a chance. I'm >>>>>> currently in the US and attending lots of meetings then head back to >>>>>> Australia tomorrow evening. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I guess we agree that the documentation of the intrinsics, let's >>>>>>> take >>>>>>> loadFence >>>>>>> for an example, talks about loads before the loadFence, and >>>>>>> stores and >>>>>>> loads after it: >>>>>>> loads >>>>>>> ------------loadFence()-------------- >>>>>>> loads, stores >>>>>>> With this, you can achieve any ordering by moving nodes up OR down: >>>>>>> Op1 Move Op1 Op2 >>>>>>> Op2 down ------------- >>>>>>> --------- =========> Op3 >>>>>>> Op3 Op1 >>>>>>> Alternatively, you can move op3 up, and get the same order: >>>>>>> Op1 Reorder Op2 Move >>>>>>> Op3 Op2 >>>>>>> Op2 Ops 1 and 2 Op1 >>>>>>> up Op3 >>>>>>> --------- =========> -------------- =========> Op1 >>>>>>> Op3 Not restricted Op3 >>>>>>> ---------- >>>>>>> by later loadFence >>>>>>> So, if the operation restricts only moves in one direction, it's >>>>>>> of no >>>>>>> help because >>>>>>> you can still get an execution order you did not expect. So >>>>>>> unidirectional operations >>>>>>> (e.g., only hindering operations from moving up) are pointless. >>>>>>> By the way, are you questioning whether the implementation is >>>>>>> correct, or >>>>>>> whether the names express what is desired? >>>>>>> If it's the first, it's of no concern to this change, which is >>>>>>> only about >>>>>>> matching these operations independently from those, that address >>>>>>> a dedicated memory operation. >>>>>>> If It's the second, please tell me what names to use, and I'll >>>>>>> fix it. >>>>>>> (I hope you can properly read the 'drawings') >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> -----Original Message----- >>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>> Sent: Dienstag, 19. November 2013 20:51 >>>>>>> To: Lindenmaier, Goetz >>>>>>> Cc: 'Vladimir Kozlov'; 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>> MemBarAcquire/ReleaseWide. >>>>>>> On 20/11/2013 5:34 AM, Lindenmaier, Goetz wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> this are the instrinsics for sun/misc/Unsafe, which are documented >>>>>>>> as shown below. So I guess that's just what is desired. >>>>>>> I don't think so! What is described for Unsafe are full >>>>>>> bi-directional >>>>>>> fences and "acquire" and "release" are only uni-directional fences! >>>>>>> David >>>>>>> ----- >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> /** >>>>>>>> * Ensures lack of reordering of loads before the fence >>>>>>>> * with loads or stores after the fence. >>>>>>>> * @since 1.8 >>>>>>>> */ >>>>>>>> public native void loadFence(); >>>>>>>> >>>>>>>> /** >>>>>>>> * Ensures lack of reordering of stores before the fence >>>>>>>> * with loads or stores after the fence. >>>>>>>> * @since 1.8 >>>>>>>> */ >>>>>>>> public native void storeFence(); >>>>>>>> >>>>>>>> /** >>>>>>>> * Ensures lack of reordering of loads or stores before >>>>>>>> the fence >>>>>>>> * with loads or stores after the fence. >>>>>>>> * @since 1.8 >>>>>>>> */ >>>>>>>> public native void fullFence(); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Tuesday, November 19, 2013 8:08 PM >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: Vladimir Kozlov; 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: >>>>>>>> Introduce MemBarAcquire/ReleaseWide. >>>>>>>> >>>>>>>> So I like the rename but I am concerned there are semantic >>>>>>>> issues here: >>>>>>>> >>>>>>>> switch(id) { >>>>>>>> case vmIntrinsics::_loadFence: >>>>>>>> - insert_mem_bar(Op_MemBarAcquire); >>>>>>>> + insert_mem_bar(Op_MemBarFenceAcquire); >>>>>>>> return true; >>>>>>>> case vmIntrinsics::_storeFence: >>>>>>>> - insert_mem_bar(Op_MemBarRelease); >>>>>>>> + insert_mem_bar(Op_MemBarFenceRelease); >>>>>>>> return true; >>>>>>>> >>>>>>>> What is a _loadFence operation? Does it really map to >>>>>>>> MembarFenceAcquire? Ditto for the _storeFence. These sound like >>>>>>>> bi-directional fences - are they? Are they really only concerned >>>>>>>> with >>>>>>>> loads or stores ? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 19/11/2013 6:34 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I made a new webrev, using the new names: >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-1-wide/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>>>> Sent: Montag, 18. November 2013 23:28 >>>>>>>>> To: Lindenmaier, Goetz; 'David Holmes' >>>>>>>>> Cc: 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: >>>>>>>>> Introduce MemBarAcquire/ReleaseWide. >>>>>>>>> >>>>>>>>> On 11/18/13 2:19 PM, Lindenmaier, Goetz wrote: >>>>>>>>>> Hi David, Vladimir, >>>>>>>>>> >>>>>>>>>> I also would prefer MemBarFenceAquire/Release, for two reasons >>>>>>>>>> - the same prefix shows they are all similar nodes. >>>>>>>>>> - I don't have to change MemBarVolatile to FullFence, >>>>>>>>>> which I didn't >>>>>>>>>> change yet and which is used in more places. >>>>>>>>> >>>>>>>>> Okay. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Goetz. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Monday, November 18, 2013 10:49 PM >>>>>>>>>> To: Vladimir Kozlov >>>>>>>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; >>>>>>>>>> 'hotspot-dev at openjdk.java.net' >>>>>>>>>> Subject: Re: RFR(M): 8028515: PPC64 (part 113.2): opto: >>>>>>>>>> Introduce MemBarAcquire/ReleaseWide. >>>>>>>>>> >>>>>>>>>> Vladimir, >>>>>>>>>> >>>>>>>>>> On 19/11/2013 5:36 AM, Vladimir Kozlov wrote: >>>>>>>>>>> I think David asked for different nodes not just one. >>>>>>>>>>> We can have new membar nodes with names matching Unsafe >>>>>>>>>>> methods names: >>>>>>>>>>> LoadFence, StoreFence, FullFence. I am fine with it. >>>>>>>>>> >>>>>>>>>> But I don't think that actually describes them - they don't >>>>>>>>>> distinguish >>>>>>>>>> between loads and stores only the direction in which the barrier >>>>>>>>>> operates. "acquire" only allows accesses to move below it; >>>>>>>>>> "release" >>>>>>>>>> only allows accesses to move above it ie: >>>>>>>>>> >>>>>>>>>> load a >>>>>>>>>> store b, c >>>>>>>>>> acquire(); >>>>>>>>>> load d >>>>>>>>>> store e,f >>>>>>>>>> release(); >>>>>>>>>> load g >>>>>>>>>> store h, i >>>>>>>>>> >>>>>>>>>> allows the loads of 'a' and 'g' to move into the region >>>>>>>>>> between acquire >>>>>>>>>> and release; similarly for the stores to b and h. But the load >>>>>>>>>> of d nor >>>>>>>>>> the store to e can not move in relation to either acquire or >>>>>>>>>> release. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> MemBar and Fence have similar meaning so lets don't mix them >>>>>>>>>>> in node names. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 11/18/13 8:19 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> as reply to your comment on the bug: >>>>>>>>>>>> >>>>>>>>>>>> Well, I sitll would need 2 different nodes, as on PPC we do >>>>>>>>>>>> MemBarAcquireWide --> lwsync >>>>>>>>>>>> MemBarReleaseWide --> lwsync >>>>>>>>>>>> MemBarVolatile --> sync. >>>>>>>>>>>> On Sparc, you even do 3 different operations. >>>>>>>>>>>> >>>>>>>>>>>> Or should I name them MemBarFenceAcquire and >>>>>>>>>>>> MemBarFenceRelease? >>>>>>>>>>>> This all depends a lot on the available instructions of the >>>>>>>>>>>> processors. >>>>>>>>>>>> Therefore I think a really clean representation that, at the >>>>>>>>>>>> same >>>>>>>>>>>> time, allows >>>>>>>>>>>> to find the cheapest set of instructions to express it on all >>>>>>>>>>>> processors, is impossible. >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz >>>>>>>>>>>> >>>>>>>>>>>> PS: Should I respond to comments in the bug right in the bug >>>>>>>>>>>> or on the mailing lists? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From:ppc-aix-port-dev-bounces at openjdk.java.net >>>>>>> >>>>>>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of >>>>>>>>>>>> Lindenmaier, Goetz >>>>>>>>>>>> Sent: Montag, 18. November 2013 15:19 >>>>>>>>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>>>>>>>>> 'ppc-aix-port-dev at openjdk.java.net'; Vladimir Kozlov >>>>>>>>>>>> Subject: RFR(M): 8028515: PPC64 (part 113.2): opto: Introduce >>>>>>>>>>>> MemBarAcquire/ReleaseWide. >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The c2 compiler inserts MemBarAcquire/Release nodes to >>>>>>>>>>>> enforce memory >>>>>>>>>>>> ordering in various places. Some order a certain load/store >>>>>>>>>>>> with other >>>>>>>>>>>> operations. Inline_unsafe_fence() inserts MemBars that do not >>>>>>>>>>>> correspont to a memory operation. So far, the same nodes >>>>>>>>>>>> were used. >>>>>>>>>>>> >>>>>>>>>>>> This change introduces MemBarAcquire/ReleaseWide to use >>>>>>>>>>>> where no >>>>>>>>>>>> dedicated load/store is ordered. With this change, these >>>>>>>>>>>> nodes can be >>>>>>>>>>>> matched differently, what is needed on PPC64. >>>>>>>>>>>> >>>>>>>>>>>> When reviewing 8024921 (part 113) we decided to avoid >>>>>>>>>>>> #defines in >>>>>>>>>>>> inline_unsafe_fence() and to introduce new MemBar operations. >>>>>>>>>>>> >>>>>>>>>>>> Please review and test this change. >>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8028515-0-wide/ >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Goetz. >>>>>>>>>>>> From david.holmes at oracle.com Tue Nov 26 14:56:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 08:56:53 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <5294BDB1.3060501@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948ED4.9060408@oracle.com> <5294BDB1.3060501@oracle.com> Message-ID: <52952735.6070308@oracle.com> On 27/11/2013 1:26 AM, Aleksey Shipilev wrote: > Hi Vitaly, > > On 11/26/2013 05:46 PM, Vitaly Davidovich wrote: >> I'm not sure I understand your reasoning in the example you gave. If we >> treat constructor like regular method, we have this sequence: >> 1) alloc memory >> 2) assign volatile field (constructor) >> 3) assign reference >> >> So what in the spec says step 3 cannot move above step 2? > > Nothing explicitly. Well, nothing in spec explicitly forbids it either. > Because JMM is *not* specifying what reorderings are allowed/forbidden. > The knowledge about the allowed/forbidden reorderings can be *derived* > from JMM as spec-ed. JMM specifies what consitutes the valid execution. A fundamental abstraction in the JMM is the happens-before relation. There is nothing in the JMM that requires that #2 happens-before #3. > The sketch I outlined show that the only valid executions under the JMM > yield only the effects which "publish" the value written into the > volatile field in constructor. That is the same sketch we settled on a > year ago discussing this very issue with Martin, Goetz, and Doug. At > that time it was a consensus the correct behavior of volatile stores in > constructors is consistent with the final field semantics. It would have been nice if that discussion has been shared with others and perhaps used to trigger an update to the spec if that was needed - something which is now impossible for JDK 8. > I think further discussion about this should be held at c-i@, if you No it should be on javamemorymodel-discussion at cs.umd.edu > want more rigorous discussion JMM-wise. I will also gladly retract my > sketch and fix/remove the offending tests in jcstress if proven wrong, > although it would be suprise me, because this effectively means many > concurrent programs I saw are royally fubar-ed (AtomicInteger initial > value is only the tip of the iceberg). It is very well-known that unsafe publication can cause you to see an object that is only default initialized. This is fixed for objects with final fields, but remains true for objects with volatile fields. The JMM is quite clear on the special treatment of only final fields. >> Also, suppose the example class has many fields, but >> only one is volatile - what then? Basically, A and A.f are two separate >> memory locations (one is computed as offset from other) and I don't >> quite get why the reordering above is not possible with constructors, >> which is just a method anyway (unless it gets some special treatment). > > Please stop saying "reordering" if you want to answer the advanced JMM > question. In JMM terms, you have to ask if there are valid executions > which yield the default value for the non-volatile field. It's hard for > me to answer this question at this point (sigh). Show me a happens-before relation that prohibits the reordering. > >> If volatile gets same treatment as final, then may as well update >> spec/Doug's cookbook to dispel the misconception. > > I don't think spec needs updating. Cookbook might need the update, but Of course the spec would need updating if volatiles are to get the same special treatment as final fields! David ------ > keep in mind that JSR 133 cookbook *is not* the JMM, it is (vague) > *interpretation* of JMM. Way too many troubles are coming from the fact > people get comfortable with JSR 133 Cookbook, and extend that comfort to > the belief they understand the Java Memory Model. I've learned for > myself that's the way the dragons lie. > > -Aleksey. > From vitalyd at gmail.com Tue Nov 26 17:20:13 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 26 Nov 2013 20:20:13 -0500 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948ED4.9060408@oracle.com> <5294BDB1.3060501@oracle.com> <52952735.6070308@oracle.com> Message-ID: I agree with David. The spec and Doug's cookbook are silent on volatiles inside constructor, whereas both call out ctor + final fields explicitly. Therefore, if we talk about constructors like regular methods (which they are, at least for this discussion), then there's nothing that indicates any happens-before/freeze/ordering/whatever-we-call-it for those volatile writes. As for things like AtomicInteger breaking, it sounds like some code publishes them unsafely and expects final field like treatment - seems like a bug in those implementations. Otherwise, it seems like VM implementations are being adjusted to hide broken code, which is of course undesirable. Whatever comes out of this discussion (or wherever it moves) relevant docs should be updated so this confusion can stop (at least for people willing to do research). There shouldn't be some assumption that all readers will interpret an otherwise vague issue correctly and consistently. If someone goes through the analysis and deduces or "proves" that, even with current JMM wording, volatiles get same treatment as finals, then that analysis should be documented in said authoritative sources; that way, we can avoid discussions like this one :). Thanks Sent from my phone On Nov 26, 2013 5:57 PM, "David Holmes" wrote: On 27/11/2013 1:26 AM, Aleksey Shipilev wrote: > Hi Vitaly, > > On 11/26/2013 05:46 PM, Vitaly Davidovich wrote: > >> I'm not sure I understand your reasoning in the example you gave. If we >> treat constructor like regular method, we have this sequence: >> 1) alloc memory >> 2) assign volatile field (constructor) >> 3) assign reference >> >> So what in the spec says step 3 cannot move above step 2? >> > > Nothing explicitly. Well, nothing in spec explicitly forbids it either. > Because JMM is *not* specifying what reorderings are allowed/forbidden. > The knowledge about the allowed/forbidden reorderings can be *derived* > from JMM as spec-ed. JMM specifies what consitutes the valid execution. > A fundamental abstraction in the JMM is the happens-before relation. There is nothing in the JMM that requires that #2 happens-before #3. The sketch I outlined show that the only valid executions under the JMM > yield only the effects which "publish" the value written into the > volatile field in constructor. That is the same sketch we settled on a > year ago discussing this very issue with Martin, Goetz, and Doug. At > that time it was a consensus the correct behavior of volatile stores in > constructors is consistent with the final field semantics. > It would have been nice if that discussion has been shared with others and perhaps used to trigger an update to the spec if that was needed - something which is now impossible for JDK 8. I think further discussion about this should be held at c-i@, if you > No it should be on javamemorymodel-discussion at cs.umd.edu want more rigorous discussion JMM-wise. I will also gladly retract my > sketch and fix/remove the offending tests in jcstress if proven wrong, > although it would be suprise me, because this effectively means many > concurrent programs I saw are royally fubar-ed (AtomicInteger initial > value is only the tip of the iceberg). > It is very well-known that unsafe publication can cause you to see an object that is only default initialized. This is fixed for objects with final fields, but remains true for objects with volatile fields. The JMM is quite clear on the special treatment of only final fields. Also, suppose the example class has many fields, but >> only one is volatile - what then? Basically, A and A.f are two separate >> memory locations (one is computed as offset from other) and I don't >> quite get why the reordering above is not possible with constructors, >> which is just a method anyway (unless it gets some special treatment). >> > > Please stop saying "reordering" if you want to answer the advanced JMM > question. In JMM terms, you have to ask if there are valid executions > which yield the default value for the non-volatile field. It's hard for > me to answer this question at this point (sigh). > Show me a happens-before relation that prohibits the reordering. > If volatile gets same treatment as final, then may as well update >> spec/Doug's cookbook to dispel the misconception. >> > > I don't think spec needs updating. Cookbook might need the update, but > Of course the spec would need updating if volatiles are to get the same special treatment as final fields! David ------ keep in mind that JSR 133 cookbook *is not* the JMM, it is (vague) > *interpretation* of JMM. Way too many troubles are coming from the fact > people get comfortable with JSR 133 Cookbook, and extend that comfort to > the belief they understand the Java Memory Model. I've learned for > myself that's the way the dragons lie. > > -Aleksey. > > From serguei.spitsyn at oracle.com Tue Nov 26 17:34:19 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Nov 2013 17:34:19 -0800 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers Message-ID: <52954C1B.60908@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8028126 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ Summary: This is a fix for a possible race condition between the VMOp_GetCurrentLocation reaching a safepoint and target debuggee thread exiting from Java execution. The fix is to recheck the existence of the last Java frame at a safepoint and clean the thread current location if the thread has been already exited from Java. I'm suggesting to fix this in hs25/JDK 8. It is important to fix as it is a P2 bug and the risk of fixing it is low. But need reviewers to share opinions on this. I'll add the 8-critical-request label if reviewers agree with the above. Testing: The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was originally failed. In progress: nsk.jvmti, nsk.jdi, nsk.jdwp Thanks, Serguei From david.holmes at oracle.com Tue Nov 26 23:40:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 17:40:46 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> Message-ID: <5295A1FE.1020800@oracle.com> On 27/11/2013 2:16 AM, David Chase wrote: > > On 2013-11-26, at 8:12 AM, David Chase wrote: >> On 2013-11-26, at 7:32 AM, David Holmes wrote: >>> On 26/11/2013 10:16 PM, David Chase wrote: >>>> >>>> On 2013-11-26, at 7:12 AM, David Holmes wrote: >>>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>>> >>>>>> On 2013-11-25, at 9:18 PM, David Holmes wrote: >>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as good a place as any - though maybe sun.misc.VM is marginally better? >>>>>> >>>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>>> I have to do a minor revision to the hotspot commit anyway. >>>>>> Is sun.misc.VM also loaded very early anyway? >>>>> >>>>> No you would have to add it as for Unsafe. >>>> >>>> But it's loaded early anyway as a normal consequence of other class loading, right? >>> >>> What do you mean by "early"? It isn't a pre-loaded class but it will be loaded during system initialization. It is approx the 120th class to be loaded. Unsafe is about 135th. >> >> 120 is earlier than 135, so by that measure it is superior. >> Do you see any other problems with the change? >> The method's not at all "Unsafe" in the technical sense of the word, so it is just a matter of choosing a good home. > > On further investigation, change to sun.misc.VM would be the first time that hotspot knows of the existence of sun.misc.VM; sun.misc.Unsafe is already filled with methods that the runtime knows about (intrinsics, etc). I think Unsafe is better. Okay. David > David > From staffan.larsen at oracle.com Wed Nov 27 00:07:44 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 27 Nov 2013 09:07:44 +0100 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <52954C1B.60908@oracle.com> References: <52954C1B.60908@oracle.com> Message-ID: <730E8C30-2C04-4984-978F-C2286765A448@oracle.com> Looks good! The fix looks safe enough to include in jdk8, however this does not look like a recent regression - the bug must have been there for a long time. Let?s try to get it approved for jdk8. Thanks, /Staffan On 27 nov 2013, at 02:34, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8028126 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ > > Summary: > This is a fix for a possible race condition between the VMOp_GetCurrentLocation > reaching a safepoint and target debuggee thread exiting from Java execution. > The fix is to recheck the existence of the last Java frame at a safepoint > and clean the thread current location if the thread has been already exited from Java. > > I'm suggesting to fix this in hs25/JDK 8. > It is important to fix as it is a P2 bug and the risk of fixing it is low. > But need reviewers to share opinions on this. > I'll add the 8-critical-request label if reviewers agree with the above. > > > Testing: > The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was originally failed. > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp > > > Thanks, > Serguei From dmitry.samersoff at oracle.com Wed Nov 27 00:08:28 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Nov 2013 12:08:28 +0400 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <52954C1B.60908@oracle.com> References: <52954C1B.60908@oracle.com> Message-ID: <5295A87C.5070000@oracle.com> Serguei, Is it better to just convert assert at ll. 273 into if (vf != NULL) ... ? -Dmitry On 2013-11-27 05:34, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8028126 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ > > > Summary: > This is a fix for a possible race condition between the > VMOp_GetCurrentLocation > reaching a safepoint and target debuggee thread exiting from Java > execution. > The fix is to recheck the existence of the last Java frame at a safepoint > and clean the thread current location if the thread has been already > exited from Java. > > I'm suggesting to fix this in hs25/JDK 8. > It is important to fix as it is a P2 bug and the risk of fixing it is > low. > But need reviewers to share opinions on this. > I'll add the 8-critical-request label if reviewers agree with the above. > > > Testing: > The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was > originally failed. > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp > > > Thanks, > Serguei -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From serguei.spitsyn at oracle.com Wed Nov 27 01:04:01 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Nov 2013 01:04:01 -0800 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <730E8C30-2C04-4984-978F-C2286765A448@oracle.com> References: <52954C1B.60908@oracle.com> <730E8C30-2C04-4984-978F-C2286765A448@oracle.com> Message-ID: <5295B581.3080701@oracle.com> Thanks, Staffan! Serguei On 11/27/13 12:07 AM, Staffan Larsen wrote: > Looks good! > > The fix looks safe enough to include in jdk8, however this does not look like a recent regression - the bug must have been there for a long time. Let?s try to get it approved for jdk8. > > Thanks, > /Staffan > > On 27 nov 2013, at 02:34, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8028126 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ >> >> Summary: >> This is a fix for a possible race condition between the VMOp_GetCurrentLocation >> reaching a safepoint and target debuggee thread exiting from Java execution. >> The fix is to recheck the existence of the last Java frame at a safepoint >> and clean the thread current location if the thread has been already exited from Java. >> >> I'm suggesting to fix this in hs25/JDK 8. >> It is important to fix as it is a P2 bug and the risk of fixing it is low. >> But need reviewers to share opinions on this. >> I'll add the 8-critical-request label if reviewers agree with the above. >> >> >> Testing: >> The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was originally failed. >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp >> >> >> Thanks, >> Serguei From david.holmes at oracle.com Wed Nov 27 01:04:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 19:04:54 +1000 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <52954C1B.60908@oracle.com> References: <52954C1B.60908@oracle.com> Message-ID: <5295B5B6.5050203@oracle.com> Hi Serguei, This looks fine to me. Definitely low risk but not sure it is critical enough for 8. Minor nit: _method_id = (jmethodID)NULL; It should never be necessary to cast NULL if assigning to a pointer type. Thanks, David On 27/11/2013 11:34 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8028126 > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ > > > Summary: > This is a fix for a possible race condition between the > VMOp_GetCurrentLocation > reaching a safepoint and target debuggee thread exiting from Java > execution. > The fix is to recheck the existence of the last Java frame at a > safepoint > and clean the thread current location if the thread has been already > exited from Java. > > I'm suggesting to fix this in hs25/JDK 8. > It is important to fix as it is a P2 bug and the risk of fixing it is > low. > But need reviewers to share opinions on this. > I'll add the 8-critical-request label if reviewers agree with the above. > > > Testing: > The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was > originally failed. > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Wed Nov 27 01:31:54 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Nov 2013 01:31:54 -0800 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <5295A87C.5070000@oracle.com> References: <52954C1B.60908@oracle.com> <5295A87C.5070000@oracle.com> Message-ID: <5295BC0A.2020108@oracle.com> Dmitry, Thank you for reviewing! On 11/27/13 12:08 AM, Dmitry Samersoff wrote: > Serguei, > > Is it better to just convert > assert at ll. 273 into if (vf != NULL) ... ? Your suggestion does not help as we hit another assert in the call to last_java_vframe(): javaVFrame* vf = _thread->last_java_vframe(&rm); This is the original assert that was reported in the bug: # Internal Error (/tmp/jprt/P1/150447.amurillo/s/src/cpu/sparc/vm/frame_sparc.cpp:718), pid=29913, tid=5 # guarantee(Thread::current() == (Thread*)thread) failed: only current thread can flush its registers The stack is: Stack: [0xffffffff06e00000,0xffffffff06f00000], sp=0xffffffff06efea60, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x12379ac] void VMError::report_and_die()+0x714;; __1cHVMErrorOreport_and_die6M_v_+0x714 V [libjvm.so+0x71daf8] void report_vm_error(const char*,int,const char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78 V [libjvm.so+0x7e76bc] void JavaFrameAnchor::make_walkable(JavaThread*)+0x68;; __1cPJavaFrameAnchorNmake_walkable6MpnKJavaThread__v_+0x68 *V [libjvm.so+0x1189358] javaVFrame*JavaThread::last_java_vframe(RegisterMap*)+0x50;; __1cKJavaThreadQlast_java_vframe6MpnLRegisterMap__pnKjavaVFrame__+0x50* V [libjvm.so+0xc6b3c8] void VM_GetCurrentLocation::doit()+0xd0;; __1cVVM_GetCurrentLocationEdoit6M_v_+0xd0 V [libjvm.so+0x1267a50] void VM_Operation::evaluate()+0xf8;; __1cMVM_OperationIevaluate6M_v_+0xf8 V [libjvm.so+0x1263994] void VMThread::evaluate_operation(VM_Operation*)+0x254;; __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x254 V [libjvm.so+0x1264454] void VMThread::loop()+0x6a4;; __1cIVMThreadEloop6M_v_+0x6a4 V [libjvm.so+0x12633fc] void VMThread::run()+0xe4;; __1cIVMThreadDrun6M_v_+0xe4 V [libjvm.so+0xf183b8] java_start+0x258;; java_start+0x258 Thanks, Serguei > > -Dmitry > > > > On 2013-11-27 05:34, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8028126 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ >> >> >> Summary: >> This is a fix for a possible race condition between the >> VMOp_GetCurrentLocation >> reaching a safepoint and target debuggee thread exiting from Java >> execution. >> The fix is to recheck the existence of the last Java frame at a safepoint >> and clean the thread current location if the thread has been already >> exited from Java. >> >> I'm suggesting to fix this in hs25/JDK 8. >> It is important to fix as it is a P2 bug and the risk of fixing it is >> low. >> But need reviewers to share opinions on this. >> I'll add the 8-critical-request label if reviewers agree with the above. >> >> >> Testing: >> The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was >> originally failed. >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp >> >> >> Thanks, >> Serguei > From serguei.spitsyn at oracle.com Wed Nov 27 01:59:17 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Nov 2013 01:59:17 -0800 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <5295B5B6.5050203@oracle.com> References: <52954C1B.60908@oracle.com> <5295B5B6.5050203@oracle.com> Message-ID: <5295C275.1030802@oracle.com> Hi David, Thank you for the review! On 11/27/13 1:04 AM, David Holmes wrote: > Hi Serguei, > > This looks fine to me. Definitely low risk but not sure it is critical > enough for 8. Thanks. The priority is high and it impacts the tests stabilization as some other tests may potentially intermittently fail by the same reason. > > Minor nit: > _method_id = (jmethodID)NULL; > > It should never be necessary to cast NULL if assigning to a pointer type. Let's consider this type cast as a hint for the code reader. :) Also other places in the code use the same pattern, better keep it for consistency. Thanks, Serguei > > Thanks, > David > > On 27/11/2013 11:34 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8028126 >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ >> >> >> >> Summary: >> This is a fix for a possible race condition between the >> VMOp_GetCurrentLocation >> reaching a safepoint and target debuggee thread exiting from Java >> execution. >> The fix is to recheck the existence of the last Java frame at a >> safepoint >> and clean the thread current location if the thread has been already >> exited from Java. >> >> I'm suggesting to fix this in hs25/JDK 8. >> It is important to fix as it is a P2 bug and the risk of fixing it is >> low. >> But need reviewers to share opinions on this. >> I'll add the 8-critical-request label if reviewers agree with the >> above. >> >> >> Testing: >> The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was >> originally failed. >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp >> >> >> Thanks, >> Serguei From david.holmes at oracle.com Wed Nov 27 02:03:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 20:03:32 +1000 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5295B96A.6090902@gmail.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> <5295B96A.6090902@gmail.com> Message-ID: <5295C374.9010304@oracle.com> Hi Peter, On 27/11/2013 7:20 PM, Peter Levart wrote: > On 11/27/2013 08:40 AM, David Holmes wrote: >> On 27/11/2013 2:16 AM, David Chase wrote: >>> On 2013-11-26, at 8:12 AM, David Chase wrote: >>>> On 2013-11-26, at 7:32 AM, David Holmes >>>> wrote: >>>>> On 26/11/2013 10:16 PM, David Chase wrote: >>>>>> On 2013-11-26, at 7:12 AM, David Holmes >>>>>> wrote: >>>>>>> On 26/11/2013 9:56 PM, David Chase wrote: >>>>>>>> On 2013-11-25, at 9:18 PM, David Holmes >>>>>>>> wrote: >>>>>>>>> We do have the jdk.internal namespace. But I think Unsafe is as >>>>>>>>> good a place as any - though maybe sun.misc.VM is marginally >>>>>>>>> better? >>>>>>>> >>>>>>>> Does anyone have any problems with sun.misc.VM as a choice? >>>>>>>> I have to do a minor revision to the hotspot commit anyway. >>>>>>>> Is sun.misc.VM also loaded very early anyway? >>>>>>> >>>>>>> No you would have to add it as for Unsafe. >>>>>> >>>>>> But it's loaded early anyway as a normal consequence of other >>>>>> class loading, right? >>>>> >>>>> What do you mean by "early"? It isn't a pre-loaded class but it >>>>> will be loaded during system initialization. It is approx the 120th >>>>> class to be loaded. Unsafe is about 135th. >>>> >>>> 120 is earlier than 135, so by that measure it is superior. >>>> Do you see any other problems with the change? >>>> The method's not at all "Unsafe" in the technical sense of the word, >>>> so it is just a matter of choosing a good home. >>> >>> On further investigation, change to sun.misc.VM would be the first >>> time that hotspot knows of the existence of sun.misc.VM; >>> sun.misc.Unsafe is already filled with methods that the runtime knows >>> about (intrinsics, etc). I think Unsafe is better. >> >> Okay. >> >> David > > Hi David(s), > > Excuse me for my ignorance, but does pre-loading the class involve it's > initialization? Is static initializer called at that time? No, pre-load is simply loading not initialization. Static initialization gets triggerred via a controlled process as it is very delicate. Even if it is > not at that time, it surely should be called before first invocation of > a method on that class (the throwIllegalAccessError() method in this > case). You need a reference to this method very early - even before > system initialization starts. How early do you expect first "faulty > invocations" could occur that need to call this method? What if calling > that method triggers non-trivial initialization which in turn encounters > another faulty invocation? These faults should only appear in application classes so generally everything should be initialized well before you need to use this method. If a core library class has a bug that triggered this need to call this method then yes it is possible that it might happen too early to succeed - but that is quite normal for the core classes, there are a number of things that can happen too early in the initialization process to work (eg throwing exceptions, using assertions). That said I'm not sure how this could fail in that all we need is a reference to the method to put in the vtable and we have that after loading. Then all that can go wrong is that we can't actually throw the exception. > sun.misc.Unsafe has a non-trivial static initialization which involves > "registerNatives()" native method invocation, and it also calls: registerNative is not an issue > sun.reflect.Reflection.registerMethodsToFilter(Unsafe.class, "getUnsafe"); > > ...which initializes hell lot of things (like java.util.HashMap for > example, which in who knows which incarnation included random hash seed > initialization which triggered random number generator initialization > with gathering of random seed from various sources, ...) > sun.misc.VM on the other hand, only has the following static > initialization: > > private static final Object lock = new Object(); > > static { > initialize(); > } > private native static void initialize(); > > > Are you okay with all possible interactions of this initialization on > all platforms? The only time the initialization order would be changed by this fix is if one of the classes initialized before-hand had a bug that required this fix to come into affect. That is obviously a JDK bug and is extremely unlikely to happen. Note that sun.misc.VM is currently initialized 44th while Unsafe is 61st. I don't see any issues with this fix in that regard. > I think a new class with only this method would be a safer choice. > Regarding back-porting, even if sun.misc.Unsafe is used as the holder > for that method, this new method will have to be added to > sun.misc.Unsafe on those legacy platforms in order to obtain this new > Method *. If the method is not found, the VM would have to behave as > before. Couldn't the pre-loading of classes be made such that some of > them are optional? It already supports optional classes. David H. -------- > > > Regard, Peter > >> >>> David >>> > From dmitry.samersoff at oracle.com Wed Nov 27 02:13:53 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Nov 2013 14:13:53 +0400 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <5295BC0A.2020108@oracle.com> References: <52954C1B.60908@oracle.com> <5295A87C.5070000@oracle.com> <5295BC0A.2020108@oracle.com> Message-ID: <5295C5E1.7020208@oracle.com> Serguei, Thank you for the explanation. Looks good for me. -Dmitry On 2013-11-27 13:31, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for reviewing! > > On 11/27/13 12:08 AM, Dmitry Samersoff wrote: >> Serguei, >> >> Is it better to just convert >> assert at ll. 273 into if (vf != NULL) ... ? > > Your suggestion does not help as we hit another assert in the call to > last_java_vframe(): > javaVFrame* vf = _thread->last_java_vframe(&rm); > > This is the original assert that was reported in the bug: > > # Internal Error > (/tmp/jprt/P1/150447.amurillo/s/src/cpu/sparc/vm/frame_sparc.cpp:718), > pid=29913, tid=5 > # guarantee(Thread::current() == (Thread*)thread) failed: only current > thread can flush its registers > > The stack is: > Stack: [0xffffffff06e00000,0xffffffff06f00000], sp=0xffffffff06efea60, > free space=1018k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x12379ac] void VMError::report_and_die()+0x714;; > __1cHVMErrorOreport_and_die6M_v_+0x714 > V [libjvm.so+0x71daf8] void report_vm_error(const char*,int,const > char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78 > V [libjvm.so+0x7e76bc] void > JavaFrameAnchor::make_walkable(JavaThread*)+0x68;; > __1cPJavaFrameAnchorNmake_walkable6MpnKJavaThread__v_+0x68 > *V [libjvm.so+0x1189358] > javaVFrame*JavaThread::last_java_vframe(RegisterMap*)+0x50;; > __1cKJavaThreadQlast_java_vframe6MpnLRegisterMap__pnKjavaVFrame__+0x50* > V [libjvm.so+0xc6b3c8] void VM_GetCurrentLocation::doit()+0xd0;; > __1cVVM_GetCurrentLocationEdoit6M_v_+0xd0 > V [libjvm.so+0x1267a50] void VM_Operation::evaluate()+0xf8;; > __1cMVM_OperationIevaluate6M_v_+0xf8 > V [libjvm.so+0x1263994] void > VMThread::evaluate_operation(VM_Operation*)+0x254;; > __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x254 > V [libjvm.so+0x1264454] void VMThread::loop()+0x6a4;; > __1cIVMThreadEloop6M_v_+0x6a4 > V [libjvm.so+0x12633fc] void VMThread::run()+0xe4;; > __1cIVMThreadDrun6M_v_+0xe4 > V [libjvm.so+0xf183b8] java_start+0x258;; java_start+0x258 > > > Thanks, > Serguei > >> >> -Dmitry >> >> >> >> On 2013-11-27 05:34, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8028126 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ >>> >>> >>> Summary: >>> This is a fix for a possible race condition between the >>> VMOp_GetCurrentLocation >>> reaching a safepoint and target debuggee thread exiting from Java >>> execution. >>> The fix is to recheck the existence of the last Java frame at a safepoint >>> and clean the thread current location if the thread has been already >>> exited from Java. >>> >>> I'm suggesting to fix this in hs25/JDK 8. >>> It is important to fix as it is a P2 bug and the risk of fixing it is >>> low. >>> But need reviewers to share opinions on this. >>> I'll add the 8-critical-request label if reviewers agree with the above. >>> >>> >>> Testing: >>> The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was >>> originally failed. >>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp >>> >>> >>> Thanks, >>> Serguei >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Nov 27 02:16:33 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Nov 2013 02:16:33 -0800 Subject: Review Request (S) 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers In-Reply-To: <5295C5E1.7020208@oracle.com> References: <52954C1B.60908@oracle.com> <5295A87C.5070000@oracle.com> <5295BC0A.2020108@oracle.com> <5295C5E1.7020208@oracle.com> Message-ID: <5295C681.3000406@oracle.com> Thanks, Dmitry! Serguei On 11/27/13 2:13 AM, Dmitry Samersoff wrote: > Serguei, > > Thank you for the explanation. Looks good for me. > > -Dmitry > > On 2013-11-27 13:31, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thank you for reviewing! >> >> On 11/27/13 12:08 AM, Dmitry Samersoff wrote: >>> Serguei, >>> >>> Is it better to just convert >>> assert at ll. 273 into if (vf != NULL) ... ? >> Your suggestion does not help as we hit another assert in the call to >> last_java_vframe(): >> javaVFrame* vf = _thread->last_java_vframe(&rm); >> >> This is the original assert that was reported in the bug: >> >> # Internal Error >> (/tmp/jprt/P1/150447.amurillo/s/src/cpu/sparc/vm/frame_sparc.cpp:718), >> pid=29913, tid=5 >> # guarantee(Thread::current() == (Thread*)thread) failed: only current >> thread can flush its registers >> >> The stack is: >> Stack: [0xffffffff06e00000,0xffffffff06f00000], sp=0xffffffff06efea60, >> free space=1018k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0x12379ac] void VMError::report_and_die()+0x714;; >> __1cHVMErrorOreport_and_die6M_v_+0x714 >> V [libjvm.so+0x71daf8] void report_vm_error(const char*,int,const >> char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78 >> V [libjvm.so+0x7e76bc] void >> JavaFrameAnchor::make_walkable(JavaThread*)+0x68;; >> __1cPJavaFrameAnchorNmake_walkable6MpnKJavaThread__v_+0x68 >> *V [libjvm.so+0x1189358] >> javaVFrame*JavaThread::last_java_vframe(RegisterMap*)+0x50;; >> __1cKJavaThreadQlast_java_vframe6MpnLRegisterMap__pnKjavaVFrame__+0x50* >> V [libjvm.so+0xc6b3c8] void VM_GetCurrentLocation::doit()+0xd0;; >> __1cVVM_GetCurrentLocationEdoit6M_v_+0xd0 >> V [libjvm.so+0x1267a50] void VM_Operation::evaluate()+0xf8;; >> __1cMVM_OperationIevaluate6M_v_+0xf8 >> V [libjvm.so+0x1263994] void >> VMThread::evaluate_operation(VM_Operation*)+0x254;; >> __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x254 >> V [libjvm.so+0x1264454] void VMThread::loop()+0x6a4;; >> __1cIVMThreadEloop6M_v_+0x6a4 >> V [libjvm.so+0x12633fc] void VMThread::run()+0xe4;; >> __1cIVMThreadDrun6M_v_+0xe4 >> V [libjvm.so+0xf183b8] java_start+0x258;; java_start+0x258 >> >> >> Thanks, >> Serguei >> >>> -Dmitry >>> >>> >>> >>> On 2013-11-27 05:34, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8028126 >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8028126-JVMTI-HS101.1/ >>>> >>>> >>>> Summary: >>>> This is a fix for a possible race condition between the >>>> VMOp_GetCurrentLocation >>>> reaching a safepoint and target debuggee thread exiting from Java >>>> execution. >>>> The fix is to recheck the existence of the last Java frame at a safepoint >>>> and clean the thread current location if the thread has been already >>>> exited from Java. >>>> >>>> I'm suggesting to fix this in hs25/JDK 8. >>>> It is important to fix as it is a P2 bug and the risk of fixing it is >>>> low. >>>> But need reviewers to share opinions on this. >>>> I'll add the 8-critical-request label if reviewers agree with the above. >>>> >>>> >>>> Testing: >>>> The test nsk/jvmti/scenarios/hotswap/HS101/hs101t006 that was >>>> originally failed. >>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp >>>> >>>> >>>> Thanks, >>>> Serguei > From david.holmes at oracle.com Wed Nov 27 03:52:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Nov 2013 21:52:43 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> Message-ID: <5295DD0B.3030604@oracle.com> Hi Goetz, On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: > Hi David, > > -- Volatile in constuctor >> AFAIK we have not seen those tests fail due to a >> missing constructor barrier. > We see them on PPC64. Our test machines have typically 8-32 processors > and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) And see follow ups - the tests are invalid. > -- IRIW issue >> I can not possibly answer to the necessary level of detail with a few >> moments thought. > Sure. There also is no solution as you require for the taskqueue problem yet, > and that's being discussed now for almost a year. It may have started a year ago but work on it has hardly been continuous. >> You are implying there is a problem here that will >> impact numerous platforms (unless you can tell me why ppc is so different?) > No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a > solution with the #defines, and that's correct for all, but not nice, I admit. > (I don't really know about ARM, though). > So if I can write down a nicer solution testing for methods that are evaluated > by the C-compiler I'm happy. > > The problem is not that IRIW is not handled by the JMM, the problem > is that > store > sync > does not assure multiple-read-atomicity, > only > sync > load > does so on PPC. And you require multiple-read-atomicity to > pass that test. What is "multiple-read-atomicity"? I'm not familiar with the term and can't find any reference to it. Thanks, David The JMM is fine. And > store > MemBarVolatile > is fine on x86, sparc etc. as there exist assembler instructions that > do what is required. > > So if you are off soon, please let's come to a solution that > might be improvable in the way it's implemented, but that > allows us to implement a correct PPC64 port. > > Best regards, > Goetz. > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 26, 2013 1:11 PM > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >> Hi everybody, >> >> thanks a lot for the detailed reviews! >> I'll try to answer to all in one mail. >> >>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >> We don't think it's correct if we omit the barrier after initializing >> a volatile field. Previously, we discussed this with Aleksey Shipilev >> and Doug Lea, and they agreed. >> Also, concurrency torture tests >> LongVolatileTest >> AtomicIntegerInitialValueTest >> will fail. >> (In addition, observing 0 instead of the inital value of a volatile field would be >> very counter-intuitive for Java programmers, especially in AtomicInteger.) > > The affects of unsafe publication are always surprising - volatiles do > not add anything special here. AFAIK there is nothing in the JMM that > requires the constructor barrier - discussions with Doug and Aleksey > notwithstanding. AFAIK we have not seen those tests fail due to a > missing constructor barrier. > >>> proposed for PPC64 is to make volatile reads extremely heavyweight >> Yes, it costs measurable performance. But else it is wrong. We don't >> see a way to implement this cheaper. >> >>> - these algorithms should be expressed using the correct OrderAccess operations >> Basically, I agree on this. But you also have to take into account >> that due to the different memory ordering instructions on different platforms >> just implementing something empty is not sufficient. >> An example: >> MemBarRelease // means LoadStore, StoreStore barrier >> MemBarVolatile // means StoreLoad barrier >> If these are consecutively in the code, sparc code looks like this: >> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >> MemBarVolatile --> membar(Assembler::StoreLoad) >> Just doing what is required. >> On Power, we get suboptimal code, as there are no comparable, >> fine grained operations: >> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >> I need an additional optimization that removes the lwsync. I can not implement >> MemBarRelease empty, as it is also used independently. >> >> Back to the IRIW problem. I think here we have a comparable issue. >> Doing the MemBarVolatile or the OrderAccess::fence() before the read >> is inefficient on platforms that have multiple-read-atomicity. >> >> I would propose to guard the code by >> VM_Version::cpu_is_multiple_read_atomic() or even better >> OrderAccess::cpu_is_multiple_read_atomic() >> Else, David, how would you propose to implement this platform independent? >> (Maybe we can also use above method in taskqueue.hpp.) > > I can not possibly answer to the necessary level of detail with a few > moments thought. You are implying there is a problem here that will > impact numerous platforms (unless you can tell me why ppc is so > different?) and I can not take that on face value at the moment. The > only reason I can see IRIW not being handled by the JMM requirements for > volatile accesses is if there are global visibility issues that are not > addressed - but even then I would expect heavy barriers at the store > would deal with that, not at the load. (This situation reminds me of the > need for read-barriers on Alpha architecture due to the use of software > cache-coherency rather than hardware cache-coherency - but we don't have > that on ppc!) > > Sorry - There is no quick resolution here and in a couple of days I will > be heading out on vacation for two weeks. > > David > ----- > >> Best regards, >> Goetz. >> >> -- Other ports: >> The IRIW issue requires at least 3 processors to be relevant, so it might >> not happen on small machines. But I can use PPC_ONLY instead >> of PPC64_ONLY if you request so (and if we don't get rid of them). >> >> -- MemBarStoreStore after initialization >> I agree we should not change it in the ppc port. If you wish, I can >> prepare an extra webrev for hotspot-comp. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 26, 2013 2:49 AM >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Okay this is my second attempt at answering this in a reasonable way :) >> >> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>> I have to ask David to do correctness evaluation. >> >> From what I understand what we see here is an attempt to fix an >> existing issue with the implementation of volatiles so that the IRIW >> problem is addressed. The solution proposed for PPC64 is to make >> volatile reads extremely heavyweight by adding a fence() when doing the >> load. >> >> Now if this was purely handled in ppc64 source code then I would be >> happy to let them do whatever they like (surely this kills performance >> though!). But I do not agree with the changes to the shared code that >> allow this solution to be implemented - even with PPC64_ONLY this is >> polluting the shared code. My concern is similar to what I said with the >> taskQueue changes - these algorithms should be expressed using the >> correct OrderAccess operations to guarantee the desired properties >> independent of architecture. If such a "barrier" is not needed on a >> given architecture then the implementation in OrderAccess should reduce >> to a no-op. >> >> And as Vitaly points out the constructor barriers are not needed under >> the JMM. >> >>> I am fine with suggested changes because you did not change our current >>> code for our platforms (please, do not change do_exits() now). >>> But may be it should be done using more general query which is set >>> depending on platform: >>> >>> OrderAccess::needs_support_iriw_ordering() >>> >>> or similar to what we use now: >>> >>> VM_Version::needs_support_iriw_ordering() >> >> Every platform has to support IRIW this is simply part of the Java >> Memory Model, there should not be any need to call this out explicitly >> like this. >> >> Is there some subtlety of the hardware I am missing here? Are there >> visibility issues beyond the ordering constraints that the JMM defines? >>> From what I understand our ppc port is also affected. David? >> >> We can not discuss that on an OpenJDK mailing list - sorry. >> >> David >> ----- >> >>> In library_call.cpp can you add {}? New comment should be inside else {}. >>> >>> I think you should make _wrote_volatile field not ppc64 specific which >>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>> >>> In do_put_xxx() can you combine your changes: >>> >>> if (is_vol) { >>> // See comment in do_get_xxx(). >>> #ifndef PPC64 >>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>> #else >>> if (is_field) { >>> // Add MemBarRelease for constructors which write volatile field >>> (PPC64). >>> set_wrote_volatile(true); >>> } >>> #endif >>> } >>> >>> Thanks, >>> Vladimir >>> >>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>> the torture test suite: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>> >>>> Example: >>>> volatile x=0, y=0 >>>> __________ __________ __________ __________ >>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>> >>>> write(x=1) read(x) write(y=1) read(y) >>>> read(y) read(x) >>>> >>>> Disallowed: x=1, y=0 y=1, x=0 >>>> >>>> >>>> Solution: This example requires multiple-copy-atomicity. This is only >>>> assured by the sync instruction and if it is executed in the threads >>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>> and omit the sync/MemBarVolatile after the volatile store. >>>> MemBarVolatile happens to be implemented by sync. >>>> We fix this in C2 and the cpp interpreter. >>>> >>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>> fails on staxf" for taskqueue.hpp. >>>> >>>> Further this change contains a fix that assures that volatile fields >>>> written in constructors are visible before the reference gets >>>> published. >>>> >>>> >>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>> strong. >>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>> What do you think? >>>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz. >>>> From aleksey.shipilev at oracle.com Wed Nov 27 04:17:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Nov 2013 16:17:43 +0400 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52952735.6070308@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <52948ED4.9060408@oracle.com> <5294BDB1.3060501@oracle.com> <52952735.6070308@oracle.com> Message-ID: <5295E2E7.6040602@oracle.com> TL;DR: Finals are special, we all get that. But there are other possible scenarios to achieve the same effect, which is the direct consequence of the usual JMM rules. You need to subsume the entire JMM along with happens-before and commit order to understand the issue. I have posted the more rigorous explanation to c-i@ here: http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011951.html I will just make a few remarks here, where it belongs: On 11/27/2013 02:56 AM, David Holmes wrote: > A fundamental abstraction in the JMM is the happens-before relation. > There is nothing in the JMM that requires that #2 happens-before #3. Yeah, you can call happens-before the fundamental abstraction in JMM, but happens-before is not the only thing that defines valid executions. Another thing is commit order and causality, and there are provisions beyond happens-before which are in play here. If I to cite the spec, there is a huge paragraph describing how happens-before is not enough to gain the causality guarantees JMM is after. The specific part that defines how to commit the trace to check if it is valid is at play here. The complete semantics of JMM lie within JLS 17.4.{6-8}, which *use* happens-before as the important part in figuring whether the execution is well-formed or not. The proof sketch follows exactly the JMM *as spec-ed*: we construct the possible traces and show that one is committable (the one which yields 42), and another one is not (the one which yields 0). Please, please try to understand that reasoning instead of ballooning up to the comfortable but useless-here abstractions like reorderings and happens-before. >> I think further discussion about this should be held at c-i@, if you > > No it should be on javamemorymodel-discussion at cs.umd.edu That's a haunted list. I'm going to use c-i at . > The JMM is quite clear on the special treatment of only final fields The JMM is clear on the "special treatment of final fields". It is a logical error to add "only" there, because it is "denying the antecedent" in disguise: "If P, then Q; Not P. Therefore, not Q". If field is final (P) then there is a construction safety (Q). The field is not final, but volatile (Not P). Therefore, the construction safety is not gainable (Not Q). >> Please stop saying "reordering" if you want to answer the advanced JMM >> question. In JMM terms, you have to ask if there are valid executions >> which yield the default value for the non-volatile field. It's hard for >> me to answer this question at this point (sigh). > > Show me a happens-before relation that prohibits the reordering. (sigh) We need to talk about the *executions*, not the happens-before orders alone! There is obviously a race, but the point of my sketch is that the *only* *committable* execution in the presence of that race is the one which yields final-field-like semantics! That is *because* happens-before ordering in another execution is inconsistent with causality. You can't explain that by happens-before alone, you need to look into the executions! >>> If volatile gets same treatment as final, then may as well update >>> spec/Doug's cookbook to dispel the misconception. >> >> I don't think spec needs updating. Cookbook might need the update, but > > Of course the spec would need updating if volatiles are to get the same > special treatment as final fields! Same logical mistake, see above. The volatile-in-constructor effect we are discussing here is the direct consequence of JMM rules as stated. It is not explicit like with finals, but it is there implicitly in rules. What really needs adjusting is the people mindset which is locked on the idea finals are not only special in their effects, but SUPER-special by disallowing any other means to achieve the same effect. That's hard to subsume, I know that's hard, because I've been there. This is not the spec problem. This is arguably the cookbook problem which is supposed to explain some of the non-trivial things in spec. -Aleksey. From aleksey.shipilev at oracle.com Wed Nov 27 04:19:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 27 Nov 2013 16:19:43 +0400 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <5295DD0B.3030604@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> Message-ID: <5295E35F.9020704@oracle.com> On 11/27/2013 03:52 PM, David Holmes wrote: > On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >> -- Volatile in constuctor >>> AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >> We see them on PPC64. Our test machines have typically 8-32 processors >> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) > > And see follow ups - the tests are invalid. I wish to believe that, because that will make our lives easier, but... nope: http://cs.oswego.edu/pipermail/concurrency-interest/2013-November/011951.html -Aleksey. From gabriel.chivoiu at oracle.com Wed Nov 27 05:39:53 2013 From: gabriel.chivoiu at oracle.com (Gabriel Chivoiu) Date: Wed, 27 Nov 2013 05:39:53 -0800 (PST) Subject: JVM hotspot vs. JRockit Message-ID: Hi All, I need some help with respect to any sort of documentation/ presentation in terms of comparison between Hotspot JVM and JRockit JVM. Is there any convergence roadmap between Oracle's JVMs JRockit and Hotspot, that you are aware of? Particularly I am interested in a competent source which can provide me insights in topics like: . Brief overview of both JVMs, maybe sth like where they come from and a statement . why the two has been moved into one JVM? . Which parameters change, when the costumer coming from JRockit. . How can a customer "migrate" from JRockit to convergenced HotSpot JVM. What to keep in mind? How to approach this? . How to tune the new JVM, general, best practices, parameters. Thank you! Gabriel Chivoiu EMEA Presales Center Bangalore | Bucharest | Malaga Gabriel Chivoiu | Staff Sales Consulting Phone +4021 36 79172 Oracle EMEA Presales Center - Technology NUSCO TOWER, 11th Floor, 42 Pipera Street | 014254 Bucharest 2 | Romania Visit our website at HYPERLINK "http://epc.oraclecorp.com/"http://epc.oraclecorp.com Oracle is committed to developing practices and products that help protect the environment From david.r.chase at oracle.com Wed Nov 27 05:40:51 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Nov 2013 08:40:51 -0500 Subject: RFR (S + L test) : 8016839 : JSR292: AME instead of IAE when calling a method In-Reply-To: <5295DD55.90607@gmail.com> References: <30C0464C-EAD6-4AD5-B564-A76DE330CC46@oracle.com> <070FC240-946C-46D9-97A6-18DF4C50C4F8@oracle.com> <52940513.6010503@oracle.com> <03FCCE5B-6BBE-41C9-ABF2-6C2592E942A3@oracle.com> <5294901B.3080207@oracle.com> <2F7F48BF-BF9F-42F6-A9C4-F0850A8E2436@oracle.com> <529494D7.3080109@oracle.com> <5DE9D25E-3368-4533-BC55-916B7CFFF71D@oracle.com> <462248EC-69C7-467B-8949-8B51808254CE@oracle.com> <5295A1FE.1020800@oracle.com> <5295B96A.6090902@gmail.com> <5295C374.9010304@oracle.com> <5295DD55.90607@gmail.com> Message-ID: <35B7D2E9-C22A-4090-BBB7-F522B0F365D4@oracle.com> On 2013-11-27, at 6:53 AM, Peter Levart wrote: > Ah, I have misunderstood the back-porting issue. It was not about not having new class but about which existing class to use as a host that might not exist in older version of platform... > > Sorry for noise. Noise is okay. This fix was a PITA, init order can hide surprises, and I don't mind going over the details. As to the activation of the code in question, practically never, except in tests or when bozo-bytecode-generators (a remark I resemble) are making mistakes. The "initialize" of the throwIAE method is deferred until loading of a class that performs an illegal-access-override of an interface method -- e.g., interface I { int m(); } class C implements I { private int m(); } so even that requires an inconsistent set of classes, which is unlikely in any normal initialization. Longer-term/hoped-for plan is to create a custom throwIAE method each time this happens so that an informative error message can be included -- "C.m() overrides I.m() but is private" (or protected, or package-inaccessible) -- but that is tricky because we don't have a good place to put the method; by the time we learn this about class C, we have rewritten its constant pool and it is difficult to add more, and the constant pool cache is fragile-yet-critical-to-interpreter-performance. So for now, I did this. I did test it as much as I could figure out how, including running the regression test in Netbeans and poking around, and also running it under jdb on some embedded platforms and trying to think of commands that might trigger embarrassing failures. The push is in the pipeline, but if you have other tests you can suggest, it is not too late to pull the emergency stop (in particular, I am gatekeeper for hs-comp this month, so I can put off the next turn of the crank till the last moment). David From goetz.lindenmaier at sap.com Wed Nov 27 09:15:56 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Nov 2013 17:15:56 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <5295DD0B.3030604@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> Hi, I updated the webrev to fix the issues mentioned by Vladimir: http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ I did not yet add the OrderAccess::needs_support_iriw_ordering() VM_Version::needs_support_iriw_ordering() or OrderAccess::cpu_is_multiple_copy_atomic() to reduce #defined, as I got no further comment on that. WRT to the validity of the tests and the interpretation of the JMM I feel not in the position to contribute substantially. But we would like to pass the torture test suite as we consider this a substantial task in implementing a PPC port. Also we think both tests show behavior a programmer would expect. It's bad if Java code runs fine on the more common x86 platform, and then fails on ppc. This will always first be blamed on the VM. The fixes for the constructor issue are only needed because we remove the sync instruction from behind stores (parse3.cpp:320) and place it before loads. Then there is no sync between volatile store and publishing the object. So we add it again in this one case (volatile store in constructor). @David >> Sure. There also is no solution as you require for the taskqueue problem yet, >> and that's being discussed now for almost a year. >It may have started a year ago but work on it has hardly been continuous. That's not true, we did a lot of investigation and testing on this issue. And we came up with a solution we consider the best possible. If you have objections, you should at least give the draft of a better solution, we would volunteer to implement and test it. Similarly, we invested time in fixing the concurrency torture issues. @David >What is "multiple-read-atomicity"? I'm not familiar with the term and >can't find any reference to it. We learned about this reading "A Tutorial Introduction to the ARM and POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf I was wrong in one thing, it's called multiple copy atomicity, I used 'read' instead. Sorry for that. (I also fixed that in the method name above). Best regards and thanks for all your involvements, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Mittwoch, 27. November 2013 12:53 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes Hi Goetz, On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: > Hi David, > > -- Volatile in constuctor >> AFAIK we have not seen those tests fail due to a >> missing constructor barrier. > We see them on PPC64. Our test machines have typically 8-32 processors > and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) And see follow ups - the tests are invalid. > -- IRIW issue >> I can not possibly answer to the necessary level of detail with a few >> moments thought. > Sure. There also is no solution as you require for the taskqueue problem yet, > and that's being discussed now for almost a year. It may have started a year ago but work on it has hardly been continuous. >> You are implying there is a problem here that will >> impact numerous platforms (unless you can tell me why ppc is so different?) > No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a > solution with the #defines, and that's correct for all, but not nice, I admit. > (I don't really know about ARM, though). > So if I can write down a nicer solution testing for methods that are evaluated > by the C-compiler I'm happy. > > The problem is not that IRIW is not handled by the JMM, the problem > is that > store > sync > does not assure multiple-read-atomicity, > only > sync > load > does so on PPC. And you require multiple-read-atomicity to > pass that test. What is "multiple-read-atomicity"? I'm not familiar with the term and can't find any reference to it. Thanks, David The JMM is fine. And > store > MemBarVolatile > is fine on x86, sparc etc. as there exist assembler instructions that > do what is required. > > So if you are off soon, please let's come to a solution that > might be improvable in the way it's implemented, but that > allows us to implement a correct PPC64 port. > > Best regards, > Goetz. > > > > > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Tuesday, November 26, 2013 1:11 PM > To: Lindenmaier, Goetz > Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >> Hi everybody, >> >> thanks a lot for the detailed reviews! >> I'll try to answer to all in one mail. >> >>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >> We don't think it's correct if we omit the barrier after initializing >> a volatile field. Previously, we discussed this with Aleksey Shipilev >> and Doug Lea, and they agreed. >> Also, concurrency torture tests >> LongVolatileTest >> AtomicIntegerInitialValueTest >> will fail. >> (In addition, observing 0 instead of the inital value of a volatile field would be >> very counter-intuitive for Java programmers, especially in AtomicInteger.) > > The affects of unsafe publication are always surprising - volatiles do > not add anything special here. AFAIK there is nothing in the JMM that > requires the constructor barrier - discussions with Doug and Aleksey > notwithstanding. AFAIK we have not seen those tests fail due to a > missing constructor barrier. > >>> proposed for PPC64 is to make volatile reads extremely heavyweight >> Yes, it costs measurable performance. But else it is wrong. We don't >> see a way to implement this cheaper. >> >>> - these algorithms should be expressed using the correct OrderAccess operations >> Basically, I agree on this. But you also have to take into account >> that due to the different memory ordering instructions on different platforms >> just implementing something empty is not sufficient. >> An example: >> MemBarRelease // means LoadStore, StoreStore barrier >> MemBarVolatile // means StoreLoad barrier >> If these are consecutively in the code, sparc code looks like this: >> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >> MemBarVolatile --> membar(Assembler::StoreLoad) >> Just doing what is required. >> On Power, we get suboptimal code, as there are no comparable, >> fine grained operations: >> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >> I need an additional optimization that removes the lwsync. I can not implement >> MemBarRelease empty, as it is also used independently. >> >> Back to the IRIW problem. I think here we have a comparable issue. >> Doing the MemBarVolatile or the OrderAccess::fence() before the read >> is inefficient on platforms that have multiple-read-atomicity. >> >> I would propose to guard the code by >> VM_Version::cpu_is_multiple_read_atomic() or even better >> OrderAccess::cpu_is_multiple_read_atomic() >> Else, David, how would you propose to implement this platform independent? >> (Maybe we can also use above method in taskqueue.hpp.) > > I can not possibly answer to the necessary level of detail with a few > moments thought. You are implying there is a problem here that will > impact numerous platforms (unless you can tell me why ppc is so > different?) and I can not take that on face value at the moment. The > only reason I can see IRIW not being handled by the JMM requirements for > volatile accesses is if there are global visibility issues that are not > addressed - but even then I would expect heavy barriers at the store > would deal with that, not at the load. (This situation reminds me of the > need for read-barriers on Alpha architecture due to the use of software > cache-coherency rather than hardware cache-coherency - but we don't have > that on ppc!) > > Sorry - There is no quick resolution here and in a couple of days I will > be heading out on vacation for two weeks. > > David > ----- > >> Best regards, >> Goetz. >> >> -- Other ports: >> The IRIW issue requires at least 3 processors to be relevant, so it might >> not happen on small machines. But I can use PPC_ONLY instead >> of PPC64_ONLY if you request so (and if we don't get rid of them). >> >> -- MemBarStoreStore after initialization >> I agree we should not change it in the ppc port. If you wish, I can >> prepare an extra webrev for hotspot-comp. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 26, 2013 2:49 AM >> To: Vladimir Kozlov >> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Okay this is my second attempt at answering this in a reasonable way :) >> >> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>> I have to ask David to do correctness evaluation. >> >> From what I understand what we see here is an attempt to fix an >> existing issue with the implementation of volatiles so that the IRIW >> problem is addressed. The solution proposed for PPC64 is to make >> volatile reads extremely heavyweight by adding a fence() when doing the >> load. >> >> Now if this was purely handled in ppc64 source code then I would be >> happy to let them do whatever they like (surely this kills performance >> though!). But I do not agree with the changes to the shared code that >> allow this solution to be implemented - even with PPC64_ONLY this is >> polluting the shared code. My concern is similar to what I said with the >> taskQueue changes - these algorithms should be expressed using the >> correct OrderAccess operations to guarantee the desired properties >> independent of architecture. If such a "barrier" is not needed on a >> given architecture then the implementation in OrderAccess should reduce >> to a no-op. >> >> And as Vitaly points out the constructor barriers are not needed under >> the JMM. >> >>> I am fine with suggested changes because you did not change our current >>> code for our platforms (please, do not change do_exits() now). >>> But may be it should be done using more general query which is set >>> depending on platform: >>> >>> OrderAccess::needs_support_iriw_ordering() >>> >>> or similar to what we use now: >>> >>> VM_Version::needs_support_iriw_ordering() >> >> Every platform has to support IRIW this is simply part of the Java >> Memory Model, there should not be any need to call this out explicitly >> like this. >> >> Is there some subtlety of the hardware I am missing here? Are there >> visibility issues beyond the ordering constraints that the JMM defines? >>> From what I understand our ppc port is also affected. David? >> >> We can not discuss that on an OpenJDK mailing list - sorry. >> >> David >> ----- >> >>> In library_call.cpp can you add {}? New comment should be inside else {}. >>> >>> I think you should make _wrote_volatile field not ppc64 specific which >>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>> >>> In do_put_xxx() can you combine your changes: >>> >>> if (is_vol) { >>> // See comment in do_get_xxx(). >>> #ifndef PPC64 >>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>> #else >>> if (is_field) { >>> // Add MemBarRelease for constructors which write volatile field >>> (PPC64). >>> set_wrote_volatile(true); >>> } >>> #endif >>> } >>> >>> Thanks, >>> Vladimir >>> >>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>> the torture test suite: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>> >>>> Example: >>>> volatile x=0, y=0 >>>> __________ __________ __________ __________ >>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>> >>>> write(x=1) read(x) write(y=1) read(y) >>>> read(y) read(x) >>>> >>>> Disallowed: x=1, y=0 y=1, x=0 >>>> >>>> >>>> Solution: This example requires multiple-copy-atomicity. This is only >>>> assured by the sync instruction and if it is executed in the threads >>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>> and omit the sync/MemBarVolatile after the volatile store. >>>> MemBarVolatile happens to be implemented by sync. >>>> We fix this in C2 and the cpp interpreter. >>>> >>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>> fails on staxf" for taskqueue.hpp. >>>> >>>> Further this change contains a fix that assures that volatile fields >>>> written in constructors are visible before the reference gets >>>> published. >>>> >>>> >>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>> strong. >>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>> What do you think? >>>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz. >>>> From volker.simonis at gmail.com Wed Nov 27 10:02:53 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Nov 2013 19:02:53 +0100 Subject: CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs In-Reply-To: References: Message-ID: Hi Vladimir, thanks a lot for commenting on this issue in the bug report. - Regarding 'UseMemSetInBOT' I agree that we should know how memset() is implemented on Solaris/Fujitsu Sparc-X and/or how BIS is working on Fujitsu Sparc-X. Could you please find this out. I don't see how I could get this information:( But in order to be on the safe side, I think we should reset UseMemSetInBOT until then: if (is_niagara() || (is_sun4v() && is_sparc64())) { // When using CMS or G1, we cannot use memset() in BOT updates // because the sun4v/CMT version in libc_psr uses BIS which // exposes "phantom zeros" to concurrent readers. See 6948537. if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || UseG1GC)) { FLAG_SET_DEFAULT(UseMemSetInBOT, false); } Currently, this is not done, that's why the second assertion fires. But you don't see it in a product build and this really bothers me most because I don't want to run into these problems on new Fujitsu machines. What do you think? - Regarding 'is_niagara(int features)', would it be fine if I'd change: static bool is_niagara(int features) { return (features & sun4v_m) != 0; } to: static bool is_niagara(int features) { return (features & sun4v_m) != 0 && (features & sparc64_family_m) == 0; } With this change, I could leave the assertion: assert((is_T_family(features) == is_niagara(features)), "Niagara should be T series"); untouched and it would work on both, Oracle and Fujitsu CPUs. On the other hand, maybe it would be clearer to remove is_niagara(features) altogether and replace create two new function: static bool is_sparc64(int features) { return (features & sparc64_family_m) != 0; } static bool is_sun4v(int features) { return (features & sun4v_m) != 0; } Then we could change the assertion to: assert((is_T_family(features) == is_sun4v(features) || is_sparc64(features)), "Niagara should be T series"); What do you think? - Regarding UseBlockCopy and UseBlockZeroing: what do you mean by "'block init instructions' could be implemented differently on Fujitsu Sparc-X"? Currently we only check 'has_block_zeroing()' for both options, but 'has_block_zeroing()' only returns true on T4. On the other hand, Fujitsu Sparc64-X supports the 'blk_init' extension - it's just not clear if it works like for T1/T2 or like for T4. So depending on this answer we should change 'has_block_zeroing()' to also work correctly on Sparc64-X, right? On Tue, Nov 26, 2013 at 6:35 PM, Volker Simonis wrote: > Hi, > > I've just opened "JDK-8029190: VM_Version::determine_features() > asserts on Fujitsu Sparc64 CPUs" > (https://bugs.openjdk.java.net/browse/JDK-8029190) and would like to > get the input of some real SPARC experts on how this could be best > fixed: > > The whole CPU detection for SPARC CPUs seems to be targeted solely to > Sun/Oracle SPARC CPUs. > > If running on a recent Fujitsu Sparc64-X CPU, debug builds immediately > crash with: > > assert(is_T_family(features) == is_niagara(features)) failed: Niagara > should be T series > > This test can not be successful on a Fujitsu Sparc64 CPU because > is_niagara(features) tests for the sysinfo string 'SI_MACHINE' which > is 'sun4v' on both, Oracle and Fujitsu CPUs while > is_T_family(features) checks that the kernel statistics module > 'cpu_info.implementation' contains the name "SPARC-T" or "SPARC-M". > However, on Fujitsu SPARC64-X CPUs, 'cpu_info.implementation' contains > the value "SPARC64-X". > > This problem can easily be worked around by changing the above assertion > to: > > assert((is_T_family(features) == is_niagara(features)) || (features & > sparc64_family_m), "Niagara should be T series"); > > But if we are using a CMS or G1, the VM will immediately crash with > the next assertion in arguments.cpp: > > if (VM_Version::is_sun4v() && UseMemSetInBOT) { > assert(!FLAG_IS_DEFAULT(UseMemSetInBOT), "Error"); > > This is again because 'is_sun4v()' is used with the semantics of > 'is_niagara()' and in VM_Version::initialize() in vm_version_sparc.cpp > we reset 'UseMemSetInBOT' to false if 'is_niagara()' is true: > > if (is_niagara()) { > // When using CMS or G1, we cannot use memset() in BOT updates > // because the sun4v/CMT version in libc_psr uses BIS which > // exposes "phantom zeros" to concurrent readers. See 6948537. > if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || > UseG1GC)) { > FLAG_SET_DEFAULT(UseMemSetInBOT, false); > } > > We could actually fix this in the same way like before, by replacing > 'is_sun4v()' with 'is_niagara()' in the assertion, but this would > require to make at least the following functions public in > vm_version_sparc.hpp: > > static bool is_T_family(int features) { return (features & T_family_m) > != 0; } > static bool is_niagara() { return is_T_family(_features); } > > However the bigger problem is that I have no idea of what the > semantics of these attributes (i.e. is_niagara, is_T_family, > is_M_family) is for Fujitsu Sparc-X CPUs? E.g. do we need to switch of > 'UseMemSetInBOT' as well? > > There's are also other CPU-features like 'UseBlockCopy' and > 'UseBlockZeroing' which are actually detected by looking at the > instruction set extensions AND the CPU family. E.g. the above options > are only enabled if the CPU supports 'block init instructions' (which > is true on both Fujitsu Sparc64-X and new Oracle Sparc-T4 CPUs) AND > the CPU family is Sparc-T4 (which is of course only true for Oracle > SParc CPUs). > > Altogether, I think we need a real SPARC expert which knows both, the > Oracle and the Fujitsu Sparc CPUs and who can tell us which of the > Oracle Sparc features currently used in the HotSpot are available in > Fujitsu CPUs as well. Moreover we should unify the various 'has_xxx()' > and 'is_xxx()' functions from vm_version_sparc.hpp to work equally > well for both CPU types. > > Thank you and best regards, > Volker > > PS: > > - the Fujitsu Sparc64-X I have access to returns the following > instruction set extensions vector and CPU features: > > getisax(2) returned: 0x400081f0 > cpu_info.implementation: SPARC64-X (chipid 0, clock 2800 MHz) > Allocation prefetching: PREFETCH at distance 512, 3 lines of 64 bytes > PrefetchCopyIntervalInBytes 512 > PrefetchScanIntervalInBytes 512 > ContendedPaddingWidth 128 > CPU:total 16 v9, popc, vis1, vis2, blk_init, sun4v, sparc64 > > - for the Sparc-T4 I've acess to this information looks as follows: > > getisax(2) returned: 0x3ffe8df0 > cpu_info.implementation: SPARC-T4 (chipid 0, clock 2848 MHz) > Allocation prefetching: BIS at distance 64, 6 lines of 32 bytes > PrefetchCopyIntervalInBytes 512 > PrefetchScanIntervalInBytes 512 > ContendedPaddingWidth 128 > CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, > niagara_plus > > As you probably know, the full meaning of the instruction set > extensions vector can be derived by inspecting > /usr/includ/sys/auxv_SPARC.h > From vladimir.kozlov at oracle.com Wed Nov 27 11:22:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 11:22:09 -0800 Subject: CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs In-Reply-To: References: Message-ID: <52964661.7030905@oracle.com> On 11/27/13 10:02 AM, Volker Simonis wrote: > Hi Vladimir, > > thanks a lot for commenting on this issue in the bug report. > > > - Regarding 'UseMemSetInBOT' I agree that we should know how memset() is > implemented on Solaris/Fujitsu Sparc-X and/or how BIS is working on Fujitsu > Sparc-X. Could you please find this out. I don't see how I could get this > information:( I will try :) > > But in order to be on the safe side, I think we should reset UseMemSetInBOT > until then: > > if (is_niagara() || (is_sun4v() && is_sparc64())) { > // When using CMS or G1, we cannot use memset() in BOT updates > // because the sun4v/CMT version in libc_psr uses BIS which > // exposes "phantom zeros" to concurrent readers. See 6948537. > if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || UseG1GC)) > { > FLAG_SET_DEFAULT(UseMemSetInBOT, false); > } > > Currently, this is not done, that's why the second assertion fires. But you > don't see it in a product build and this really bothers me most because I > don't want to run into these problems on new Fujitsu machines. What do you > think? Totally agree. Why you need 'is_sun4v() &&' ? Can we have sparc64 which are not sun4v? > - Regarding 'is_niagara(int features)', would it be fine if I'd change: > > static bool is_niagara(int features) { return (features & sun4v_m) != 0; } > > to: > > static bool is_niagara(int features) { return (features & sun4v_m) != 0 && > (features & sparc64_family_m) == 0; } I prefer this change. Add comment that sun4v_m is true on both. > > With this change, I could leave the assertion: > > assert((is_T_family(features) == is_niagara(features)), "Niagara should > be T series"); > > untouched and it would work on both, Oracle and Fujitsu CPUs. > > On the other hand, maybe it would be clearer to remove is_niagara(features) > altogether and replace create two new function: > > static bool is_sparc64(int features) { return (features & > sparc64_family_m) != 0; } > static bool is_sun4v(int features) { return (features & > sun4v_m) != 0; } > > Then we could change the assertion to: > > assert((is_T_family(features) == is_sun4v(features) || > is_sparc64(features)), "Niagara should be T series"); > > What do you think? > > > > - Regarding UseBlockCopy and UseBlockZeroing: what do you mean by "'block > init instructions' could be implemented differently on Fujitsu Sparc-X"? > Currently we only check 'has_block_zeroing()' for both options, but > 'has_block_zeroing()' only returns true on T4. On the other hand, Fujitsu > Sparc64-X supports the 'blk_init' extension - it's just not clear if it > works like for T1/T2 or like for T4. So depending on this answer we should > change 'has_block_zeroing()' to also work correctly on Sparc64-X, right? BIS was since T1. But T4 implementation of BIS instructions GUARANTEE zeroing of cacheline before storing value (STXA) without fetching data from memory. It is used only for big arrays (BlockZeroingLowLimit) because it still need StoreLoad membar (which is expensive). See MacroAssembler::bis_zeroing(). It used for initializing new arrays before they are visible to other threads since the state of memory before membar is undefined. And I don't know how particular STXA ASI_ST_BLKINIT_PRIMARY works on Sparc64-X. Regards, Vladimir > > > > On Tue, Nov 26, 2013 at 6:35 PM, Volker Simonis wrote: > >> Hi, >> >> I've just opened "JDK-8029190: VM_Version::determine_features() >> asserts on Fujitsu Sparc64 CPUs" >> (https://bugs.openjdk.java.net/browse/JDK-8029190) and would like to >> get the input of some real SPARC experts on how this could be best >> fixed: >> >> The whole CPU detection for SPARC CPUs seems to be targeted solely to >> Sun/Oracle SPARC CPUs. >> >> If running on a recent Fujitsu Sparc64-X CPU, debug builds immediately >> crash with: >> >> assert(is_T_family(features) == is_niagara(features)) failed: Niagara >> should be T series >> >> This test can not be successful on a Fujitsu Sparc64 CPU because >> is_niagara(features) tests for the sysinfo string 'SI_MACHINE' which >> is 'sun4v' on both, Oracle and Fujitsu CPUs while >> is_T_family(features) checks that the kernel statistics module >> 'cpu_info.implementation' contains the name "SPARC-T" or "SPARC-M". >> However, on Fujitsu SPARC64-X CPUs, 'cpu_info.implementation' contains >> the value "SPARC64-X". >> >> This problem can easily be worked around by changing the above assertion >> to: >> >> assert((is_T_family(features) == is_niagara(features)) || (features & >> sparc64_family_m), "Niagara should be T series"); >> >> But if we are using a CMS or G1, the VM will immediately crash with >> the next assertion in arguments.cpp: >> >> if (VM_Version::is_sun4v() && UseMemSetInBOT) { >> assert(!FLAG_IS_DEFAULT(UseMemSetInBOT), "Error"); >> >> This is again because 'is_sun4v()' is used with the semantics of >> 'is_niagara()' and in VM_Version::initialize() in vm_version_sparc.cpp >> we reset 'UseMemSetInBOT' to false if 'is_niagara()' is true: >> >> if (is_niagara()) { >> // When using CMS or G1, we cannot use memset() in BOT updates >> // because the sun4v/CMT version in libc_psr uses BIS which >> // exposes "phantom zeros" to concurrent readers. See 6948537. >> if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || >> UseG1GC)) { >> FLAG_SET_DEFAULT(UseMemSetInBOT, false); >> } >> >> We could actually fix this in the same way like before, by replacing >> 'is_sun4v()' with 'is_niagara()' in the assertion, but this would >> require to make at least the following functions public in >> vm_version_sparc.hpp: >> >> static bool is_T_family(int features) { return (features & T_family_m) >> != 0; } >> static bool is_niagara() { return is_T_family(_features); } >> >> However the bigger problem is that I have no idea of what the >> semantics of these attributes (i.e. is_niagara, is_T_family, >> is_M_family) is for Fujitsu Sparc-X CPUs? E.g. do we need to switch of >> 'UseMemSetInBOT' as well? >> >> There's are also other CPU-features like 'UseBlockCopy' and >> 'UseBlockZeroing' which are actually detected by looking at the >> instruction set extensions AND the CPU family. E.g. the above options >> are only enabled if the CPU supports 'block init instructions' (which >> is true on both Fujitsu Sparc64-X and new Oracle Sparc-T4 CPUs) AND >> the CPU family is Sparc-T4 (which is of course only true for Oracle >> SParc CPUs). >> >> Altogether, I think we need a real SPARC expert which knows both, the >> Oracle and the Fujitsu Sparc CPUs and who can tell us which of the >> Oracle Sparc features currently used in the HotSpot are available in >> Fujitsu CPUs as well. Moreover we should unify the various 'has_xxx()' >> and 'is_xxx()' functions from vm_version_sparc.hpp to work equally >> well for both CPU types. >> >> Thank you and best regards, >> Volker >> >> PS: >> >> - the Fujitsu Sparc64-X I have access to returns the following >> instruction set extensions vector and CPU features: >> >> getisax(2) returned: 0x400081f0 >> cpu_info.implementation: SPARC64-X (chipid 0, clock 2800 MHz) >> Allocation prefetching: PREFETCH at distance 512, 3 lines of 64 bytes >> PrefetchCopyIntervalInBytes 512 >> PrefetchScanIntervalInBytes 512 >> ContendedPaddingWidth 128 >> CPU:total 16 v9, popc, vis1, vis2, blk_init, sun4v, sparc64 >> >> - for the Sparc-T4 I've acess to this information looks as follows: >> >> getisax(2) returned: 0x3ffe8df0 >> cpu_info.implementation: SPARC-T4 (chipid 0, clock 2848 MHz) >> Allocation prefetching: BIS at distance 64, 6 lines of 32 bytes >> PrefetchCopyIntervalInBytes 512 >> PrefetchScanIntervalInBytes 512 >> ContendedPaddingWidth 128 >> CPU:total 64 v9, popc, vis1, vis2, vis3, blk_init, cbcond, sun4v, >> niagara_plus >> >> As you probably know, the full meaning of the instruction set >> extensions vector can be derived by inspecting >> /usr/includ/sys/auxv_SPARC.h >> From vladimir.kozlov at oracle.com Wed Nov 27 12:40:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 12:40:59 -0800 Subject: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6CE0F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE68276@DEWDFEMB12A.global.corp.sap> <5290022B.8010009@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE687CC@DEWDFEMB12A.global.corp.sap> <5293DB6B.6020901@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C0A7@DEWDFEMB12A.global.corp.sap> <5294D372.9030209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE0F@DEWDFEMB12A.global.corp.sap> Message-ID: <529658DB.9090503@oracle.com> Yes, it is acceptable because flags are in places where they should be. I will deal with closed changes. interp_masm_ppc_64.cpp diffs are empty. load_heap_oop_with_trap_null_check() is commented. In macroAssembler_ppc.inline.hpp TrapBasedNullChecks is global: + COMPILER2_PRESENT(assert(TrapBasedNullChecks, "sanity")); c2_globals_sparc.hpp comment (x86): // Not needed on x86. opto/c2_globals.hpp can you extend flag's comment explaining when it is used. globals.hpp: typo in comment 'don;t' About allowed_deopt_reasons(), sorry I missed it before but it should be calculated after we done parsing, better just before code_gen() call in Compile constructor which compiles methods. Make it special Compile's method. The reason is too_many_traps() checks total number in all inlined methods: trap_count(reason). Regards, Vladimir On 11/27/13 7:00 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I tried to move the flags to c2_globals, but it seems not > appropriate for TrapBasedNullChecks. > It's used wherever other platforms do an implicit null check -- > which is not always guarded by ImplicitNullCheck. E.g. > MacroAssembler::null_check() (which is called null_check_throw > on ppc.) and the loads following the call to it. > Many of these are in the template interpreter, and as we intend > to do a PPC port of the template interpreter, we should consider this. > > I prepared a new webrev where I moved TrapBasedNullChecks > to globals.hpp, and TrapBasedRangeChecks to c2_globals.hpp. > http://cr.openjdk.java.net/~goetz/webrevs/8029015-2-trch/ > > Is this acceptable to you? > I'm sorry if this means even more closed changes for you. > > Best regards, > Goetz. > > PS: Did you intenionally only reply to me because you mention > the closed sources? > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 26. November 2013 18:00 > To: Lindenmaier, Goetz > Subject: Re: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks > > On 11/26/13 12:50 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> I don't see it in the ppc.ad version I have, that is why I asked >> The predicate should look like this: >> predicate(TrapBasedNullChecks && >> _kids[0]->_leaf->as_Bool()->_test._test == BoolTest::ne && >> _leaf->as_If()->_prob >= PROB_LIKELY_MAG(4) && >> Matcher::branches_to_uncommon_trap(_leaf)); >> I added the last check to jdk8 about 4 weeks ago, when merging recent >> improvements from our VM: >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/rev/3f89fd0a071d > > Okay. > >> >>> can factor out repetitive checks to a separate method in IfNode >> You mean I should add something like this: >> _leaf->as_If()->branches_unlikely() { return _prob >= PROB_LIKELY_MAG(4) } >> Maybe also including the condition to test? >> I don't think branches_to_uncommon_trap() should be called from within >> an If node, as it's a graph pattern match that's got nothing to do in a node >> implementation. >> Having it in the ad file is more flexible. E.g., I can play around with the >> probabilities. > > Okay, if it helps you. > >> >> The ARCH_FLAGS issue: >> I admit it's not intended to define ARCH_FLAGS that are used in >> platform independent code. It works though, if they are >> defined on all platforms using C2. >> The advantage is that I can make the flag 'product' on PPC, >> and 'debug' on the others. >> I should be able to switch off these flags, as debugging is >> impossible if the VM throws SIGTRAP all the time. So if >> we have to debug a product VM, I must switch them off. > > I understand what you want to do - do not generated guarded code on other platforms without #ifdef. > But it will not help since we moved code into separate method. Yes, inlined code will not be generated but separate > method will be. > > I wish we had better way without polluting all globals_.hpp files. > I would need to prepare closed changes, get reviews and test before the push. > > Thanks, > Vladimir > >> >> By the way, I have a flag UseSIGTRAP in the ppc ARCH_FLAGS. >> If I move that to globals.hpp, I could protect the code I >> changed in the os_linux.cpp file by UseSIGTRAP instead of >> #ifdef PPC64. But it must be a product flag, too. Maybe this >> does not matter in this case, as the added code in os_linux.cpp >> should not be performance relevant. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Tuesday, November 26, 2013 12:21 AM >> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(L): 8029015: PPC64 (part 216): opto: trap based null and range checks >> >> On 11/25/13 5:24 AM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> I made a new webrev: >>> http://cr.openjdk.java.net/~goetz/webrevs/8029015-1-trch/ >>> >>>> First general question. Why you did not create specialized Mach node >>>> like MachNullCheckNode to handle such cases and using existing code in >>>> lcm.cpp? Or it would be more complicated changes? >>> I think lcm is not a good place to create new nodes. The right place is the >>> matcher. Also, I would have to implement a platform independent factory >>> method to create the nodes, that is implemented on each platform. >>> And to specify a node that inherits from a shared MachNode, mayby >>> MachTrapCheckNode, requires a rule with an idea opcode. >>> Finally, I think the nodes checking ranges are not handles in lcm? >> >> I thought that in lcm you will have more opportunity to generate trap >> checks. Anyway, it is not correctness issue but performance (and may be >> not). >> I am fine with what you have now. >> >> Also I was looking on predicates for these nodes in ppc.ad and I thought >> may be you can factor out repetitive checks to a separate method in IfNode: >> >> predicate(TrapBasedNullChecks && >> _kids[0]->_leaf->as_Bool()->_test._test == BoolTest::ne && >> _leaf->as_If()->_prob >= PROB_ALWAYS); >> >> you will get more clean code there and you will not need next change: >> >> + AD.addInclude(AD._DFA_file, "opto/cfgnode.hpp"); // Use PROB_MAX in >> predicate. >> >> >>>> To avoid changes in closed sources can you put TrapBasedNullChecks and >>>> TrapBasedRangeChecks into opto/c2_globals.hpp (thay are used only by C2) >>>> and set them to 'true' if FLAG_IS_DEFAULT() in >>>> src/cpu/ppc/vm/vm_version_ppc.cpp ? >>> It's in ARCH_FLAGS, so that it can be a develop flag on sparc/x86 and a >>> product on ppc. But being in ARCH_FLAGS, closed sources should not need >>> adaptions. There is no ARCH_FLAGS for the c2_globals_.hpp files. >> >> No, they can not be ARCH_FLAGS because they are referenced in C2 shared >> code (PhaseCFG::fixup_flow()): >> >> + if ((TrapBasedNullChecks || TrapBasedRangeChecks) && >> >> They are C2 flags. To compile this code for closed sources flags have to >> be defined. I asked to define them in opto/c2_globals.hpp because >> otherwise I will have to add them to ARCH_FLAGS in closed globals_.hpp >> >> The example of strict ARCH_FLAGS is UseAddressNop which is used only in >> src/cpu/x86/vm/* files. >> >>>> You moved _allowed_reasons code to Compile::Init() which is called for >>>> stubs too. But you removed if (C->is_method_compilation()) check. Why? >>> Did I? It's still in gcm! And I also check it in branches_to_uncommon_trap(). >> >> I phrased my question not accurately. The code which set >> _allowed_reasons was done before only under (C->is_method_compilation()) >> check. >> And I see that you added the check to Compile::Init() in this version so >> it is good. >> >>>> Where branches_to_uncommon_trap() is used? >>> In the predicates in ppc.ad, but also In our zArch/s390 port. >> >> I don't see it in the ppc.ad version I have, that is why I asked: >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/09f97b967480/src/cpu/ppc/vm/ppc.ad >> >> Thanks, >> Vladimir >> >>> >>>> output.cpp: can you replace next node to move is_TrapBasedCheckNode() to >>>> MachNode class?: >>> Done. But it's the only typecheck method in MachNode now, all the others >>> are in node, as the one used a few lines above: is_MachNullCheck. But well, it's not tied >>> to a node class as the others. >>> >>> Thanks for the review and best regards, >>> Goetz. >>> >>>> Thanks, >>>> Vladimir >>> >>> On 11/22/13 6:41 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I prepared a webrev for the trap based checks feature used on PPC: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8029015-0-trch/ >>>> >>>> PPC has the tdi instruction that does a compare and raises SIGTRAP >>>> if the compare is successful. >>>> With this instruction conditional branches leading to uncommon >>>> traps can be implemented very efficiently. >>>> This is especially needed on AIX, where there are almost no >>>> possibilities for ImplicitNullChecks as the zero page is not >>>> protected. >>>> >>>> On linux, this accounts for about 2% jvm2008 performance. >>>> >>>> Possibilities for trap based range checks and trap based null checks >>>> are recognized during matching. To support this, we added a method >>>> branches_to_uncommon_trap() to be used in the predicate during >>>> matching. >>>> The computation of the final block layout must know about this, >>>> as it must place the fallthrough properly and adapt the condition >>>> in the tdi instruction. >>>> We added a method is_TrapBasedCheckNode so these nodes >>>> can be recogized in a platform independent way. >>>> >>>> Please review and test this change. >>>> >>>> Best regards, >>>> Goetz >>>> From volker.simonis at gmail.com Wed Nov 27 12:43:00 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Nov 2013 21:43:00 +0100 Subject: CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs In-Reply-To: <52964661.7030905@oracle.com> References: <52964661.7030905@oracle.com> Message-ID: On Wednesday, November 27, 2013, Vladimir Kozlov wrote: > On 11/27/13 10:02 AM, Volker Simonis wrote: > >> Hi Vladimir, >> >> thanks a lot for commenting on this issue in the bug report. >> >> >> - Regarding 'UseMemSetInBOT' I agree that we should know how memset() is >> implemented on Solaris/Fujitsu Sparc-X and/or how BIS is working on >> Fujitsu >> Sparc-X. Could you please find this out. I don't see how I could get this >> information:( >> > > I will try :) > > >> But in order to be on the safe side, I think we should reset >> UseMemSetInBOT >> until then: >> >> if (is_niagara() || (is_sun4v() && is_sparc64())) { >> // When using CMS or G1, we cannot use memset() in BOT updates >> // because the sun4v/CMT version in libc_psr uses BIS which >> // exposes "phantom zeros" to concurrent readers. See 6948537. >> if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || >> UseG1GC)) >> { >> FLAG_SET_DEFAULT(UseMemSetInBOT, false); >> } >> >> Currently, this is not done, that's why the second assertion fires. But >> you >> don't see it in a product build and this really bothers me most because I >> don't want to run into these problems on new Fujitsu machines. What do you >> think? >> > > Totally agree. Why you need 'is_sun4v() &&' ? Can we have sparc64 which > are not sun4v? Actually I simply don't know. From Wikipedia ( http://en.wikipedia.org/wiki/SPARC64_VI) I read that there exist Sparc64 V, VI, VII, VIII, IX and X, but I don't know which of them is the first that implemented sun4v. We only recently got a Sparc64-X so that's the only one I can actually look at. So I think the above check is the best I can currently do. But I will be happy to change it once we get new informations. > - Regarding 'is_niagara(int features)', would it be fine if I'd change: >> >> static bool is_niagara(int features) { return (features & sun4v_m) != 0; >> } >> >> to: >> >> static bool is_niagara(int features) { return (features & sun4v_m) != 0 >> && >> (features & sparc64_family_m) == 0; } >> > > I prefer this change. Add comment that sun4v_m is true on both. OK, I'll prepare a webrev. > > >> With this change, I could leave the assertion: >> >> assert((is_T_family(features) == is_niagara(features)), "Niagara should >> be T series"); >> >> untouched and it would work on both, Oracle and Fujitsu CPUs. >> >> On the other hand, maybe it would be clearer to remove >> is_niagara(features) >> altogether and replace create two new function: >> >> static bool is_sparc64(int features) { return (features & >> sparc64_family_m) != 0; } >> static bool is_sun4v(int features) { return (features & >> sun4v_m) != 0; } >> >> Then we could change the assertion to: >> >> assert((is_T_family(features) == is_sun4v(features) || >> is_sparc64(features)), "Niagara should be T series"); >> >> What do you think? >> >> >> >> - Regarding UseBlockCopy and UseBlockZeroing: what do you mean by "'block >> init instructions' could be implemented differently on Fujitsu Sparc-X"? >> Currently we only check 'has_block_zeroing()' for both options, but >> 'has_block_zeroing()' only returns true on T4. On the other hand, Fujitsu >> Sparc64-X supports the 'blk_init' extension - it's just not clear if it >> works like for T1/T2 or like for T4. So depending on this answer we should >> change 'has_block_zeroing()' to also work correctly on Sparc64-X, right? >> > > BIS was since T1. But T4 implementation of BIS instructions GUARANTEE > zeroing of cacheline before storing value (STXA) without fetching data from > memory. It is used only for big arrays (BlockZeroingLowLimit) because it > still need StoreLoad membar (which is expensive). See > MacroAssembler::bis_zeroing(). It used for initializing new arrays before > they are visible to other threads since the state of memory before membar > is undefined. > > And I don't know how particular STXA ASI_ST_BLKINIT_PRIMARY works on > Sparc64-X. Who could we ask? Maybe the Solaris-Kernel people (unfortunately there's no more OpenSolaris)? Maybe some Fujitsu folks? > > Regards, > Vladimir > > > > > On Tue, Nov 26, 2013 at 6:35 PM, Volker Simonis >wrote: > > Hi, > > I've just opened "JDK-8029190: VM_Version::determine_features() > asserts on Fujitsu Sparc64 CPUs" > (https://bugs.openjdk.java.net/browse/JDK-8029190) and would like to > get the input of some real SPARC experts on how this could be best > fixed: > > The whole CPU detection for SPARC CPUs seems to be targeted solely to > Sun/Oracle SPARC CPUs. > > If running on a recent Fujitsu Sparc64-X CPU, debug builds immediately > crash with: > > assert(is_T_family(features) == is_niagara(features)) failed: Niagara > should be T series > > This test can not be successful on a Fujitsu Sparc64 CPU because > is_niagara(features) tests for the sysinfo string 'SI_MACHINE' which > is 'sun4v' on both, Oracle and Fujitsu CPUs while > is_T_family(features) checks that the kernel statistics module > 'cpu_info.implementation' contains the name "SPARC-T" or "SPARC-M". > However, on Fujitsu SPARC64-X CPUs, 'cpu_info.implementation' contains > the value "SPARC64-X". > > This problem can easily be worked around by changing the above assertion > to: > > assert((is_T_family(features) == is_niagara(features)) || (features & > sparc64_family_m), "Niagara should be T series"); > > But if we are using a CMS or G1, the VM will immediately crash with > the next assertion in arguments.cpp: > > if (VM_Version::is_sun4v() && UseMemSetInBOT) { > assert(!FLAG_IS_DEFAULT(UseMemSetInBOT), "Error"); > > This is again because 'is_sun4v()' is used with the semantics of > 'is_niagara()' and in VM_Version::initialize() in vm_version_sparc.cpp > we reset 'UseMemSetInBOT' to false if 'is_niagara()' is true: > > if (is_niagara()) { > // When using CMS or G1, we cannot use memset() in BOT updates > // because the sun4v/CMT version in libc_psr uses BIS which > // exposes "phantom zeros" to concurrent readers. See 6948537. > if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || > UseG1GC)) { > FLAG_SET_DEFAULT(UseMemSetInBOT, false); > } > > We could actually fix this in the same way like before, by replacing > 'is_sun4v()' with 'is_niagara()' in the assertion, but this would > require to make at least the following functions public in > vm_version_sparc.hpp: > > static bool is_T_family(int features) { return (features & T_family_m) > != 0; } > static bool is_niagara() { return is_T_family(_features); } > > However the bigger problem is that I have no idea of what the > semantics of these attributes (i.e. is_niagara, is_T_family, > is_M_family) is for Fujitsu Sparc-X CPUs? E.g. do we need to switch of > 'UseMemSetInBOT' as well? > > There's are also other CPU-features like 'UseBlockCopy' and > 'UseBlockZeroing' which are actually detected by looking at the > instruction set extensions AND the CPU family. E.g. the above options > are only enabled if the CPU supports 'block init instructions' (which > is true on both Fujitsu Sparc64-X and new Oracle Sparc-T4 CPUs) AND > the CPU family is Sparc-T4 (which is of course only true for Oracle > SParc CPUs). > > Altogether, I think we need a real SPARC expert which knows both, the > Oracle and the Fujitsu Sparc CPUs and who can tell us which of the > Oracle Sparc features currently used in the HotSpot are available in > Fujitsu CPUs as well. Moreover we should unify the various 'has_xxx()' > and 'is_xxx()' functions from vm_version_sparc.hpp to work equally > well for both CPU types. > > Thank you and best regards, > Volker > > PS: > > - the Fujitsu Sparc64-X I have access to returns the following > instruction set extensions vector and CPU features: > > getisax(2) returned: 0x400081f0 > cpu_info.implementation: SPARC64-X (chipid 0, clock 2800 MHz) > Allocation prefetching: PREFETCH at distance 512, 3 lines of 64 bytes > PrefetchCopyIntervalInBytes 512 > PrefetchScanIntervalInBytes 512 > ContendedPaddingWidth 128 > CPU:total 16 v9, popc, vis1, vis2, blk_init, sun4v, sparc64 > > - for the Sparc-T4 I've acess to this information looks as follows: > > getisax(2) returned: 0x3ffe8df0 > cpu_info.implementation: SPARC-T4 (chipid 0, clock 2848 MHz) > Allocation prefetching: BIS at distance 64, 6 lines of 32 bytes > PrefetchCopyIntervalInBytes 512 > Prefe > > From vladimir.kozlov at oracle.com Wed Nov 27 12:59:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 12:59:32 -0800 Subject: CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs In-Reply-To: References: <52964661.7030905@oracle.com> Message-ID: <52965D34.5090207@oracle.com> >>> if (is_niagara() || (is_sun4v() && is_sparc64())) { > So I think the above check is the best I can currently do. But I will be > happy to change it once we get new informations. I think we should simple use has_blk_init() check to guard UseMemSetInBOT setting. Regards, Vladimir On 11/27/13 12:43 PM, Volker Simonis wrote: > On Wednesday, November 27, 2013, Vladimir Kozlov wrote: > >> On 11/27/13 10:02 AM, Volker Simonis wrote: >> >>> Hi Vladimir, >>> >>> thanks a lot for commenting on this issue in the bug report. >>> >>> >>> - Regarding 'UseMemSetInBOT' I agree that we should know how memset() is >>> implemented on Solaris/Fujitsu Sparc-X and/or how BIS is working on >>> Fujitsu >>> Sparc-X. Could you please find this out. I don't see how I could get this >>> information:( >>> >> >> I will try :) >> >> >>> But in order to be on the safe side, I think we should reset >>> UseMemSetInBOT >>> until then: >>> >>> if (is_niagara() || (is_sun4v() && is_sparc64())) { >>> // When using CMS or G1, we cannot use memset() in BOT updates >>> // because the sun4v/CMT version in libc_psr uses BIS which >>> // exposes "phantom zeros" to concurrent readers. See 6948537. >>> if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || >>> UseG1GC)) >>> { >>> FLAG_SET_DEFAULT(UseMemSetInBOT, false); >>> } >>> >>> Currently, this is not done, that's why the second assertion fires. But >>> you >>> don't see it in a product build and this really bothers me most because I >>> don't want to run into these problems on new Fujitsu machines. What do you >>> think? >>> >> >> Totally agree. Why you need 'is_sun4v() &&' ? Can we have sparc64 which >> are not sun4v? > > > Actually I simply don't know. From Wikipedia ( > http://en.wikipedia.org/wiki/SPARC64_VI) I read that there exist Sparc64 V, > VI, VII, VIII, IX and X, but I don't know which of them is the first that > implemented sun4v. We only recently got a Sparc64-X so that's the only one > I can actually look at. > > So I think the above check is the best I can currently do. But I will be > happy to change it once we get new informations. > > >> - Regarding 'is_niagara(int features)', would it be fine if I'd change: >>> >>> static bool is_niagara(int features) { return (features & sun4v_m) != 0; >>> } >>> >>> to: >>> >>> static bool is_niagara(int features) { return (features & sun4v_m) != 0 >>> && >>> (features & sparc64_family_m) == 0; } >>> >> >> I prefer this change. Add comment that sun4v_m is true on both. > > > OK, I'll prepare a webrev. > > >> >> >>> With this change, I could leave the assertion: >>> >>> assert((is_T_family(features) == is_niagara(features)), "Niagara should >>> be T series"); >>> >>> untouched and it would work on both, Oracle and Fujitsu CPUs. >>> >>> On the other hand, maybe it would be clearer to remove >>> is_niagara(features) >>> altogether and replace create two new function: >>> >>> static bool is_sparc64(int features) { return (features & >>> sparc64_family_m) != 0; } >>> static bool is_sun4v(int features) { return (features & >>> sun4v_m) != 0; } >>> >>> Then we could change the assertion to: >>> >>> assert((is_T_family(features) == is_sun4v(features) || >>> is_sparc64(features)), "Niagara should be T series"); >>> >>> What do you think? >>> >>> >>> >>> - Regarding UseBlockCopy and UseBlockZeroing: what do you mean by "'block >>> init instructions' could be implemented differently on Fujitsu Sparc-X"? >>> Currently we only check 'has_block_zeroing()' for both options, but >>> 'has_block_zeroing()' only returns true on T4. On the other hand, Fujitsu >>> Sparc64-X supports the 'blk_init' extension - it's just not clear if it >>> works like for T1/T2 or like for T4. So depending on this answer we should >>> change 'has_block_zeroing()' to also work correctly on Sparc64-X, right? >>> >> >> BIS was since T1. But T4 implementation of BIS instructions GUARANTEE >> zeroing of cacheline before storing value (STXA) without fetching data from >> memory. It is used only for big arrays (BlockZeroingLowLimit) because it >> still need StoreLoad membar (which is expensive). See >> MacroAssembler::bis_zeroing(). It used for initializing new arrays before >> they are visible to other threads since the state of memory before membar >> is undefined. >> >> And I don't know how particular STXA ASI_ST_BLKINIT_PRIMARY works on >> Sparc64-X. > > > Who could we ask? Maybe the Solaris-Kernel people (unfortunately there's no > more OpenSolaris)? Maybe some Fujitsu folks? > > >> >> Regards, >> Vladimir >> >> >> >> >> On Tue, Nov 26, 2013 at 6:35 PM, Volker Simonis >> wrote: >> >> Hi, >> >> I've just opened "JDK-8029190: VM_Version::determine_features() >> asserts on Fujitsu Sparc64 CPUs" >> (https://bugs.openjdk.java.net/browse/JDK-8029190) and would like to >> get the input of some real SPARC experts on how this could be best >> fixed: >> >> The whole CPU detection for SPARC CPUs seems to be targeted solely to >> Sun/Oracle SPARC CPUs. >> >> If running on a recent Fujitsu Sparc64-X CPU, debug builds immediately >> crash with: >> >> assert(is_T_family(features) == is_niagara(features)) failed: Niagara >> should be T series >> >> This test can not be successful on a Fujitsu Sparc64 CPU because >> is_niagara(features) tests for the sysinfo string 'SI_MACHINE' which >> is 'sun4v' on both, Oracle and Fujitsu CPUs while >> is_T_family(features) checks that the kernel statistics module >> 'cpu_info.implementation' contains the name "SPARC-T" or "SPARC-M". >> However, on Fujitsu SPARC64-X CPUs, 'cpu_info.implementation' contains >> the value "SPARC64-X". >> >> This problem can easily be worked around by changing the above assertion >> to: >> >> assert((is_T_family(features) == is_niagara(features)) || (features & >> sparc64_family_m), "Niagara should be T series"); >> >> But if we are using a CMS or G1, the VM will immediately crash with >> the next assertion in arguments.cpp: >> >> if (VM_Version::is_sun4v() && UseMemSetInBOT) { >> assert(!FLAG_IS_DEFAULT(UseMemSetInBOT), "Error"); >> >> This is again because 'is_sun4v()' is used with the semantics of >> 'is_niagara()' and in VM_Version::initialize() in vm_version_sparc.cpp >> we reset 'UseMemSetInBOT' to false if 'is_niagara()' is true: >> >> if (is_niagara()) { >> // When using CMS or G1, we cannot use memset() in BOT updates >> // because the sun4v/CMT version in libc_psr uses BIS which >> // exposes "phantom zeros" to concurrent readers. See 6948537. >> if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || >> UseG1GC)) { >> FLAG_SET_DEFAULT(UseMemSetInBOT, false); >> } >> >> We could actually fix this in the same way like before, by replacing >> 'is_sun4v()' with 'is_niagara()' in the assertion, but this would >> require to make at least the following functions public in >> vm_version_sparc.hpp: >> >> static bool is_T_family(int features) { return (features & T_family_m) >> != 0; } >> static bool is_niagara() { return is_T_family(_features); } >> >> However the bigger problem is that I have no idea of what the >> semantics of these attributes (i.e. is_niagara, is_T_family, >> is_M_family) is for Fujitsu Sparc-X CPUs? E.g. do we need to switch of >> 'UseMemSetInBOT' as well? >> >> There's are also other CPU-features like 'UseBlockCopy' and >> 'UseBlockZeroing' which are actually detected by looking at the >> instruction set extensions AND the CPU family. E.g. the above options >> are only enabled if the CPU supports 'block init instructions' (which >> is true on both Fujitsu Sparc64-X and new Oracle Sparc-T4 CPUs) AND >> the CPU family is Sparc-T4 (which is of course only true for Oracle >> SParc CPUs). >> >> Altogether, I think we need a real SPARC expert which knows both, the >> Oracle and the Fujitsu Sparc CPUs and who can tell us which of the >> Oracle Sparc features currently used in the HotSpot are available in >> Fujitsu CPUs as well. Moreover we should unify the various 'has_xxx()' >> and 'is_xxx()' functions from vm_version_sparc.hpp to work equally >> well for both CPU types. >> >> Thank you and best regards, >> Volker >> >> PS: >> >> - the Fujitsu Sparc64-X I have access to returns the following >> instruction set extensions vector and CPU features: >> >> getisax(2) returned: 0x400081f0 >> cpu_info.implementation: SPARC64-X (chipid 0, clock 2800 MHz) >> Allocation prefetching: PREFETCH at distance 512, 3 lines of 64 bytes >> PrefetchCopyIntervalInBytes 512 >> PrefetchScanIntervalInBytes 512 >> ContendedPaddingWidth 128 >> CPU:total 16 v9, popc, vis1, vis2, blk_init, sun4v, sparc64 >> >> - for the Sparc-T4 I've acess to this information looks as follows: >> >> getisax(2) returned: 0x3ffe8df0 >> cpu_info.implementation: SPARC-T4 (chipid 0, clock 2848 MHz) >> Allocation prefetching: BIS at distance 64, 6 lines of 32 bytes >> PrefetchCopyIntervalInBytes 512 >> Prefe >> >> From volker.simonis at gmail.com Wed Nov 27 14:04:40 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Nov 2013 23:04:40 +0100 Subject: CPU-feature detection is broken for new Fujitsu Sparc64-X CPUs In-Reply-To: <52965D34.5090207@oracle.com> References: <52964661.7030905@oracle.com> <52965D34.5090207@oracle.com> Message-ID: On Wednesday, November 27, 2013, Vladimir Kozlov wrote: > >>> if (is_niagara() || (is_sun4v() && is_sparc64())) { > > So I think the above check is the best I can currently do. But I will be > > happy to change it once we get new informations. > > I think we should simple use has_blk_init() check to guard UseMemSetInBOT > setting. > > Yes, that's good! > Regards, > Vladimir > > On 11/27/13 12:43 PM, Volker Simonis wrote: > > On Wednesday, November 27, 2013, Vladimir Kozlov wrote: > > On 11/27/13 10:02 AM, Volker Simonis wrote: > > Hi Vladimir, > > thanks a lot for commenting on this issue in the bug report. > > > - Regarding 'UseMemSetInBOT' I agree that we should know how memset() is > implemented on Solaris/Fujitsu Sparc-X and/or how BIS is working on > Fujitsu > Sparc-X. Could you please find this out. I don't see how I could get this > information:( > > > I will try :) > > > But in order to be on the safe side, I think we should reset > UseMemSetInBOT > until then: > > if (is_niagara() || (is_sun4v() && is_sparc64())) { > // When using CMS or G1, we cannot use memset() in BOT updates > // because the sun4v/CMT version in libc_psr uses BIS which > // exposes "phantom zeros" to concurrent readers. See 6948537. > if (FLAG_IS_DEFAULT(UseMemSetInBOT) && (UseConcMarkSweepGC || > UseG1GC)) > { > FLAG_SET_DEFAULT(UseMemSetInBOT, false); > } > > Currently, this is not done, that's why the second assertion fires. But > you > don't see it in a product build and this really bothers me most because I > don't want to run into these problems on new Fujitsu machines. What do you > think? > > > Totally agree. Why you need 'is_sun4v() &&' ? Can we have sparc64 which > are not sun4v? > > > > Actually I simply don't know. From Wikipedia ( > http://en.wikipedia.org/wiki/SPARC64_VI) I read that there exist Sparc64 > V, > VI, VII, VIII, IX and X, but I don't know which of them is the first that > implemented sun4v. We only recently got a Sparc64-X so that's the only one > I can actually look at. > > So I think the above check is the best I can currently do. But I will be > happy to change it once we get new informations. > > > - Regarding 'is_niagara(int features)', would it be fine if I'd change: > > > static bool is_niagara(int features) { return (features & sun4v_m) != 0; > } > > to: > > static bool is_niagara(int features) { return (features & sun4v_m) != 0 > && > (features & sparc64_family_m) == 0; } > > > I prefer this change. Add comment that sun4v_m is true on both. > > > > OK, I'll prepare a webrev. > > > > > With this change, I could leave the assertion: > > assert((is_T_family(features) == is_niagara(features)), "Niagara should > be T series"); > > untouched and it would work on both, Oracle and Fujitsu CPUs. > > On the other hand, maybe it would be clearer to remove > is_niagara(features) > altogether and replace create two new function: > > static bool is_sparc64(int features) { return (features & > sparc64_family_m) != 0; } > static bool is_sun4v(int features) { return (features & > sun4v_m) != 0; } > > Then we could change the assertion to: > > assert((is_T_family(features) == is_sun4v(features) || > is_sparc64(features)), "Niagara should be T series"); > > What do you think? > > > > - Regarding UseBlockCopy and UseBlockZeroing: what do you mean by "'block > init instructions' could be implemented differently on Fujitsu Sparc-X"? > Currently we only check 'has_block_zeroing()' for both options, but > 'has_block_zeroing()' only returns true on T4. On the other hand, Fujitsu > Sparc64-X supports the 'blk_init' extension - it's just not clear if it > works like for T1/T2 or like for T4. So depending on this answer we should > change 'has_block_zeroing()' to also work correctly on Sparc64-X, right? > > > BIS was since T1. But T4 implementation of BIS instructions GUARANTEE > zeroing of cacheline before storing value (STXA) without fetching data from > memory. It is used onl > > From vladimir.kozlov at oracle.com Wed Nov 27 14:15:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 14:15:45 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> Message-ID: <52966F11.3050309@oracle.com> On 11/27/13 9:15 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev to fix the issues mentioned by Vladimir: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ Changes in library_call.cpp are incorrect, should be NOT_PPC64(): PPC64_ONLY(insert_mem_bar(Op_MemBarVolatile)); You did not merge code in do_put_xxx() as I asked. Thanks, Vladimir > > I did not yet add the > OrderAccess::needs_support_iriw_ordering() > VM_Version::needs_support_iriw_ordering() > or > OrderAccess::cpu_is_multiple_copy_atomic() > to reduce #defined, as I got no further comment on that. > > > WRT to the validity of the tests and the interpretation of the JMM > I feel not in the position to contribute substantially. > > But we would like to pass the torture test suite as we consider > this a substantial task in implementing a PPC port. Also we think > both tests show behavior a programmer would expect. It's bad if > Java code runs fine on the more common x86 platform, and then > fails on ppc. This will always first be blamed on the VM. > > The fixes for the constructor issue are only needed because we > remove the sync instruction from behind stores (parse3.cpp:320) > and place it before loads. Then there is no sync between volatile store > and publishing the object. So we add it again in this one case > (volatile store in constructor). > > > @David >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> It may have started a year ago but work on it has hardly been continuous. > That's not true, we did a lot of investigation and testing on this issue. > And we came up with a solution we consider the best possible. If you > have objections, you should at least give the draft of a better solution, > we would volunteer to implement and test it. > Similarly, we invested time in fixing the concurrency torture issues. > > @David >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. > We learned about this reading "A Tutorial Introduction to the ARM and > POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and > Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for > Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen > and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. > http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf > > I was wrong in one thing, it's called multiple copy atomicity, I used 'read' > instead. Sorry for that. (I also fixed that in the method name above). > > Best regards and thanks for all your involvements, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 27. November 2013 12:53 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> -- Volatile in constuctor >>> AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >> We see them on PPC64. Our test machines have typically 8-32 processors >> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) > > And see follow ups - the tests are invalid. > >> -- IRIW issue >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. >> Sure. There also is no solution as you require for the taskqueue problem yet, >> and that's being discussed now for almost a year. > > It may have started a year ago but work on it has hardly been continuous. > >>> You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so different?) >> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >> solution with the #defines, and that's correct for all, but not nice, I admit. >> (I don't really know about ARM, though). >> So if I can write down a nicer solution testing for methods that are evaluated >> by the C-compiler I'm happy. >> >> The problem is not that IRIW is not handled by the JMM, the problem >> is that >> store >> sync >> does not assure multiple-read-atomicity, >> only >> sync >> load >> does so on PPC. And you require multiple-read-atomicity to >> pass that test. > > What is "multiple-read-atomicity"? I'm not familiar with the term and > can't find any reference to it. > > Thanks, > David > > The JMM is fine. And >> store >> MemBarVolatile >> is fine on x86, sparc etc. as there exist assembler instructions that >> do what is required. >> >> So if you are off soon, please let's come to a solution that >> might be improvable in the way it's implemented, but that >> allows us to implement a correct PPC64 port. >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 26, 2013 1:11 PM >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>> Hi everybody, >>> >>> thanks a lot for the detailed reviews! >>> I'll try to answer to all in one mail. >>> >>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>> We don't think it's correct if we omit the barrier after initializing >>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>> and Doug Lea, and they agreed. >>> Also, concurrency torture tests >>> LongVolatileTest >>> AtomicIntegerInitialValueTest >>> will fail. >>> (In addition, observing 0 instead of the inital value of a volatile field would be >>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >> >> The affects of unsafe publication are always surprising - volatiles do >> not add anything special here. AFAIK there is nothing in the JMM that >> requires the constructor barrier - discussions with Doug and Aleksey >> notwithstanding. AFAIK we have not seen those tests fail due to a >> missing constructor barrier. >> >>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>> Yes, it costs measurable performance. But else it is wrong. We don't >>> see a way to implement this cheaper. >>> >>>> - these algorithms should be expressed using the correct OrderAccess operations >>> Basically, I agree on this. But you also have to take into account >>> that due to the different memory ordering instructions on different platforms >>> just implementing something empty is not sufficient. >>> An example: >>> MemBarRelease // means LoadStore, StoreStore barrier >>> MemBarVolatile // means StoreLoad barrier >>> If these are consecutively in the code, sparc code looks like this: >>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>> MemBarVolatile --> membar(Assembler::StoreLoad) >>> Just doing what is required. >>> On Power, we get suboptimal code, as there are no comparable, >>> fine grained operations: >>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>> I need an additional optimization that removes the lwsync. I can not implement >>> MemBarRelease empty, as it is also used independently. >>> >>> Back to the IRIW problem. I think here we have a comparable issue. >>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>> is inefficient on platforms that have multiple-read-atomicity. >>> >>> I would propose to guard the code by >>> VM_Version::cpu_is_multiple_read_atomic() or even better >>> OrderAccess::cpu_is_multiple_read_atomic() >>> Else, David, how would you propose to implement this platform independent? >>> (Maybe we can also use above method in taskqueue.hpp.) >> >> I can not possibly answer to the necessary level of detail with a few >> moments thought. You are implying there is a problem here that will >> impact numerous platforms (unless you can tell me why ppc is so >> different?) and I can not take that on face value at the moment. The >> only reason I can see IRIW not being handled by the JMM requirements for >> volatile accesses is if there are global visibility issues that are not >> addressed - but even then I would expect heavy barriers at the store >> would deal with that, not at the load. (This situation reminds me of the >> need for read-barriers on Alpha architecture due to the use of software >> cache-coherency rather than hardware cache-coherency - but we don't have >> that on ppc!) >> >> Sorry - There is no quick resolution here and in a couple of days I will >> be heading out on vacation for two weeks. >> >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>> -- Other ports: >>> The IRIW issue requires at least 3 processors to be relevant, so it might >>> not happen on small machines. But I can use PPC_ONLY instead >>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>> >>> -- MemBarStoreStore after initialization >>> I agree we should not change it in the ppc port. If you wish, I can >>> prepare an extra webrev for hotspot-comp. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 2:49 AM >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Okay this is my second attempt at answering this in a reasonable way :) >>> >>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>> I have to ask David to do correctness evaluation. >>> >>> From what I understand what we see here is an attempt to fix an >>> existing issue with the implementation of volatiles so that the IRIW >>> problem is addressed. The solution proposed for PPC64 is to make >>> volatile reads extremely heavyweight by adding a fence() when doing the >>> load. >>> >>> Now if this was purely handled in ppc64 source code then I would be >>> happy to let them do whatever they like (surely this kills performance >>> though!). But I do not agree with the changes to the shared code that >>> allow this solution to be implemented - even with PPC64_ONLY this is >>> polluting the shared code. My concern is similar to what I said with the >>> taskQueue changes - these algorithms should be expressed using the >>> correct OrderAccess operations to guarantee the desired properties >>> independent of architecture. If such a "barrier" is not needed on a >>> given architecture then the implementation in OrderAccess should reduce >>> to a no-op. >>> >>> And as Vitaly points out the constructor barriers are not needed under >>> the JMM. >>> >>>> I am fine with suggested changes because you did not change our current >>>> code for our platforms (please, do not change do_exits() now). >>>> But may be it should be done using more general query which is set >>>> depending on platform: >>>> >>>> OrderAccess::needs_support_iriw_ordering() >>>> >>>> or similar to what we use now: >>>> >>>> VM_Version::needs_support_iriw_ordering() >>> >>> Every platform has to support IRIW this is simply part of the Java >>> Memory Model, there should not be any need to call this out explicitly >>> like this. >>> >>> Is there some subtlety of the hardware I am missing here? Are there >>> visibility issues beyond the ordering constraints that the JMM defines? >>>> From what I understand our ppc port is also affected. David? >>> >>> We can not discuss that on an OpenJDK mailing list - sorry. >>> >>> David >>> ----- >>> >>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>> >>>> I think you should make _wrote_volatile field not ppc64 specific which >>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>> >>>> In do_put_xxx() can you combine your changes: >>>> >>>> if (is_vol) { >>>> // See comment in do_get_xxx(). >>>> #ifndef PPC64 >>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>> #else >>>> if (is_field) { >>>> // Add MemBarRelease for constructors which write volatile field >>>> (PPC64). >>>> set_wrote_volatile(true); >>>> } >>>> #endif >>>> } >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>> the torture test suite: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>> >>>>> Example: >>>>> volatile x=0, y=0 >>>>> __________ __________ __________ __________ >>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>> >>>>> write(x=1) read(x) write(y=1) read(y) >>>>> read(y) read(x) >>>>> >>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>> >>>>> >>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>> assured by the sync instruction and if it is executed in the threads >>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>> MemBarVolatile happens to be implemented by sync. >>>>> We fix this in C2 and the cpp interpreter. >>>>> >>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>> fails on staxf" for taskqueue.hpp. >>>>> >>>>> Further this change contains a fix that assures that volatile fields >>>>> written in constructors are visible before the reference gets >>>>> published. >>>>> >>>>> >>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>> strong. >>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>> What do you think? >>>>> >>>>> Please review and test this change. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From goetz.lindenmaier at sap.com Wed Nov 27 14:42:26 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Nov 2013 22:42:26 +0000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52966F11.3050309@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52966F11.3050309@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CE6CF66@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for the hint with the wrong macro, would have been bad to debug. I fixed both. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, November 27, 2013 11:16 PM To: Lindenmaier, Goetz; David Holmes Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes On 11/27/13 9:15 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev to fix the issues mentioned by Vladimir: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ Changes in library_call.cpp are incorrect, should be NOT_PPC64(): PPC64_ONLY(insert_mem_bar(Op_MemBarVolatile)); You did not merge code in do_put_xxx() as I asked. Thanks, Vladimir > > I did not yet add the > OrderAccess::needs_support_iriw_ordering() > VM_Version::needs_support_iriw_ordering() > or > OrderAccess::cpu_is_multiple_copy_atomic() > to reduce #defined, as I got no further comment on that. > > > WRT to the validity of the tests and the interpretation of the JMM > I feel not in the position to contribute substantially. > > But we would like to pass the torture test suite as we consider > this a substantial task in implementing a PPC port. Also we think > both tests show behavior a programmer would expect. It's bad if > Java code runs fine on the more common x86 platform, and then > fails on ppc. This will always first be blamed on the VM. > > The fixes for the constructor issue are only needed because we > remove the sync instruction from behind stores (parse3.cpp:320) > and place it before loads. Then there is no sync between volatile store > and publishing the object. So we add it again in this one case > (volatile store in constructor). > > > @David >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> It may have started a year ago but work on it has hardly been continuous. > That's not true, we did a lot of investigation and testing on this issue. > And we came up with a solution we consider the best possible. If you > have objections, you should at least give the draft of a better solution, > we would volunteer to implement and test it. > Similarly, we invested time in fixing the concurrency torture issues. > > @David >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. > We learned about this reading "A Tutorial Introduction to the ARM and > POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and > Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for > Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen > and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. > http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf > > I was wrong in one thing, it's called multiple copy atomicity, I used 'read' > instead. Sorry for that. (I also fixed that in the method name above). > > Best regards and thanks for all your involvements, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 27. November 2013 12:53 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> -- Volatile in constuctor >>> AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >> We see them on PPC64. Our test machines have typically 8-32 processors >> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) > > And see follow ups - the tests are invalid. > >> -- IRIW issue >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. >> Sure. There also is no solution as you require for the taskqueue problem yet, >> and that's being discussed now for almost a year. > > It may have started a year ago but work on it has hardly been continuous. > >>> You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so different?) >> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >> solution with the #defines, and that's correct for all, but not nice, I admit. >> (I don't really know about ARM, though). >> So if I can write down a nicer solution testing for methods that are evaluated >> by the C-compiler I'm happy. >> >> The problem is not that IRIW is not handled by the JMM, the problem >> is that >> store >> sync >> does not assure multiple-read-atomicity, >> only >> sync >> load >> does so on PPC. And you require multiple-read-atomicity to >> pass that test. > > What is "multiple-read-atomicity"? I'm not familiar with the term and > can't find any reference to it. > > Thanks, > David > > The JMM is fine. And >> store >> MemBarVolatile >> is fine on x86, sparc etc. as there exist assembler instructions that >> do what is required. >> >> So if you are off soon, please let's come to a solution that >> might be improvable in the way it's implemented, but that >> allows us to implement a correct PPC64 port. >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 26, 2013 1:11 PM >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>> Hi everybody, >>> >>> thanks a lot for the detailed reviews! >>> I'll try to answer to all in one mail. >>> >>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>> We don't think it's correct if we omit the barrier after initializing >>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>> and Doug Lea, and they agreed. >>> Also, concurrency torture tests >>> LongVolatileTest >>> AtomicIntegerInitialValueTest >>> will fail. >>> (In addition, observing 0 instead of the inital value of a volatile field would be >>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >> >> The affects of unsafe publication are always surprising - volatiles do >> not add anything special here. AFAIK there is nothing in the JMM that >> requires the constructor barrier - discussions with Doug and Aleksey >> notwithstanding. AFAIK we have not seen those tests fail due to a >> missing constructor barrier. >> >>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>> Yes, it costs measurable performance. But else it is wrong. We don't >>> see a way to implement this cheaper. >>> >>>> - these algorithms should be expressed using the correct OrderAccess operations >>> Basically, I agree on this. But you also have to take into account >>> that due to the different memory ordering instructions on different platforms >>> just implementing something empty is not sufficient. >>> An example: >>> MemBarRelease // means LoadStore, StoreStore barrier >>> MemBarVolatile // means StoreLoad barrier >>> If these are consecutively in the code, sparc code looks like this: >>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>> MemBarVolatile --> membar(Assembler::StoreLoad) >>> Just doing what is required. >>> On Power, we get suboptimal code, as there are no comparable, >>> fine grained operations: >>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>> I need an additional optimization that removes the lwsync. I can not implement >>> MemBarRelease empty, as it is also used independently. >>> >>> Back to the IRIW problem. I think here we have a comparable issue. >>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>> is inefficient on platforms that have multiple-read-atomicity. >>> >>> I would propose to guard the code by >>> VM_Version::cpu_is_multiple_read_atomic() or even better >>> OrderAccess::cpu_is_multiple_read_atomic() >>> Else, David, how would you propose to implement this platform independent? >>> (Maybe we can also use above method in taskqueue.hpp.) >> >> I can not possibly answer to the necessary level of detail with a few >> moments thought. You are implying there is a problem here that will >> impact numerous platforms (unless you can tell me why ppc is so >> different?) and I can not take that on face value at the moment. The >> only reason I can see IRIW not being handled by the JMM requirements for >> volatile accesses is if there are global visibility issues that are not >> addressed - but even then I would expect heavy barriers at the store >> would deal with that, not at the load. (This situation reminds me of the >> need for read-barriers on Alpha architecture due to the use of software >> cache-coherency rather than hardware cache-coherency - but we don't have >> that on ppc!) >> >> Sorry - There is no quick resolution here and in a couple of days I will >> be heading out on vacation for two weeks. >> >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>> -- Other ports: >>> The IRIW issue requires at least 3 processors to be relevant, so it might >>> not happen on small machines. But I can use PPC_ONLY instead >>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>> >>> -- MemBarStoreStore after initialization >>> I agree we should not change it in the ppc port. If you wish, I can >>> prepare an extra webrev for hotspot-comp. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 2:49 AM >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Okay this is my second attempt at answering this in a reasonable way :) >>> >>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>> I have to ask David to do correctness evaluation. >>> >>> From what I understand what we see here is an attempt to fix an >>> existing issue with the implementation of volatiles so that the IRIW >>> problem is addressed. The solution proposed for PPC64 is to make >>> volatile reads extremely heavyweight by adding a fence() when doing the >>> load. >>> >>> Now if this was purely handled in ppc64 source code then I would be >>> happy to let them do whatever they like (surely this kills performance >>> though!). But I do not agree with the changes to the shared code that >>> allow this solution to be implemented - even with PPC64_ONLY this is >>> polluting the shared code. My concern is similar to what I said with the >>> taskQueue changes - these algorithms should be expressed using the >>> correct OrderAccess operations to guarantee the desired properties >>> independent of architecture. If such a "barrier" is not needed on a >>> given architecture then the implementation in OrderAccess should reduce >>> to a no-op. >>> >>> And as Vitaly points out the constructor barriers are not needed under >>> the JMM. >>> >>>> I am fine with suggested changes because you did not change our current >>>> code for our platforms (please, do not change do_exits() now). >>>> But may be it should be done using more general query which is set >>>> depending on platform: >>>> >>>> OrderAccess::needs_support_iriw_ordering() >>>> >>>> or similar to what we use now: >>>> >>>> VM_Version::needs_support_iriw_ordering() >>> >>> Every platform has to support IRIW this is simply part of the Java >>> Memory Model, there should not be any need to call this out explicitly >>> like this. >>> >>> Is there some subtlety of the hardware I am missing here? Are there >>> visibility issues beyond the ordering constraints that the JMM defines? >>>> From what I understand our ppc port is also affected. David? >>> >>> We can not discuss that on an OpenJDK mailing list - sorry. >>> >>> David >>> ----- >>> >>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>> >>>> I think you should make _wrote_volatile field not ppc64 specific which >>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>> >>>> In do_put_xxx() can you combine your changes: >>>> >>>> if (is_vol) { >>>> // See comment in do_get_xxx(). >>>> #ifndef PPC64 >>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>> #else >>>> if (is_field) { >>>> // Add MemBarRelease for constructors which write volatile field >>>> (PPC64). >>>> set_wrote_volatile(true); >>>> } >>>> #endif >>>> } >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>> the torture test suite: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>> >>>>> Example: >>>>> volatile x=0, y=0 >>>>> __________ __________ __________ __________ >>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>> >>>>> write(x=1) read(x) write(y=1) read(y) >>>>> read(y) read(x) >>>>> >>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>> >>>>> >>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>> assured by the sync instruction and if it is executed in the threads >>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>> MemBarVolatile happens to be implemented by sync. >>>>> We fix this in C2 and the cpp interpreter. >>>>> >>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>> fails on staxf" for taskqueue.hpp. >>>>> >>>>> Further this change contains a fix that assures that volatile fields >>>>> written in constructors are visible before the reference gets >>>>> published. >>>>> >>>>> >>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>> strong. >>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>> What do you think? >>>>> >>>>> Please review and test this change. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From vladimir.kozlov at oracle.com Wed Nov 27 15:06:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Nov 2013 15:06:28 -0800 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6CF66@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52966F11.3050309@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CF66@DEWDFEMB12A.global.corp.sap> Message-ID: <52967AF4.5030400@oracle.com> From my point it is fine. But you need approval from David too. Thanks, Vladimir On 11/27/13 2:42 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for the hint with the wrong macro, would have been > bad to debug. I fixed both. > > Best regards, > Goetz. > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, November 27, 2013 11:16 PM > To: Lindenmaier, Goetz; David Holmes > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > On 11/27/13 9:15 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I updated the webrev to fix the issues mentioned by Vladimir: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ > > Changes in library_call.cpp are incorrect, should be NOT_PPC64(): > > PPC64_ONLY(insert_mem_bar(Op_MemBarVolatile)); > > You did not merge code in do_put_xxx() as I asked. > > Thanks, > Vladimir > >> >> I did not yet add the >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> or >> OrderAccess::cpu_is_multiple_copy_atomic() >> to reduce #defined, as I got no further comment on that. >> >> >> WRT to the validity of the tests and the interpretation of the JMM >> I feel not in the position to contribute substantially. >> >> But we would like to pass the torture test suite as we consider >> this a substantial task in implementing a PPC port. Also we think >> both tests show behavior a programmer would expect. It's bad if >> Java code runs fine on the more common x86 platform, and then >> fails on ppc. This will always first be blamed on the VM. >> >> The fixes for the constructor issue are only needed because we >> remove the sync instruction from behind stores (parse3.cpp:320) >> and place it before loads. Then there is no sync between volatile store >> and publishing the object. So we add it again in this one case >> (volatile store in constructor). >> >> >> @David >>>> Sure. There also is no solution as you require for the taskqueue problem yet, >>>> and that's being discussed now for almost a year. >>> It may have started a year ago but work on it has hardly been continuous. >> That's not true, we did a lot of investigation and testing on this issue. >> And we came up with a solution we consider the best possible. If you >> have objections, you should at least give the draft of a better solution, >> we would volunteer to implement and test it. >> Similarly, we invested time in fixing the concurrency torture issues. >> >> @David >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >> We learned about this reading "A Tutorial Introduction to the ARM and >> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. >> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >> >> I was wrong in one thing, it's called multiple copy atomicity, I used 'read' >> instead. Sorry for that. (I also fixed that in the method name above). >> >> Best regards and thanks for all your involvements, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 27. November 2013 12:53 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> -- Volatile in constuctor >>>> AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>> We see them on PPC64. Our test machines have typically 8-32 processors >>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >> >> And see follow ups - the tests are invalid. >> >>> -- IRIW issue >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> >> It may have started a year ago but work on it has hardly been continuous. >> >>>> You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so different?) >>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >>> solution with the #defines, and that's correct for all, but not nice, I admit. >>> (I don't really know about ARM, though). >>> So if I can write down a nicer solution testing for methods that are evaluated >>> by the C-compiler I'm happy. >>> >>> The problem is not that IRIW is not handled by the JMM, the problem >>> is that >>> store >>> sync >>> does not assure multiple-read-atomicity, >>> only >>> sync >>> load >>> does so on PPC. And you require multiple-read-atomicity to >>> pass that test. >> >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. >> >> Thanks, >> David >> >> The JMM is fine. And >>> store >>> MemBarVolatile >>> is fine on x86, sparc etc. as there exist assembler instructions that >>> do what is required. >>> >>> So if you are off soon, please let's come to a solution that >>> might be improvable in the way it's implemented, but that >>> allows us to implement a correct PPC64 port. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 1:11 PM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>>> Hi everybody, >>>> >>>> thanks a lot for the detailed reviews! >>>> I'll try to answer to all in one mail. >>>> >>>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>>> We don't think it's correct if we omit the barrier after initializing >>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>> and Doug Lea, and they agreed. >>>> Also, concurrency torture tests >>>> LongVolatileTest >>>> AtomicIntegerInitialValueTest >>>> will fail. >>>> (In addition, observing 0 instead of the inital value of a volatile field would be >>>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >>> >>> The affects of unsafe publication are always surprising - volatiles do >>> not add anything special here. AFAIK there is nothing in the JMM that >>> requires the constructor barrier - discussions with Doug and Aleksey >>> notwithstanding. AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >>> >>>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>> see a way to implement this cheaper. >>>> >>>>> - these algorithms should be expressed using the correct OrderAccess operations >>>> Basically, I agree on this. But you also have to take into account >>>> that due to the different memory ordering instructions on different platforms >>>> just implementing something empty is not sufficient. >>>> An example: >>>> MemBarRelease // means LoadStore, StoreStore barrier >>>> MemBarVolatile // means StoreLoad barrier >>>> If these are consecutively in the code, sparc code looks like this: >>>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>> Just doing what is required. >>>> On Power, we get suboptimal code, as there are no comparable, >>>> fine grained operations: >>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>>> I need an additional optimization that removes the lwsync. I can not implement >>>> MemBarRelease empty, as it is also used independently. >>>> >>>> Back to the IRIW problem. I think here we have a comparable issue. >>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>> is inefficient on platforms that have multiple-read-atomicity. >>>> >>>> I would propose to guard the code by >>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>> OrderAccess::cpu_is_multiple_read_atomic() >>>> Else, David, how would you propose to implement this platform independent? >>>> (Maybe we can also use above method in taskqueue.hpp.) >>> >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so >>> different?) and I can not take that on face value at the moment. The >>> only reason I can see IRIW not being handled by the JMM requirements for >>> volatile accesses is if there are global visibility issues that are not >>> addressed - but even then I would expect heavy barriers at the store >>> would deal with that, not at the load. (This situation reminds me of the >>> need for read-barriers on Alpha architecture due to the use of software >>> cache-coherency rather than hardware cache-coherency - but we don't have >>> that on ppc!) >>> >>> Sorry - There is no quick resolution here and in a couple of days I will >>> be heading out on vacation for two weeks. >>> >>> David >>> ----- >>> >>>> Best regards, >>>> Goetz. >>>> >>>> -- Other ports: >>>> The IRIW issue requires at least 3 processors to be relevant, so it might >>>> not happen on small machines. But I can use PPC_ONLY instead >>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>> >>>> -- MemBarStoreStore after initialization >>>> I agree we should not change it in the ppc port. If you wish, I can >>>> prepare an extra webrev for hotspot-comp. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>>> >>>> Okay this is my second attempt at answering this in a reasonable way :) >>>> >>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>>> I have to ask David to do correctness evaluation. >>>> >>>> From what I understand what we see here is an attempt to fix an >>>> existing issue with the implementation of volatiles so that the IRIW >>>> problem is addressed. The solution proposed for PPC64 is to make >>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>> load. >>>> >>>> Now if this was purely handled in ppc64 source code then I would be >>>> happy to let them do whatever they like (surely this kills performance >>>> though!). But I do not agree with the changes to the shared code that >>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>> polluting the shared code. My concern is similar to what I said with the >>>> taskQueue changes - these algorithms should be expressed using the >>>> correct OrderAccess operations to guarantee the desired properties >>>> independent of architecture. If such a "barrier" is not needed on a >>>> given architecture then the implementation in OrderAccess should reduce >>>> to a no-op. >>>> >>>> And as Vitaly points out the constructor barriers are not needed under >>>> the JMM. >>>> >>>>> I am fine with suggested changes because you did not change our current >>>>> code for our platforms (please, do not change do_exits() now). >>>>> But may be it should be done using more general query which is set >>>>> depending on platform: >>>>> >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> >>>>> or similar to what we use now: >>>>> >>>>> VM_Version::needs_support_iriw_ordering() >>>> >>>> Every platform has to support IRIW this is simply part of the Java >>>> Memory Model, there should not be any need to call this out explicitly >>>> like this. >>>> >>>> Is there some subtlety of the hardware I am missing here? Are there >>>> visibility issues beyond the ordering constraints that the JMM defines? >>>>> From what I understand our ppc port is also affected. David? >>>> >>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>> >>>> David >>>> ----- >>>> >>>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>>> >>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>> >>>>> In do_put_xxx() can you combine your changes: >>>>> >>>>> if (is_vol) { >>>>> // See comment in do_get_xxx(). >>>>> #ifndef PPC64 >>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>> #else >>>>> if (is_field) { >>>>> // Add MemBarRelease for constructors which write volatile field >>>>> (PPC64). >>>>> set_wrote_volatile(true); >>>>> } >>>>> #endif >>>>> } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>>> Hi, >>>>>> >>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>> the torture test suite: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>> >>>>>> Example: >>>>>> volatile x=0, y=0 >>>>>> __________ __________ __________ __________ >>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>> >>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>> read(y) read(x) >>>>>> >>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>> >>>>>> >>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>> assured by the sync instruction and if it is executed in the threads >>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>> MemBarVolatile happens to be implemented by sync. >>>>>> We fix this in C2 and the cpp interpreter. >>>>>> >>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>> fails on staxf" for taskqueue.hpp. >>>>>> >>>>>> Further this change contains a fix that assures that volatile fields >>>>>> written in constructors are visible before the reference gets >>>>>> published. >>>>>> >>>>>> >>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>> strong. >>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>> What do you think? >>>>>> >>>>>> Please review and test this change. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> From david.holmes at oracle.com Wed Nov 27 15:33:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Nov 2013 09:33:59 +1000 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> Message-ID: <52968167.4050906@oracle.com> TL;DR version: Discussion on the c-i list has now confirmed that a constructor-barrier for volatiles is not required as part of the JMM specification. It *may* be required in an implementation that doesn't pre-zero memory to ensure you can't see uninitialized fields. So the tests for this are invalid and this part of the patch is not needed in general (ppc64 may need it due to other factors). Re: "multiple copy atomicity" - first thanks for correcting the term :) Second thanks for the reference to that paper! For reference: "The memory system (perhaps involving a hierarchy of buffers and a complex interconnect) does not guarantee that a write becomes visible to all other hardware threads at the same time point; these architectures are not multiple-copy atomic." This is the visibility issue that I referred to and affects both ARM and PPC. But of course it is normally handled by using suitable barriers after the stores that need to be visible. I think the crux of the current issue is what you wrote below: > The fixes for the constructor issue are only needed because we > remove the sync instruction from behind stores (parse3.cpp:320) > and place it before loads. I hadn't grasped this part. Obviously if you fail to do the sync after the store then you have to do something around the loads to get the same results! I still don't know what lead you to the conclusion that the only way to fix the IRIW issue was to put the fence before the load - maybe when I get the chance to read that paper in full it will be clearer. So ... the basic problem is that the current structure in the VM has hard-wired one choice of how to get the right semantics for volatile variables. You now want to customize that but not all the requisite hooks are present. It would be better if volatile_load and volatile_store were factored out so that they could be implemented as desired per-platform. Alternatively there could be pre- and post- hooks that could then be customized per platform. Otherwise you need platform-specific ifdef's to handle it as per your patch. I'm not happy with the ifdef approach but I won't block it. I think this is an area where a lot of clean up is needed in the VM. The barrier abstractions are a confused mess in my opinion. Thanks, David ----- On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: > Hi, > > I updated the webrev to fix the issues mentioned by Vladimir: > http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ > > I did not yet add the > OrderAccess::needs_support_iriw_ordering() > VM_Version::needs_support_iriw_ordering() > or > OrderAccess::cpu_is_multiple_copy_atomic() > to reduce #defined, as I got no further comment on that. > > > WRT to the validity of the tests and the interpretation of the JMM > I feel not in the position to contribute substantially. > > But we would like to pass the torture test suite as we consider > this a substantial task in implementing a PPC port. Also we think > both tests show behavior a programmer would expect. It's bad if > Java code runs fine on the more common x86 platform, and then > fails on ppc. This will always first be blamed on the VM. > > The fixes for the constructor issue are only needed because we > remove the sync instruction from behind stores (parse3.cpp:320) > and place it before loads. Then there is no sync between volatile store > and publishing the object. So we add it again in this one case > (volatile store in constructor). > > > @David >>> Sure. There also is no solution as you require for the taskqueue problem yet, >>> and that's being discussed now for almost a year. >> It may have started a year ago but work on it has hardly been continuous. > That's not true, we did a lot of investigation and testing on this issue. > And we came up with a solution we consider the best possible. If you > have objections, you should at least give the draft of a better solution, > we would volunteer to implement and test it. > Similarly, we invested time in fixing the concurrency torture issues. > > @David >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. > We learned about this reading "A Tutorial Introduction to the ARM and > POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and > Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for > Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen > and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue problem. > http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf > > I was wrong in one thing, it's called multiple copy atomicity, I used 'read' > instead. Sorry for that. (I also fixed that in the method name above). > > Best regards and thanks for all your involvements, > Goetz. > > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 27. November 2013 12:53 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes > > Hi Goetz, > > On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> -- Volatile in constuctor >>> AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >> We see them on PPC64. Our test machines have typically 8-32 processors >> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) > > And see follow ups - the tests are invalid. > >> -- IRIW issue >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. >> Sure. There also is no solution as you require for the taskqueue problem yet, >> and that's being discussed now for almost a year. > > It may have started a year ago but work on it has hardly been continuous. > >>> You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so different?) >> No, only PPC does not have 'multiple-read-atomicity'. Therefore I contributed a >> solution with the #defines, and that's correct for all, but not nice, I admit. >> (I don't really know about ARM, though). >> So if I can write down a nicer solution testing for methods that are evaluated >> by the C-compiler I'm happy. >> >> The problem is not that IRIW is not handled by the JMM, the problem >> is that >> store >> sync >> does not assure multiple-read-atomicity, >> only >> sync >> load >> does so on PPC. And you require multiple-read-atomicity to >> pass that test. > > What is "multiple-read-atomicity"? I'm not familiar with the term and > can't find any reference to it. > > Thanks, > David > > The JMM is fine. And >> store >> MemBarVolatile >> is fine on x86, sparc etc. as there exist assembler instructions that >> do what is required. >> >> So if you are off soon, please let's come to a solution that >> might be improvable in the way it's implemented, but that >> allows us to implement a correct PPC64 port. >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Tuesday, November 26, 2013 1:11 PM >> To: Lindenmaier, Goetz >> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>> Hi everybody, >>> >>> thanks a lot for the detailed reviews! >>> I'll try to answer to all in one mail. >>> >>>> Volatile fields written in constructor aren't guaranteed by JMM to occur before the reference is assigned; >>> We don't think it's correct if we omit the barrier after initializing >>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>> and Doug Lea, and they agreed. >>> Also, concurrency torture tests >>> LongVolatileTest >>> AtomicIntegerInitialValueTest >>> will fail. >>> (In addition, observing 0 instead of the inital value of a volatile field would be >>> very counter-intuitive for Java programmers, especially in AtomicInteger.) >> >> The affects of unsafe publication are always surprising - volatiles do >> not add anything special here. AFAIK there is nothing in the JMM that >> requires the constructor barrier - discussions with Doug and Aleksey >> notwithstanding. AFAIK we have not seen those tests fail due to a >> missing constructor barrier. >> >>>> proposed for PPC64 is to make volatile reads extremely heavyweight >>> Yes, it costs measurable performance. But else it is wrong. We don't >>> see a way to implement this cheaper. >>> >>>> - these algorithms should be expressed using the correct OrderAccess operations >>> Basically, I agree on this. But you also have to take into account >>> that due to the different memory ordering instructions on different platforms >>> just implementing something empty is not sufficient. >>> An example: >>> MemBarRelease // means LoadStore, StoreStore barrier >>> MemBarVolatile // means StoreLoad barrier >>> If these are consecutively in the code, sparc code looks like this: >>> MemBarRelease --> membar(Assembler::LoadStore | Assembler::StoreStore) >>> MemBarVolatile --> membar(Assembler::StoreLoad) >>> Just doing what is required. >>> On Power, we get suboptimal code, as there are no comparable, >>> fine grained operations: >>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, LoadLoad >>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, LoadLoad, StoreLoad >>> obviously, the lwsync is superfluous. Thus, as PPC operations are more (too) powerful, >>> I need an additional optimization that removes the lwsync. I can not implement >>> MemBarRelease empty, as it is also used independently. >>> >>> Back to the IRIW problem. I think here we have a comparable issue. >>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>> is inefficient on platforms that have multiple-read-atomicity. >>> >>> I would propose to guard the code by >>> VM_Version::cpu_is_multiple_read_atomic() or even better >>> OrderAccess::cpu_is_multiple_read_atomic() >>> Else, David, how would you propose to implement this platform independent? >>> (Maybe we can also use above method in taskqueue.hpp.) >> >> I can not possibly answer to the necessary level of detail with a few >> moments thought. You are implying there is a problem here that will >> impact numerous platforms (unless you can tell me why ppc is so >> different?) and I can not take that on face value at the moment. The >> only reason I can see IRIW not being handled by the JMM requirements for >> volatile accesses is if there are global visibility issues that are not >> addressed - but even then I would expect heavy barriers at the store >> would deal with that, not at the load. (This situation reminds me of the >> need for read-barriers on Alpha architecture due to the use of software >> cache-coherency rather than hardware cache-coherency - but we don't have >> that on ppc!) >> >> Sorry - There is no quick resolution here and in a couple of days I will >> be heading out on vacation for two weeks. >> >> David >> ----- >> >>> Best regards, >>> Goetz. >>> >>> -- Other ports: >>> The IRIW issue requires at least 3 processors to be relevant, so it might >>> not happen on small machines. But I can use PPC_ONLY instead >>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>> >>> -- MemBarStoreStore after initialization >>> I agree we should not change it in the ppc port. If you wish, I can >>> prepare an extra webrev for hotspot-comp. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 2:49 AM >>> To: Vladimir Kozlov >>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes >>> >>> Okay this is my second attempt at answering this in a reasonable way :) >>> >>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>> I have to ask David to do correctness evaluation. >>> >>> From what I understand what we see here is an attempt to fix an >>> existing issue with the implementation of volatiles so that the IRIW >>> problem is addressed. The solution proposed for PPC64 is to make >>> volatile reads extremely heavyweight by adding a fence() when doing the >>> load. >>> >>> Now if this was purely handled in ppc64 source code then I would be >>> happy to let them do whatever they like (surely this kills performance >>> though!). But I do not agree with the changes to the shared code that >>> allow this solution to be implemented - even with PPC64_ONLY this is >>> polluting the shared code. My concern is similar to what I said with the >>> taskQueue changes - these algorithms should be expressed using the >>> correct OrderAccess operations to guarantee the desired properties >>> independent of architecture. If such a "barrier" is not needed on a >>> given architecture then the implementation in OrderAccess should reduce >>> to a no-op. >>> >>> And as Vitaly points out the constructor barriers are not needed under >>> the JMM. >>> >>>> I am fine with suggested changes because you did not change our current >>>> code for our platforms (please, do not change do_exits() now). >>>> But may be it should be done using more general query which is set >>>> depending on platform: >>>> >>>> OrderAccess::needs_support_iriw_ordering() >>>> >>>> or similar to what we use now: >>>> >>>> VM_Version::needs_support_iriw_ordering() >>> >>> Every platform has to support IRIW this is simply part of the Java >>> Memory Model, there should not be any need to call this out explicitly >>> like this. >>> >>> Is there some subtlety of the hardware I am missing here? Are there >>> visibility issues beyond the ordering constraints that the JMM defines? >>>> From what I understand our ppc port is also affected. David? >>> >>> We can not discuss that on an OpenJDK mailing list - sorry. >>> >>> David >>> ----- >>> >>>> In library_call.cpp can you add {}? New comment should be inside else {}. >>>> >>>> I think you should make _wrote_volatile field not ppc64 specific which >>>> will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() >>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>> >>>> In do_put_xxx() can you combine your changes: >>>> >>>> if (is_vol) { >>>> // See comment in do_get_xxx(). >>>> #ifndef PPC64 >>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>> #else >>>> if (is_field) { >>>> // Add MemBarRelease for constructors which write volatile field >>>> (PPC64). >>>> set_wrote_volatile(true); >>>> } >>>> #endif >>>> } >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>> the torture test suite: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>> >>>>> Example: >>>>> volatile x=0, y=0 >>>>> __________ __________ __________ __________ >>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>> >>>>> write(x=1) read(x) write(y=1) read(y) >>>>> read(y) read(x) >>>>> >>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>> >>>>> >>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>> assured by the sync instruction and if it is executed in the threads >>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>> MemBarVolatile happens to be implemented by sync. >>>>> We fix this in C2 and the cpp interpreter. >>>>> >>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>> fails on staxf" for taskqueue.hpp. >>>>> >>>>> Further this change contains a fix that assures that volatile fields >>>>> written in constructors are visible before the reference gets >>>>> published. >>>>> >>>>> >>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>> strong. >>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>> What do you think? >>>>> >>>>> Please review and test this change. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> From vitalyd at gmail.com Wed Nov 27 17:25:33 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 27 Nov 2013 20:25:33 -0500 Subject: RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes In-Reply-To: <52968167.4050906@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE6883E@DEWDFEMB12A.global.corp.sap> <5293F087.2080700@oracle.com> <5293FE15.9050100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C4C5@DEWDFEMB12A.global.corp.sap> <52948FF1.5080300@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6C554@DEWDFEMB12A.global.corp.sap> <5295DD0B.3030604@oracle.com> <4295855A5C1DE049A61835A1887419CC2CE6CE61@DEWDFEMB12A.global.corp.sap> <52968167.4050906@oracle.com> Message-ID: Just want to say (as I did on the c-i thread) that having to emit a fence for non pre zeroing implementations would need to happen for normal fields as well, so I don't even see how that part is at all relevant to volatiles. Sent from my phone On Nov 27, 2013 6:35 PM, "David Holmes" wrote: > TL;DR version: > > Discussion on the c-i list has now confirmed that a constructor-barrier > for volatiles is not required as part of the JMM specification. It *may* be > required in an implementation that doesn't pre-zero memory to ensure you > can't see uninitialized fields. So the tests for this are invalid and this > part of the patch is not needed in general (ppc64 may need it due to other > factors). > > Re: "multiple copy atomicity" - first thanks for correcting the term :) > Second thanks for the reference to that paper! For reference: > > "The memory system (perhaps involving a hierarchy of buffers and a complex > interconnect) does not guarantee that a write becomes visible to all other > hardware threads at the same time point; these architectures are not > multiple-copy atomic." > > This is the visibility issue that I referred to and affects both ARM and > PPC. But of course it is normally handled by using suitable barriers after > the stores that need to be visible. I think the crux of the current issue > is what you wrote below: > > > The fixes for the constructor issue are only needed because we > > remove the sync instruction from behind stores (parse3.cpp:320) > > and place it before loads. > > I hadn't grasped this part. Obviously if you fail to do the sync after the > store then you have to do something around the loads to get the same > results! I still don't know what lead you to the conclusion that the only > way to fix the IRIW issue was to put the fence before the load - maybe when > I get the chance to read that paper in full it will be clearer. > > So ... the basic problem is that the current structure in the VM has > hard-wired one choice of how to get the right semantics for volatile > variables. You now want to customize that but not all the requisite hooks > are present. It would be better if volatile_load and volatile_store were > factored out so that they could be implemented as desired per-platform. > Alternatively there could be pre- and post- hooks that could then be > customized per platform. Otherwise you need platform-specific ifdef's to > handle it as per your patch. > > I'm not happy with the ifdef approach but I won't block it. I think this > is an area where a lot of clean up is needed in the VM. The barrier > abstractions are a confused mess in my opinion. > > Thanks, > David > ----- > > On 28/11/2013 3:15 AM, Lindenmaier, Goetz wrote: > >> Hi, >> >> I updated the webrev to fix the issues mentioned by Vladimir: >> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >> >> I did not yet add the >> OrderAccess::needs_support_iriw_ordering() >> VM_Version::needs_support_iriw_ordering() >> or >> OrderAccess::cpu_is_multiple_copy_atomic() >> to reduce #defined, as I got no further comment on that. >> >> >> WRT to the validity of the tests and the interpretation of the JMM >> I feel not in the position to contribute substantially. >> >> But we would like to pass the torture test suite as we consider >> this a substantial task in implementing a PPC port. Also we think >> both tests show behavior a programmer would expect. It's bad if >> Java code runs fine on the more common x86 platform, and then >> fails on ppc. This will always first be blamed on the VM. >> >> The fixes for the constructor issue are only needed because we >> remove the sync instruction from behind stores (parse3.cpp:320) >> and place it before loads. Then there is no sync between volatile store >> and publishing the object. So we add it again in this one case >> (volatile store in constructor). >> >> >> @David >> >>> Sure. There also is no solution as you require for the taskqueue >>>> problem yet, >>>> and that's being discussed now for almost a year. >>>> >>> It may have started a year ago but work on it has hardly been continuous. >>> >> That's not true, we did a lot of investigation and testing on this issue. >> And we came up with a solution we consider the best possible. If you >> have objections, you should at least give the draft of a better solution, >> we would volunteer to implement and test it. >> Similarly, we invested time in fixing the concurrency torture issues. >> >> @David >> >>> What is "multiple-read-atomicity"? I'm not familiar with the term and >>> can't find any reference to it. >>> >> We learned about this reading "A Tutorial Introduction to the ARM and >> POWER Relaxed Memory Models" by Luc Maranget, Susmit Sarkar and >> Peter Sewell, which is cited in "Correct and Efficient Work-Stealing for >> Weak Memory Models" by Nhat Minh L?, Antoniu Pop, Albert Cohen >> and Francesco Zappa Nardelli (PPoPP `13) when analysing the taskqueue >> problem. >> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf >> >> I was wrong in one thing, it's called multiple copy atomicity, I used >> 'read' >> instead. Sorry for that. (I also fixed that in the method name above). >> >> Best regards and thanks for all your involvements, >> Goetz. >> >> >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 27. November 2013 12:53 >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >> Reads of Independent Writes >> >> Hi Goetz, >> >> On 26/11/2013 10:51 PM, Lindenmaier, Goetz wrote: >> >>> Hi David, >>> >>> -- Volatile in constuctor >>> >>>> AFAIK we have not seen those tests fail due to a >>>> missing constructor barrier. >>>> >>> We see them on PPC64. Our test machines have typically 8-32 processors >>> and are Power 5-7. But see also Aleksey's mail. (Thanks Aleksey!) >>> >> >> And see follow ups - the tests are invalid. >> >> -- IRIW issue >>> >>>> I can not possibly answer to the necessary level of detail with a few >>>> moments thought. >>>> >>> Sure. There also is no solution as you require for the taskqueue >>> problem yet, >>> and that's being discussed now for almost a year. >>> >> >> It may have started a year ago but work on it has hardly been continuous. >> >> You are implying there is a problem here that will >>>> impact numerous platforms (unless you can tell me why ppc is so >>>> different?) >>>> >>> No, only PPC does not have 'multiple-read-atomicity'. Therefore I >>> contributed a >>> solution with the #defines, and that's correct for all, but not nice, I >>> admit. >>> (I don't really know about ARM, though). >>> So if I can write down a nicer solution testing for methods that are >>> evaluated >>> by the C-compiler I'm happy. >>> >>> The problem is not that IRIW is not handled by the JMM, the problem >>> is that >>> store >>> sync >>> does not assure multiple-read-atomicity, >>> only >>> sync >>> load >>> does so on PPC. And you require multiple-read-atomicity to >>> pass that test. >>> >> >> What is "multiple-read-atomicity"? I'm not familiar with the term and >> can't find any reference to it. >> >> Thanks, >> David >> >> The JMM is fine. And >> >>> store >>> MemBarVolatile >>> is fine on x86, sparc etc. as there exist assembler instructions that >>> do what is required. >>> >>> So if you are off soon, please let's come to a solution that >>> might be improvable in the way it's implemented, but that >>> allows us to implement a correct PPC64 port. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Tuesday, November 26, 2013 1:11 PM >>> To: Lindenmaier, Goetz >>> Cc: 'Vladimir Kozlov'; 'Vitaly Davidovich'; ' >>> hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' >>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >>> Reads of Independent Writes >>> >>> Hi Goetz, >>> >>> On 26/11/2013 9:22 PM, Lindenmaier, Goetz wrote: >>> >>>> Hi everybody, >>>> >>>> thanks a lot for the detailed reviews! >>>> I'll try to answer to all in one mail. >>>> >>>> Volatile fields written in constructor aren't guaranteed by JMM to >>>>> occur before the reference is assigned; >>>>> >>>> We don't think it's correct if we omit the barrier after initializing >>>> a volatile field. Previously, we discussed this with Aleksey Shipilev >>>> and Doug Lea, and they agreed. >>>> Also, concurrency torture tests >>>> LongVolatileTest >>>> AtomicIntegerInitialValueTest >>>> will fail. >>>> (In addition, observing 0 instead of the inital value of a volatile >>>> field would be >>>> very counter-intuitive for Java programmers, especially in >>>> AtomicInteger.) >>>> >>> >>> The affects of unsafe publication are always surprising - volatiles do >>> not add anything special here. AFAIK there is nothing in the JMM that >>> requires the constructor barrier - discussions with Doug and Aleksey >>> notwithstanding. AFAIK we have not seen those tests fail due to a >>> missing constructor barrier. >>> >>> proposed for PPC64 is to make volatile reads extremely heavyweight >>>>> >>>> Yes, it costs measurable performance. But else it is wrong. We don't >>>> see a way to implement this cheaper. >>>> >>>> - these algorithms should be expressed using the correct OrderAccess >>>>> operations >>>>> >>>> Basically, I agree on this. But you also have to take into account >>>> that due to the different memory ordering instructions on different >>>> platforms >>>> just implementing something empty is not sufficient. >>>> An example: >>>> MemBarRelease // means LoadStore, StoreStore barrier >>>> MemBarVolatile // means StoreLoad barrier >>>> If these are consecutively in the code, sparc code looks like this: >>>> MemBarRelease --> membar(Assembler::LoadStore | >>>> Assembler::StoreStore) >>>> MemBarVolatile --> membar(Assembler::StoreLoad) >>>> Just doing what is required. >>>> On Power, we get suboptimal code, as there are no comparable, >>>> fine grained operations: >>>> MemBarRelease --> lwsync // Doing LoadStore, StoreStore, >>>> LoadLoad >>>> MemBarVolatile --> sync // // Doing LoadStore, StoreStore, >>>> LoadLoad, StoreLoad >>>> obviously, the lwsync is superfluous. Thus, as PPC operations are more >>>> (too) powerful, >>>> I need an additional optimization that removes the lwsync. I can not >>>> implement >>>> MemBarRelease empty, as it is also used independently. >>>> >>>> Back to the IRIW problem. I think here we have a comparable issue. >>>> Doing the MemBarVolatile or the OrderAccess::fence() before the read >>>> is inefficient on platforms that have multiple-read-atomicity. >>>> >>>> I would propose to guard the code by >>>> VM_Version::cpu_is_multiple_read_atomic() or even better >>>> OrderAccess::cpu_is_multiple_read_atomic() >>>> Else, David, how would you propose to implement this platform >>>> independent? >>>> (Maybe we can also use above method in taskqueue.hpp.) >>>> >>> >>> I can not possibly answer to the necessary level of detail with a few >>> moments thought. You are implying there is a problem here that will >>> impact numerous platforms (unless you can tell me why ppc is so >>> different?) and I can not take that on face value at the moment. The >>> only reason I can see IRIW not being handled by the JMM requirements for >>> volatile accesses is if there are global visibility issues that are not >>> addressed - but even then I would expect heavy barriers at the store >>> would deal with that, not at the load. (This situation reminds me of the >>> need for read-barriers on Alpha architecture due to the use of software >>> cache-coherency rather than hardware cache-coherency - but we don't have >>> that on ppc!) >>> >>> Sorry - There is no quick resolution here and in a couple of days I will >>> be heading out on vacation for two weeks. >>> >>> David >>> ----- >>> >>> Best regards, >>>> Goetz. >>>> >>>> -- Other ports: >>>> The IRIW issue requires at least 3 processors to be relevant, so it >>>> might >>>> not happen on small machines. But I can use PPC_ONLY instead >>>> of PPC64_ONLY if you request so (and if we don't get rid of them). >>>> >>>> -- MemBarStoreStore after initialization >>>> I agree we should not change it in the ppc port. If you wish, I can >>>> prepare an extra webrev for hotspot-comp. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Tuesday, November 26, 2013 2:49 AM >>>> To: Vladimir Kozlov >>>> Cc: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ' >>>> ppc-aix-port-dev at openjdk.java.net' >>>> Subject: Re: RFR(M): 8029101: PPC64 (part 211): ordering of Independent >>>> Reads of Independent Writes >>>> >>>> Okay this is my second attempt at answering this in a reasonable way :) >>>> >>>> On 26/11/2013 10:51 AM, Vladimir Kozlov wrote: >>>> >>>>> I have to ask David to do correctness evaluation. >>>>> >>>> >>>> From what I understand what we see here is an attempt to fix an >>>> existing issue with the implementation of volatiles so that the IRIW >>>> problem is addressed. The solution proposed for PPC64 is to make >>>> volatile reads extremely heavyweight by adding a fence() when doing the >>>> load. >>>> >>>> Now if this was purely handled in ppc64 source code then I would be >>>> happy to let them do whatever they like (surely this kills performance >>>> though!). But I do not agree with the changes to the shared code that >>>> allow this solution to be implemented - even with PPC64_ONLY this is >>>> polluting the shared code. My concern is similar to what I said with the >>>> taskQueue changes - these algorithms should be expressed using the >>>> correct OrderAccess operations to guarantee the desired properties >>>> independent of architecture. If such a "barrier" is not needed on a >>>> given architecture then the implementation in OrderAccess should reduce >>>> to a no-op. >>>> >>>> And as Vitaly points out the constructor barriers are not needed under >>>> the JMM. >>>> >>>> I am fine with suggested changes because you did not change our current >>>>> code for our platforms (please, do not change do_exits() now). >>>>> But may be it should be done using more general query which is set >>>>> depending on platform: >>>>> >>>>> OrderAccess::needs_support_iriw_ordering() >>>>> >>>>> or similar to what we use now: >>>>> >>>>> VM_Version::needs_support_iriw_ordering() >>>>> >>>> >>>> Every platform has to support IRIW this is simply part of the Java >>>> Memory Model, there should not be any need to call this out explicitly >>>> like this. >>>> >>>> Is there some subtlety of the hardware I am missing here? Are there >>>> visibility issues beyond the ordering constraints that the JMM defines? >>>> >>>>> From what I understand our ppc port is also affected. David? >>>>> >>>> >>>> We can not discuss that on an OpenJDK mailing list - sorry. >>>> >>>> David >>>> ----- >>>> >>>> In library_call.cpp can you add {}? New comment should be inside else >>>>> {}. >>>>> >>>>> I think you should make _wrote_volatile field not ppc64 specific which >>>>> will be set to 'true' only on ppc64. Then you will not need >>>>> PPC64_ONLY() >>>>> except in do_put_xxx() where it is set to true. Too many #ifdefs. >>>>> >>>>> In do_put_xxx() can you combine your changes: >>>>> >>>>> if (is_vol) { >>>>> // See comment in do_get_xxx(). >>>>> #ifndef PPC64 >>>>> insert_mem_bar(Op_MemBarVolatile); // Use fat membar >>>>> #else >>>>> if (is_field) { >>>>> // Add MemBarRelease for constructors which write volatile >>>>> field >>>>> (PPC64). >>>>> set_wrote_volatile(true); >>>>> } >>>>> #endif >>>>> } >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of >>>>>> the torture test suite: >>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/ >>>>>> >>>>>> Example: >>>>>> volatile x=0, y=0 >>>>>> __________ __________ __________ __________ >>>>>> | Thread 0 | | Thread 1 | | Thread 2 | | Thread 3 | >>>>>> >>>>>> write(x=1) read(x) write(y=1) read(y) >>>>>> read(y) read(x) >>>>>> >>>>>> Disallowed: x=1, y=0 y=1, x=0 >>>>>> >>>>>> >>>>>> Solution: This example requires multiple-copy-atomicity. This is only >>>>>> assured by the sync instruction and if it is executed in the threads >>>>>> doing the loads. Thus we implement volatile read as sync-load-acquire >>>>>> and omit the sync/MemBarVolatile after the volatile store. >>>>>> MemBarVolatile happens to be implemented by sync. >>>>>> We fix this in C2 and the cpp interpreter. >>>>>> >>>>>> This addresses a similar issue as fix "8012144: multiple SIGSEGVs >>>>>> fails on staxf" for taskqueue.hpp. >>>>>> >>>>>> Further this change contains a fix that assures that volatile fields >>>>>> written in constructors are visible before the reference gets >>>>>> published. >>>>>> >>>>>> >>>>>> Looking at the code, we found a MemBarRelease that to us, seems too >>>>>> strong. >>>>>> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice. >>>>>> What do you think? >>>>>> >>>>>> Please review and test this change. >>>>>> >>>>>> Best regards, >>>>>> Goetz. >>>>>> >>>>>> From gabriel.chivoiu at oracle.com Wed Nov 27 23:38:03 2013 From: gabriel.chivoiu at oracle.com (Gabriel Chivoiu) Date: Wed, 27 Nov 2013 23:38:03 -0800 (PST) Subject: JVM hotspot vs. JRockit In-Reply-To: References: Message-ID: Hi All, I need some help with respect to any sort of documentation/ presentation in terms of comparison between Hotspot JVM and JRockit JVM. Is there any convergence roadmap between Oracle's JVMs JRockit and Hotspot, that you are aware of? Particularly I am interested in a competent source which can provide me insights in topics like: . Brief overview of both JVMs, maybe sth like where they come from and a statement . why the two has been moved into one JVM? . Which parameters change, when the costumer coming from JRockit. . How can a customer "migrate" from JRockit to convergenced HotSpot JVM. What to keep in mind? How to approach this? . How to tune the new JVM, general, best practices, parameters. Thank you! Gabriel Chivoiu EMEA Presales Center Bangalore | Bucharest | Malaga Gabriel Chivoiu | Staff Sales Consulting Phone +4021 36 79172 Oracle EMEA Presales Center - Technology NUSCO TOWER, 11th Floor, 42 Pipera Street | 014254 Bucharest 2 | Romania Visit our website at HYPERLINK "http://epc.oraclecorp.com/"http://epc.oraclecorp.com Oracle is committed to developing practices and products that help protect the environment From markus.gronlund at oracle.com Thu Nov 28 05:13:44 2013 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Thu, 28 Nov 2013 13:13:44 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20131128131401.97D52628E9@hg.openjdk.java.net> Changeset: 19146c82b6fc Author: hseigel Date: 2013-11-21 14:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/19146c82b6fc 8028520: JVM should not throw VerifyError when a private method overrides a final method Summary: Exclude private methods when checking for final method override. Reviewed-by: kamg, coleenp, dholmes, mseledtsov ! src/share/vm/classfile/classFileParser.cpp Changeset: 260ac69dc096 Author: mgronlun Date: 2013-11-23 09:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/260ac69dc096 Merge Changeset: 86e6d691f2e1 Author: mgronlun Date: 2013-11-23 12:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/86e6d691f2e1 8028128: Add a type safe alternative for working with counter based data Reviewed-by: dholmes, egahlin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/gcTimer.cpp ! src/share/vm/gc_implementation/shared/gcTimer.hpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp ! src/share/vm/gc_implementation/shared/gcTraceTime.cpp ! src/share/vm/gc_implementation/shared/gcTraceTime.hpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/trace/noTraceBackend.hpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/traceBackend.hpp ! src/share/vm/trace/traceEvent.hpp ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceTime.hpp ! src/share/vm/trace/traceTypes.xsl ! src/share/vm/trace/tracetypes.xml + src/share/vm/utilities/ticks.cpp + src/share/vm/utilities/ticks.hpp + src/share/vm/utilities/ticks.inline.hpp Changeset: 22eaa15b7960 Author: hseigel Date: 2013-11-26 09:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22eaa15b7960 8026065: InterfaceMethodref for invokespecial must name a direct superinterface Summary: Add verification to check that invokespecial of an InterfaceMethodref names a method in a direct superinterface of the current class or interface in accordance with JSR 335, JVMS 4.9.2 Structural Constraints. Reviewed-by: acorn, hseigel, coleenp Contributed-by: lois.foltan at oracle.com ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: e567d5afd4dd Author: hseigel Date: 2013-11-26 16:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e567d5afd4dd 8028160: [TESTBUG] Exclude failing (runtime) jtreg tests using @ignore Summary: Use @ignore to exclude failing tests Reviewed-by: coleenp, ctornqvi, mseledtsov Contributed-by: george.triantafillou at oracle.com ! test/runtime/6626217/Test6626217.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/InitialThreadOverflow/testme.sh ! test/runtime/LoadClass/LoadClassNegative.java ! test/runtime/XCheckJniJsig/XCheckJSig.java ! test/runtime/jsig/Test8017498.sh ! test/runtime/memory/ReadFromNoaccessArea.java From john.coomes at oracle.com Thu Nov 28 10:31:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:31:30 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b118 for changeset d6820a414f18 Message-ID: <20131128183134.11F02628FE@hg.openjdk.java.net> Changeset: 5029f982dfae Author: cl Date: 2013-11-28 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5029f982dfae Added tag jdk8-b118 for changeset d6820a414f18 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:31:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:31:41 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b118 for changeset e4e5069250e7 Message-ID: <20131128183153.E0040628FF@hg.openjdk.java.net> Changeset: 6b37ae056340 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/6b37ae056340 Added tag jdk8-b118 for changeset e4e5069250e7 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:31:22 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:31:22 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b118 for changeset 0a6db1aac998 Message-ID: <20131128183122.67871628FD@hg.openjdk.java.net> Changeset: 06d512d44c31 Author: cl Date: 2013-11-28 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/06d512d44c31 Added tag jdk8-b118 for changeset 0a6db1aac998 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:32:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:32:00 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b118 for changeset 76a598cf50c4 Message-ID: <20131128183208.A102C62900@hg.openjdk.java.net> Changeset: 7ac7d1afd966 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/7ac7d1afd966 Added tag jdk8-b118 for changeset 76a598cf50c4 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:32:26 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:32:26 +0000 Subject: hg: hsx/hotspot-main/jdk: 4 new changesets Message-ID: <20131128183432.38A9962901@hg.openjdk.java.net> Changeset: 6c1f5c7baab0 Author: ksrini Date: 2013-11-21 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c1f5c7baab0 8028645: [infra] purge applet demos from the Solaris distros Reviewed-by: erikj ! makefiles/CompileDemos.gmk Changeset: 66c98bd811f1 Author: rgallard Date: 2013-11-25 20:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/66c98bd811f1 8029043: Update nroff files for JDK 8 Reviewed-by: weijun, alanb, ksrini, naoto ! src/bsd/doc/man/appletviewer.1 ! src/bsd/doc/man/extcheck.1 ! src/bsd/doc/man/idlj.1 ! src/bsd/doc/man/jar.1 ! src/bsd/doc/man/jarsigner.1 ! src/bsd/doc/man/java.1 ! src/bsd/doc/man/javac.1 ! src/bsd/doc/man/javadoc.1 ! src/bsd/doc/man/javah.1 ! src/bsd/doc/man/javap.1 + src/bsd/doc/man/jcmd.1 ! src/bsd/doc/man/jconsole.1 ! src/bsd/doc/man/jdb.1 + src/bsd/doc/man/jdeps.1 ! src/bsd/doc/man/jhat.1 ! src/bsd/doc/man/jinfo.1 + src/bsd/doc/man/jjs.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/jstat.1 ! src/bsd/doc/man/jstatd.1 ! src/bsd/doc/man/keytool.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/wsgen.1 ! src/bsd/doc/man/wsimport.1 ! src/bsd/doc/man/xjc.1 ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/jcmd.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 + src/linux/doc/man/jdeps.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 + src/linux/doc/man/jjs.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/jcmd.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 + src/solaris/doc/sun/man/man1/jdeps.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 + src/solaris/doc/sun/man/man1/jjs.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: 28ca338366ff Author: rgallard Date: 2013-11-25 20:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28ca338366ff Merge Changeset: a1c49f8881ae Author: cl Date: 2013-11-28 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1c49f8881ae Added tag jdk8-b118 for changeset 28ca338366ff ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:41:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:41:00 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b118 for changeset 8d014b039b44 Message-ID: <20131128184106.6B29E62904@hg.openjdk.java.net> Changeset: b55a011cf8ae Author: cl Date: 2013-11-28 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/b55a011cf8ae Added tag jdk8-b118 for changeset 8d014b039b44 ! .hgtags From john.coomes at oracle.com Thu Nov 28 10:40:40 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 28 Nov 2013 18:40:40 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b118 for changeset 4fd6a7ff8c06 Message-ID: <20131128184051.7CE8A62902@hg.openjdk.java.net> Changeset: 1f6ffcd56363 Author: cl Date: 2013-11-28 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1f6ffcd56363 Added tag jdk8-b118 for changeset 4fd6a7ff8c06 ! .hgtags From mrblairarchibald at gmail.com Thu Nov 28 14:02:04 2013 From: mrblairarchibald at gmail.com (Blair Archibald) Date: Thu, 28 Nov 2013 22:02:04 +0000 Subject: Young Generation Heap Layout Message-ID: Hi, I'm experimenting with new methods of performing heap resizing (like Ergonomics/Adaptive size policy but with different principles/techniques). I'm working mainly with the ParallelScavenge GC/Heap and was wondering if there is a particular reason that the young generation needs to be in the form: Eden | To | From I would like to do some (fairly aggressive) Eden resizing so it would be beneficial to have a young generation as follows: To | From | Eden This provides the possibility of scaling the generation to provide free space at the end of eden. When I tried this however I got various issues with CompressedOOPs and when running without CompressedOOPs I get strange segfaults. Are there any particular areas where this space layout invariant needs to be enforced? Would it ever be possible to have a layout with eden at the end? Many thanks, Blair From Peter.B.Kessler at Oracle.COM Thu Nov 28 15:20:58 2013 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 28 Nov 2013 15:20:58 -0800 Subject: Young Generation Heap Layout In-Reply-To: References: Message-ID: <5297CFDA.8090308@Oracle.COM> I don't know of a reason that you couldn't reorder the spaces within the young generation. They are arranged that way for a reason similar to the one you are thinking of, but with respect to the heap as a whole. Long ago the heap used to be Eden | From | To | Old probably because that's the obvious way to do it and no one thought there were advantages to be had from different layouts. But then we wanted to resize the old generation, and the observation was that after a young generation collection the eden is almost always empty (always in some collectors), and after a compacting collection of the old generation the high end of the old generation is empty, so if we laid the heap out Old | Eden | From | To then we could move the boundary between Old and Eden. Are you thinking of doing something similar between from (empty after collections) and eden? Then you could move that boundary every other young generation collection. That is, when From is adjacent to Eden. But that happens even with the spaces laid out as they are, with To just above Eden. Now I'm curious as to what you are thinking about. It's convenient (read, performant) to have a single address comparison to tell you whether an oop is in the young generation or the old generation, and within the young generation whether it is in Eden or one of the survivor spaces. It doesn't seem like you'd make those less efficient. ... peter On 2013/11/28 14:02, Blair Archibald wrote: > Hi, > > I'm experimenting with new methods of performing heap resizing (like > Ergonomics/Adaptive size policy but with different principles/techniques). > > I'm working mainly with the ParallelScavenge GC/Heap and was wondering if > there is a particular reason that the young generation needs to be in the > form: > > Eden | To | From > > I would like to do some (fairly aggressive) Eden resizing so it would be > beneficial to have a young generation as follows: > > To | From | Eden > > This provides the possibility of scaling the generation to provide free > space at the end of eden. When I tried this however I got various issues > with CompressedOOPs and when running without CompressedOOPs I get strange > segfaults. > > Are there any particular areas where this space layout invariant needs to > be enforced? Would it ever be possible to have a layout with eden at the > end? > > Many thanks, > Blair > From tao.mao at oracle.com Thu Nov 28 18:07:31 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 28 Nov 2013 18:07:31 -0800 Subject: Young Generation Heap Layout In-Reply-To: <5297CFDA.8090308@Oracle.COM> References: <5297CFDA.8090308@Oracle.COM> Message-ID: <5297F6E3.10809@oracle.com> Use this link to clearly see the layout (ignore perm-gen part, it's gone) http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.generations Thanks. Tao On 11/28/13 3:20 PM, Peter B. Kessler wrote: > I don't know of a reason that you couldn't reorder the spaces within > the young generation. They are arranged that way for a reason similar > to the one you are thinking of, but with respect to the heap as a > whole. Long ago the heap used to be > > Eden | From | To | Old > > probably because that's the obvious way to do it and no one thought > there were advantages to be had from different layouts. But then we > wanted to resize the old generation, and the observation was that > after a young generation collection the eden is almost always empty > (always in some collectors), and after a compacting collection of the > old generation the high end of the old generation is empty, so if we > laid the heap out > > Old | Eden | From | To > > then we could move the boundary between Old and Eden. > > Are you thinking of doing something similar between from (empty after > collections) and eden? Then you could move that boundary every other > young generation collection. That is, when From is adjacent to Eden. > But that happens even with the spaces laid out as they are, with To > just above Eden. Now I'm curious as to what you are thinking about. > > It's convenient (read, performant) to have a single address comparison > to tell you whether an oop is in the young generation or the old > generation, and within the young generation whether it is in Eden or > one of the survivor spaces. It doesn't seem like you'd make those > less efficient. > > ... peter > > On 2013/11/28 14:02, Blair Archibald wrote: >> Hi, >> >> I'm experimenting with new methods of performing heap resizing (like >> Ergonomics/Adaptive size policy but with different >> principles/techniques). >> >> I'm working mainly with the ParallelScavenge GC/Heap and was >> wondering if >> there is a particular reason that the young generation needs to be in >> the >> form: >> >> Eden | To | From >> >> I would like to do some (fairly aggressive) Eden resizing so it would be >> beneficial to have a young generation as follows: >> >> To | From | Eden >> >> This provides the possibility of scaling the generation to provide free >> space at the end of eden. When I tried this however I got various issues >> with CompressedOOPs and when running without CompressedOOPs I get >> strange >> segfaults. >> >> Are there any particular areas where this space layout invariant >> needs to >> be enforced? Would it ever be possible to have a layout with eden at the >> end? >> >> Many thanks, >> Blair >> From mrblairarchibald at gmail.com Fri Nov 29 02:30:17 2013 From: mrblairarchibald at gmail.com (Blair Archibald) Date: Fri, 29 Nov 2013 10:30:17 +0000 Subject: Young Generation Heap Layout In-Reply-To: <5297F6E3.10809@oracle.com> References: <5297CFDA.8090308@Oracle.COM> <5297F6E3.10809@oracle.com> Message-ID: Hi, Thanks for all your help so far! So my idea was that we aren't scaling the boundary between old and young, (or eden and survivor as adaptive size seems to already do) but instead we would have the heap as follows: Old | S0 | S1 | Eden | where S0 starts at the low of the virtual space shown in: http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.generations Since Perm has been moved, we should be able to use the PSVirtualSpace::expand_by method (called by resize generations) to ask the OS for some extra virtual space at the end of the young gen i.e S0 | S1 | Eden | New Virtual Space Then we can scale into this new space. (eventually we scale it back down!) However as mentioned before I can't seem to place the young gen with Eden anywhere except virtual_space()->low() without a large amount of errors occurring (generally segfaults) and I'm wondering mainly why this would be the case? I hope this makes more sense! Many thanks, Blair On 29 November 2013 02:07, Tao Mao wrote: > Use this link to clearly see the layout (ignore perm-gen part, it's gone) > http://www.oracle.com/technetwork/java/javase/gc- > tuning-6-140523.html#par_gc.generations > > Thanks. > Tao > > > On 11/28/13 3:20 PM, Peter B. Kessler wrote: > >> I don't know of a reason that you couldn't reorder the spaces within the >> young generation. They are arranged that way for a reason similar to the >> one you are thinking of, but with respect to the heap as a whole. Long ago >> the heap used to be >> >> Eden | From | To | Old >> >> probably because that's the obvious way to do it and no one thought there >> were advantages to be had from different layouts. But then we wanted to >> resize the old generation, and the observation was that after a young >> generation collection the eden is almost always empty (always in some >> collectors), and after a compacting collection of the old generation the >> high end of the old generation is empty, so if we laid the heap out >> >> Old | Eden | From | To >> >> then we could move the boundary between Old and Eden. >> >> Are you thinking of doing something similar between from (empty after >> collections) and eden? Then you could move that boundary every other young >> generation collection. That is, when From is adjacent to Eden. But that >> happens even with the spaces laid out as they are, with To just above Eden. >> Now I'm curious as to what you are thinking about. >> >> It's convenient (read, performant) to have a single address comparison to >> tell you whether an oop is in the young generation or the old generation, >> and within the young generation whether it is in Eden or one of the >> survivor spaces. It doesn't seem like you'd make those less efficient. >> >> ... peter >> >> On 2013/11/28 14:02, Blair Archibald wrote: >> >>> Hi, >>> >>> I'm experimenting with new methods of performing heap resizing (like >>> Ergonomics/Adaptive size policy but with different >>> principles/techniques). >>> >>> I'm working mainly with the ParallelScavenge GC/Heap and was wondering if >>> there is a particular reason that the young generation needs to be in the >>> form: >>> >>> Eden | To | From >>> >>> I would like to do some (fairly aggressive) Eden resizing so it would be >>> beneficial to have a young generation as follows: >>> >>> To | From | Eden >>> >>> This provides the possibility of scaling the generation to provide free >>> space at the end of eden. When I tried this however I got various issues >>> with CompressedOOPs and when running without CompressedOOPs I get strange >>> segfaults. >>> >>> Are there any particular areas where this space layout invariant needs to >>> be enforced? Would it ever be possible to have a layout with eden at the >>> end? >>> >>> Many thanks, >>> Blair >>> >>> From thomas.schatzl at oracle.com Fri Nov 29 03:44:16 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Nov 2013 12:44:16 +0100 Subject: Young Generation Heap Layout In-Reply-To: References: <5297CFDA.8090308@Oracle.COM> <5297F6E3.10809@oracle.com> Message-ID: <1385725456.2843.87.camel@cirrus> Hi, On Fri, 2013-11-29 at 10:30 +0000, Blair Archibald wrote: > Hi, > > Thanks for all your help so far! > > So my idea was that we aren't scaling the boundary between old and young, > (or eden and survivor as adaptive size seems to already do) but instead we > would have the heap as follows: > > Old | S0 | S1 | Eden | > > where S0 starts at the low of the virtual space shown in: > http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#par_gc.generations > > Since Perm has been moved, we should be able to use the > PSVirtualSpace::expand_by method (called by resize generations) to ask the > OS for some extra virtual space at the end of the young gen i.e > > S0 | S1 | Eden | New Virtual Space As an alternative you could keep the current layout and add code that updates the virtual space members. Note that I am almost sure that some (C++) code contains copies of the virtual space values (base address/size, the size policies and the collector policies) and you have to update them. But this is the same problem than when you expand at high addresses. At least you do not need to dig into code generation when changing this in this way. > Then we can scale into this new space. (eventually we scale it back down!) > > However as mentioned before I can't seem to place the young gen with Eden > anywhere except virtual_space()->low() without a large amount of errors > occurring (generally segfaults) and I'm wondering mainly why this would be > the case? Generated (barrier) code assumes that the young generation is located before the old gen to distinguish between references from/to the old/young generation. You need to fix code generation. Thomas From stefan.johansson at oracle.com Fri Nov 29 05:26:10 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 29 Nov 2013 14:26:10 +0100 Subject: RFR: 8029329: tmtools tests fail with NPE (in the tool) when run with G1 and FlightRecorder Message-ID: <529895F2.5090205@oracle.com> Hi, Please review this fix for: https://bugs.openjdk.java.net/browse/JDK-8029329 Webrev: http://cr.openjdk.java.net/~sjohanss/8029329/webrev.00/ Summary: The iterator used by the SA for walking through G1s heap regions used the total number of regions as the limit for hasNext. This caused a NullPointerException when reaching the first unallocated region. Updated the SA to initialize the iterator with the currently allocated number of regions as limit instead. Testing: * Tested builds through JPRT * Ran vm.tmtools.testlist throught Aurora and observed no failures on the test I expected to pass. Thanks, Stefan From mikael.gerdin at oracle.com Fri Nov 29 06:57:29 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 29 Nov 2013 15:57:29 +0100 Subject: RFR: 8029329: tmtools tests fail with NPE (in the tool) when run with G1 and FlightRecorder In-Reply-To: <529895F2.5090205@oracle.com> References: <529895F2.5090205@oracle.com> Message-ID: <9571764.YSXFaManI1@mgerdin03> Stefan, On Friday 29 November 2013 14.26.10 Stefan Johansson wrote: > Hi, > > Please review this fix for: > https://bugs.openjdk.java.net/browse/JDK-8029329 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8029329/webrev.00/ Typo: + // uint _allocated_lenght Otherwise the change looks good. /Mikael > > Summary: > The iterator used by the SA for walking through G1s heap regions used > the total number of regions as the limit for hasNext. This caused a > NullPointerException when reaching the first unallocated region. Updated > the SA to initialize the iterator with the currently allocated number of > regions as limit instead. > > Testing: > * Tested builds through JPRT > * Ran vm.tmtools.testlist throught Aurora and observed no failures on > the test I expected to pass. > > Thanks, > Stefan From stefan.johansson at oracle.com Fri Nov 29 07:03:54 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 29 Nov 2013 16:03:54 +0100 Subject: RFR: 8029329: tmtools tests fail with NPE (in the tool) when run with G1 and FlightRecorder In-Reply-To: <9571764.YSXFaManI1@mgerdin03> References: <529895F2.5090205@oracle.com> <9571764.YSXFaManI1@mgerdin03> Message-ID: <5298ACDA.1060502@oracle.com> On 2013-11-29 15:57, Mikael Gerdin wrote: > Stefan, > > On Friday 29 November 2013 14.26.10 Stefan Johansson wrote: >> Hi, >> >> Please review this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8029329 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8029329/webrev.00/ > Typo: > + // uint _allocated_lenght Thanks for catching this Mikael. I will fix this before getting the change pushed, but won't post another webrev if nothing else needs to be fixed. Thanks, Stefan > > > Otherwise the change looks good. > > /Mikael > >> Summary: >> The iterator used by the SA for walking through G1s heap regions used >> the total number of regions as the limit for hasNext. This caused a >> NullPointerException when reaching the first unallocated region. Updated >> the SA to initialize the iterator with the currently allocated number of >> regions as limit instead. >> >> Testing: >> * Tested builds through JPRT >> * Ran vm.tmtools.testlist throught Aurora and observed no failures on >> the test I expected to pass. >> >> Thanks, >> Stefan From david.r.chase at oracle.com Fri Nov 29 10:56:06 2013 From: david.r.chase at oracle.com (david.r.chase at oracle.com) Date: Fri, 29 Nov 2013 18:56:06 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20131129185610.C312D6293E@hg.openjdk.java.net> Changeset: 9d15b81d5d1b Author: drchase Date: 2013-11-26 18:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9d15b81d5d1b 8016839: JSR292: AME instead of IAE when calling a method Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null. Reviewed-by: acorn, jrose, coleenp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klassVtable.cpp ! test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java ! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java + test/compiler/jsr292/methodHandleExceptions/p/C.java + test/compiler/jsr292/methodHandleExceptions/p/Dok.java + test/compiler/jsr292/methodHandleExceptions/p/E.java + test/compiler/jsr292/methodHandleExceptions/p/F.java + test/compiler/jsr292/methodHandleExceptions/p/I.java + test/compiler/jsr292/methodHandleExceptions/p/Tdirect.java + test/compiler/jsr292/methodHandleExceptions/p/Treflect.java Changeset: 2315fab779ca Author: drchase Date: 2013-11-29 11:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2315fab779ca Merge ! src/share/vm/classfile/systemDictionary.hpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java From alejandro.murillo at oracle.com Fri Nov 29 14:04:26 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 29 Nov 2013 22:04:26 +0000 Subject: hg: hsx/hsx25/hotspot: 11 new changesets Message-ID: <20131129220504.322DD62942@hg.openjdk.java.net> Changeset: e6dfcdf37ef2 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e6dfcdf37ef2 Added tag jdk8-b118 for changeset c9f439732b18 ! .hgtags Changeset: e51d73189692 Author: amurillo Date: 2013-11-22 13:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e51d73189692 8028815: new hotspot build - hs25-b61 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 19146c82b6fc Author: hseigel Date: 2013-11-21 14:41 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/19146c82b6fc 8028520: JVM should not throw VerifyError when a private method overrides a final method Summary: Exclude private methods when checking for final method override. Reviewed-by: kamg, coleenp, dholmes, mseledtsov ! src/share/vm/classfile/classFileParser.cpp Changeset: 260ac69dc096 Author: mgronlun Date: 2013-11-23 09:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/260ac69dc096 Merge Changeset: 86e6d691f2e1 Author: mgronlun Date: 2013-11-23 12:25 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/86e6d691f2e1 8028128: Add a type safe alternative for working with counter based data Reviewed-by: dholmes, egahlin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/gcTimer.cpp ! src/share/vm/gc_implementation/shared/gcTimer.hpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp ! src/share/vm/gc_implementation/shared/gcTraceTime.cpp ! src/share/vm/gc_implementation/shared/gcTraceTime.hpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/trace/noTraceBackend.hpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/traceBackend.hpp ! src/share/vm/trace/traceEvent.hpp ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceTime.hpp ! src/share/vm/trace/traceTypes.xsl ! src/share/vm/trace/tracetypes.xml + src/share/vm/utilities/ticks.cpp + src/share/vm/utilities/ticks.hpp + src/share/vm/utilities/ticks.inline.hpp Changeset: 22eaa15b7960 Author: hseigel Date: 2013-11-26 09:52 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22eaa15b7960 8026065: InterfaceMethodref for invokespecial must name a direct superinterface Summary: Add verification to check that invokespecial of an InterfaceMethodref names a method in a direct superinterface of the current class or interface in accordance with JSR 335, JVMS 4.9.2 Structural Constraints. Reviewed-by: acorn, hseigel, coleenp Contributed-by: lois.foltan at oracle.com ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: e567d5afd4dd Author: hseigel Date: 2013-11-26 16:03 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e567d5afd4dd 8028160: [TESTBUG] Exclude failing (runtime) jtreg tests using @ignore Summary: Use @ignore to exclude failing tests Reviewed-by: coleenp, ctornqvi, mseledtsov Contributed-by: george.triantafillou at oracle.com ! test/runtime/6626217/Test6626217.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/InitialThreadOverflow/testme.sh ! test/runtime/LoadClass/LoadClassNegative.java ! test/runtime/XCheckJniJsig/XCheckJSig.java ! test/runtime/jsig/Test8017498.sh ! test/runtime/memory/ReadFromNoaccessArea.java Changeset: 9d15b81d5d1b Author: drchase Date: 2013-11-26 18:16 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9d15b81d5d1b 8016839: JSR292: AME instead of IAE when calling a method Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null. Reviewed-by: acorn, jrose, coleenp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klassVtable.cpp ! test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java ! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java + test/compiler/jsr292/methodHandleExceptions/p/C.java + test/compiler/jsr292/methodHandleExceptions/p/Dok.java + test/compiler/jsr292/methodHandleExceptions/p/E.java + test/compiler/jsr292/methodHandleExceptions/p/F.java + test/compiler/jsr292/methodHandleExceptions/p/I.java + test/compiler/jsr292/methodHandleExceptions/p/Tdirect.java + test/compiler/jsr292/methodHandleExceptions/p/Treflect.java Changeset: 2315fab779ca Author: drchase Date: 2013-11-29 11:32 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2315fab779ca Merge ! src/share/vm/classfile/systemDictionary.hpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: b2426da30009 Author: amurillo Date: 2013-11-29 11:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b2426da30009 Merge - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: ce42d815dd21 Author: amurillo Date: 2013-11-29 11:10 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ce42d815dd21 Added tag hs25-b61 for changeset b2426da30009 ! .hgtags From alejandro.murillo at oracle.com Fri Nov 29 15:35:10 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 29 Nov 2013 23:35:10 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20131129233519.37D0462943@hg.openjdk.java.net> Changeset: e6dfcdf37ef2 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e6dfcdf37ef2 Added tag jdk8-b118 for changeset c9f439732b18 ! .hgtags Changeset: b2426da30009 Author: amurillo Date: 2013-11-29 11:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2426da30009 Merge - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: ce42d815dd21 Author: amurillo Date: 2013-11-29 11:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce42d815dd21 Added tag hs25-b61 for changeset b2426da30009 ! .hgtags Changeset: b6b9a5d4cda0 Author: amurillo Date: 2013-11-29 11:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b6b9a5d4cda0 8029367: new hotspot build - hs25-b62 Reviewed-by: jcoomes ! make/hotspot_version